A sprint commitment built on nominal headcount is a commitment to fiction. A useful team capacity planning example starts with the hours people can realistically give to delivery, then makes the trade-offs visible before the Sprint Goal is set. That discipline protects teams from the familiar pattern of optimistic planning, mid-sprint disruption and retrospective explanations.
For Scrum Masters, Engineering Managers and Product Owners, capacity planning is not a promise that every hour will produce a backlog item. It is an operational control. Used well, it helps the team choose a credible amount of work, preserve space for quality activities and expose constraints that leadership needs to resolve.
What team capacity planning should measure
Capacity is the amount of time a team has available for planned delivery during a sprint. It is not the same as velocity, utilisation or the number of people assigned to a team.
Velocity describes what the team has historically completed, usually in story points. Capacity describes the practical time available in the upcoming sprint. Both matter. Velocity gives a valuable delivery baseline; capacity explains why that baseline may not apply this time.
A two-week sprint with six engineers does not automatically create 60 person-days of delivery capacity. Planned leave, public holidays, support cover, ceremonies, training, production work and team members split across initiatives all reduce the usable total. Ignoring these factors does not make them disappear. It simply moves the problem into the sprint.
The objective is not to drive utilisation towards 100 per cent. A team operating with no slack cannot respond intelligently to a production incident, a late discovery or a genuine priority change. It will usually cut testing, documentation or technical debt work first, creating a larger delivery cost later.
A team capacity planning example for a two-week sprint
Consider a product squad with a 10-working-day sprint. The team includes four software engineers, one test engineer, one Product Owner and one Scrum Master. The Product Owner and Scrum Master contribute to delivery planning and flow, but they should not be counted as full-time build capacity unless they are genuinely completing delivery tasks.
The initial engineering capacity is straightforward: four engineers multiplied by 10 days equals 40 person-days. The test engineer adds 10 person-days. That gives 50 person-days before operational reality is applied.
| Team member or activity | Calculation | Available capacity |
|---|---:|---:|
| Engineer A | 10 days less 1 day annual leave | 9 days |
| Engineer B | 10 days less 2 days production support | 8 days |
| Engineer C | 10 days less 1 day training | 9 days |
| Engineer D | 10 days less 1 day interview panel | 9 days |
| Test engineer | 10 days less 1 day release support | 9 days |
| Total delivery capacity | | 44 days |
The squad now has 44 person-days, not 50. Next, account for planned team overhead. If the team spends around 10 per cent of its time in Sprint Planning, refinement, Daily Scrum, Sprint Review, retrospective and essential technical coordination, the working capacity falls to roughly 40 person-days.
That figure is a planning input, not an instruction to fill every available hour. The team may reserve a further 10 to 15 per cent for unplanned support, defect investigation and small operational requests. In this case, a sensible planned delivery capacity is 35 to 36 person-days.
This is where the Product Owner makes a better trade-off. Rather than selecting the highest possible number of backlog items, they select work that supports the Sprint Goal and fits the team’s actual ability to design, build, test and integrate it. If the goal requires a risky integration, the reserve may need to be larger. If the team has stable systems and little support demand, it may be reasonable to commit closer to the full 40 days.
Convert capacity into a credible sprint forecast
Time capacity alone does not tell a team how many story points to select. The conversion should be based on the team’s own history, not a generic points-per-day rate imposed across the organisation.
Assume this squad has completed an average of 32 story points over its previous six comparable sprints. However, those sprints typically had 45 effective delivery days after leave and overhead. The upcoming sprint has 36 planned delivery days.
A simple adjustment is:
Capacity-adjusted forecast = historical average velocity × upcoming delivery capacity ÷ typical delivery capacity
In this case:
32 × 36 ÷ 45 = 25.6 story points
The team should therefore discuss a forecast around 25 or 26 points, subject to the nature of the work. If those points include an unfamiliar architectural change, external dependency or complex test environment, 22 to 24 points may be the more professional decision.
This is why capacity planning must sit alongside backlog refinement. A numerical forecast cannot compensate for vague acceptance criteria, hidden dependencies or oversized stories. The arithmetic is only as reliable as the work entering Sprint Planning.
Plan by skill constraint, not just total days
A common planning failure occurs when the total looks healthy but one specialist becomes the bottleneck. In the example above, the squad may have 35 delivery days overall, yet only nine test-engineer days. If every story requires extensive regression testing, the tester’s capacity, not engineering capacity, determines what can finish.
The same issue appears with platform engineers, UX designers, data specialists, security reviewers and people authorised to deploy to production. Treat these as explicit constraints during planning. Do not assume that available developers can absorb the work without examining skills, pairing opportunities, quality risk and the cost of context switching.
Cross-functional teams reduce this risk over time, but cross-skilling is not an instant fix for a sprint already under pressure. Use capacity planning to identify the constraint early, then decide whether to reduce scope, sequence work differently, pair deliberately or secure support.
Build a repeatable planning routine
The strongest teams do not create a fresh spreadsheet from memory every sprint. They maintain a lightweight capacity view that is easy to update and visible to everyone involved in planning.
Start three to five working days before Sprint Planning. Team members confirm leave, recurring support duties, training, release activity and known business commitments. The Scrum Master or delivery lead records this information without turning the process into surveillance. The purpose is to establish availability, not to audit individual effort.
During refinement, identify work that needs scarce skills or has external dependencies. During Sprint Planning, confirm the capacity number, review recent velocity and agree the reserve for uncertainty. The Product Owner then orders the backlog against the Sprint Goal, while the team decides what it can forecast.
At the retrospective, compare planned capacity with what actually happened. If 15 per cent of the sprint was repeatedly consumed by support work, stop treating that work as an exception. Make it a recognised capacity deduction. If the team consistently delivers more than forecast without quality deterioration, inspect whether estimates, flow or the contingency level need adjusting.
Avoid false precision and harmful behaviours
Capacity planning becomes counterproductive when leaders use it to measure individual productivity or justify permanent overcommitment. People are not interchangeable units of output, and person-days do not capture collaboration, complexity or discovery.
Avoid converting every task into hours merely to prove that the plan adds up. For many Agile teams, story points remain the better way to estimate relative effort and uncertainty. Capacity should adjust the sprint forecast, while story-level estimates help the team understand the shape of the work.
Also avoid carrying incomplete work forward without examining why it missed the sprint. A capacity shortfall may be the cause, but so may a blocked dependency, weak refinement, excessive work in progress or quality issues discovered too late. Treat the planning data as evidence for improvement, not as a defence of the current process.
A well-maintained capacity worksheet is one of the simplest battle-tested tools in an Agile operating model. It turns availability into an explicit planning decision, gives Product Owners a defensible forecast and gives teams permission to protect quality. When the next sprint begins, the goal is not to prove that the team can be busy. It is to create the conditions for meaningful work to finish properly.