Scrum, day 15: planning toward a Sprint Goal

Today's objective: connect a Sprint's purpose, selected work, and delivery plan, and explain why a capacity calculation cannot supply the goal.

Read alongside: Scrum.org's Sprint Planning reference and Scrum: A Pocket Guide, fourth edition, §2.5, focusing on Sprint Planning. Allow roughly five minutes for this companion, plus the assigned reading.

Begin with the decision the Sprint should enable

We have examined what can change during a Sprint. Now return to the start of the fictional ShiftSwap team's decline-flow work. Elena brings observations from employees who can see that a request was declined but cannot determine what to do next.

The Product Goal concerns dependable exchanges at the first two cafés. Elena proposes improving the second café's decline experience as the next step toward it. The Developers bring what they know about the current product, the available skills, and the work needed for a usable change.

An easy way to begin would be to estimate the capacity, take items from the top of the backlog until the total fits, and call that the Sprint plan. The resulting list might be achievable while still lacking a common purpose. The team first needs to discuss why this Sprint would be valuable.

Establish a goal together

The Scrum Team develops this Sprint Goal:

Employees at the second café can understand a declined request and choose a valid next step without asking the manager to interpret the outcome.

Elena contributes the product intent and stakeholder evidence. The Developers contribute their understanding of what might be possible and what requires investigation. The goal emerges from that conversation; it should not be an unexplained slogan attached after every task has already been selected.

The wording leaves room to choose a suitable implementation. It also excludes some attractive alternatives. A reporting dashboard or a general redesign would need a convincing connection to this purpose before displacing the work required to achieve it.

This is an example of a goal, not a required sentence template. The important test is whether the team can use it to make a coherent decision when the work differs from its initial expectations.

Select work with real delivery conditions in view

Through discussion with Elena, the Developers select the work they believe they can complete. They examine the shared Definition of Done, their recent experience, current availability, and relevant dependencies.

One Developer will be absent for two working days. The team also expects to pair while checking the message service, following the learning plan from day 09. Those facts belong in the forecast. Counting every calendar hour as interchangeable capacity would hide them.

The team considers these options:

The order in the Product Backlog informs the conversation, but selection still requires the Developers' delivery judgment. The Product Owner cannot make a forecast credible simply by insisting that another item fit.

Plan how the result can become Done

The Developers identify the work needed to deliver the selected result. They start with the unresolved record and policy questions, then connect implementation to examples and integrated checks.

For the first day, they have a concrete plan: examine representative old records, confirm the employee-facing explanation with the manager, and trace one complete declined request through the existing product. They also identify the implementation and checking work that is likely to follow.

They do not need a minute-by-minute plan for the whole Sprint. They need an actionable starting point and enough understanding to make their forecast responsible. As information arrives, the Developers will update the Sprint Backlog.

The Sprint Backlog brings together the goal, selected Product Backlog items, and the delivery plan. These answer related questions about purpose, scope, and approach. A list containing only ticket identifiers would leave much of that reasoning implicit.

Surface ambiguity without creating a new approval gate

During planning, the team discovers that “valid next action” means different things to different people. It spends a short time working through examples. For one declined request, inviting another eligible colleague is possible; for another, the requested shift is already in the past.

If the uncertainty is too large, the Developers should reconsider what they can responsibly select. They can discuss a smaller useful result or better-understood work that supports the goal.

This does not require a separate mandatory “Definition of Ready” or an approval committee. Clear examples and ongoing refinement can help the team prepare, while the Scrum framework leaves the supporting techniques open. A checklist is useful only if it improves understanding rather than becoming a substitute for conversation.

Finish with a plan people can explain

Before the event ends, a Developer should be able to describe the Sprint Goal, the selected work, the main uncertainty, and how the team intends to begin. Elena should understand the forecast and its important assumptions. The team should know where its current plan will be maintained.

Sprint Planning has a maximum eight-hour timebox for a one-month Sprint and is usually shorter for shorter Sprints. This is an upper boundary, not a target duration or a reason to postpone every useful clarification until the meeting.

The test is whether the conversation supports coherent work and future adaptation. A beautifully filled board with an unclear goal has not supplied the same value.

Rewrite a Sprint plan

Take a list of tasks from a real or imagined Sprint. Write the shared purpose those tasks serve. Identify one task whose contribution is unclear and one missing piece of work needed to make the result usable.

Then describe a smaller selection that could still achieve the purpose. Include a capacity constraint, a quality requirement, and the first action needed to resolve a consequential uncertainty.

Reflection: if one selected item turns out to be much larger than expected, does the goal help you choose what to adjust? If it merely repeats the task list, revisit what makes the Sprint valuable.

The next companion follows the Developers as they inspect that plan during a Daily Scrum.