The value stream

The Sprint

A weekly newspaper comes out on Thursday, whether the week has been rich or poor in news. The date does not move, and it is the content that adjusts. Scrum organizes work in the same way, in fixed-length periods called Sprints. This article presents the patterns that describe the Sprint, its goal, the production period it protects and the rhythm it sets.

A fixed length, a content that adjusts

In A Scrum Book (2019), Jeff Sutherland, James Coplien and their co-authors describe Scrum through patterns, that is, proven solutions to recurring problems, presented with the forces that pull against them. The Sprint pattern starts from three observations. In complex work, the team always runs the risk of solving the wrong problem, and only frequent feedback limits that risk. A team does not settle into regular delivery without a cadence, and people need markers to see that they are making progress. Finally, the Product Backlog, the ordered list of everything still to be done, is suited to looking far ahead, but the Developers, the people who do the work, must at some point focus on a slice of that list and see it through.

The solution is to "organize development around recurring, frequent, fixed-length, time-boxed intervals called Sprints." The Sprint is both a duration, during which the team produces, and a cadence, which marks out the calendar. Its maximum length is one month. The authors note that two weeks has become the dominant practice. Drawing on Donald Reinertsen (The Principles of Product Development Flow, 2009), they add that a regular cadence prevents deviations from building up from one period to the next.

Every Sprint follows the same course. It opens with Sprint Planning, where the team chooses a goal and builds its plan. Then comes the production period, punctuated each day by the Daily Scrum. It ends with the Sprint Review, where the product is examined, and then the Sprint Retrospective, where the team examines its way of working.

The authors suggest seeing the Sprint in three ways. It is a unit of time, and therefore of cost, since a stable team costs the same amount each Sprint. It is a unit of delivery, which produces an Increment, that is, a usable and enriched version of the product. It is also a unit of learning, like a weekly piano lesson.

One rule in the pattern allows no exception. In the authors' words, "When the Sprint is over, it is over": a Sprint is never extended to finish work in progress. The authors present this boundary as a space that the Developers manage themselves, and not as a way of hurrying them.

The Sprint Goal gives the reason for the work

Following a list of tasks does not guarantee that value is being created. That is the problem of the Sprint Goal pattern. When the plan is only a list, everyone takes their own line and works alone, and the team loses what its members would bring one another by working together. The plan also does not survive the Sprint intact: unforeseen work appears, or it becomes clear that not everything will be finished. The team then needs to replan quickly, and to do so it needs a criterion.

The solution is for the Scrum Team (the Developers, the Product Owner and the Scrum Master) to commit to a short statement of the value it wants to create during the Sprint, and for all the work to relate to it. The goal is formulated together, led by the Product Owner, the person accountable for the value of the product. The Developers must be able to explain how they will reach it, and the statement stays on display. The authors credit Ken Schwaber and Mike Beedle with the first description of the Sprint Goal, in 2001.

A fractions pathway. Four math teachers at a lower secondary school work in two-week Sprints to build practice pathways. Their Sprint Goal is this: "By the end of the two weeks, first-year students (aged 11) can practice fractions on their own with a pathway tested in one class." Their plan includes an initial assessment, six progressive worksheets, the answer keys and a trial in one first-year class.

On the Wednesday of the second week, one of the teachers is out for three days. The six worksheets will not be ready. The team goes back to the goal and asks what is essential for students to practice on their own on a tested pathway. It keeps the assessment, the first four worksheets, their answer keys and the classroom trial. The two extension worksheets go back into the list of work to come. On Friday, the goal has been reached even though the original plan has not.

Jeff Sutherland reports a case observed at Palm in 2007. Teams were running out of steam on technical items whose usefulness they could not see. Once the link with the Sprint Goal, which was to improve the system's performance by 10%, had been restored, motivation returned. This account is a testimony, not a measurement.

The Production Episode, protected time

The Production Episode pattern refers to the part of the Sprint between Sprint Planning and the Sprint Review. It answers a problem of focus. Information that arrives at the right time helps the Developers, but every interruption costs them time to pick up the thread again. According to the authors, a work list accompanied by a deadline imposed from outside degrades motivation and quality. They draw on a study by Teresa Amabile and her colleagues (1976), which measured the effect of such deadlines on intrinsic motivation, and not on the quality of the work. Having no deadline at all is no better: according to the law stated by C. Northcote Parkinson in 1955, work expands to fill all the time available.

The solution is to reserve a bounded and protected interval for the Developers. The Product Owner and the Developers agree that the former adds or changes no item during this interval. The Product Owner remains free to reorder the Product Backlog, but those changes take effect only at the next Sprint Planning. For their part, the Developers have chosen the amount of work themselves, as a forecast and not as a promise. If they finish early, they take the next item at the top of the Product Backlog. If the plan is under threat, they fall back on the Sprint Goal.

A request in mid-Sprint. A team is developing an app for booking medical appointments. Its Sprint Goal is that patients can move an appointment without calling. On the Tuesday of the second week, the Product Owner comes to see the Developers.

"Sales are meeting a large clinic on Thursday. They'd need an export of the schedules to a spreadsheet. Can you add it?"

"The export doesn't contribute to the goal, and we've never discussed it," replies one of the Developers. "If we take it on, we won't finish moving appointments."

