Sprint planning: how to start a sprint the team actually believes in

Sprint planning is where a sprint is won or lost. A sprint that starts with a clear goal and a commitment the team chose for itself tends to run calmly to the finish. A sprint that starts with a pile of tickets someone else selected tends to end with a scramble, a slipped scope, and a quiet loss of trust in the process.

This guide covers the whole ceremony in practical detail: what it must produce, how to prepare, how to run the session hour by hour, and the failure modes to watch for. It assumes you know the basics of the framework; if not, start with the complete Scrum guide.

What planning must produce

By the end of sprint planning you need exactly three things:

1. A Sprint Goal. One sentence describing why the sprint is worth running.
2. A forecast. The set of product backlog items the Developers believe they can finish, pulled by them, not assigned to them.
3. A plan. At least the first few days of work broken down far enough that people can start immediately.

The Scrum Guide frames these as three questions: why is this sprint valuable, what can be done, and how will the chosen work get done. Everything else, including the agenda below, is in service of answering those three questions well.

The timebox is a maximum of eight hours for a one-month sprint. For the two-week sprints most teams run, plan for two to four hours. If planning regularly overruns, the problem is almost never the meeting; it is unrefined work arriving at the meeting, which is what the backlog refinement guide is for.

The Sprint Goal comes first

Most teams do this backwards. They fill the sprint with tickets, then squint at the pile and reverse-engineer a "goal" that summarises it, usually something like "complete the selected items". That is not a goal, it is a description.

A real Sprint Goal is chosen before the tickets and shapes which tickets get in. It gives the team something to steer by when reality intervenes mid-sprint, and it defines what "success" means independently of ticket count.

Compare two versions of the same sprint at an online retailer:

• Weak: "Finish checkout tickets and assorted bugs."
• Strong: "A customer can pay with a saved card in under ten seconds."

Halfway through the sprint an engineer discovers the card vault migration is messier than expected. With the weak goal, there is no basis for deciding what to drop, so the team just works late. With the strong goal, the decision is nearly automatic: the two cosmetic bugs slip, the migration gets a second pair of hands, and the sprint still succeeds at the only thing it promised.

Practical tips for writing one:

• Phrase it as an outcome a user or stakeholder would recognise, not as a list of nouns from the tickets.
• One goal, not three. If you genuinely have two unrelated priorities, pick the more valuable one as the goal and treat the other as ordinary backlog.
• Keep it visible all sprint. This matters more than it sounds; a goal nobody sees again until the review might as well not exist. WannaTrack pins the Sprint Goal to the top of the board for the whole sprint for exactly this reason.

Capacity and velocity: making the forecast honest

The Developers decide how much fits in the sprint, and they need two numbers to do it honestly.

Velocity is how much work the team has actually finished in recent sprints, in whatever unit the team estimates with (typically story points, covered in the refinement guide). Velocity is an observation, not a target. If the last four sprints finished 31, 28, 35, and 30 points, forecasting 45 because the quarter is ending is not optimism, it is fiction.

Capacity is how much of the team is actually available this sprint. Velocity assumes a normal sprint; capacity corrects for reality. A worked example for a five-person team on two-week sprints:

• Trailing velocity: about 30 points per sprint.
• This sprint: one engineer on holiday all week one, a public holiday for everyone, and one engineer on support rotation at roughly half output.
• Available person-days: roughly 70 percent of normal.
• Honest forecast: about 20 points, not 30.

Teams that skip this correction have the same experience every time: the sprint "mysteriously" fails, morale dips, and the retro concludes that estimates were wrong when actually the calendar was ignored.

Do this arithmetic in the open, during planning. This is one of the places where tooling quietly changes behaviour: WannaTrack shows committed points climbing against capacity as you drag items into the sprint, with recent velocity alongside, so overcommitment stops being an abstract risk and becomes a visible red number the whole team can see and argue with.

Two habits that protect the forecast:

