How to do Agile Capacity Planning in Agile Scrum

Capacity planning in Scrum means working out how much time the team genuinely has available in the coming Sprint, after leave, holidays, meetings and support work are removed. It gives the Developers a realistic ceiling before they decide how much to pull in, and it is most useful for teams whose availability changes from Sprint to Sprint.

Key Highlights

• Capacity is available time. Velocity is delivered output. Confusing the two is the most common mistake teams make here.
• The calculation is simple arithmetic, and the difficulty is entirely in being honest about what to subtract.
• A focus factor accounts for the gap between hours present and hours spent on Sprint work. Most teams land between 0.6 and 0.8, and using someone else's number without checking your own is where the plan breaks.
• Capacity planning helps most when availability swings. Stable teams usually get better forecasts from velocity alone.
• The output is a ceiling, not a target. Filling capacity exactly leaves no room for the things that always happen.
• If capacity says one thing and velocity says another, trust velocity. It is measured, and capacity is estimated.

Capacity Is Not Velocity

Worth settling first, because almost every problem in this area traces back to it.

Capacity is how much time the team has available for Sprint work. It is calculated in advance, from a calendar, and it is an input to planning.

Velocity is how much the team actually completed in past Sprints. It is measured after the fact, usually in points, and it is an observation rather than a plan. Our guide to agile velocity covers how it is calculated and where it is reliable.

The reason this matters is that they answer different questions. Capacity answers how many hours we have. Velocity answers how much we historically get done with hours like those. Velocity already includes every inefficiency a capacity calculation has to estimate: interruptions, rework, meetings that overran, the item that turned out harder than expected.

Which is why a stable team is usually better served by velocity alone. If the last five Sprints delivered 28, 31, 26, 30 and 29 points with a full team, the sixth will probably deliver around 29. No capacity arithmetic improves on that.

Capacity planning earns its place when the team is not stable. Two people on leave, a public holiday, a new joiner at half speed, a Sprint with a two day company offsite. In those cases velocity from a full team overstates what is possible, and capacity is what tells you by how much.

If you are working through Scrum mechanics and want to check where you stand, our free CSM practice test covers the framework and takes a few minutes.

The Calculation

Six steps, in order.

Step one: count the working days. A two week Sprint is normally ten working days. Subtract public holidays. If there is a holiday on the Tuesday of week two, you have nine.

Step two: list each person's availability. Individually, not as a team average. Someone on leave for three days has seven available days, not ten. A part time member at three days a week has six.

Step three: subtract known commitments. Interviews, training, an all hands, a planned production release, time promised to another team. If a developer is spending two days supporting a launch, those days are not available.

Step four: convert to hours. Use actual working hours rather than the contracted figure. Six to seven hours is realistic for most people once ordinary overhead is accounted for, and using eight builds an error into the plan on day one.

Step five: apply a focus factor. This is the percentage of available time that actually goes to Sprint work rather than everything else. More on this below, because it is where the judgement sits.

Step six: subtract recurring Scrum events. Daily Scrum, Sprint Planning, Review and Retrospective. For a two week Sprint these typically consume five to seven hours per person. Some teams fold this into the focus factor instead, which is fine as long as it is not counted twice.

What comes out is a number of hours the team can realistically spend on Sprint Backlog items. That number goes into Sprint Planning as a constraint the Developers use when deciding what to select.

The Focus Factor

The step most articles state without explaining, and the one that decides whether the whole calculation is useful.

A focus factor acknowledges that being at work is not the same as working on Sprint items. Emails, code review for other teams, an unplanned production issue, a colleague asking for help, context switching between items. None of it is waste exactly, and all of it consumes the day.

Common ranges look roughly like this.

The important part is that you should be deriving your own rather than adopting a number from an article. The method is straightforward: take the last three Sprints, compare the hours the team had available against the hours actually recorded against Sprint items, and the ratio is your focus factor. Most teams doing this for the first time are surprised by how low it is.

A team that assumes 0.8 when the reality is 0.6 overcommits by a third every Sprint. That shows up as carryover, and it usually gets blamed on estimation rather than on the planning assumption that caused it.