"Would a mock-up be enough for Thursday?"

"Yes. And you can put the export at the top of the Product Backlog for Monday's Sprint Planning."

The Production Episode rule has done its job. The request waits for the next Sprint, the Product Owner knows what an interruption would have cost, and Sales will have their mock-up on Thursday.

In the exceptional cases where the goal becomes unattainable, the Product Owner can cut the Sprint short, as described in the article Protecting the Sprint from interruptions.

Fixed Work, or counting separately what cannot be estimated

Not all of a team's work lends itself to estimation. Nobody can say how long it will take to understand a poorly defined need or to have an idea. If this work is mixed into the Sprint's plan, the forecasts lose their reliability. The Fixed Work pattern proposes separating two categories. Work on the product, which the Developers know how to estimate, fills the Production Episode. Work that cannot be estimated is given fixed-length slots, outside that budget: Sprint Planning, the Sprint Review, the Sprint Retrospective and the Product Backlog preparation sessions. You do what fits in the slot, and if you finish earlier, you move on.

A calculation shows what this represents. In a two-week Sprint on a 35-hour week, each person has 70 hours. As an example, count 4 hours of Sprint Planning, 2 hours of Sprint Review, an hour and a half of retrospective, ten Daily Scrums of a quarter of an hour (2.5 hours) and 7 hours of Product Backlog preparation. Fixed work takes up 17 hours. That leaves 53 hours for production, about three quarters of the Sprint.

Rhythm and calendar

The note Rhythms: Patterns of Time defends a simple idea: for some activities, regularity counts for more than frequency. You brush your teeth at a set time without thinking about it. In the same way, a team whose meetings come around at a known cadence no longer has to wonder when it will meet and can concentrate on the content. The authors therefore advise establishing a cadence first, then adjusting the length and frequency of each event. They draw on the anthropologist Edward T. Hall (The Dance of Life, 1983).

The Follow the Moon pattern extends this idea. People do not produce the same thing every day of the year, and holidays, vacations and local customs upset a calendar of Sprints drawn with a ruler. The proposed solution is to align the start and end of Sprints with the new moon and the full moon, and to build with the team a long-term calendar that takes vacations and holidays into account. The authors themselves class this pattern among the advanced practices and ask that it be applied with common sense.

The fit with the moon is only approximate, since the lunar month lasts about 29.5 days and not 28. The most useful part of the pattern is probably the calendar drawn up together. For the team of teachers, the school year is already divided into periods separated by holidays: a seven-week period holds three two-week Sprints, and the remaining week is used for the end-of-term staff meetings on each class and for the review.

Team Sprint: a Sprint whose content the Developers choose

The Team Sprint pattern (also called Hack Sprint) deals with a frustration. The Developers have ideas for improving the product, their tools or their working environment. These ideas go into the Product Backlog, but requests judged more profitable always go ahead of them. The Product Owner may also underestimate proposals whose interest only becomes apparent once they are built. In the long run, the team becomes discouraged at having no hold over its work.

The solution is for the Product Owner to organize, every five or ten Sprints for example, a whole Sprint whose items and goal the Developers choose. The items still go through the Product Backlog, so that the work remains visible. The pattern rules out one use: the Team Sprint is not for making up for lost time or for fixing accumulated quality shortcuts, because quality is maintained in every Sprint. The authors cite the testimony of Gabrielle Benefield, who introduced these Sprints at Yahoo! in 2003 because some teams found the rhythm of Scrum relentless.

What the 2020 Scrum Guide says

The Guide describes the Sprint as a fixed-length event of one month or less, and states that a new Sprint starts immediately after the conclusion of the previous one. On this point it agrees with the pattern.
Since 2020, the Sprint Goal has been the commitment attached to the Sprint Backlog, and Sprint Planning opens with the question of why this Sprint is valuable.
The Guide is more flexible than the Production Episode. It forbids changes that would endanger the Sprint Goal and any decrease in quality, but it allows scope to be clarified and renegotiated with the Product Owner as more is learned.
The Guide provides that a Sprint can be canceled if its goal becomes obsolete, and that only the Product Owner has the authority to do so.
The terms Production Episode, Fixed Work, Team Sprint and Follow the Moon are specific to the book. It writes "Development Team" where the 2020 Guide says "Developers".

Limits and pitfalls

The word Sprint suggests a race at full speed, and some organizations take it literally. Yet the Scrum Guide speaks of working "at a sustainable pace".

Two drifts empty the Sprint of its meaning. The first is the waterfall Sprint, where the first week is spent on analysis, the second on building and the last day on testing. The second is the two-day extension to finish off: it seems reasonable, but it destroys the cadence and makes measurements incomparable from one Sprint to the next. A goal reduced to "finish the fourteen planned items" poses another problem, since it provides no criterion for replanning.

The scope freeze can also be applied rigidly: refusing an urgent fix in the name of the Sprint does users a disservice. At the other extreme, a Product Owner who changes the plan every two days takes away from the Developers the protected time that justifies the arrangement.

The Sprint does not suit all work. A support team whose requests arrive without warning often gets on better with continuous flow. As for the benefits of cadence, they rest on the authors' experience and on general research into rhythm and motivation, not on controlled comparisons. The article Criticism and the state of the evidence returns to this distinction.