• Leave slack on purpose. Production incidents, urgent customer bugs, and code review of other people's work all consume real time. Teams that plan to 100 percent of capacity are planning to fail; 80 to 85 percent is a sensible default until your own data says otherwise.
• Count everything or count nothing. If bugs and support work enter the sprint but carry no points, your velocity silently understates the team's real throughput, and every future forecast inherits the error. We see this constantly, including on our own team, and it is worth a working agreement either way.

A step-by-step agenda for a two-week sprint

This agenda assumes a refined backlog and takes two to three hours. Timings are for a team of five to eight people.

Before the meeting (Product Owner, 30 minutes, async). Confirm the backlog order still reflects reality, draft a candidate Sprint Goal, and check the top items are actually ready: clear description, acceptance criteria, an estimate. Anything failing that test gets pulled from contention now, not discovered mid-meeting.

1. Set the stage (10 minutes). The Product Owner presents the state of the product, anything learned at the last sprint review, and the proposed Sprint Goal. The team discusses and agrees the goal, possibly reworded. Agreeing the goal first is the whole trick; it turns the rest of the meeting from "how much stuff" into "what serves this".

2. Establish capacity (10 minutes). Walk the calendar together: holidays, interviews, on-call, company events. Write the resulting capacity number where everyone can see it.

3. Select the work (45 to 75 minutes). Walk the backlog from the top. For each item: the Product Owner clarifies intent, the Developers confirm the estimate still holds (re-vote it if new information has emerged; a quick round of planning poker inside the ticket takes two minutes), and the team pulls it in or stops. Stop when the committed total reaches the capacity you agreed, not when the wishlist runs out. Items that serve the Sprint Goal jump the queue over items that merely sit high in the backlog.

4. Plan the how (30 to 45 minutes). For at least the first items, break the work down: subtasks, sequencing, who starts where, known risks. This is where a developer says "the payments sandbox is still broken from last time", and the team finds out on day one instead of day six. Not every item needs decomposing in the meeting; the sprint backlog belongs to the Developers and evolves daily.

5. Confidence check (5 minutes). Ask the room: on a fist of five, how confident are we that we hit this goal? Threes and below get to say why, and the scope adjusts on the spot. This sounds like ritual; it is actually the cheapest risk report you will ever get.

Then stop. The output is on the board, the goal is pinned, and people start work the same day.

Anti-patterns to watch for

The pre-planned sprint. A manager or Product Owner arrives with the sprint already loaded and the meeting is a readout. This destroys the one thing that makes forecasts reliable, which is that the people doing the work sized it and chose it. The Product Owner owns what is most valuable; the Developers own how much fits. Both halves are load-bearing.

Planning as discovery. If the team is hearing about items for the first time in planning, the meeting balloons to four hours of requirements archaeology. The fix is upstream: refinement happens during the sprint, so planning only handles ready work.

The stretch goal that is not. "Committed" items plus "stretch" items where the stretch items are quietly expected. If everything is expected, nothing is stretch; the overcommitment is just wearing a costume.

Carry-over amnesia. Unfinished items roll into the next sprint automatically, keep their old estimate, and nobody asks why they did not finish. Carry-over is fine; unexamined carry-over hides a broken estimate, a hidden dependency, or a person silently stuck. Make re-pulling carried work an explicit decision like any other.

Ignoring the burndown from day one. Planning does not end when the meeting ends; the forecast is a hypothesis the sprint tests daily. A burndown that flatlines for four days is planning feedback arriving early. WannaTrack's burndown recomputes the moment a ticket moves, so the daily scrum can catch the flatline on day four rather than the review discovering it on day ten.

How you know planning is working

Three signs, all measurable:

• The team hits its Sprint Goal most sprints, even when individual tickets slip. Goals are the unit of success, tickets are the unit of work.
• The forecast error shrinks. Compare committed points to completed points across the last six sprints; a healthy team converges toward small, boring variance. A velocity chart makes this a thirty-second check.
• Planning gets shorter, not longer, as refinement improves upstream.

Sprint planning is a forecast, and forecasts earn trust by being honest rather than impressive. Choose a real goal, correct for the calendar, let the people doing the work size the work, and let the sprint prove you right or teach you something. The next guide in the series covers the ceremony that keeps the plan alive day to day: the daily scrum.