Sprint Planning Template

Why most sprint planning templates stop being used

Planning meetings tend to produce a list of tickets and not much else. Everyone leaves with a shared sense of what was discussed, but nothing written down that could settle a disagreement a week later about what was actually agreed. The template exists to force four specific things onto the page that a ticket list on its own leaves out. None of them are complicated; all of them are easy to skip when the room just wants to get through the ticket list and move on.

There is no stated goal. Without one sentence describing what the sprint is for, the meeting becomes ticket triage (pick items until the hour runs out) and nobody can say afterward whether the sprint succeeded, only whether every ticket got closed. Those aren't the same question, and conflating them is how a sprint can close every ticket and still miss the point.

The commitment is never checked against capacity. Items get pulled in until the backlog "feels" sufficiently covered, not until the team's actual available hours run out. The first missed sprint of a project is usually the first one where nobody did this arithmetic, and it's rarely repeated as a lesson because the miss gets blamed on the work instead of the missing check.

The plan and the board disagree by day two. The planning notes live in a document or a slide, the board gets updated separately by whoever remembers, and within a week the two have quietly diverged, usually in whichever direction avoids an awkward conversation about what got dropped. This is exactly the gap that closes when the committed list turns into real cards on the ShipSprint board the same session: there's no second document to drift away from what the team actually agreed to.

Carryover disappears into this sprint's total. Unfinished work from last sprint gets folded back in without anyone noticing the pattern, so a team that consistently overcommits never sees the trend that would tell them to stop. Three sprints of quietly absorbed carryover looks, from the outside, exactly like three sprints of accurate planning, until someone finally adds it up.

Risks get mentioned but not written down. Someone says "the sandbox access might not come through in time" out loud in the meeting, everyone nods, and then nobody writes it anywhere. Two weeks later it's the reason the sprint missed, and it's treated as a surprise instead of the known risk it actually was.

How to use it

1. 01Hold planning at a fixed point in the cycle and write the goal sentence first, before anyone opens the backlog. It's much harder to write honestly once a list of tickets is already on the table.
2. 02Calculate capacity honestly. Subtract approved leave and any known interruptions for the sprint. A number based on headcount alone is wrong on day one and stays wrong for the whole sprint.
3. 03Pull items until capacity runs out, not until the backlog feels sufficiently covered. Stop pulling the moment the committed total meets the capacity number, even if it feels early.
4. 04Turn each committed line into a task before the meeting ends. A commitment that only exists as a document tends to stay a document, and the board quietly stops reflecting what was actually agreed.
5. 05File next sprint's carryover as its own line, not blended into the new total, so the trend is visible across sprints and not just guessed at from memory.
6. 06Say the risks out loud and then write them down in the same breath. A risk mentioned once in a meeting and never recorded has a way of becoming an excuse instead of a warning.

The page itself is short on purpose. It's meant to be read in under a minute by anyone who wasn't in the room, which is a different job than the board: the board is for the team working the sprint, this page is for anyone checking what was agreed. A page that grows past one screen usually means the planning meeting tried to do the board's job as well as its own, and both end up worse for it.