Sprint Planning

If you've worked in an agile team, you know sprint planning: the team gathers, reviews the backlog, estimates stories, and commits to a sprint goal. It's well-documented, widely practiced, and — here's the part nobody talks about — often done with zero regard for actual capacity.

A team of six "commits" to 80 story points. But one person is on holiday Thursday and Friday. Another has 12 hours blocked for a different client. A third just came off a brutal sprint and is running on fumes. The real available capacity isn't what the velocity chart says — it's whatever is left after time off, cross-project allocations, and the overhead nobody accounts for.

The Missing Input

Good sprint planning needs a capacity check before the commitment. That means:

1. Pull each team member's availability for the sprint window. 2. Subtract any existing allocations to other projects. 3. Factor in overhead — meetings, code reviews, support rotation. 4. What's left is your true sprint capacity in hours, not an abstract point number.

A 10-day sprint with a 5-person team looks like 400 hours on paper. In practice, after holidays, a half-time allocation to Project B, and the usual meeting tax, you might have 260 usable hours. Planning to 400 is how teams end up in perpetual overallocation.

Bridging the Gap

The fix is connecting your sprint board to your resource schedule. When the schedule already shows who's available and for how many hours, sprint planning becomes a conversation grounded in reality rather than optimism. You'll still estimate stories — but you'll stop promising work that physically can't fit into the sprint window.