Every few months an Agile thread reopens the same fight, and the sprint planning capacity spreadsheet is always at the centre of it. Someone posts that the beautiful, elaborate capacity sheet — hours per person, minus PTO, minus ceremonies, down to the half-day — is the problem. The replies split hard. One camp calls the sheet planning theatre. The other camp answers that you cannot promise anything to anyone without it. Both sides are half right, and the disagreement is not really about spreadsheets.

What the argument is actually about

Strip the thread down and it is a push-versus-pull argument. One side wants to stop pushing work into a sprint based on a capacity number guessed on day zero, and instead pull work in as real capacity frees up. The other side answers that a team still needs some level of confidence in its ability to deliver inside a timeframe — otherwise the sprint goal is a wish and the retro has nothing to inspect.

Neither position requires killing the spreadsheet. What both positions reject is the same thing: treating a capacity number calculated before the sprint starts as a fact that stays true for two weeks. The sheet is not wrong. The claim of precision is.

Where the capacity spreadsheet earns its keep

The strongest defence in these threads is simple: some inputs are not predictions at all. Holidays, approved leave, a training day, a person who is 50% on your team and 50% on someone else’s — these are known quantities. Ignoring them does not make a team more agile. It makes the commitment quietly dishonest.

• Known absences. Two people out for three days each is 30% of a five-person sprint. That is not a forecast; it is arithmetic.
• Part-time and split allocation. Averages hide the one engineer carrying three teams. Per-person capacity is the only way that surfaces before planning rather than after.
• The support tax. If a team reliably loses a day a week to production support, the sheet is where that shows up as a number instead of a grumble.

If your team is part-time or matrixed, this is the part of the spreadsheet to keep. We covered the mechanics in how to calculate team capacity when half your team is part-time.

Where it quietly lies to you

Three failure modes come up again and again in the replies.

1. Double estimation. The team sizes the backlog in story points, then re-estimates the same items in hours to fill the sheet. That is a well-documented anti-pattern: it costs a chunk of the planning meeting and produces two numbers that disagree. Pick one currency. Our take on which: story points vs hours.
2. Precision theatre. A cell reading 6.5 available hours implies a confidence nobody in the room actually has. The decimal point is doing persuasion, not measurement.
3. It goes stale on day two. Someone gets pulled onto an incident, a dependency lands late, a story turns out to be twice its size. The spreadsheet does not know, because nobody reopens it until the next planning session.

That third one is the real damage. A capacity number that is never revisited turns into a commitment that is never re-forecast — which is how a sprint fails on day nine for a reason that was visible on day three.

The fix: capacity as a ceiling, not a shopping list

The version of the spreadsheet that survives contact with a real sprint does three things differently.

• Plan to roughly 80% of it. Filling capacity to 100% leaves no room for the interrupts that arrive every sprint anyway. The remaining 20% is not slack; it is the thing that makes the other 80% land.
• Let the sprint goal do the constraining. Capacity tells you what will not fit. The goal tells you what matters. Only one of those belongs at the top of the board.
• Re-read it mid-sprint. Capacity is a live number. If it is only correct on day one, it is only useful on day one.

Doing this in Jira without the spreadsheet

The reason so many teams still maintain a side spreadsheet is that Jira’s default sprint view shows the work but not the people. Sprint Planning, Capacity & Resource Planning for Jira puts per-person capacity next to the sprint backlog on one screen: individual availability including part-time and multi-team allocation, remaining capacity that updates as work moves, and over-allocation surfaced during planning instead of during the retro. The sheet stops being a parallel artifact because the numbers live where the decision is made.

The upstream half matters just as much. Most planning meetings run long because the backlog was not touched since the last one — which is a refinement problem wearing a planning costume. Backlog Refinement for Jira keeps items sized and ready so planning is a selection decision, not a discovery session.

Where this sits in the wider practice

The capacity question is one input into a larger meeting. For the full workflow — the goal, the estimation, the selection, and the mistakes that keep repeating — start with our pillar guide: Sprint Planning: The Complete Guide for Agile Teams in Jira. If you want the meeting itself to run shorter, the sprint planning checklist is the fastest place to start, and common sprint planning mistakes covers the patterns that produce the spreadsheet in the first place.

And if the capacity number is sound but the meeting around it still overruns, the mechanics matter as much as the arithmetic. Our step-by-step walkthrough of how to run sprint planning in Jira covers the sequence — sprint goal, estimation, capacity check, selection — that turns an available-hours figure into a commitment the team can actually stand behind.

Keep the spreadsheet’s honesty about who is actually available. Drop its pretence that the number stays true. That is the whole argument, settled.