Sprint planning: how much work should you actually commit to?
Teams overcommit because planning is optimistic and history is inconvenient. Here's how to size a sprint from evidence instead of hope.
Almost every team that misses sprints misses them the same way: the sprint was too big on day one. Nobody noticed, because the plan was made from optimism and the evidence was in a chart nobody opened.
Velocity, in one paragraph
Velocity is how many story points your team actually completed per sprint, averaged over the last few sprints. It isn't a target, a performance metric, or comparable between teams — it's a measurement of your team's throughput in your team's units. Its only job is to tell you what a realistic next sprint looks like.
The rule of thumb
Commit to roughly your three-sprint rolling average, adjusted for who's actually available. If you completed 30, 34 and 26 points, your average is 30 — so plan about 30, less if someone is on holiday.
Teams get into trouble by:
- Planning to their best sprint ever. That sprint had unusually clear work and nobody off sick.
- Ignoring carry-over. Work dragged in from last sprint is not free capacity.
- Forgetting the non-sprint work. Support rotations, interviews, incidents. If a third of your week is unplanned work, a third of your capacity isn't available.
- Treating points as hours. The moment a point means an hour, estimates become commitments and people pad them.
Estimating without ceremony
Use a small scale — 1, 2, 3, 5, 8 — and stop estimating anything bigger than 8. An item that large isn't estimated, it's unsplit. Break it up, and if you can't, that's your signal it isn't understood well enough to plan.
Estimate relatively, not absolutely: "is this bigger or smaller than that thing we did last month?" is a question humans answer accurately. "How many hours is this?" is not.
Catching an overcommitted sprint on day one
The information needed to spot this is available during planning: you have the committed points and the historical average. The comparison just usually isn't put in front of anyone.
VectorKan does that comparison automatically and says it in words — for example, "overcommitted: 140% of your usual velocity, about 14 points likely won't land." Cutting scope during planning is a five-minute conversation. Explaining a missed sprint at the review is a much longer one.
What to do when you're over
Cut whole items, not corners on all of them. Six finished features beat nine at 80%, because 80% of a feature ships to nobody. Decide explicitly what's dropping out, tell whoever asked for it, and start the sprint with a plan the team believes.
Frequently asked questions
How many story points should a sprint have?
Use your team's rolling average from the last three sprints, adjusted for holidays and carry-over. There's no universal number — points are relative to your team, so comparing point totals between teams is meaningless.
What is a good velocity?
A stable one. Velocity is a planning input, not a score, and a team whose velocity is predictable is easier to plan around than one whose velocity is high but erratic.
Why do teams consistently overcommit?
Planning tends to assume the best case: no incidents, no sick days, no carry-over, and full clarity on every ticket. Comparing the plan against actual historical throughput before the sprint starts corrects most of it.
Should story points be converted to hours?
No. Once a point equals an hour, estimates become commitments, people pad them, and you lose the fast relative sizing that made points useful in the first place.