The first of the Scrum events is the Sprint. It is unlike the others because it is a “container” event . All the other events happen within the Sprint and its time-box.
More than anything else, the Sprint is a time-box. It divides ongoing work into discrete pieces that are no more than 30 days long. At the beginning of each sprint, there is a sprint planning meeting during which the goals of the sprint’s work are agreed on. At the end of the sprint, there is a review of the accomplishments that were made and a discussion of lessons learned. After a sprint ends, a new one begins and the cycle repeats.
The most basic purpose the Sprint serves has to do with the theory of Empirical Process Control. The theory holds that all decisions must be based on measurements rather than predictions. By dividing up work into “iterations,” it becomes possible to measure the amount of work that can be done over time. If we measure the PBIs completed during a sprint, we can get a measurement of the Scrum team’s velocity—its ability to get things done. If we measure the team’s velocity, we get a statistic we can use for forecasting completion of future work.
Another important purpose of the Sprint is to provide focus for the team. At the beginning of each sprint, there is a meeting during the scope of the sprint is agreed on by all parties. That agreement stays in effect for the duration of the sprint unless all parties agree to change it. This agreement allows the team to focus on the agreed-on priorities and to ignore other demands or requests. Priorities may change drastically by the time the next sprint begins, but for the life of the current sprint, the team focuses exclusively on what was agreed on at the beginning of the sprint.
The sprint cycle has been likened to a heartbeat for the Scrum Framework. Each cycle takes in a number of PBIs in the beginning and pumps out product features in the end. Too many chaotic scope changes may cause something similar to Ventricular fibrillation, during which the heart tries to beat too fast and can’t pump any blood. Too many priorities may mean that none get addressed properly. The focus provided by the Sprint cycle allows the team to focus on producing rather than reacting.
The fact that the Sprint is a measurement device leads to a number of important rules for sprints.
Sprints Are Continuous and Contiguous : They Keep on Going and There Is No “in Between”
In order for sprints to be useful in measuring a team’s ability to get PBIs implemented, all the work the team does must be included in the measurement. If the team’s purpose is to create a product, then everything it does is part of that job. Everything it does must be measured to figure out the capacity of the team.
A team’s velocity is defined as how much of the Product Backlog it implements during a sprint. That information is vital to the Development Team members for forecasting their ability to deliver scope in a sprint. They need to be able to make this forecast to negotiate a sprint scope with the Product Owner.
The team’s velocity is also important to the Product Owner. The accuracy of the velocity measurement is vital for making forecasts of future delivery dates of the various features in the Product Backlog.
If sprints were not contiguous (meaning, there is some time in between sprints), then the amount of work needed to create PBIs would not be captured completely within the velocity measurement. Whatever work happened in that “in between” time is hidden and not measured.
For a sprint to be able to measure a team’s velocity accurately, it must include all the work the team does. All of the team’s work must happen within a sprint. There must be no “in between” time.
Sprints Must All Produce “Done” Increments of Product
The Scrum Guide states that the purpose of a sprint is to produce a done increment of product . In other words, whatever is produced during a sprint must be ready to give to a client with no further work required.
In practice, this can be a high threshold to meet. Teams that have not organized themselves very effectively sometimes complete only part of the work needed before the product increment can be given to a client. They point out correctly that they have expended a good deal of effort on the increment even though it is not ready to give to a customer. They ask why that effort “should not “count.”
The answer to that question is a different question: How can incomplete work be measured at all?
If someone says the PBI is 90% complete, what does that mean?
- 1.
The work is not done.
- 2.
The amount of work remaining is a guess, and that guess is probably wrong.
It is not possible to measure something that has not happened yet. There is no way to measure the work that is yet to be done and determine that it is 10% of the total. (I have had many instances of a subordinate saying the work was “90% done” after one week and “92% done” after a second week.)
The work product of a sprint must be “done” before it can be measurable. That is why The Scrum Guide defines “done” as no further work required. The work of implementing a PBI can only be measured when there is no further work required to do. Only then can the measurement “count” toward understanding the team’s velocity.
Once Agreed To, the Length of the Sprint Should Not Be Changed
The Scrum Guide states that sprints may be no longer than 30 calendar days, but may be shorter. It gives no further restrictions on the lengths of sprints.
In practice, the lengths of sprints are negotiated between Product Owners and Development Teams based on their interests. Product Owners value the transparency of the product that comes at the end of each sprint, and also the ability to change priorities, which comes at the beginning of each new sprint. The Development Team tends to value the stability and focus that exist between the beginning and the end of a sprint. Thus, the Product Owner values “short” sprints and the Development Team values “long sprints.” They end up negotiating a compromise at the beginning of the product’s life. They stick to this compromise unless there is some drastic change that warrants scrapping the agreement and starting over.
Some people think, mistakenly, that sprints are actually deadlines for getting work done. I have heard some Product Owners tell Development Teams they will “hold the sprint open” a few extra days so the team can meet the deadline.
Sprints are not deadlines. They are measuring tools . They are needed for teams to measure what they can get done during a fixed period of time.
If a Product Owner “holds open” a sprint so the team can complete everything, this distorts any measurements that might have been made. The Sprint is a yardstick for measuring the amount of results that are produced within it. “Holding the sprint open” is like using a yardstick made from rubber. Stretching it to make things fit results in a lack of accuracy and a lack of understanding about what the team’s actual velocity is.
Every Sprint Is Like Every Other Sprint; There Are No “Special” Sprints
Some people give names to certain sprints, implying they are somehow different from other sprints. One such sprint is the so-called Sprint 0. Another is the hardening sprint.
Sprint 0 (it is claimed) is a different sort of sprint. Its purpose is to “get things ready” so the team can start sprinting effectively afterward. It comes at the very beginning of a project and is in some ways analogous to the idea of Gate 0 in the PMI SDLC framework.
Sprint 0 has the same fundamental structure as any other sprint. It starts with a sprint planning meeting where the Product Backlog is reviewed and a scope is agreed on. The scope is then worked by the team members, who use daily scrum meetings to manage their progress. At the end, there is a sprint review of what has been completed and a sprint retrospective to identify lessons learned. Any item that was not completed is put back into the product backlog and the process repeats.
The so-called Sprint 0 does not differ from any other sprint as far as its structure is concerned. It only differs because of the kinds of goals that are to be met. Measuring the team’s ability to get things done does not depend on the kinds of problems they are solving.
The Hardening Sprint is another idea that makes little sense in the context of the Sprint as a measuring tool. It is a sprint in which no new PBIs are attempted. It is just a sprint in which previous work is refactored, shortcuts are reworked, and messy code is “cleaned up .” The proponents of hardening sprints recommend that every third or fourth sprint be devoted to these “hardening” activities .
As noted previously, it makes no sense to try to measure work that is not complete. If hardening activities are necessary, does that mean the work done on the hardened items in previous sprints was not complete? Does the velocity recorded from those previous sprints have any accuracy?
Another conundrum is how to measure the impact of the hardening sprint on the team’s measured velocity. Clearly the work done on the items in the original sprints was not complete, so efforts during the hardening sprint should be added in to calculate velocity. But which efforts? There is no requirement that a hardening sprint fix only those problems left over from sprints since the previous hardening sprint. There is also no guarantee that all the issues can be fixed in only one hardening sprint. The hardening sprint is just some extra time for the team to work on some things that should have been completed in the first place.
Hardening Sprints ruin a team’s ability to measure its velocity. The need for them comes from teams that feel pressure to accomplish more than they are able to accomplish. They take shortcuts to make it appear the work has been completed, but then use the mechanism of the Hardening Sprint to really finish the work. (Or not.)
Hardening Sprints cause significant problems in exchange for little (if any) benefit. It is better to finish a PBI completely during its original sprint and then measure the actual velocity achieved by the team. Only then will the statistic make any real sense.
The Definition of “Done ”
The requirement to finish every Product Backlog Item during a sprint leads to some interesting questions. When is a PBI finished? When we say it is done, what does done mean?
In the Scrum Framework, the word done means “ready to give to a customer with no further work required.” To determine that no further work is required, it is helpful to understand the kinds of tasks to be performed so that, in the end, the product is ready to give to a customer.
This definition of done can be slippery if not spelled out formally. Everyone tends to view done from the point of view of their own contribution rather than from the point of view of the customer. A programmer says the work is done when the programing is complete. A tester says the work is done when the testing is complete. A customer says the work is done when the product can be used by the customer as the customer expects.
Within the Scrum Framework the Development Team is accountable for creating the product. All team members must understand what done means from the point of view of the customer, and must accept responsibility for delivering done increments.
The definition of done within the Scrum Framework captures a shared understanding of what it means for an increment to be ready to give to a customer. It often takes the form of a checklist of tasks the development team must blend into its Sprint Backlog.
Using a formal definition of done helps make sure completed items at the end of a sprint really do require no further work before they are given to a customer. This makes them measurable and relevant to understanding the team’s ability to get things done. This in turn makes progress on working the Product Backlog clearer and more uniform, and—above all—results in a more reliable forecast.
Summary
Sprints are a key element of the Scrum Framework because they provide a way to measure the work that is being done. At the end of a specific period of time (in other words, the Sprint time-box), it is possible to see what has been accomplished and thus get an idea of what can be accomplished over time.
To be measurable, the work in a sprint must be done. In other words, no further work is required before the product is given to a customer. A definition of done is often used to identify the standard tasks that need to be performed before the product is ready for customer use.
The amount of done work the team can produce in a sprint is called the team’s velocity. Understanding the team’s velocity gives clarity about what can be expected from the team in the future. Applying the measured velocity of a team to the sizes of PBIs in the product backlog gives a way to forecast delivery dates in an empirical way—that is, based on measured facts rather than guesswork.