Sprint Planning Template

The template below is timeboxed to two hours for a two-week sprint, which is enough when refinement happened beforehand and far too little when it did not.

Quick answer: Sprint planning has to produce three things: a sprint goal in one sentence, a set of work the team believes fits, and genuine confidence rather than compliance. Everything else in the meeting is a means to those. Most sprint planning fails because it produces only the second — a list of tickets with no unifying goal and no honest capacity check.

What the Meeting Has to Produce

A goal the team can state in a sentence, a committed set of work, and belief that it is achievable.

A sprint goal, not a list

The goal is one sentence describing what the sprint achieves. "Customers can complete checkout without contacting support" is a goal. "Finish tickets 412, 418 and 423" is a list.

The difference matters mid-sprint. When something unexpected arrives, a goal tells you what to protect and what can be dropped. A list gives you no basis for that decision, so everything gets defended equally and the sprint fails as a whole.

A committed set of work

The items the team believes it can complete, pulled rather than assigned, with acceptance criteria clear enough to start on.

Commitment means something specific: the team has looked at the work, understands it, and thinks it fits. A manager announcing what will be done is not a commitment, whatever it is called.

Confidence the team actually holds

Ask directly at the end: on a scale of one to five, how confident are we? Anything below three means the plan is wrong.

Teams routinely accept plans they privately believe are unachievable. Asking the question openly makes it socially acceptable to say so, which is the point.

The Sprint Planning Template

A two-hour agenda for a two-week sprint, assuming refinement happened in advance.

Time Section Output 0:00–0:10 Last sprint review Completed vs committed, carry-over identified

0:10–0:20 Capacity check Available days after leave, support duty, meetings 0:20–0:35 Sprint goal proposed One sentence, agreed by the team 0:35–1:20 Backlog walkthrough Items pulled, questions resolved, acceptance criteria confirmed 1:20–1:40 Dependencies and risks External blockers named with owners 1:40–1:50 Confidence check 1–5 vote; below 3 means reduce scope 1:50–2:00 Confirm and record Sprint backlog set, goal recorded, owners assigned

A Filled Example

The same template completed for a two-week sprint with a team of five.

Section Example Last sprint Committed 34 points, completed 28. Two items carried over: payment retry logic, error state designs.

Capacity 5 people × 10 days = 50 days. Minus 3 days leave, 5 days support duty, ~5 days meetings = 37 effective days. Recent velocity 26–30 points.

Plan to 27.

Sprint goal "A customer whose card is declined can retry payment and complete checkout without contacting support."

Committed items Payment retry logic (8, carried over). Error state designs (3, carried over). Retry UI implementation (5). Decline reason messaging (5). Retry analytics events (3). Regression tests (3). Total 27.

Dependencies Payment provider sandbox access — owner S.

Thapa, needed by day 3. Copy review from legal — owner A. Rai, needed by day 6.

Confidence 4/5. One concern raised: provider sandbox has been unreliable. Mitigation agreed — if unavailable by day 4, swap in the analytics work.

Not in this sprint Refund flow, saved card management, subscription billing changes.

Calculating What Fits

Start from what the team actually delivered recently, subtract known interruptions, and leave room for the unplanned.

Start from measured velocity

Use the average of the last three to five sprints, not a target and not the best sprint you ever had.

Velocity is a planning input, not a performance measure. Teams whose velocity is treated as a target inflate estimates, and the number stops being useful for planning — which is the only thing it was for.

Subtract the known interruptions

Leave, public holidays, support rotation, interviews, all-hands meetings, training.

Most teams plan against nominal availability and then wonder why they miss. Five people for ten days is fifty days on paper and rarely more than thirty-five in practice. Where the tool tracks time against sprints, this ratio becomes visible rather than debated.

Leave room for what arrives

Every team has unplanned work — production issues, urgent requests, things that were harder than expected.

Reserve a proportion based on your own history rather than a rule of thumb. If a quarter of every sprint has historically gone to unplanned work, plan for three quarters and stop being surprised.

Running the Meeting Well

Refine beforehand, let the team pull work rather than assigning it, and stop the moment capacity is reached.

Groom before, not during

The single biggest determinant of whether sprint planning takes two hours or four is whether the backlog was refined in advance.

Items arriving unrefined mean the meeting becomes a requirements workshop. Run a short refinement session mid-sprint so the top of the backlog is always ready — clear enough that anyone could pick it up.

Let the team pull, do not assign

The team selects what it takes on. This is not ceremony — it is what makes the commitment real.

Assigned work produces compliance. Pulled work produces ownership, and the difference shows in what happens when something goes wrong mid-sprint.

Stop when the capacity is full

When the committed points reach the planned capacity, stop. Do not add one more small item because it looks easy.

That last item is where overcommitment starts, and it is always added with the best intentions.

Common Sprint Planning Mistakes

Three failures: planning to full capacity, treating the goal as a list, and estimating work during the meeting.

Planning to 100 percent capacity

A sprint planned to full theoretical capacity has no absorption for anything unexpected, and something unexpected happens in nearly every sprint.

The result is chronic carry-over, which corrupts velocity data and makes future planning worse.

Plan to what you actually deliver.

A goal that is just a list of tickets

"Complete the checkout tickets" is not a goal — it provides no basis for deciding what to protect when the sprint is disrupted.

Write the goal in terms of what a user can do afterwards. If you cannot, the sprint may not have a coherent theme, which is itself worth knowing.

Estimating in the meeting

Estimating unrefined items during planning is what turns two hours into four and exhausts everyone.

Estimates belong in refinement. Planning is for selecting and committing, not for working out what things are.