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.
The following sections explore each of these characteristics in more detail.
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
Because in each sprint Scrum teams plan to work only on those items that they believe they can start and finish within the sprint, timeboxing limits the amount of work in process (WIP).
Timeboxes forces team to prioritize and perform the small amount of work that matters most.
Teams must complete and validated all of the work of the sprint by the end of the sprint. This helps shift the focus away from unreliable forms of progress reporting, such as conformance to a plan, and also helps to demonstrate progress against big features that might require more than one timebox to complete. It also helps the stakeholders and teams learn exactly what remains to be done to deliver the entire feature.
Avoids Unnecessary Perfectionism
Timeboxing forces an end to potentially unbounded work, such as gold plating, by establishing a fixed end date for the sprint by which a good solution must be complete.
The hard deadline at the end of the sprint creates a sense of urgency to complete the job, encouraging team members to diligently apply themselves to complete the work on time,
Although we cannot predict with much certainty exactly the work a Scrum team will complete a year from now, it is completely reasonable to expect that a team can predict the work it can complete during the next short-duration sprint.
Ease of Planning
It is easier, and more accurate, to plan a few weeks' worth of work than six months' worth of work.
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 Chapter 14 for an example.
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.
It is natural for interest and excitement to decline the longer one has to wait for gratification, especially when there is no visible progress and no end in sight. Short sprints keep participant excitement high by delivering working assets frequently.
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.
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. Doing so leverages the benefits of cadence and simplifies planning. 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
What Is a Sprint Goal?
Each sprint can be summarized by a sprint goal that 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 alterning the goal during the sprint.
Change versus Clarification
Although the sprint goal should not be materially changed, 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.
Consequences of Change
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.
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 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. For example, suppose a team is building software and doesn't have the actual hardware on which to test the software; it can't really claim that the results produced at the end of the sprint are potentially shippable. Some teams, then, might (necessarily) start with a lesser end state and let their definition of done build over time as impediments are removed.
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. These acceptance criteria eventually will be verified in acceptance tests. 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.
Done versus Done-Done
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 play a crucial role in the Scrum framework. They are the skeleton on which most other activities and artifacts are placed. Keep them short, timeboxed, and consistent in duration. Identify a sprint goal, which shouldn't change without good economic cause. By the end of every sprint, teams should produce potentially shippable product increment that is completed according to a commonly accepted definition of done. The next chapter will focus on inputs to sprints: user stories and requirements.