It’s day 7 of a 10-day sprint.
The burndown chart looks like a ski slope that went flat. Three critical user stories are still in "In Progress", two are blocked waiting on PR reviews, and the team realizes they won't even hit 70% of what they committed to.
At the sprint retro, someone inevitably says:
"We just had too many unexpected meetings and PRs this sprint."
Then, in planning the following Monday, what happens?
The team looks at their average "historical velocity", pulls in the exact same number of story points, and repeats the cycle.Sprint failure usually isn’t a developer productivity problem. It’s a capacity calculation problem.
The Dangerous Myth of the 40-Hour Developer Week
When planning sprints, many engineering teams make a fatal mathematical assumption:
5 engineers × 8 hours/day × 10 days = 400 hours of development capacity.
This number is pure fiction. In the real world, no software engineer spends 8 hours a day writing feature code.
On any given week, engineering time gets consumed by:
- Code reviews & PR feedback: 1–1.5 hours/day
- Agile ceremonies (Standups, Grooming, Retros): ~4–6 hours/sprint
- Production support, alerts & bug triage: 0.5–1 hour/day
- Slack interruptions & context switching: 1 hour/day When you assume a developer has 40 hours of focused coding time per week, you are overcommitting your sprint before line 1 of code is even written. --- ## Velocity vs. Capacity: Why Historical Velocity Lies Many teams rely purely on Velocity (the average story points completed in past sprints). Velocity is a useful backwards-looking metric, but it has a blind spot: it assumes every sprint has the same available manpower. Velocity completely breaks down when:
- An engineer takes 3 days of PTO.
- There is a bank holiday on Friday.
- A senior engineer is onboarding a new hire.
- The team has extra architecture review sessions. Velocity tells you what you did in the past. Capacity tells you what you can actually do in the upcoming two weeks. ---
The Realistic Capacity Formula: Introducing "Focus Factor"
To forecast sprint bandwidth accurately, high-velocity engineering teams use a metric called Focus Factor (or Productive Availability).
Focus factor represents the actual percentage of a workday an engineer can dedicate to pure sprint deliverables:
- Senior Engineers / Tech Leads (50% – 60%): High meeting load, architecture reviews, unblocking junior devs.
- Mid-Level Engineers (70% – 75%): Good focus, standard review load.
- Junior Engineers (70%): Lower ceremony load, but require mentoring and research time.
The Realistic Capacity Formula:
True Capacity =
[(Work Days - PTO - Holidays) × Working Hours × Focus Factor]
- Sprint Ceremonies Overhead
An Example:
Take an engineer in a 10-day sprint (80 nominal hours):
1 day of PTO = 72 hours left
Focus Factor of 70% = 50.4 focused hours
Minus 6 hours for sprint ceremonies = 44.4 true hours
Instead of 80 hours, this developer realistically has 44 hours to build features.
Multiply that gap across a 6-person team, and you suddenly realize why your sprints were overcommitted by 150+ hours.
We Got Tired of Spreadsheets, So We Built a Free Tool
Manually calculating PTO, bank holidays, focus factors, and ceremony hours inside an Excel sheet every two weeks is tedious.
To solve this, we built a free, zero-friction browser calculator:
👉 Try the Free Sprint Capacity Calculator
What Makes It Useful for Engineering Leads
We built this utility with zero corporate fluff:
No Sign-Up or Paywall: Open it directly in your browser during sprint planning.
Per-Engineer Granularity: Set individual focus factors, PTO days, and daily work hours for each team member.
Deducts Ceremony Overhead: Automatically accounts for standups, sprint reviews, and planning time.
Story Point Conversion: Converts your team's available net hours into a realistic Story Point target based on your historical points-per-hour ratio.
100% Client-Side Privacy: Your team's names and capacity numbers run entirely in local JavaScript and are never stored on external servers.
How to Run Better Sprint Planning Next Monday
If you want to end the cycle of overcommitting and sprint roll-overs, try this 3-step adjustment:
Calculate capacity before opening Jira: Don't look at the backlog first. Run the Sprint Capacity Calculator
to know your true net available hours.
Leave a 15% buffer: Sprints should plan for ~85% of total capacity. Production bugs and unexpected dependency blockers happen every sprint.
Commit to the capacity, not the wish list: If the product backlog demands 60 points but your team has 42 points of capacity due to holidays, adjust scope during planning—not on day 9 of the sprint.
Helpful Resources:
🧮 Sprint Capacity Calculator
📐 Free Architecture Decision Record (ADR) Generator
🛠️ Klority Free Agile Tools Hub
If your team is looking for a modern engineering workspace that natively unites capacity planning, project management, and QA test cases into one fast tool, take a look at what we’re building at Klority
.
series: Free Developer Tools
Over to you:
How does your team calculate sprint capacity?
Do you use Focus Factors, or rely purely on historical velocity?
What percentage of your sprint is usually lost to meetings and interruptions?
Let's discuss in the comments below! 👇
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.