A sprint planning template is the most downloaded and least examined artifact in Scrum. Every team has one. Very few teams can say which field on it decides whether the sprint will finish. A LinkedIn post that gathered several dozen comments this fortnight put it more bluntly, warning new scrum masters against the habit of planning to a flat 80% of capacity, and the thread under it is a tour of every way a template can look complete while the number that matters is a guess.

This article gives you a sprint planning template with five fields, explains why the capacity field is the one that does the work, and shows how to fill it from real availability rather than a percentage. It sits under our sprint planning guide and pairs with the sprint planning checklist; the template is what you fill in, the checklist is what you confirm before you commit.

The five fields

1. Sprint goal. One sentence, one outcome. If you need “and”, it is two goals. See how to write a sprint goal.
2. Capacity, per person. Working days in the sprint, minus days off, minus known non-sprint load (support rota, another project, onboarding). Summed, not assumed.
3. Carryover. What is coming in unfinished from the last sprint, with its remaining estimate, before any new work is discussed.
4. Committed backlog. The items the team is promising, each one refined and sized, in the order they will be pulled.
5. Risks and dependencies. Anything outside the team that has to happen for the goal to be met, with a name against it.

Most templates in circulation have fields one, four and five. Some have three. Almost none have two in a form that survives contact with a real team calendar, and that is the gap the LinkedIn thread was really about.

Why “80% of capacity” is the wrong number

The 80% rule is popular because it is easy: take the team’s nominal hours, knock a fifth off for meetings and interruptions, plan to the rest. The post that started the discussion argues, correctly, that 80% is already too full for most teams because it leaves nothing for the unplanned work every sprint attracts. But the deeper problem is not the percentage. It is that a percentage is applied to a nominal number nobody checked.

Two people out for three days, a third on the support rota for the whole sprint, a fourth detailed to another team for half of it: a ten-person team can lose a quarter of its capacity to known, scheduled absence before a single interruption occurs. Apply 80% to the nominal figure and you have planned to 80% of a number that was never real. Apply it to the actual availability and the commitment has a chance. The capacity field earns its place on the template only when it is built person by person, day by day.

Filling the template from Jira instead of from memory

The reason the capacity field goes unfilled is that the information lives in three places: the HR calendar, the support rota, and each person’s head. Divim’s Sprint Planning, Capacity & Resource Planning for Jira puts per-person availability for the sprint on the same screen as the backlog being planned, so the capacity field is a total the team can see and argue with, not a percentage someone applied in a spreadsheet the night before. Days off and partial allocations are entered once and the sprint total moves with them.

Field four has its own failure mode: items that arrive at planning unsized or unrefined, which the template then records as committed anyway. Backlog Refinement for Jira is built so that the refinement happens before the meeting, and the committed backlog on the template is a list of items that were actually ready. The template does not get better. What goes into it does.

A sprint planning template you can copy

Sprint name and dates. Sprint goal (one sentence). Capacity table: one row per person, working days, days off, other load, net days, with a total at the bottom. Carryover: item, remaining estimate, why it did not finish. Committed backlog: item, estimate, owner, in pull order. Risks and dependencies: description, owner, date needed by. Confidence: the team’s own read, recorded at the end of planning, so the retrospective can compare it with what happened.

That last line is the one most templates are missing. A commitment with a confidence attached can be learned from. A commitment without one is just a list. For the meeting that fills the template in, see the sprint planning meeting agenda, and for the whole method, the complete sprint planning guide.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio