Stephen Turner
Akash Kumar
Jordan Lee
Taylor Scott
How to run Sprint Planning that ends with a goal worth keeping
Sprint Planning starts a Sprint by agreeing why it matters, what work fits and how the Developers will do it. It should end with a Sprint Goal stakeholders can understand, the selected Product Backlog items and a first plan. Together those make the Sprint Backlog.
What Sprint Planning must produce
The Scrum Guide gives Sprint Planning three topics: why this Sprint is valuable, what can be done this Sprint, and how the chosen work will get done. The whole Scrum Team creates the plan together.
The meeting produces the Sprint Backlog: the Sprint Goal, the selected Product Backlog items and the plan for delivering them. The Sprint Goal must be final before Sprint Planning ends.
The event is timeboxed to eight hours for a one-month Sprint, and is usually shorter for shorter Sprints.
Prepare the inputs before anyone arrives
The Product Owner makes sure people are ready to discuss the most important Product Backlog items and how they relate to the Product Goal. Top items that are still vague will eat the meeting.
Developers bring what helps them forecast: how much they finished recently, who is away next Sprint, and the Definition of Done. The Scrum Guide notes that knowing these makes forecasts more confident. You can also invite people who can advise, such as a specialist on a risky item.
An agenda for a two-week Sprint
This is one way to fit the three topics into about three hours. Adjust it to your team and Sprint length.
| Time | Topic | Output |
|---|---|---|
| 20 min | Why: the Product Owner proposes how the Sprint could add value | A draft Sprint Goal |
| 70 min | What: Developers select and refine items with the Product Owner | Selected items that fit capacity |
| 70 min | How: Developers break items into work of a day or less | A first plan for the opening days |
| 20 min | Check: reread the goal against the selected work | Final Sprint Goal and Sprint Backlog |
Example: from a list of tickets to a Sprint Goal
A billing team brings five items: payment retry, a retry confirmation email, an invoice PDF fix, a tax field and a dashboard tweak. A goal like "finish these five tickets" tells stakeholders nothing.
After discussion, the team agrees: "Customers whose card payment fails can retry without contacting support." Payment retry and its confirmation email serve that goal, so they're in. The invoice fix is small and urgent, so it comes along as extra work.
The tax field and dashboard tweak go back to the Product Backlog. Now the goal explains why the Sprint is valuable, and it leaves room to change the exact work if retry turns out harder than expected.
Let Developers own the how
For each selected item, the Developers plan the work needed to meet the Definition of Done. The Scrum Guide says how they do this is their call alone.
Plan the first days in detail and leave later work coarser. If a task won't break down below a day, ask whether it hides a decision or an unknown. Name it now rather than mid-Sprint.
After the meeting: keep the goal visible
Put the Sprint Goal where the team sees it every day, such as the top of the board or the Daily Scrum notes. When work turns out different than expected, Developers negotiate scope with the Product Owner without changing the goal.
Record which items you deferred and why. That helps the next Sprint Planning and the Sprint Review.
Planning with Bridge
Record Sprint Planning in Bridge, whether you host it on Bridge or capture it from Zoom, Meet or Teams. The notes include a summary, decisions and follow-ups, so the final Sprint Goal and deferred items are easy to find.
Add each Sprint's planning and review meetings to one space. The team can then look back at past goals and forecasts in one place.