This chapter describes sprints, the time-boxed iterations that Scrum uses to organize work.
Sprints are the skeleton of the Scrum framework.
Though each organization will have its own unique implementation of Scrum, the following sprint characteristics (with a few exceptions) should apply to every sprint and every team:
- All sprints are timeboxed, meaning they have a fixed start and end date.
- Generally speaking, sprints are consistently the same short length, somewhere between one week and one calendar month.
- As a rule, no goal-altering changes in scope or personnel are permitted during each sprint.
- At the end of each sprint, a potentially shippable product increment is created in accordance with the team's agreed-upon definition of done.
Sprints Are Timeboxed
Each sprint takes place in a time frame with specific start and end dates, called a timebox. Inside this timebox, the team is expected to work at a sustainable pace to complete a chosen set of work that aligns with a sprint goal. Timeboxing is important for several reasons, which are discussed below.
- Establishes a WIP Limit.
- Forces Prioritization.
- Demonstrates Progress.
- Avoids Unnecessary Perfectionism.
- Motivates Closure.
- Improves Predictability.
Sprints Are Short in Duration
Sprints are short in duration (between one week and one calendar month). Being of short duration is important for several reasons, which are discussed below.
- Ease of Planning. It is easier, and more accurate, to plan a few weeks' worth of work than six months' worth of work.
- Fast Feedback. During each sprint, Scrum teams create working software and then have the opportunity to inspect and adapt what they built and how they built it. This fast feedback enables teams to quickly identify and exploit emergent opportunities and prune unfavorable product paths or development approaches.
- Improved Return on Investment. Short sprints allow for early and more frequent deliverables, which gives companies the opportunity to generate revenue sooner, improving their overall return on investment. See Scrum Planning Principles: Chapter 14 for an example.
- Bounded Error. Scrum teams insist on short-duration sprints because they provide frequent coordination and feedback. That way, if something goes wrong, it at least goes wrong in a small way.
- Rejuvenated Excitement. Short sprints keep participant excitement high by delivering working assets frequently.
- Frequent Checkpoints. One valued aspect of a sequential (plan-driven or waterfall) project is a well-defined set of milestones, many of which are tied to go/no-go funding decisions. Scrum actually provides managers, stakeholders, product owners, and others with even more checkpoints (sprint reviews) to make decisions based on demonstrable working features.
Sprints Are a Consistent Duration
As a rule, Scrum teams should pick a consistent duration for their sprints and not change it for the duration of the development effort unless there is a compelling reason, such as a product release or holiday that falls outside the normal sprint duration. Not being able to complete the work inside the sprint is not a compelling reason to change the sprint length. These are symptoms of dysfunction and opportunities for improvement.
Consistent sprints provide a regular, predictable rhythm to the Scrum development effort. A regular cadence tends to level out the intensity of the work, reduces coordination overhead (such as meeting scheduling), and improves multi-team synchronization.
When all sprints are the same length, the team gets comfortable with the amount of work that it can accomplish in a typical sprint (its velocity), which helps them be more predictable. It also helps simplify the rest of the planning math, including determining the likely number of sprints in the release. For more on planning, read "The Math of Fixed-Scope Multi-team Release Planning."
No Goal-Altering Changes during Sprints
What Is a Sprint Goal?
A sprint goal describes the business purpose and value of the sprint. The sprint goal is the foundation of a mutual commitment made by the team and the product owner. The team commits to meeting the goal by the end of the sprint; the product owner commits to not altering the goal during the sprint.
Although the sprint goal should not be materially changed during a sprint, it can be clarified. Changes are alterations in work or resources that have the potential to generate waste, disrupt the flow of work, or increase the scope of work. A common example might be adding a product backlog item, or significantly expanding the scope of a product backlog item. Clarifications, on the other hand, are additional details provided to help the team achieve its sprint goal. It is completely reasonable for the team to ask clarifying questions about product backlog items during the sprint, and for the product owner to answer. An example of a clarifying question might be whether results should be sorted alphabetically or by type.
It might seem that the "no-goal-altering-changes rule" is in direct conflict with the core Scrum principle that we should embrace change. Remember that Scrum teams do embrace change, but in a balanced, economically sensible way. In other words, they must consider the economic consequences, the waste, associated with the change, which increases in relation to the level of investment in the changed work. For more on this, read the blog post "Economically Sensible Change." The economics can also be affected by the potential deterioration of team motivation and trust that can accompany a change.
With that being said, remember that the no-goal-altering-changes rule is a rule, not a law. If the economic consequences of making the change are far less than the economics consequences of deferring the change, making the change is the smart business decision. Making pragmatic decisions with Scrum is why it is so imperative to understand the agile principles behind the Scrum framework.
Should the sprint goal become completely invalid, the Scrum team may decide that continuing with the current sprint makes no sense and advise the product owner to abnormally terminate the sprint. When that happens, the sprint comes to an abrupt end and the Scrum team meets to perform a sprint retrospective. The Scrum team then meets with the product owner to plan the next sprint. Keep in mind that this is a serious disruption of the fast, flexible flow of features; as such, it should be a rare event that is used only when an economically significant event occurs that completely invalidates the sprint.
Sprints Have a Definition of Done
What Is the Definition of Done?
The definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be potentially shippable. That doesn't mean that the product must actually be shipped, rather that it has been completed to such a degree that it could be put into production. Most of the time, a bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented—and that would deliver validated customer value. Scrum teams need to have a robust definition of done, one that provides a high level of confidence that what they build is of high quality and can be shipped. Anything less robs the organization of the business opportunity of shipping at its discretion, and can lead to the accrual of technical debt, as discussed in Technical Debt & Scrum: Chapter 8.
Definition of Done Can Evolve Over Time
You can think of the definition of done as defining the state of the work at the end of the sprint. Many teams start out with a definition of done that doesn't end in a state where all features are completed to the extent that they could go live or be shipped. For some, real impediments might prevent them from reaching this state at the start of development, even though it is the ultimate goal. Some teams, then, might (necessarily) start with a lesser end state and let their definition of done build over time as impediments are removed. Read more about this topic in the blog "Changing the Definition of Done."
Definition of Done versus Acceptance Criteria
As discussed more fully in the next chapter, each product backlog item that is brought into a sprint should have a set of conditions of satisfaction (item-specific acceptance criteria), specified by the product owner. A product backlog item can be considered done only when both the item-specific acceptance criteria and the sprint-level definition of done have been satisfied.
Teams shouldn't need two different concepts to specify an item's degree of completeness, done and done-done—Done should mean done. If your team is using done-done, gradually wean them off this crutch to the point where done means meets the acceptance criteria and the definition of done.
Related blog content includes "Nonfunctional Requirements and Your Definition of Done" and "Done-Done: The Crutch of the Undone."
Sprints in Scrum Summary
Sprints play a crucial role in the Scrum framework. They are the skeleton on which most other activities and artifacts are placed. The next chapter will focus on inputs to sprints: user stories and requirements.