Is Your Sprint Plan Realistic? A Practical Guide to Jira Capacity Planning

The usual test for whether a sprint is realistic is quick: add up the committed story points, compare them to the team's average velocity, and if the total is at or under it, ship the plan. It's the right instinct — you're checking demand against a limit. The trouble is that "average velocity" is the wrong limit, and a single team-level number hides the two things that actually sink sprints. Here's a more honest way to check.

Why "points ≤ velocity" isn't capacity planning

Average velocity is a historical average of a team that had everyone present. This sprint isn't that team. Two people are on leave for three days, one is half-allocated to another project, and there's a company holiday on Friday. Your real capacity for this sprint could be well below the average — and comparing your commitment to the average tells you nothing about that gap.

It also collapses everyone into one bucket. A sprint can be comfortably "under velocity" as a team while one engineer is loaded to 150% and someone else is at 40%. The team total looks fine; the plan is not fine.

What a realistic check actually looks at

1. Real capacity, not average speed

Start from what the team can actually do this sprint: each person's capacity, minus their time off, minus company holidays, adjusted for how much of their week is really available. That's a very different number from last quarter's average velocity — and it's the number your commitment should be compared against. A practical refinement is effective capacity: raw capacity multiplied by how much of what the team plans it historically delivers (if you don't have that history yet, a standard 80% is a safer assumption than 100%).

Once you have that, the verdict is simple: capacity comfortably above demand is deliverable; capacity that only just covers demand (say, within 90–100%) is tight; capacity below demand is overcommitted. No amount of optimism changes which bucket you're in.

2. Check every person, not just the team

Roll the same demand-versus-capacity check down to each individual. Useful bands: over ~115% of their capacity is overloaded, 90–115% is optimal, 60–90% is available, and under 60% is underloaded. This is where the hidden failures live — the sprint that's "green" overall but has one person who can't possibly finish their share. Balancing that load (or moving work off the overloaded person) is often the entire fix.

3. The mid-sprint trap: judge remaining work against remaining capacity

This one catches almost everyone. Halfway through a sprint, its full capacity no longer applies — you've already spent the elapsed days on the work that's now done. A 36-point sprint at its midpoint has roughly 18 points of capacity left, not 36. So a sprint with 20 points of open work can read "fine" against its full capacity while being genuinely overcommitted against the capacity that's actually left. The honest check compares remaining demand to remaining capacity — the days still ahead of you — so a stuffed sprint can't look deliverable just because it hasn't run out of calendar yet.

4. Look week by week, not just per sprint

Overload rarely spreads evenly. A sprint can net out fine while one specific week inside it is badly over capacity because three deadlines and a holiday collide. Bucketing demand and capacity by week surfaces exactly which weeks break, so you can move work off the pinch point instead of finding out when it's due.

From "looks fine" to "is fine"

A realistic sprint plan is one where the work that's left fits the capacity that's actually left — for the team and for each person, this week and next, with time off and holidays already subtracted. Check it that way and you stop shipping plans that were overcommitted from day one and only revealed it at the retro.

Project Commander runs exactly this check on your live Jira project. Every sprint carries a Deliverable / Tight / Overcommitted badge from a direct demand-versus-capacity comparison; active sprints are judged on remaining work against remaining capacity; each team member gets a load band; and when a sprint is overcommitted, Auto-Level rebalances the work across sprints in one click so you can see a plan that actually fits.