Sprint Planning

Sprint planning answers two questions: what is worth doing next, and how much of it can this team realistically finish. Everything else in the meeting is in service of those. It is worth being clear that planning is not estimation. If the team is sizing stories during sprint planning, the meeting will overrun and the estimates will be poor, because people are simultaneously being asked to understand the work and commit to it. Estimation belongs in refinement, earlier and unhurried. Planning should start with a backlog that is already sized. A planning session for a two-week sprint should take one to two hours. If yours regularly takes four, the problem is almost always upstream — the backlog was not ready.

The most common way planning goes wrong is opening the backlog and pulling stories from the top until the capacity is full. That produces a sprint that is busy and incoherent: eleven unrelated items, no single thing you could demonstrate, and nothing to prioritise against when something goes wrong mid-sprint. A sprint goal is a one-sentence statement of what the sprint is trying to achieve — “users can reset their own passwords without contacting support” rather than “finish PROJ-412 through PROJ-419”. It earns its place the moment something slips, because it tells the team which stories are load-bearing and which can be dropped. Agree the goal first, then select the stories that serve it, then fill remaining capacity with whatever else is valuable. Sprints with a genuine goal tend to end with something demonstrable even when they do not end with everything finished.

Velocity tells you what the team has historically delivered in a normal sprint. The next sprint is rarely normal, so the average needs adjusting for what you already know: • Holidays, leave and public holidays — pro-rata the velocity against the days actually available. • Known interruptions — a release, an audit, two days of interviews. These consume capacity whether or not anyone estimates them. • Support and on-call load — if the team carries a rota, reserve capacity rather than hoping it is quiet. • Carry-over — unfinished work from the last sprint comes in at its original estimate and takes capacity first. • New joiners — a new team member reduces velocity for a while before increasing it. Plan for the dip. A sensible rule is to commit to the lower end of the velocity range rather than the average. Teams that consistently finish early can pull more in; teams that consistently overcommit train everyone around them to discount their forecasts.

Scrum has moved away from the word “commitment” deliberately. What the team produces in planning is a forecast: its best current judgement of what it can deliver, given what it knows today. The distinction sounds like semantics and is not. A commitment treated as a promise changes behaviour in predictable ways — padding, quiet scope reduction, work called done that is not quite done. A forecast can be revised when the world changes without anyone having broken their word. This does not mean the sprint plan is casual. The team should intend to deliver it and should raise it early when it becomes clear they will not. The difference is in what happens when a forecast misses: a functioning team examines why, and a dysfunctional one looks for who.

1. Review the outcome of the last sprint briefly — what carried over and why. Five minutes. 2. Confirm capacity for the coming sprint, adjusted for leave and known interruptions. 3. Agree the sprint goal. The product owner proposes; the team challenges it for feasibility. 4. Select the stories that serve the goal, in priority order, until capacity is reached. Anything not already estimated goes back to refinement rather than being sized on the spot. 5. Walk the selected stories for dependencies and sequencing — what blocks what, and who is needed for which. 6. Sanity check: does the team believe this is deliverable? An unenthusiastic yes is a no. Anything that requires a decision from someone not in the room should be parked explicitly rather than guessed at. A story built on an assumed answer is the most reliable source of mid-sprint surprises.

• Estimating during planning — the meeting overruns and the numbers are rushed. Fix refinement instead. • Planning to 100% of capacity — leaves nothing for the interruptions that arrive every sprint. Most teams plan to around 80%. • No sprint goal — the team cannot prioritise when something slips, so everything slips equally. • Stories too large — a single 13-point story in a two-week sprint carries a real risk of ending the sprint at zero percent on that item. • Silent dissent — the team agrees in the room and privately believes the plan is impossible. Ask each person directly if you suspect this. • Ignoring carry-over — starting each sprint as though the backlog of unfinished work does not exist guarantees a widening gap between plan and reality. Most of these are visible in the retrospective if anyone looks. A sprint that ends badly almost always ends badly for a reason that was present at planning.

Sprints go wrong. What matters is how early it is said out loud and what gets protected when it happens. The order to sacrifice things in is usually: scope first, then the lowest-value stories, then the sprint goal itself — and quality never. Cutting quality moves the cost into the next sprint with interest, and teams that do it repeatedly find their velocity declining for reasons they cannot explain. If the goal itself has become unachievable or irrelevant — the requirement changed, the assumption was wrong — the honest move is to say so and re-plan rather than spending the remaining week delivering something nobody wants. That is a legitimate outcome, and a team that is allowed to do it will surface problems far earlier than one that is not.