A practical sprint planning template covering backlog refinement, sprint goal writing, capacity calculation, and the common mistakes that cause sprints to fail. Includes a worked example.
Sprint planning fails in one of three ways: the team commits to more than it can deliver (overcommitment), the sprint goal is so vague it is meaningless ('improve performance', 'finish the backlog'), or the backlog items are not refined enough to estimate accurately, causing mid-sprint surprises. The root cause is almost always one of two things: backlog items were not refined before the planning meeting (items are discussed for the first time in planning, with no prior estimation), or capacity was not calculated before committing (the team picks stories based on gut feel rather than actual available hours). This guide covers both.
73%
Of teams regularly overcommit in sprint planning
40%
Of sprint failures caused by under-refined backlog items
2×
Improvement in sprint completion rate with pre-sprint refinement
Most sprint planning failures are caused by work that was not done before the meeting. The meeting itself should be primarily a confirmation of decisions already made, not a first-time discussion of what goes in the sprint.
Backlog refinement (2–3 days before)
Review the top 20–30 backlog items. Split stories larger than 8 points. Clarify acceptance criteria on items likely to be pulled into the sprint. Estimate anything unestimated in the top 15 items.
Capacity calculation (1 day before)
Count available days for each team member. Subtract known meetings, PTO, on-call duties. Multiply by your team's average focus factor (typically 60–70% of raw hours). This is your sprint capacity in hours.
Velocity check (1 day before)
Review the last 3 sprints' delivered story points. Calculate the average. This is your starting point for sprint commitment — not a ceiling, but a baseline.
Sprint goal draft (1 day before)
The tech lead and PM draft a 1–2 sentence sprint goal before the meeting. The team refines it in the first 10 minutes of planning, but starting with a draft is far more effective than starting from nothing.
Priority order confirmed (morning of meeting)
PM confirms the priority order of the top 15 backlog items. Any last-minute priority changes are resolved before — not during — the planning meeting.
A good sprint goal is a single sentence that describes the business outcome the team is working toward — not a list of features. It should answer: 'At the end of this sprint, what will be true about the product that isn't true now?' The goal should be specific enough to resolve mid-sprint trade-off questions: if an unplanned bug comes up, does it affect the sprint goal? If yes, it gets prioritised. If no, it waits. Vague goals like 'improve the billing experience' fail this test — any billing-related task can justify itself against a vague goal. A good goal might be: 'Payment flows for Starter and Pro subscriptions work end-to-end in both INR and USD with correct tax calculation.' That goal helps the team make prioritisation decisions and gives stakeholders a clear statement of what the sprint delivers.
Weak sprint goals
Strong sprint goals
Capacity calculation is simple but often skipped because it feels like overhead. It is the most impactful 10-minute exercise in sprint planning. For each team member: take their available working days in the sprint, subtract planned time off and recurring meeting load (typically 20–40% of a workday), multiply by your team's focus factor (0.6–0.7 is typical). Sum the result across the team in story points, using your historical velocity to calibrate (if your team delivers 1 story point per focused hour on average, that becomes your conversion factor). This gives you a ceiling for sprint commitment. Most teams find they have been committing to 30–40% more work than their calculated capacity, which explains why sprints consistently end with incomplete items.
The focus factor
Focus factor is the percentage of a workday spent on sprint tasks vs. meetings, reviews, admin, and interruptions. For most product teams it is 60–70%. If your team consistently misses sprint goals, measure actual focus time for one sprint — the number is almost always lower than people think.
A well-run sprint planning meeting has four parts and should take no more than 90 minutes for a team of 4–8 people. Any longer and backlog items were not refined enough before the meeting.
Sprint goal alignment (10 min)
Review the draft sprint goal. Discuss and refine. Confirm everyone understands what the sprint is delivering and why it matters.
Capacity review (10 min)
Review calculated capacity per team member. Confirm any late-breaking PTO or blockers. Establish total available story points for the sprint.
Backlog walkthrough (40–60 min)
Walk the priority-ordered backlog top-down. For each item: confirm the estimate is still accurate, check acceptance criteria, assign an owner. Stop when you hit the capacity ceiling.
Commitment confirmation (5–10 min)
Review the full sprint board. Does the team collectively believe this is achievable? If anyone has serious doubts, adjust now — not in week two.
Decuga tracks sprint velocity, completion rate, lead time, cycle time, and scope creep automatically as your team moves tasks through the board. After each sprint, the analytics tab shows you delivered story points vs. committed points (your completion rate), the average lead time for tasks completed this sprint, cycle time from in-progress to done, and how many tasks were added mid-sprint (scope creep). These four metrics, tracked over 3–5 sprints, tell you whether your estimation is improving, whether your focus factor assumptions are accurate, and whether scope creep is a systemic problem. No manual data entry, no spreadsheet — just the sprint data you already have, surfaced automatically.
Ready to try Decuga?
Start free — no account or credit card required. One month free trial of the Starter plan.
Start free trial