One caution. A low focus factor is information, not a verdict on the team. If it sits at 0.5, the useful question is what is consuming the other half, and quite often the answer is support work that should be visible in the backlog rather than absorbed silently.

A Worked Example

Real numbers make this concrete. A team of five, two week Sprint, one public holiday.

Working days available: nine after the holiday.

Total: 35.5 person days.

At 6.5 working hours per day, that is 231 hours.

Apply a focus factor of 0.65, derived from the team's own last three Sprints: 150 hours.

Subtract Scrum events. Roughly six hours per person across the Sprint, so 30 hours for the team: 120 hours of realistic capacity.

That last number is what goes into planning. It is a long way from the 400 hours a naive five people times ten days times eight hours calculation would produce, and that gap is exactly why the exercise is worth doing.

Note what happened to Developer B. Three days of leave removed roughly a tenth of the team's capacity for that Sprint. Without the calculation, a team working from full team velocity would have planned as though those days existed.

Turning Hours Into a Plan

Capacity comes out in hours. Backlog items are usually sized in story points. Bridging the two is where teams get stuck.

Two approaches work, and one does not.

Adjust velocity proportionally. The simplest and usually the best. If full capacity is normally 180 hours and this Sprint is 120, the team has 67 percent of normal capacity, so plan around 67 percent of normal velocity. A team averaging 30 points plans for about 20. No conversion between hours and points required.

Task in hours during planning. Break selected items into tasks, estimate those in hours, and stop when the total approaches capacity. This works, and it is more precise, but it makes Sprint Planning considerably longer. Reasonable for teams that need the detail, unnecessary for most.

Deriving an hours per point rate. This is the approach to avoid. Points are deliberately not a time unit, and converting them into one removes the reason for using them. Teams that do this eventually find the rate drifts and stops meaning anything.

The proportional method is what most teams settle on, and it is the one to start with. It requires a reasonably stable velocity to work from, which is another reason velocity is worth tracking properly.

Running the Conversation in Planning

The calculation itself should happen before the session, not during it. Five people watching one person fill in a spreadsheet is a poor use of a planning timebox.

Circulate the numbers beforehand. Leave and known commitments should already be in the calendar, so the capacity figure can be worked out the day before and shared. Anyone who spots an error can correct it before the session rather than in it.

Open planning with the number and the comparison. We have about 67 percent of our usual capacity this Sprint, so we should be looking at around 20 points rather than 30. Ten seconds, and it frames the selection immediately.

Do not defend the number. If someone thinks the focus factor is wrong, that is worth hearing. The figure is an estimate, and a team that feels able to challenge it will produce better ones over time.

Let it inform the selection, not decide it. Capacity says what is possible. The Developers still choose what to take, and there are Sprints where they will reasonably take less than capacity allows because the work is unusually uncertain.

Revisit it if something changes. Someone falling ill in week one changes the picture. That does not mean recalculating formally, but it should prompt an honest conversation about what now fits, and the Sprint Goal is what tells the team which items to protect. Keeping that conversation useful rather than defensive is a facilitation job, and it is one of the areas CSM Certification Training spends real time on.

Handled this way the whole thing adds perhaps two minutes to Sprint Planning. Handled badly it adds forty.

When People Are Split Across Teams

Common, and it breaks capacity planning in a specific way worth naming.

A developer allocated fifty percent to two teams does not deliver half the output in each. Context switching between two codebases, two sets of priorities and two sets of meetings costs real time, and the usual estimate is that the effective figure is closer to thirty five or forty percent per team rather than fifty.

Three practical consequences.

Count shared people at less than their nominal allocation. If someone is nominally half time, plan for forty percent. Teams that count the full fifty percent consistently miss.

Both teams should know. A shared person often ends up quietly prioritising whichever team asked most recently, which means neither team's plan holds.

Treat it as an impediment, not a constraint to optimise around. Better capacity arithmetic does not fix a structural problem. The Scrum Master's job here is to make the cost visible to whoever made the allocation, rather than absorbing it into a spreadsheet.

