Capacity planning in Scrum is the number of hours a team can actually commit to a sprint, calculated from real availability rather than the hours sitting on a calendar. Get that number wrong and everything built on top of it, the sprint goal, the stakeholder promise, the roadmap date, is wrong too. The formula itself isn't complicated. What breaks it is a team that mixes in-house engineers with nearshore or augmented ones, because the two groups don't share a payroll, a start date, or, often, a public holiday calendar. If you're still deciding who holds authority across that mix, settle that first; the capacity math below assumes the roles are already assigned.
What capacity planning in Scrum actually means
Capacity planning isn't a term the Scrum Guide defines. Search the Scrum Guide and "capacity" appears exactly once, in the Sprint Planning section, in a single sentence: "the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts." That's it. No formula, no worked example, no mention of focus factor or holidays. The Guide treats capacity as something the Developers already understand about themselves rather than something it needs to teach.
That gap is why teams end up inventing their own capacity math from scratch. The Guide leaves the mechanics entirely to the team, which is fine for a single-location team with a shared calendar and works far less well once part of the roster sits in a different country under a different contract.
Capacity vs. velocity: two different questions
Capacity is a forecast: how much work this specific team can take on next sprint, built from hours, headcount, and known absences. Velocity is a record: how many story points the team actually closed in past sprints. One looks forward, one looks back, and they answer different questions, so keep them apart in planning.
Velocity is also less stable than most planning conversations assume. Mountain Goat Software's argument for capacity-driven sprint planning puts a number on that instability: velocity bounces around in roughly a plus-or-minus 20 percent range from sprint to sprint, with no underlying change in how the team is performing. A single sprint's velocity is a noisy signal, and story points aren't standardized between teams anyway, so comparing one team's velocity against another's tells you less than it looks like it does. If you need a number that does travel between teams, DORA's four metrics for delivery speed and stability measure something closer to actual delivery performance than a point count ever will.
How to plan sprint capacity in Scrum
1. Start with working days, per location
List every person on the team with their working days for the sprint, then subtract public holidays using each person's own location's calendar. A single shared calendar for the whole team is the mistake this step exists to avoid. An in-house engineer in the UK and a nearshore engineer in Poland can lose entirely different days in the same two-week sprint. On a blended team, one shared calendar produces a wrong capacity number whenever the two countries' holidays differ.
2. Subtract known individual commitments
Pull out anything already booked against a person's time: approved leave, part-time schedules, a support rotation, a fixed technical-debt allocation. If your team commits a fixed percentage of sprint capacity to debt paydown rather than treating it as leftover time, subtract that slice here, before you get to the hours math.
3. Convert working days to hours
Multiply each person's remaining working days by their working hours per day. Float's comparison of a naive and an adjusted capacity formula shows how far apart these get: an eight-person team at a flat 8 hours a day, 5 days a week comes out to 320 hours a week, but once you subtract meetings and other non-project time, the same team's realistic weekly capacity drops to 192 hours. The gross number and the real number are rarely close.
4. Apply a focus factor
Gross hours aren't available hours. A focus factor discounts the total for meetings, interruptions, and context-switching that never shows up on a calendar as a named event. Smartsheet's standard capacity formula walks through the arithmetic directly: a team with 400 raw hours applying a 0.8 focus factor lands at 320 realistic hours. A team still forming, or one carrying heavy support duties, should run toward the low end of that range rather than assume it's already earned an 0.8.
5. Subtract time spent in Scrum events
Standups, planning, refinement, review, and retro all consume hours that don't produce sprint work directly. Add up each person's time across every ceremony for the sprint and subtract it from the focus-adjusted total. If your team is scheduling those ceremonies across a nearshore time-zone gap, the overlap windows for running standup, planning, and review live are worth setting before you lock the sprint calendar.
6. Total by location, then combine
Add up realistic hours separately for each location before you sum them into one team total. Doing the subtraction per location first is what catches a holiday, a time-zone-driven meeting overlap, or a contract minimum that only affects one part of the team. Combine too early and those location-specific losses get averaged away before anyone notices them.
Where the formula breaks on a blended in-house/nearshore team
Every step above works the same way whether the whole team sits in one office or not. Two things about a blended team don't fit cleanly into any of the six steps, and the standard capacity-planning guides don't model either one.
Mismatched public holiday calendars
Take a 2-week sprint running Monday, 29 June, through Friday, 10 July 2026, on a team of 4 in-house engineers in the US and 2 nearshore engineers in Poland. Independence Day, 4 July 2026, falls on a Saturday, so OPM's 2026 federal holiday schedule observes it on Friday, 3 July, under the rule that a Saturday holiday moves to the preceding Friday. Poland has no public holiday in that window at all, per Poland's official 2026 public holiday list.
The arithmetic: the US side has 4 people at 9 working days each (10 gross, minus the 3 July holiday), for 36 person-days. The Polish side has 2 people at 10 working days each, for 20 person-days. That's 56 person-days total, or 448 hours at 8 hours a day. Apply a 0.75 focus factor for an established team and you get 336 realistic hours. Subtract 6 hours per person across the sprint's standups, planning, refinement, review, and retro, 36 hours for the 6-person team, and the sprint's true capacity is 300 hours.
Run that same sprint on a single shared calendar instead and the number moves in one of two directions, depending on which calendar you picked. Assume nobody has a holiday that week (defaulting to Poland's calendar) and the US side's person-days come out to 40 instead of 36, a 4-person-day, 32-hour overstatement before the focus factor, 24 hours after it, about 8 percent of the sprint's real capacity, quietly baked into the commitment. Assume everyone observes the US holiday instead and the Polish engineers lose a day they don't actually have, understating the sprint by 12 realistic hours and under-booking two people who were available the whole time.
The mismatch runs in the other direction too. A sprint crossing the UK's late-May bank holiday, Monday, 25 May 2026, per the UK government's 2026 bank holiday list, docks the UK side a day while Poland's calendar that week is clear. And two of Poland's 2026 public holidays, 15 August and 26 December, fall on a Saturday, which under Polish practice banks a substitute day off to be taken at another time rather than costing that sprint at all. A UK or US in-house side loses nothing the week of 15 August, but the Polish engineer still owes a day, and it usually lands in a later sprint that a capacity plan built only for the current one won't see coming.
A new augmented engineer's first sprint
Simpliaxis's capacity-planning guide addresses a related but different case: one developer allocated half-and-half to two teams doesn't deliver half their output to each; the effective figure lands closer to 35-40 percent per team than 50. That's one person's attention divided between two backlogs. A blended team's new-joiner problem is a different shape: a whole seat, under a separate contract, starting from zero context.
Simpliaxis puts a new joiner's effective capacity at 30 to 50 percent in their first month, and adds that whoever is onboarding them loses time too. That ramp period is where a vendor's engagement terms matter. A fixed block of paid hours during ramp means paying full rate for a seat producing a fraction of its eventual output. Lemon.io's own engagement terms describe a first engagement of four weeks of paid work, up to 160 hours. HighCircl runs no minimum-hour commitment on an augmented seat and matches a shortlist in 72 hours, which matters most during exactly this window: sizing a seat down, or adding a second one for the back half of a sprint, doesn't require renegotiating a month-long commitment first.
Common capacity planning mistakes
Treating gross hours as real capacity inflates the plan, and that's the gap Float's naive-versus-adjusted comparison above exists to close. A team that skips the focus factor step plans against hours it was never going to have.
A close second: assuming focus factor is fixed once you've picked it. A team that starts carrying more support tickets, or absorbs a round of cross-team code review, needs a lower focus factor than the one it set three sprints ago. Setting a review-turnaround SLA for reviews that cross team or time-zone boundaries is worth doing before that load shows up as an unexplained capacity shortfall instead of a planned one.
The third is using last sprint's velocity as this sprint's capacity ceiling, treated as an absolute number rather than a noisy one. A sprint that closed 40 points because two people were out reflects that absence, and locking it in as the team's new normal misreads a one-off for a trend.
FAQ
Does the Scrum Guide define capacity planning or velocity?
No. The Scrum Guide mentions "capacity" once, in the Sprint Planning section, without a formula attached, and the word "velocity" doesn't appear in the document at all. Both terms come from practice built on top of Scrum rather than from the framework itself.
What focus factor should a team with augmented or nearshore engineers use?
There's no separate scale for a blended team; the same focus-factor range applies, and it should be set by how established and how protected from interruption the team actually is, rather than by where its engineers sit. A team newly combining in-house and augmented seats should start toward the lower end of its range until the group has a few sprints of real history together.
How much capacity does a new augmented engineer add in their first sprint?
Plan for roughly 30 to 50 percent of a full seat, in line with what Simpliaxis documents for new joiners generally, and expect whoever is onboarding them to lose some of their own capacity in the process. A vendor contract without a minimum-hour lock-in makes it easier to size that seat correctly during the ramp instead of committing to full hours from day one.
How do you handle a sprint that crosses a holiday only one side of the team observes?
Subtract the holiday only from that location's working days, rather than from the whole team's total. Calculating person-days per location before combining them, as in step 6 above, is what catches this; a single shared calendar either overstates or understates the sprint depending on which side's holidays it defaults to.