The Sprint and Sprint Planning: Why, What, How and the Sprint Goal
A Sprint is a fixed-length event of one month or less; Sprint Planning produces the Sprint Goal and the Sprint Backlog through the why, what and how topics. The Developers commit to the Sprint Goal, not to the selected items, which are a forecast. The post shows good and bad Sprint Goals, why only the Product Owner can cancel a Sprint, and the Bookstore team's real capacity calculation, which comes to 72 percent of gross capacity.
Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. Timebox values are for a one-month Sprint, as in the Guide.
Guess First
The Bookstore team works in two-week Sprints: ten working days, five Developers, 50 person-days on paper. In this Sprint Zeynep is on leave for two days, the team rotates a production support duty and whoever is on duty spends half their time on support. And there are the Scrum events: Sprint Planning, a Daily Scrum every day, Sprint Review, Sprint Retrospective and a refinement session.
What percentage of the 50 person-days can really go to the Sprint Goal: 90 percent, 70 percent or 50 percent? Write down your guess; you will see the team's actual calculation halfway through the post. One more question: which of these two Sprint Goals matches the Guide's definition? "Finish the 12 tickets in Sprint 7" or "A registered customer can create a return request end to end for a delivered single-item order, and the request shows up in the support panel."
The Sprint: The Heartbeat of Scrum
The Guide defines Sprints as the heartbeat of Scrum, where ideas are turned into value. Sprints are fixed-length events of one month or less to create consistency, and a new Sprint starts immediately after the previous one ends. All the work needed to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective, happens within Sprints. So there is no "gap week", "preparation week" or "test week" between Sprints.
Four rules apply during the Sprint:
- No changes are made that would endanger the Sprint Goal.
- Quality does not decrease.
- The Product Backlog is refined as needed.
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
The last two rules say the Sprint is not a frozen contract. When it turned out on day three that the shipping company's API (Application Programming Interface) returns the return label only as a PDF (Portable Document Format), Ayşe and Selin changed "show the label on screen" to "email the label". The Sprint Goal (a customer can create a return request end to end) did not change; the work leading to it did.
Choosing the length is a trade-off. The Guide says that when a Sprint's horizon is too long the Sprint Goal may become invalid, and complexity and risk may rise; shorter Sprints generate more learning cycles and limit the risk of cost and effort to a smaller time frame. Bookstore chose two weeks: with one-week Sprints the fixed cost of Planning, Review and Retrospective grew proportionally too large; with four weeks stakeholder feedback dropped to once a month. Once chosen, the length stays fixed; "let's extend this Sprint by two days" is not an option.
Who Can Cancel a Sprint?
According to the Guide, a Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has that authority. It happened once at Bookstore: on day four the payment provider announced it would shut down its partial refund API, and the whole Sprint Goal was about partial refunds. Selin cancelled the Sprint; the team held a new Sprint Planning the same day.
Cancellation should be rare and is expensive: unfinished work either returns to the Product Backlog or is re-evaluated, Planning is redone and the team's rhythm breaks. The 2020 Guide shortened the cancellation section considerably compared with earlier versions; a single principle remains: a Sprint is cancelled only when its goal has lost its meaning, and only by the Product Owner. A manager saying "something urgent came up, stop the Sprint" is outside that principle. That work goes to Selin; Selin decides whether the Sprint Goal still makes sense.
Sprint Planning: Why, What, How
Sprint Planning initiates the Sprint by laying out the work to be performed; the plan is the collaborative work of the entire Scrum Team. The Product Owner ensures attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The team may also invite other people for advice; in the Sprint where the shipping API was being figured out, an expert from accounting joined the first half hour.
The 2020 Guide splits Planning into three topics. "What" and "how" had been there since 2013; "why" was added in 2020.
Topic one: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility in this Sprint; then the whole Scrum Team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized before the end of Planning.
Topic two: What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog; the items may be refined in the process. Selecting how much fits is hard; the Guide says the more the Developers know about their past performance, upcoming capacity and Definition of Done, the more confident they will be in their forecast.
Topic three: How will the chosen work get done? For each selected item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers.
The Sprint Goal, the selected items and the plan for delivering them together make up the Sprint Backlog. Planning is timeboxed to a maximum of eight hours for a one-month Sprint; for shorter Sprints the event is usually shorter. Bookstore's two-week Planning takes three hours in most Sprints and has never gone past four.
Forecast, Not Commit
In the 2010 Guide the team "committed" in Sprint Planning to completing the work it selected. The 2011 revision changed this: the Developers create a forecast of the work they believe will be done in the Sprint, and that forecast changes as more becomes known during the Sprint. The reason was behavior seen in the field: when every selected item was treated like a promise, teams either selected too little or "kept the promise" by cutting quality.
In 2020 the word commitment came back, but in a different place: the Developers commit to the Sprint Goal, not to the list of selected items. The Guide defines the Sprint Goal as the single objective for the Sprint and adds an important flexibility: although the Sprint Goal is a commitment, it provides flexibility in terms of the exact work needed to achieve it. If the work turns out to be different than expected, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal. So the item list is a forecast, and the Sprint Goal is a commitment.
Good Sprint Goal, Bad Sprint Goal
How the Sprint Goal is written decides whether that flexibility exists at all. Examples from Bookstore's first Sprints:
| Sprint Goal | Problem or strength |
|---|---|
| Finish the 12 tickets in Sprint 7 | Not a goal but a list; when one ticket slips the goal slips, and there is no flexibility at all |
| Complete the returns backend | Limited to a layer; nothing usable may come out at the end of the Sprint |
| A registered customer can create a return request end to end for a delivered single-item order, and the request shows up in the support panel | Meaningful to stakeholders and testable; the goal holds even if the shipping label is emailed instead of shown on screen |
| Learn whether partial refunds work at the payment provider with a real test refund | A learning goal; the Increment may be small, but it closes a risky unknown |
A good Sprint Goal has two signs. First, when the team has to drop an item, it can ask "does the goal still hold?". Second, it can be explained to a stakeholder in one sentence at the Sprint Review. If what you are trying to explain is a list, you probably have a summary of the Sprint Backlog, not a Sprint Goal.
Capacity: The Reality of the Calendar
Back to the opening question. Here is the Bookstore team's calculation for this Sprint:
| Item | Person-days |
|---|---|
| Gross: 5 Developers × 10 days | 50.0 |
| Scrum events and refinement (11.25 hours per person: Planning 4, Daily 9 × 0.25, Review 2, Retro 1.5, refinement 1.5) | -7.0 |
| Support duty: one person per day, half their time | -5.0 |
| Zeynep's leave | -2.0 |
| Left for the Sprint Goal | 36.0 |
The result is 72 percent of gross capacity. Code reviews, environment problems and unexpected meetings are not in the table, so the real ratio is lower still. That is why, when selecting items, the team does not look at hours but at the number of items actually Done in the last three Sprints (9, 11 and 10 respectively), and, given this Sprint's lower capacity, starts with 8 items. The estimation technique itself, story points or item counts, belongs to the upcoming Estimation and Planning series; the Guide only says past performance, capacity and the Definition of Done should feed the forecast.
In Production: What to Watch
The most honest number for the health of the Sprint and Planning is the rate of reaching the Sprint Goal. The percentage of selected items finished is secondary; if the goal holds, a few items returning to the Product Backlog is normal. Bookstore reached its Sprint Goal four times in the last six Sprints; in the two Sprints where it did not, the common factor was that no capacity table had been made in Planning. What metrics do and do not show is the topic of the eighth post in the series.
The length of Planning is a signal too. If Planning keeps pushing the timebox, the problem is usually not in Planning but in refinement: the items are not small and clear enough to enter a Sprint, and analysis is being attempted inside Planning.
At scale, even if several teams working on the same product hold separate Plannings, aligning their Sprints on the same calendar makes dependencies visible. The Guide does not require it; scaling frameworks such as Nexus define it.
Common Pitfalls
Turning the Sprint Goal into a summary of the ticket list. "Finish the payment, return and notification work" is not a goal but three items joined by commas. Such a goal scatters the team across separate jobs instead of one purpose; the "coherence and focus" the Guide wants from a Sprint Goal is lost.
Forgetting meetings and support load in capacity planning. Work selected against gross capacity overflows every Sprint and the team concludes "we can't estimate"; the problem is not the estimate but the reality of the calendar.
Turning Planning into a meeting where the Product Owner or a manager hands out work. The "how" is at the Developers' discretion; who picks up which work item is a decision for the self-managing team as well.
Extending the Sprint, or opening "Sprint 7b" when the goal is missed. The fixed length is a deliberate constraint; keeping the rhythm makes the team's forecasts comparable from Sprint to Sprint.
A Small Experiment
★☆☆ Write down your last three Sprint Goals and try to explain each to a stakeholder in one sentence. Mark the goals you could only explain by listing items.
★★☆ Build a capacity table like the one above for your next Sprint: subtract events, support load and leave from gross capacity. At the end of the Sprint, write the actual distribution into the same table and find the line with the biggest gap.
★★★ For one Sprint, record the changes to the Sprint Backlog: items added, removed and split, with reasons. At the end of the Sprint, separate the changes made while protecting the Sprint Goal from the ones that changed the goal. Who made the decision in the second group?
The Sprint has started and there is a plan. In the next post we look at how that plan is inspected every day: why the Daily Scrum is not a status report, why the three questions were dropped in 2020, and what walking the board from right to left is good for.