Sprint planning · Scrum · Agile
How to run sprint planning, with a worked example
By T. Krause
Sprint planning has three questions to answer, and a list of tickets answers only one. Here is how to run it, followed through a made-up sprint from a one-line goal to a capacity sum and the first day's tasks.
To run sprint planning, get the whole Scrum team together and answer three questions in order. Why is this sprint valuable? What can be done in it? How will the chosen work get done? The first answer becomes a one-sentence sprint goal, the second is a list that fits the team's capacity, and the third is a plan for the first few days.
Those three questions come from the Scrum Guide, the 2020 text by Ken Schwaber and Jeff Sutherland that defines Scrum. It's short and free to read. It doesn't mention points, velocity or a capacity formula, so anything below on those is one common way to do it and our suggestion, not part of Scrum itself.
We make Prompt Board, and our sprint planning template opens on the sprint below. A wall works just as well if everyone's in the same room.
The questions and the board
| Scrum Guide topic | Our template's frames |
|---|---|
| Why is this Sprint valuable? | Sprint goal |
| What can be Done this Sprint? | Capacity, Candidates, Committed |
| How will the chosen work get done? | None, so add a frame |
Our board doesn't have a frame for the third question. That's a gap in the template, so the example below adds one by hand.
The guide says the whole Scrum Team creates the plan, and that the Product Owner makes sure people are ready to discuss the most important backlog items. The team can also invite others for advice. The Developers choose what to take on and how to do it. "No one else tells them how to turn Product Backlog items into Increments of value."
Sprint 25, frame by frame
Everything in this section is invented: the team, the product, the sprint, the numbers, the people and the outcome. It doesn't describe any real team.
A team of five developers works on a reporting product, with two-week sprints. This one has nine working days, because the company is closed for one day.
Before the meeting
The Product Owner brings the top of the backlog with estimates already on it. The Scrum Guide puts sizing with the Developers, during refinement, so these estimates are the developers' own. One person also brings the completed points from the last three sprints, because the guide says the more developers know about "their past performance, their upcoming capacity, and their Definition of Done", the more confident they'll be in their forecasts.
Why: the sprint goal
The guide calls the goal "the single objective for the Sprint". The Product Owner proposes customers being able to take report data into a spreadsheet, and the team reshapes that into one line.
Customers can export reports as CSV.
The test is whether someone could check it on the last day. A goal like "make progress on reporting" couldn't pass that.
What: capacity
The Capacity frame holds three notes: 5 devs, 9 days. Leo out Mon-Tue. About 20 points.
Here's where the third note comes from. Five developers for nine days is 45 person-days, and Leo's two days out leave 43. The last three sprints finished 21, 22 and 19 points, with 45 person-days each, for an average of about 20.7. Scaling that by 43 out of 45 gives about 19.8, so the team writes "about 20". The figure is rough on purpose, and a false decimal wouldn't help.
What: candidates and the cut
Four items come in from the top of the backlog.
| Candidate | Points | Serves the goal? |
|---|---|---|
| CSV export | 8 | Yes, it's the goal |
| Report filters | 5 | Yes, filters decide what gets exported |
| Fix date picker | 3 | Yes, it sets the export's date range |
| Audit log | 13 | No |
The total is 29, which is over capacity. The first three come to 16, leaving 4 spare. The audit log doesn't fit in 4 points, and it doesn't serve this goal, so it goes back to the backlog. The team could split a small piece off to use the spare points, but it would pull attention from the goal, so it leaves the audit log out. The spare 4 points give it room for surprises.
The Committed frame now holds CSV export, Report filters and Fix date picker.
How: the frame you add
The guide says developers often break backlog items into "smaller work items of one day or less". The team doesn't need to do this for the whole sprint in the meeting. It adds a frame called How, and breaks down what starts first.
| Task for CSV export | Who |
|---|---|
| Agree the column list with the Product Owner | Mina |
| Write the export query with date range | Leo, from Wednesday |
| Add the export button and file download | Sam |
| Test with the largest sample report | Mina |
Report filters and the date picker get a few notes each, and the rest waits until someone picks it up. The first three days are clear, and that's enough to end the meeting.
Committed, or forecast?
Our template's frame says Committed. The Scrum Guide uses that word differently: "Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it." For how much work fits, the guide talks about forecasts.
That matters in week two. Suppose the date picker turns out larger than 3 points. The team talks to the Product Owner about what to change, and the goal stays. Nobody has broken a promise by swapping a task, as long as customers can still export a report.
A 90-minute agenda
For a one-month sprint, the guide caps planning at eight hours, and says shorter sprints usually have shorter events. It gives no figure for two weeks. We'd start at 90 minutes and adjust after a few sprints.
| Minutes | What happens |
|---|---|
| 10 | Product Owner proposes the value, team drafts the goal |
| 10 | Work out capacity from who's here and past sprints |
| 30 | Go through candidates, ask questions, split what's too large |
| 10 | Cut to capacity, finalise the goal |
| 25 | Break down the first items and agree who starts what |
| 5 | Read the goal aloud and check that nobody has a doubt left |
If the session overruns, the items were probably not ready. Fix that in refinement, because planning is a poor place to find out what a ticket means.
When it goes wrong
The goal is a list of tickets. "Finish tickets 141 to 146" gives the team nothing to protect when something slips. Ask what a customer could do at the end that they can't do now.
Capacity assumes everyone's free all day. Take off holidays and known absences, and start from what past sprints finished, not from a sum of available hours.
The team fills every last point. Nothing's left for surprises, so one of them costs you the goal. Compare what you planned with what you finished at the next retrospective.
Everything's a must. If stakeholders won't let anything go, sort the list first with a MoSCoW prioritisation.
Frequently asked questions
Who attends sprint planning?
The whole Scrum Team: the Product Owner, the Scrum Master and the Developers. The guide says the team may also invite other people to give advice.
How long should sprint planning take?
The Scrum Guide's limit is eight hours for a one-month sprint, and shorter sprints are usually shorter. It doesn't set a figure for two weeks. Our suggestion is to start at 90 minutes.
Does Scrum require story points?
No. The guide doesn't mention them, and it asks the Developers to size the work without naming a unit. Points, hours or a count of items can all work if the team's past numbers mean something to it.
What is the output of sprint planning?
The sprint goal, the items selected for the sprint and a plan for delivering them. The guide calls these three together the Sprint Backlog.
What's the difference between sprint planning and backlog refinement?
Refinement is when the team splits, describes and sizes items ahead of time. Planning is when it picks from the ready items and agrees a goal. Good refinement makes planning shorter.
Do you need sprint planning if you use kanban?
Sprint planning belongs to Scrum. A team on a continuous board pulls work as capacity frees up, so it doesn't need this event in this form. Our guide to using a kanban board covers that way of working.
Plan your next sprint
Write the goal first, then let it decide what goes in. Open the sprint planning template, replace Sprint 25 with your own numbers, and add a How frame for the first items. During the sprint, a daily standup keeps the goal in view.