Sprint Planning, Review and Done: A Scrum Guide Walkthrough

Sprint Planning opens a Sprint and the Sprint Review comes near its end. Connecting them is a quieter idea that decides whether either event means much: the Definition of Done. If "done" is fuzzy, the plan rests on guesses and the review inspects work that is not really finished.

This guide looks closely at those three elements as described in the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland, which scrumguides.org presents as the current edition as of this writing. It focuses on how to run them well in practice. For a broader tour of Scrum's accountabilities and artifacts, see our guide Scrum Explained in Plain English.

Sprint Planning: Three Questions

The Scrum Guide says Sprint Planning "initiates the Sprint by laying out the work to be performed for the Sprint," and that the plan is created by the whole Scrum Team. The Product Owner makes sure 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 to give advice.

The event addresses three topics:

1. Why is this Sprint valuable? The Product Owner proposes how the product could increase its value, and the whole team collaborates on a Sprint Goal. The Guide says the Sprint Goal must be finalized before Sprint Planning ends.
2. What can be done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog. The team may refine items during this process.
3. How will the chosen work get done? For each selected item, the Developers plan the work needed to create an Increment that meets the Definition of Done. The Guide notes this is often done by breaking items into smaller work items of one day or less, and that how this is done is at the sole discretion of the Developers.

The Sprint Goal, the selected items and the plan together form the Sprint Backlog. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint and is usually shorter for shorter Sprints.

Making Sprint Planning Work in Practice

• Start with the goal, not the list. If the team picks items first and writes a goal afterward, the goal usually becomes a summary of unrelated work. The Guide describes the Sprint Goal as "the single objective for the Sprint" and says it creates "coherence and focus."
• Arrive with a refined backlog. The Guide treats refinement as an ongoing activity, not part of the planning event. Items that have not been discussed before planning tend to consume the timebox.
• Forecast from evidence. The Guide says the more the Developers know about their past performance, upcoming capacity and Definition of Done, the more confident their forecasts will be. Capacity changes such as holidays belong in the conversation. Our guide to estimation in agile teams covers forecasting approaches.
• Keep the goal stable and the scope flexible. If work turns out differently than expected, the Guide says the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal.

The Sprint Review: A Working Session

According to the Scrum Guide, the purpose of the Sprint Review "is to inspect the outcome of the Sprint and determine future adaptations." The Scrum Team presents its results to key stakeholders, and progress toward the Product Goal is discussed. Attendees review what was accomplished and what has changed in their environment, then collaborate on what to do next. The Product Backlog may be adjusted as a result.

Two details are easy to miss. First, the Guide calls the Sprint Review "a working session" and says the team "should avoid limiting it to a presentation." Second, it states that the Sprint Review "should never be considered a gate to releasing value." Increments can be delivered to stakeholders before the Sprint ends.

The Sprint Review is the second-to-last event of the Sprint, before the Retrospective, and is timeboxed to a maximum of four hours for a one-month Sprint.

Running a Better Sprint Review

Because the Guide frames the review as collaboration, design the time around stakeholder input.

• Show the product, not slides. Let stakeholders use the working Increment where possible.
• Talk about the environment. Market changes, new regulations, budget shifts or customer feedback can change what is most valuable next.
• Return to the Product Goal. Discuss what the team learned about progress toward it, not just which items were completed.
• Leave with a changed backlog. If nothing in the Product Backlog changes after a review, it is worth asking whether stakeholders were really invited to influence direction.

The Definition of Done

The Scrum Guide describes the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures required for the product." It adds that "the moment a Product Backlog item meets the Definition of Done, an Increment is born." Elsewhere the Guide states that work cannot be considered part of an Increment unless it meets the Definition of Done.

The Definition of Done is the commitment attached to the Increment, and it creates transparency by giving everyone a shared understanding of what was completed. The rules are firm:

• If an item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.
• If the organization has a Definition of Done as a standard, all Scrum Teams must follow it as a minimum. Otherwise, the Scrum Team must create one appropriate for the product.
• The Developers are required to conform to it.
• If several Scrum Teams work on the same product, they must mutually define and comply with the same Definition of Done.

Scrum.org's introduction to the Definition of Done gives example items for a health-focused software application, including all testing completed, no known defects, code review completed and passed, and meeting general security requirements. Your list will depend on your product, users and regulatory context.

How the Three Fit Together

In Sprint Planning, the Developers plan the work needed to meet it, so a stricter definition means more work per item and a more honest forecast. In the Sprint Review, only work that meets it can be presented, so stakeholders inspect real progress rather than demos of half-finished features.

The Sprint Retrospective closes the loop. The Guide says the team inspects how the Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. Teams can strengthen their definition over time, for example by adding automated security checks once the tooling exists.

A Hypothetical Example

Imagine a five-person team building an online appointment system for a small clinic, working in two-week Sprints. In planning, the Product Owner explains that patients often miss appointments. The team agrees on a Sprint Goal: patients receive a reminder before their appointment. The Developers select three items and break them into tasks.

Midway through, one item, text-message reminders, turns out to need a vendor contract that will not be ready in time. The Developers and Product Owner agree to deliver email reminders this Sprint, which still meets the goal. At the review, the clinic manager tries the reminder flow and points out that many patients prefer text messages, so the Product Owner moves that item up the backlog. Because the team's Definition of Done includes accessibility checks, the email template is reviewed for screen readers before it counts as done.

Key takeaways

• Sprint Planning answers why the Sprint is valuable, what can be done and how it will be done, and produces a Sprint Goal before it ends.
• Keep the Sprint Goal stable and negotiate scope with the Product Owner when work turns out differently than expected.
• The Sprint Review is a working session with stakeholders, not a demo for approval, and it is never a gate to releasing value.
• The Definition of Done is the Increment's commitment; work that does not meet it cannot be released or presented at the review.
• Inspect and strengthen the Definition of Done in retrospectives so planning and reviews rest on an honest picture of progress.

Sources

• Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
• Scrum Guides, Revision History
• Scrum.org, What Is a Definition of Done?