Capacity Planning in Scrum: A Simple Method That Holds Up
By Sebastiaan Jansen · · 10 min read
Scrum capacity planning turns real availability into a limit on what the next sprint can hold. Count net hours after leave, meetings, and support, then stop adding backlog items once that limit is full. Do it before anyone calls the sprint committed.
A full backlog looks productive in planning. It gets expensive on day eight, when half the items still haven't started.
What scrum capacity planning is deciding
Capacity is the focused work the people in this sprint can finish. Treat it as a ceiling. It isn't a target to beat, and it isn't last sprint's velocity with a motivational bump.
Teams tend to mix up three numbers:
- Availability is who is here, and for how many days.
- Capacity is availability after meetings, support, and the fact that nobody does sprint work for every hour they are present.
- Commitment is the product-backlog slice that fits inside that capacity, tied to one sprint goal.
Skip the middle number and planning becomes a negotiation about optimism.
Capacity is not velocity
Velocity is finished work from past sprints, usually in story points. Capacity is the time this sprint offers. A team can have a steady velocity and almost no capacity in the same sprint, for example when two people are at a conference and one is on call.
Use velocity as a check. If the hour math matches what recent sprints finished, you are in range. If the load is already full and someone still wants another large item "because we will be focused this time," go with the capacity number.
Story points compare items with each other. They won't tell you that a teammate is out Thursday and Friday. Sprint poker sizes the work, and capacity planning sizes the sprint.
What the Scrum Guide leaves open
The Scrum Guide says the Developers select Sprint items and plan the work for the Sprint Goal. It prescribes no hours, points, or formula, so the team still needs its own repeatable way to decide what fits.
How to do scrum capacity planning
Capacity planning in scrum happens after you know who is in the sprint and before you fill the sprint backlog. In a one-hour planning meeting it takes about ten minutes. The rest goes to the goal, the backlog slice, and how you will deliver it. The fuller sequence is in sprint planning. Capacity is one constraint inside that sequence and doesn't need its own ceremony.
1. List the people and the days
Write down everyone who will pick up sprint items and the days they are actually in. Ten working days is common for a two-week sprint. One person might have seven after a holiday and two days of leave. A stakeholder who only attends the review adds nothing.
Write the days as dates, not as a headcount. "Priya is out Thursday and Friday of week one" is a plan. "We are about five" is a guess you will have to unwind in the review.
2. Set a focus factor
A focus factor is the share of a working day that goes to sprint backlog work. The rest goes to stand-up, reviews, chat, production questions, and the ordinary cost of being on a team.
As an illustration, many teams try 0.6 to 0.7 on an eight-hour day, which is about five hours of sprint work. That is not a benchmark. If half the week is interrupts, 0.7 will lie to you. Take a recent sprint and look at how many of the hours people were present went to items that were already in the sprint backlog at planning. Pick a ratio close to that share, and change it when interrupts change.
One factor for the whole team is enough unless someone's job is different. A person on first-line support three days a week needs a lower factor than everyone else.
3. Subtract known commitments
The focus factor covers ordinary overhead. Named events come off in hours, either before the factor or after it, but never both:
- All-hands, offsites, and training already on the calendar.
- A planned release, migration, or on-call rotation on specific days.
- Interviews, sales support, or a bug quota you already promised.
- A small reserve for the riskiest unknown in the sprint goal, if you always find one.
Recurring interrupts stay in the factor. One-off events go on this list. If you can't name it, don't subtract it.
Do the subtraction in one place and say which place. "Booked hours come off first, then we apply the factor" is a rule the next facilitator can repeat. Mixing the two in the same meeting double-counts the training day or leaves the on-call shift inside the pool.
4. Match work to the number, then stop
Spend the pool on backlog items, widest uncertainty first. Each item needs a rough hour budget that the people doing the work agree with. Points are the cross-check. Hours are what you spend down.
When the pool is gone, the next item waits. "Just this small one" is an argument with a number you already calculated. A sprint planning template with a capacity line, a goal line, and a commitment list keeps the three from drifting apart.
5. Spend the scarce person first
The team total can look open while one role is already full. If only one person can change the payment service, every item that needs that change has to fit in that person's hours, not in the team pool. Put those items on the table first, spend that person's hours, then fill everyone else.
A sprint that is under the team total and over one person's hours stalls in the same place every morning. The board shows movement. The goal doesn't, because the remaining work all waits on the same review.
A worked example
This is an illustration, not a benchmark. Five people, a ten-day sprint, eight-hour days, and a focus factor of 0.65 because last sprint's backlog work was about that share of time present. Booked hours come off first, then the factor. For Priya: (64 − 8) × 0.65 = 36. The pool is 210.
| Person | Days in | Hours present | Already booked | Hours left | At 0.65 |
|---|---|---|---|---|---|
| Priya | 8 | 64 | 8 (training) | 56 | 36 |
| Jon | 10 | 80 | 16 (on call) | 64 | 42 |
| Sam | 10 | 80 | 0 | 80 | 52 |
| Noor | 6 | 48 | 0 | 48 | 31 |
| Lee | 10 | 80 | 4 (interviews) | 76 | 49 |
| Total | 210 |
| Item | Hours | Running total | In? |
|---|---|---|---|
| Checkout error states | 40 | 40 | Yes |
| Invoice PDF fixes | 28 | 68 | Yes |
| Admin export | 36 | 104 | Yes |
| Empty-state copy and layout | 18 | 122 | Yes |
| Retry logic for webhooks | 34 | 156 | Yes |
| Audit log filters | 30 | 186 | Yes |
| Settings redesign | 40 | 226 | No |
226 is over 210, so the settings redesign stays in the product backlog. The slice is 186 hours, which leaves 24 hours of slack for webhook retry, estimated at anywhere between 20 and 50 hours. Don't spend that slack on a seventh item. If you use points, compare only these six items with recent sprints.
Skills decide the cut as much as arithmetic does. Settings redesign needs Lee for most of the UI and Sam for the permissions change. Lee still has room after audit log filters. Sam does not. Checkout, webhooks, and the admin export already use most of Sam's 52 hours, because Sam is the only person who can change the payment service. Dropping audit log filters to "make the redesign fit" would still double-book Sam. The redesign waits. The sprint goal stays on checkout and invoices, which is what the review is supposed to show.
Noor's four days out take away more than enthusiasm can put back. Jon's on-call hours came off before the factor. Leaving them in would plan Jon twice: once as a full ten-day contributor, and again as the person who will spend two of those days on the pager.
Walk one item before you lock the hours. Webhook retry is the widest range on the list, 20 to 50. The people doing it agree 34 is a fair middle, and the 24 hours of slack cover the top of that range only if nothing else expands. If they cannot agree a middle, split the item or leave it out. An item with no agreed budget is how the pool gets spent twice.
Mistakes that make the number useless
Counting bodies, not days. "We are five, so we take what we took last time" falls apart when someone is half gone. Rebuild the table each sprint.
Raising the focus factor so an item fits. If it only fits at 0.8 and your honest factor is 0.6, it does not fit.
Planning bugs at zero. Recurring fixes need a reserve, either a lower factor or an hour bucket that features cannot touch. Otherwise a surprise on Wednesday blows the sprint goal.
Taking too many items. 210 hours is not eleven items. Every item carries its own review, testing, and restart cost. A few finished items beat a wide sprint backlog stuck at 70 percent.
Booking the same hour twice. A design review on Thursday is a named event, so it comes off the pool. The item that needs that review still includes time to prepare for it. Subtract the meeting. Leave the preparation inside the item. Teams that subtract both, or neither, finish the week short and cannot say which line was wrong.
Treating the first plan as final. If someone is ill on day two, cut back to the goal. Falrow cycles keep unfinished work on a reviewed rollover, so the cut stays visible on the board.
Say which item leaves. "We will try" keeps the original list and adds a quiet second list in people's heads. Removing the settings redesign from the sprint backlog, in the meeting, is the decision. Saying you might still get to it is how it comes back on Wednesday without a new capacity check.
Hours, points, and the next date
Keep points for relative size and hours for this sprint's ceiling. Points alone miss that Noor is out.
Once the team is stable, throughput (items finished per sprint) gives you a second check. If the team usually finishes five to seven and the plan has twelve, either the hour math has a hole or the items are smaller than usual.
Forecasts are for work that runs past one sprint. Cycle time tells you when a larger body of work will land. It won't tell you whether webhook retry is done by Friday. Falrow insights calculate cycle time percentiles, cumulative flow, and a Monte Carlo forecast from 2,000 runs on the tickets. A date request gets a range. The next two weeks stay on the capacity table.
Specialists create fake capacity. If only one person can do the database work and four items need it, that person's hours are the constraint, so plan those first. The other four people being free does not create a fifth database hour.
If a stakeholder asks for a date on the settings redesign during planning, answer with where it sits, not with a squeezed factor. It is the first item that did not fit. It starts when a later sprint has room in Sam's hours and in the team pool. That is a queue position, and nobody should hear it as a promise that this sprint will stretch.
What to write down
Keep four lines for next time: people and days, the focus factor, hours subtracted and why, and the committed total. If the factor turns out wrong, change it once and write down the cause. If your tracker has no field for booked hours, keep the table in a note.
Open that note at the start of the next planning meeting, before anyone proposes an item. Last sprint's lines answer three questions in a minute: who was out, what you subtracted, and whether the factor matched the interrupts you actually had. If on-call ate more than the 16 hours you removed, change the subtraction, not the ambition.
Skip the arithmetic only for a non-feature sprint, such as a bug-bash with one goal or a sealed incident. A short meeting is not a reason to skip the number.
FAQ
How do you calculate team capacity in Scrum?
List each person, the days they are in, and the hours already taken by named events. Multiply what remains by a focus factor, the share of a normal day that goes to sprint backlog work. The sum is your pool. Around 0.65 is a common illustration, but use the figure that matched your recent sprints.
What is the difference between capacity and velocity?
Capacity is the time available in this sprint after leave, meetings, and known commitments. Velocity is work finished in past sprints, often in story points. Capacity moves with the calendar. Velocity moves slowly, and only after work is done. Load the sprint from capacity, then check it against recent velocity.
Should scrum capacity planning use hours or story points?
Use hours for the ceiling, because days off and on-call are measured in hours. Use story points to compare items with each other and with past sprints. Points miss that two people are away, and hours can fake precision on work you haven't designed yet. Keep budgets rough, agree them with the people doing the work, and stop when the pool is spent.
How much slack should a sprint plan leave?
Leave whatever remains when the next item doesn't fit, plus a separate bucket if defects always arrive. In the example, 186 hours sat against a pool of 210, so about a tenth stayed free for the widest estimate. There is no universal percentage. If the buffer goes untouched, you are over-reserving. If it's gone by Wednesday, the factor is too high or the defect bucket is too small.