Capacity planning for Scrum teams: a sprint budget you can actually spend

12 October 2026 · Updated 19 October 2026 · 9 min read

Most sprints that go wrong don't go wrong in the middle. They go wrong in planning, when a team commits to time it doesn't have. Capacity planning is the habit of checking the budget before you spend it: who is really around, how much of their day is really free, and what that means for how much work to take on. This guide follows one team through a difficult sprint, step by step.

Capacity is a budget, not a target

A team's capacity is the amount of sprint work it can realistically finish in the time it has. It is a budget: something you check before you commit, the way you'd check your account before booking a holiday. It is not a target to hit or a number to beat. A team that treats capacity as a target starts padding estimates, skipping tests or working late, and every one of those makes the next forecast worse.

Three numbers are all you need:

• Availability: the days each person is actually at work during the sprint, after holidays, public holidays, training and conferences.
• Focus: the share of those days that goes to sprint work. Nobody spends eight hours a day on the sprint backlog. Meetings, support, reviews and email take the rest. Many teams start by assuming about 0.7 and adjust from there.
• Velocity: how many story points the team finishes in a normal sprint, averaged over the last few.

Multiply availability by focus and you get focused days. Compare this sprint's focused days with a normal sprint's, scale your velocity by the same amount, and you have a forecast based on the sprint you're actually about to have.

Meet the Harbour team

The Harbour team builds a booking app. Five people have worked together for a while: Ana and Ben on the backend, Chloe on the frontend, Eli in QA and Fran in design, who splits her week with another team. Their sprints last two weeks, and over the last six sprints they finished 32, 38, 35, 40, 33 and 38 points: an average of 36.

Sprint 14 is not a normal sprint:

• A public holiday falls on the second Monday, so everyone has 9 working days, not 10.
• Ana is on call, which the team reckons halves the time she has for sprint work.
• Chloe is on holiday for three days.
• Eli spends a day at a testing conference.
• Dev joins as a second frontend developer. He's sharp, but it's his first sprint, and Ben has offered to mentor him.

Step 1: fill in the capacity worksheet

Before the planning meeting, the Scrum Master asks everyone for their days and fills in a short table. Each person's focus starts at the usual 0.7 and moves only for a reason the team can name.

The table takes five minutes and does something no formula can: it gets every absence and distraction said out loud before anyone commits to anything.

Step 2: compare with a normal sprint

The 36-point average came from the five original team members in ordinary sprints: 10 days each at their usual focus, which is 7 focused days for Ana, Ben, Chloe and Eli and 6 for Fran. That's 34 focused days in a normal sprint.

Sprint 14 has 27.8, about 82% of normal, despite the extra person. Scale the velocity by the same amount:

36 points × 27.8 ÷ 34 ≈ 29 points.

Notice what Dev does to the numbers. He adds 2.7 focused days and costs Ben 0.9, so in his first sprint the team gains less than two days. That's normal, and it's why a new joiner rarely makes a team faster straight away.

Step 3: turn one number into a range

Velocity moves around from sprint to sprint, so a single number promises more precision than you have. Use the spread of recent sprints instead. Sort the last six (32, 33, 35, 38, 38, 40), drop the highest and the lowest, and the rest run from 33 to 38. Scaled to 82%, that's about 27 to 31 points for Sprint 14.

The Harbour team plans in two layers:

• A commitment of about 27 points, the low end of the range, chosen to serve the sprint goal. This is what they tell stakeholders.
• About 4 points of stretch work, ready and estimated, to pull in if the sprint goes well. Nobody outside the team is promised it.

If you don't have six sprints of history yet, use whatever you have and widen the range. Commit low, and let the actual results set your velocity.

Step 4: check each discipline, not just the total

A plan can fit the total and still break in one place. This is the step most teams skip. Look at where the Harbour team's focused days are this sprint:

Frontend is the thin slice: Chloe is away for three days and Dev is still learning. If most of the 27 points the team wants are frontend-heavy stories, the sprint will jam even though the total fits. The fix is cheap if you catch it in planning: swap in a backend-heavy story, split a frontend story so part of it waits, or agree that Ben pairs with Dev on frontend work for a few days.

To see this, you need estimates that show where the effort sits. Teams that estimate each discipline's part of a story separately, for example frontend, backend and QA, can add up each column and compare it with that discipline's share of the focused days.

Where capacity leaks

Focus is the number teams most often get wrong, because the work that eats it never shows up on the board. The usual leaks:

• Scrum events. With the usual timeboxes scaled to a two-week sprint (about four hours of planning, two of review, an hour and a half of retrospective, and fifteen minutes a day for the Daily Scrum), events take around ten hours per person. That's over 10% of the sprint before any other meeting.
• Support and bugs. Production issues, customer questions and urgent fixes arrive whether or not they were planned. A team that handles them should plan for them.
• Reviews and helping others. Code reviews, pairing and answering questions are real work and good work, but they come out of the same days.
• Context switching. Someone split across three projects doesn't give each a third of their time. Every switch costs time to get back into the work.
• Onboarding. A new joiner takes time from the people teaching them, as Ben's 0.6 shows.
• The days around holidays. Handing over before time off and catching up after it both cost focus that the calendar doesn't show.

You don't need a time-tracking system to find your real focus. For two sprints, tag every piece of unplanned work on the board as it arrives, and in the retrospective ask: how much of our time went to the sprint backlog? If stories keep slipping, lower your focus. If the team regularly finishes early, raise it.

When capacity changes mid-sprint

On day four of Sprint 14, Ben catches the flu and is off for three days. The plan was built on his 5.4 focused days and he'll now have about 3.6. What should the team do?

• Say it in the next Daily Scrum. A capacity change is news, not a private problem to work around.
• Protect the sprint goal, not the list. The goal stays; the stories that serve it least are the ones to give up.
• Agree the swap with the Product Owner. Move a story back to the backlog together. Quietly stretching everything else is how sprints end with five half-finished stories instead of four finished ones.
• Don't count it against the team. Leave the sprint's lower velocity in your history; it's an honest data point, and the range method keeps one bad sprint from distorting the next plan.

Four capacity myths

"A fully booked team is an efficient team"

It feels wasteful to leave slack, but a team planned to 100% has no room for anything to go wrong, and something always does. As anyone who has queued at a busy supermarket knows, waiting times grow quickly as a system gets close to full. Work waits for reviews, testers and answers in the same way. Slack is what lets urgent work move without derailing everything else.

"Adding people adds capacity straight away"

Fred Brooks put it bluntly in The Mythical Man-Month: adding people to a late software project makes it later. New people need time to learn the codebase, and the people teaching them lose time too. Dev added less than two focused days to his first sprint; plan for a few sprints of ramp-up.

"Velocity should go up every sprint"

A steady velocity is a healthy one. Velocity measures a team against its own estimates, so pressure to raise it mostly raises the estimates. Judge a team by whether it delivers what it plans, not by whether the number grows.

"Capacity is the manager's job"

In Scrum, the developers decide how much work they can take on. A manager or Scrum Master can run the worksheet, but the people doing the work are the ones who know that a migration needs a quiet day, or that next week's on-call rota is heavy. A forecast they don't believe in isn't a commitment.

A capacity checklist for your next planning

1. Collect everyone's days at work, including public holidays, training and conferences.
2. Give each person a focus, starting from your usual value, and write down why it changes.
3. Add up the focused days and compare them with a normal sprint.
4. Scale your velocity range by the same ratio.
5. Commit to the low end, and line up stretch work for the rest.
6. Check each discipline against its share of the focused days.
7. Agree how you'll handle a capacity change mid-sprint before it happens.

For the rest of the meeting, from the sprint goal to a sample agenda, see our sprint planning guide, and to keep the meeting itself on schedule, see timeboxing sprint planning.

Capacity planning FAQ

Should we plan capacity in hours or story points?

Use days for availability and points for the work. Days are the natural unit for who is around; points are the natural unit for how big the work is. The ratio of focused days connects the two, without ever turning a point into a number of hours.

How do we plan capacity for a brand-new team?

Fill in the worksheet anyway: it still shows who is around and what else they're doing. Then make a cautious first guess, keep the first sprint light, and use what you actually finish as your starting velocity. After three or four sprints the range method starts to work.

Do we count the Scrum Master and the Product Owner?

Count only time spent on the sprint backlog. If your Scrum Master also writes code half the time, count half. Time spent facilitating, refining the backlog or talking to stakeholders is valuable, but it isn't capacity for sprint work.

What focus should we start with?

Somewhere between 0.6 and 0.8 is a common starting point, and 0.7 is a reasonable default. Treat it as a guess to be corrected by your own sprints, not a rule.

Estimate with your capacity in mind, in Storyvote

Capacity tells you how many points you can afford. The other half is knowing what each story costs, and that comes from estimating together. Storyvote is free planning poker that helps with both:

• Per-discipline estimates. Split a story into frontend, backend and QA, for example. Each part gets its own vote and the story shows the total, so you can check each discipline against its capacity, as in step 4.
• A running total. The Stories panel adds up every saved estimate, ready to compare with this sprint's range.
• Hidden votes and a discussion timer. Everyone votes at once, so nobody anchors on the first number, and a timer on the discussion keeps each round short.
• Import and export. Bring in your backlog from Jira, Trello or a CSV file and take the estimates back out when you're done.

New to estimating together? Start with what planning poker is.

← All articles