Most sprint failures do not arrive with a bang. They creep in during planning, when the team picks a goal without checking who is actually available to do the work. The capacity test is the small habit that separates a realistic sprint goal from wishful thinking.
Scrum does not force the practice. The Scrum Guide treats capacity as something developers should know about based on past performance and immediate availability, not as a mandatory step. That soft framing is exactly why teams keep skipping it.
The short version
- The capacity test is the check of who is actually available during a sprint, before a goal is set
- The Scrum Guide does not require the practice; it only recommends that developers know their upcoming capacity
- Ignoring it leads to two failure modes: over-commitment and false caution
- Both failure modes erode stakeholder trust when they repeat across sprints
The cost of skipping it
Capacity is not constant. Public holidays, sick leave, vacations, parental leave, and resignations all chew into it. New joiners add hours but usually subtract velocity during onboarding. A team that pretends its capacity from last sprint still applies is setting up the next sprint to fail.
Two outcomes tend to follow. The first is over-commitment: the team picks a sprint goal it cannot realistically finish, then misses it in front of stakeholders. The second is the opposite trap, where the team hedges so hard that the goal becomes tiny and nobody feels the sprint was worth running. Both look different, but they share a root cause: the goal was set without a capacity conversation.
The deeper damage is trust. Stakeholders do not see your planning meeting; they see whether valuable increments ship on time. When sprints miss repeatedly, those stakeholders start treating every commitment as suspect, which makes future planning harder for everyone.
How to run the test in five minutes
The fix is not glamorous. Open the sprint planning meeting with a quick capacity pass. List every team member, mark the days they are available, and write down the resulting person-days. Subtract meetings, on-call rotations, and any known support load. The number that comes out is the ceiling for this sprint's commitment.
This is not a forecast in story points. It is a sanity check. If the team has been delivering well and several members are suddenly out for most of the sprint, the realistic target is much smaller than usual. Pretending otherwise wastes a sprint and a round of stakeholder goodwill.
Our analysis
Most agile advice focuses on ceremonies and artifacts, which is why the capacity test gets ignored. It is not on any checklist. It does not produce a document. It only produces a number the team has to be honest about.
Teams that skip the test usually do so because they want to preserve optimism. Nobody wants to start planning by saying, "Half of us are out next week." But pretending otherwise does not protect morale; it sets up a public failure that hurts morale far more.
There is also a subtle cultural point. Self-managing teams are supposed to make capacity decisions themselves. Handing capacity to a manager or a Scrum Master removes the team's ability to learn how to forecast, which is one of the core skills Scrum is meant to develop.
Worth watching: whether your retrospective ever surfaces capacity surprises. If the team is regularly surprised by who was or was not available, the test is not being run early enough.
Worked example
Say two of your engineers are on a long-running training course that eats most of their time this sprint, and a third is on parental leave. Run the test before pulling backlog items. You have far less effective capacity than the team name suggests. Pull work accordingly, and tell the product owner early that the goal will be smaller. The alternative is pulling a full slate of stories, missing several, and explaining the miss in the review.
Bottom line
Spend five minutes on the capacity test. Every sprint. It is the cheapest insurance your team can buy against the most common sprint failure pattern, and it directly protects the trust your stakeholders place in every commitment you make.
Key takeaways
- The capacity test is a quick check of who is available before setting a sprint goal
- Skipping it causes both over-commitment and false caution, both of which damage stakeholder trust
- Running the test takes five minutes and turns capacity surprises into planned trade-offs
Frequently asked questions
Does the Scrum Guide require a capacity test?
No. The Scrum Guide only recommends that developers know their upcoming capacity based on past performance and immediate availability.
What is the most common symptom of skipping the test?
A sprint goal that is either too ambitious or unrealistically small, both of which undermine trust with stakeholders.
How long should the capacity test take?
Roughly five minutes at the start of sprint planning, according to standard Scrum practice.
Who runs the capacity test?
The developers, since Scrum teams are self-managing and own their own capacity decisions.