The Scrum Guide – 2020
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality does not decrease;
- The Product Backlog is refined as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
© 2020 Ken Schwaber and Jeff Sutherland
Commentary
The Scrum Sprint is indeed an iteration having certain defined characteristics and a name peculiar to Scrum. While most agile frameworks are incremental and iterative, there are subtle differences. (For an example, see the classic eXtreme Programming introduction.)
Length: the definition gives us the maximum length, only. There is no minimum length. In practice, it is very likely that 1-week or shorter is only viable in a DevOps environment. The most popular length is 2 weeks – long enough not to be too disruptive, short enough for reliable forecasting and for allowing a change of direction.
Sprints follow one another without gaps. There are two strong practical reasons to keep ourselves to this rule:
- Scrum has a ‘cadence’. If the length, the start and the end of the Sprints are arbitrary, the process becomes very difficult to follow.
- A pause between the iterations is basically a waste. What would justify stopping the production process?
People new to Scrum often wonder whether it is possible to go live with a product anytime. The answer is yes, the Sprint and the release are not necessarily connected. The outcome of the Sprint is a usable, potentially releasable increment, however, the release itself can happen any time, earlier or later:
- For many organizations, change management is a rigorous process that involves multiple organizational functions. As a consequence, in a complex environment, it is typical to go live with a package that is completely unrelated to any Sprint.
- For teams working on small bodies of work that should go live fast and independently from one another (such as in continuous deployment), waiting for the end of the Sprint is not an option. These teams handle all small pieces as little increments but still plan and monitor their progress through Sprints.
In the early times of Scrum, Sprints were typically 1 month long. Cancellation was a dramatic event, just like calling off a project. Today, when Sprints tend to be 2 weeks long or even less, this is rather just an opportunity to reconsider whether the efforts spent on a particular piece of work are still worth it. The consequences of the cancellation are common sense, the work Done and not Done is handled as usual. However, considering the exceptional circumstances leading to the cancellation, a team may make unusual decisions better fitting their situation. In the end, cancellation is so rare that it is enough to know that it is the Product Owner who should say the final word on it.
The Story of the Sprint Zero
Scrum.org does not endorse the concept of the Sprint Zero. We plan our Sprints with the goal of implementing working solutions. No increment, no Sprint. If the team is working on setting up the development environment and elaborating the product vision, that is not a Sprint. Others insist that ‘zero’ clarifies that the scope of the work is preparation for the first Sprint, therefore there is no point in banning an expression on semantic grounds. However, since Scrum.org decides about the exam questions, this settles the debate.
The Scrum Guide – 2017
The Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
- No changes are made that would endanger the Sprint Goal;
- Quality goals do not decrease; and,
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
The Sprint
A Sprint is an iteration. Sprints are time-boxed. During the Sprint, the ScrumMaster ensures that no changes are made that would affect the Sprint Goal. Both Team composition and quality goals remain constant throughout the Sprint. Sprints contain and consist of the Sprint Planning meeting, the development work, the Sprint Review, and the Sprint Retrospective. Sprints occur one after another, with no time in between Sprints.
A project is used to accomplish something; in software development, it is used to build a product or system. Every project consists of a definition of what is to be built, a plan to build it, the work done according to the plan, and the resultant product. Every project has a horizon, which is to say the time frame for which the plan is good. If the horizon is too long, the definition may have changed, too many variables may have entered in, the risk may be too great, etc. Scum is a framework for a project whose horizon is no more than one month long, where there is enough complexity that a longer horizon is too risky. The predictability of the project has to be controlled at least each month, and the risk that the project may go out of control or become unpredictable is contained at least each month.
Tip
If the Team senses that it has overcommitted, it meets with the Product Owner to remove or reduce the scope of Product Backlog selected for the Sprint. If the Team senses that it may have extra time, it can work with the Product Owner to select additional Product Backlog.Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Team, or the ScrumMaster. Under what kind of circumstances might a Sprint need to be cancelled? Management may need to cancel a Sprint if the Sprint Goal becomes obsolete. This could occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. However, because of the short duration of Sprints, it rarely makes sense to do so.
When a Sprint is cancelled, any completed and “done” Product Backlog items are reviewed. They are accepted if they represent a potentially shippable increment. All other Product Backlog items are put back on the Product Backlog with their initial estimates. Any work done on them is assumed to be lost. Sprint terminations consume resources, since everyone has to regroup in another Sprint planning meeting to start another Sprint. Sprint terminations are often traumatic to the Team, and they are very uncommon.
Tip
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved
When a Team begins Scrum, two-week Sprints allow it to learn without wallowing in uncertainty. Sprints of this length can be synchronized with other Teams by adding two increments together.
Let’s take a closer look at this sentence:
All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
Note that Product Backlog items do not become Sprint Backlog items when we add them to the Sprint Backlog. This is an over-explanation just to state that we do not somehow transform or lose Product Backlog items during the Sprint, something either becomes an Increment and a part of the product or remains a Product Backlog item.
“Note that Product Backlog Items do not become Sprint Backlog Items when we add them to the Sprint Backlog.”
I had to re-read this 5 times in order to understand it. Thank you! I did not understand this previously.