Where Teams Get It Wrong

Planning to fill capacity exactly. If capacity says 120 hours and the team selects exactly 120 hours of work, the first interruption breaks the Sprint. Leave headroom. Ten to fifteen percent is a reasonable buffer for most teams, and it should be deliberate rather than accidental.

Using contracted hours. Eight hours a day is a contract, not a working reality. Nobody produces eight hours of focused work, and building the plan on that assumption guarantees a shortfall.

Ignoring support and on call. If two people spend a day a week on production support, that is two days per Sprint gone. Teams frequently treat this as invisible, which is why capacity numbers come out too high.

Applying one focus factor to everyone. A senior developer fielding questions all day and a new joiner who is not yet a first point of contact do not have the same focus factor. Averaging is fine for a rough plan and misleading when one person carries most of the interruptions.

Treating capacity as a target. The number is a ceiling. Teams told to hit their capacity will hit it by cutting quality, and the Definition of Done is usually where that shows up first.

Recalculating obsessively. Once per Sprint, during or just before planning, is enough. Teams that maintain elaborate capacity spreadsheets are usually spending more time on the arithmetic than the accuracy justifies.

Forgetting new joiners take capacity rather than adding it. Someone in their first month is typically at 30 to 50 percent, and they consume time from whoever is onboarding them. Counting a new starter as a full team member is one of the more predictable ways to miss a Sprint.

When Capacity Planning Is Not Worth It

Being direct about this saves teams a lot of wasted effort.

If the team is stable, availability rarely changes, and velocity has been consistent for several Sprints, capacity planning adds very little. Velocity already accounts for everything the calculation is trying to estimate, and doing both means maintaining a spreadsheet to arrive at a number you already had.

If the team is new and has no velocity yet, capacity planning is genuinely useful, because it is the only forecast available. Expect it to be rough for the first few Sprints.

If availability swings significantly, holiday season, a team split across projects, frequent support rotations, capacity planning is worth the effort every Sprint.

The honest summary is that capacity planning is a tool for uncertainty in availability. Where that uncertainty does not exist, the effort is better spent elsewhere. A Scrum Master who notices the team is calculating capacity out of habit rather than need should say so, and knowing when to remove a practice is as much part of the role as introducing one. That judgement is covered directly in CSM Certification Training.

Capacity Planning in Scrum Versus Traditional Planning

The distinction matters because people arrive at Scrum carrying assumptions from elsewhere.

In traditional resource planning, capacity is usually planned months ahead, allocated by a manager, and tracked against utilisation targets. People are assigned across multiple projects at percentages.

In Scrum, capacity is calculated for one Sprint at a time, by the team, and used by the Developers to decide what they can commit to. There is no utilisation target, because a team at ninety percent utilisation has no slack and therefore no ability to absorb the unexpected.

The generic discipline of capacity planning across an organisation is a related but separate subject, and the mechanics differ enough that borrowing directly from one to the other tends to cause friction.

The practical consequence: if someone asks for team capacity three months out, the honest answer in Scrum is a range based on velocity, not a schedule. Presenting a precise number for a Sprint that has not been planned yet creates a commitment nobody can keep.

Closing Thoughts

The arithmetic in capacity planning is trivial. The value is entirely in the honesty of the inputs, and specifically in the focus factor, which is where optimism enters the calculation and quietly sets the team up to miss.

Two things are worth holding onto. Capacity is a ceiling rather than a target, so planning to fill it exactly removes the room every Sprint turns out to need. And where velocity and capacity disagree, velocity is the one built on evidence.

It is also a practice worth reviewing periodically. Teams adopt capacity planning during a period of instability, the instability passes, and the spreadsheet stays. Noticing that and dropping it is a legitimate improvement, not a lapse in discipline.

If you are building the judgement to run these conversations well, CSM Certification Training covers Sprint Planning, forecasting and the facilitation that keeps them honest, which is where most of this plays out in practice. Request the curriculum for the full agenda and upcoming dates, or start with the free CSM practice test to find your gaps first.