🏃 Sprint Capacity Planner

Why Your Sprint Always Feels Impossibly Full (and How Capacity Math Changes That)

Every sprint retrospective has at least one uncomfortable truth hiding inside it: the team committed to 42 story points and delivered 28. Nobody sandbagged. Nobody was slacking. The team was genuinely working hard all sprint long — and still came up short. The culprit is almost never laziness. It is almost always a planning assumption so deeply embedded that nobody thinks to question it: the idea that a person at work for eight hours is productively working on sprint tasks for eight hours.

They are not. They never have been. And once you stop planning as if they are, your sprint forecasts become dramatically more accurate.

The Hidden Drain on Developer Hours

Walk through a realistic Tuesday for a senior developer. There is a 30-minute daily standup. A mid-morning Slack thread about a production alert pulls 45 minutes of attention even though the developer is not the one fixing it. Lunch. A spontaneous design discussion after lunch. A recruiter screen the developer agreed to help with. Code review requests that land throughout the afternoon. By the time the developer closes the laptop, maybe five of those eight hours touched actual sprint work — and that is a good day.

This is what the "focus factor" represents in sprint planning. Industry surveys and team retrospective data consistently show that individual contributors in cross-functional software teams have effective focus factors somewhere between 60 and 75 percent. That means for every ten working days in a sprint, a developer is realistically available for six to seven and a half days of sprint-focused output. Not ten.

At a team level, the compounding effect is significant. A four-person team that plans as if each person delivers 80 hours of sprint work in a two-week sprint is actually working with somewhere around 220 to 240 focused hours — not 320. Planning as though you have 320 hours means you are chronically over-committing by roughly 30 percent before the sprint even starts.

What Availability Percentage Actually Measures

Availability and focus factor sound similar but they measure different things. Availability is about presence — is this person here, working, for the full sprint? A developer on a two-week sprint who has four days of approved PTO has 60 percent availability. A part-time contractor who works three days per week on your team has roughly 60 percent availability. Someone splitting time equally between your team and a parallel initiative is at 50 percent availability.

Focus factor, on the other hand, assumes the person is present and accounts for how much of that present time goes toward sprint deliverables versus the ambient work of being on a software team. Standups, code reviews, planning ceremonies, incident response, knowledge transfer, HR processes — these all eat into focus but they are not absence. They are overhead.

Combining both gives you a realistic picture of actual sprint contribution. A developer at 80 percent availability and 70 percent focus factor delivers 56 percent of theoretical maximum output. On a ten-day sprint with eight-hour days, that is 44.8 hours — not 80.

The Holiday Problem That Derails Every December Sprint

Most teams track planned absence at an individual level but forget to model it in aggregate. When planning a sprint that overlaps with a public holiday, many teams simply note "we have a holiday on Thursday" and then plan the sprint as if it has ten working days anyway. They absorb the loss through heroics, or they carry items over, or they roll the shortfall into the retrospective as a capacity surprise.

Capacity planning that accounts for holidays at the individual level is especially important for distributed teams. A US-based developer celebrating Thanksgiving is unavailable for two to four days while a UK colleague on the same team works normally. Treating the sprint as uniformly reduced by one day dramatically underestimates the US developer's capacity loss and overestimates the UK developer's.

The correct approach is to model holidays per team member, subtract them from that member's available sprint days, and then sum across the team. The difference between team-level and member-level holiday accounting can swing your sprint capacity estimate by 15 to 20 percent on holiday-heavy sprints.

The Buffer You're Probably Not Taking

Even after accounting for availability, focus factor, and holidays, mature engineering teams reserve an additional buffer — typically 10 to 20 percent of calculated capacity — for unplanned work. This is not pessimism. It is calibration.

Unplanned work arrives in every sprint: a critical bug reported by a customer three days in, an urgent security patch, an urgent stakeholder demo that needs a quick change nobody scoped. Teams that have no buffer in their sprint capacity get destabilized by these arrivals. Teams that plan with a buffer handle them without disrupting the sprint commitment.

The right buffer percentage depends on team maturity and domain. A team in a stable product with good test coverage and a low-interruption culture might run comfortably at a 10 percent buffer. A team maintaining a legacy system with frequent production incidents or a team that regularly gets pulled into cross-team dependencies might need 20 to 25 percent. Track your unplanned work over several sprints and let the data set your buffer, not instinct.

Story Points vs. Hours: Using the Converter Wisely

Many teams plan in story points and track velocity over multiple sprints, which sidesteps the need to convert capacity to points explicitly. But for teams just starting out, for teams rebuilding after significant turnover, or for teams trying to set realistic targets after a major process change, converting hours to points via an hours-per-point ratio is an effective bridge.

Your historical hours-per-point ratio is calculated simply: total hours spent on completed story-pointed work in a sprint divided by total story points delivered. For a typical business application team, this tends to land between four and eight hours per story point. It reflects not just the work itself but your team's shared calibration of point values.

The key is to use your actual historical ratio, not an industry average. A team that has been running sprints for six months has a real ratio derived from their own work. That ratio is far more predictive than any benchmark. Update it every quarter as the team grows and the product matures.

A Real Planning Session, Before and After

A five-person product team — three developers, one QA engineer, one designer — was consistently delivering around 65 to 70 percent of their sprint commitments for four straight quarters. They attributed it to scope creep and stakeholder-added requests mid-sprint, which was partially true. But a deeper look at their planning process revealed they had never accounted for focus factor at all. They were planning to 100 percent of theoretical hours.

After introducing capacity planning with realistic availability (the designer was split 50/50 with another team), a 68 percent average focus factor based on their time-tracking data, and a 15 percent unplanned-work buffer, their modeled sprint capacity dropped from 280 planned hours to 168 effective hours. Their sprint commitment dropped accordingly. For the first time, they delivered 97 percent of their sprint in the following cycle. The change was not in execution — it was entirely in honest planning.

Making Capacity Planning a Team Habit

The most effective teams do capacity planning at the start of every sprint, not just at the start of a project. Availability changes. People take PTO. Focus factor shifts when a team is deep in production stability work versus greenfield feature development. A quick five-minute capacity calculation before the sprint planning meeting — entering current availability, any holidays, and the agreed buffer — sets a ceiling for the sprint commitment before a single story is discussed.

This prevents the negotiation dynamic that tanks so many sprint plannings: stakeholders pushing for more commitments, teams reluctant to push back without data. With a capacity number in hand, the conversation shifts from "can we add one more story?" to "that would require us to exceed our 168-hour capacity — which story would you like to defer?"

That is a very different, much more productive conversation. And it starts with 30 seconds of honest math.