Sprint Capacity Planning: Account for the Hidden Work

A hypothetical team starts with 25 person-days on a planning spreadsheet. Leave reduces that to 23; support, mentoring, and recurring duties consume another eight. Sprint capacity planning must explain the remaining 15 before anyone promises 25 days of feature delivery.

Run a short work sample

For two weeks, ask the team to record meaningful chunks of work in a few categories. Use existing tickets where possible. A daily rough allocation is usually more useful than asking people to reconstruct every five-minute interruption.

Explain that the sample evaluates the plan, not individual effort. Do not publish a leaderboard or assume a high support allocation indicates poor productivity.

A hypothetical five-developer team might report 23 available person-days after leave. Recurring duties, support, and onboarding account for approximately eight of those days. That leaves roughly 15 for planned delivery, before considering uncertainty and uneven skill availability.

Those numbers are an example, not a staffing formula. The important discovery is that the original plan may have assumed 25 feature days that never existed.

Should a manager track every developer's hours?

Not for this exercise. A short, approximate team-level sample can reveal missing work without continuous monitoring. Use more detailed time records only when a separate operational or contractual need requires them, and explain that purpose.

Make sprint capacity planning include the real work

A person being employed for five days does not mean five days are available for uninterrupted implementation. Leave, interviews, release support, and coaching all use capacity.

Atlassian's 2025 developer-experience research found substantial self-reported time lost to organizational inefficiencies. That supports looking beyond coding when investigating delays. It does not mean every non-coding activity is waste: a careful review or a useful design conversation can prevent much more work later.

Distinguish three categories:

• Planned delivery work, including its review and validation.
• Necessary recurring or unplanned responsibilities.
• Avoidable friction, such as waiting for access nobody owns.

The response differs for each. Plan the first, provide coverage for the second, and reduce the third.

Find the constrained responsibility

Capacity is not completely interchangeable. Fifteen available days do not help if every feature requires the same reviewer, database expert, or release owner.

Ask about these responsibilities before dividing a backlog among developers. They determine whether work can finish, not just whether it can begin.

Is code review part of sprint capacity?

Yes. Every change that requires review consumes somebody's time. Include review capacity when deciding how many changes to start, even if the tracker does not assign separate points to it.

Limit how much work starts

A board full of active items may indicate that the team is repeatedly switching tasks while waiting. DORA's work-in-process guidance supports limiting concurrent work and focusing on completion.

Choose a limit with the team that reflects the actual workflow. When the review queue fills, help finish or review existing work before starting another feature. Investigate a persistent queue rather than simply raising the limit.

My article on PHP team management without workflow bloat explains why this should remain a lightweight operating agreement.

Plan with recent demand, not a universal buffer

If support demand fluctuates, inspect several comparable weeks. Identify the ordinary range and the occasional exceptional incident. A blanket rule such as reserving 20% for every team can be too much or too little.

Choose an initial allowance, say what it covers, and agree on what happens if it is exceeded. The response might be deferring lower-priority work, activating backup coverage, or revising the delivery forecast within the team's planning framework.

Keep the allowance visible. Hidden buffers are difficult to defend because stakeholders cannot see the responsibility they protect.

What if stakeholders insist on using all available capacity?

Clarify that support, validation, mentoring, and releases already use capacity. Present the work that must be removed or the service consequence of removing its coverage. A full plan should reflect the complete responsibility, not just the visible feature list.

Compare the plan with the week that happened

At the end of the sprint, examine the largest differences. Did support exceed the allowance? Did a release take longer because the rollback procedure was unclear? Did someone quietly spend two days helping another team?

Turn that explanation into the next planning change. A recurring review bottleneck might justify training another reviewer. Repeated access delays need an owner. A one-off incident does not automatically justify lowering every future commitment.

Also ask what valuable work was invisible. Recognizing mentoring and incident prevention matters for fair performance conversations as well as planning. See managing developer workload without burnout.

If your plans consistently exceed what the team can finish, my technical leadership consulting can help identify the missing work and the constraints worth fixing first.