The metric that finally made our sprint planning predictable
When I was a team lead, sprint planning was the single most frustrating part of the job.
Every planning meeting looked the same. Engineers gave estimates in hours, we filled the sprint to the top, everyone nodded, and two weeks later we missed the release date. Then we would do the retro, promise to "be more realistic", and repeat the exact same thing next sprint.
My department head finally sat me down and taught me Focus Factor. It sounds obvious when you read it but I had been ignoring it in practice: a developer does not write product code 8 hours a day. There are DSMs, code reviews, estimation sessions, planning, demo, retro, support tickets, bug fixes, fly-in tasks, shortened days, other projects, vacations. Once you subtract all of that, real product time is usually 50-75% of the calendar.
So we stopped planning against "working days × 8" and started planning from the Focus Factor.
The formulas are simple:
- Total Time = working days × 8
- Task Time = Total - (Processes + Support + Meetings + Fly-in + Wind)
- Focus Factor = Task Time / Total Time
We also tracked:
- Stability = 1 - (Fly-in / Total) - below 0.85 means the sprint is getting broken into by unplanned work
- Support Ratio = Support / Total - above 20-25% means the product is probably unstable
- Adjusted Focus = Task Time / (Total - Wind) - fair for people who were only partially available
We started in Excel. Formulas and colored cells: red < 50%, yellow 50-74%, green 75%+. Then we put the metric on a team dashboard and compared sprints over time.
The effect was fast. Release dates became achievable because we stopped planning 100% of calendar time. Sprint goals stopped being wishes. Nobody was secretly overloaded because the overload was visible in the numbers before the sprint even started. And when support ratio spiked, we treated it as a system signal (quality, WIP control) instead of blaming someone.
The key mindset shift: Focus Factor is not a productivity metric for people. It is an indicator of organizational noise.
Maintaining the spreadsheet and rebuilding comparisons by hand got annoying, so I wrote a small web app for it.
It does Focus Factor per member with live recalculation, sprint report with stability / support ratio / adjusted focus, sprint-vs-sprint compare with deltas, team-level trends, and a shareable public report link you can drop in a work chat for sprint review. Jira integration is next.
Kotlin + Spring Boot backend, React + TypeScript frontend. Two demo teams seeded at startup so you can play with it in 2 minutes. EN and ES locales. Light / dark theme.
Curious what actually worked for you. What metrics or tools genuinely improved sprint planning for your team - not what sounded good in a process doc, but what you kept using after six months?