Sprints in Scrum: Chapter 4

This chapter describes sprints, the time-boxed iterations that Scrum uses to organize work.

Sprints Overview

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

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. Read the blog post “No Goal-Altering Changes During Sprints” to learn more about this Scrum rule. 

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.

Innolution offers many courses, including Certified ScrumMaster and Certified Product Owner courses, that delve into sprints in much more detail. View all Scrum training offerings from Innolution.