Focus Factor fixed my sprint planning. Here is the method and a tool I built for it

Tiana — Tue, 21 Apr 2026 06:12:00 +0000

The pain

When I was a team lead, sprint planning was my constant pain.

Every planning meeting was the same. Engineers gave estimates in hours, I stacked the sprint to the top of the team's calendar, everyone said "we can do this", and two weeks later we were past the release date and nobody was surprised.

The retro would conclude "we need to be more realistic" and we would repeat the exact same pattern next sprint.

The fix

My department head showed me Focus Factor. The core idea is embarrassingly simple: a developer does not write product code for 8 hours a day.

A working day has:

DSMs, code review, estimation, demo, retro, planning (the recurring process load)
Support tickets, bug fixes, monitoring, legacy work
Meetings outside the recurring process
Fly-in tasks that land during the sprint
Shortened days, vacations, other projects, external commitments

Once you subtract all of that, the real product time per sprint is usually 50-75% of the calendar, not 100%.

So you plan the sprint from that real number, not from "working days × 8".

What the metric actually is

Total Time    = working days × 8
Task Time     = Total - (Processes + Support + Meetings + Fly-in + Wind)
Focus Factor  = Task Time / Total Time × 100

Color buckets we used:

0 - 49% red - the team is drowning in operational work
50 - 74% yellow - it works but it is unstable
75%+ green - strong focus on the product

A realistic ceiling is 70-75%. If you see 90% sustained, your data is lying.

A couple of related metrics that paid off quickly:

Stability Factor = 1 - (Fly-in / Total Time)           // < 0.85 means unstable planning
Support Ratio    = Support / Total Time                // > 0.25 means quality problems
Adjusted Focus   = Task Time / (Total Time - Wind)     // fair for partial availability
Team Focus       = Σ Task Time / Σ Total Time          // the one you actually manage by

The key mindset shift: Focus Factor is not a productivity metric for people. It is an indicator of organizational noise.

If focus drops, the problem is in the system (support load, fly-in discipline, meeting bloat), not in someone's motivation.

From Excel to a tool

We ran this in Excel for months. Formulas, colored cells, weekly updates, per-team tab. It worked, but it was painful to compare sprints, keep the roster in sync, and share a clean view with stakeholders.

So I wrote a small open-source tool to stop living in spreadsheets.

Repo: https://github.com/tiana-code/sprint-pulse

Stack: Kotlin + Spring Boot 3, JPA, Liquibase, H2 or Postgres, React + TypeScript + Vite + Tailwind + Recharts.

Planning from Focus Factor

A sprint in Planning status has an editable hour matrix per member. Focus Factor, Adjusted Focus, Stability and Support Ratio recalculate live. When the sprint starts or closes, the table becomes read-only - this matters, because editing history after the fact destroys trend data.

Sprint report

Every sprint gets a full report: per-member hours, team totals, KPIs, a time-breakdown chart per member, and an auto-generated recommendation (focus critical, support high, stability low, healthy).

Compare sprints over time

Pick any two or more sprints, get a delta column and a side-by-side chart. This is where you catch "our focus dropped from 73% to 45% and support load doubled - something broke in the last release cycle".

Team-level view

Two screens:

Teams comparison - one row per team with average and latest Focus Factor, capacity, stability, support share
Trends - Focus Factor, time breakdown and stability-support lines over sprints for a single team

Shareable report link

Every sprint has a public read-only link you can drop into a work chat for sprint review. No auth. Good for a quick "here is what we delivered, here is what the numbers say" without screenshots.

What is next

Jira integration. The plan is to pull sprint scope, members, working days and support hours from Jira / Tempo and stop retyping.

Run it locally

git clone https://github.com/tiana-code/sprint-pulse
cd sprint-pulse

# backend
cd backend && ./gradlew bootRun
# http://localhost:8081, login admin / admin

# frontend
cd ../frontend && npm install && npm run dev
# http://localhost:5173

Two demo teams with four to seven sprints are seeded at startup so you can click around without typing anything. SEED_ENABLED=false disables it for prod.

Your turn

What metrics and tools actually fixed sprint planning for you? Not what a book recommended - what you were still using after six months. Drop them in the comments.

DEV Community: Tiana