Engineering OKR velocity

Engineering OKR velocity — is your quarter feasible?

Most engineering OKRs fail not because teams are slow — but because targets were set without capacity math. This calculator runs two checks: (1) does total quarter capacity even cover the OKR target, and (2) given progress so far, will you land the target by quarter end? If either number is below 100%, you have time to cut scope, add focus, or raise the flag.

The capacity calculation

Real engineering capacity is not "engineers × hours in a quarter." The formula that matches reality:

• Raw capacity: engineers × points per engineer per sprint × sprints per quarter
• OKR-available capacity: raw × (1 − KTLO%). KTLO = keeping-the-lights-on work: bugs, support, on-call, small asks, meetings, dependency upgrades.

KTLO is 20-40% of team time in mature products. If you don't account for it, you over-commit and miss. If you over-account, you under-commit and lose credibility.

Typical velocity numbers

• Startup / early-stage: 8-12 points per engineer per 2-week sprint. Low KTLO (maybe 15-20%). High output, low stability.
• Growth-stage SaaS: 6-10 points/eng/sprint. KTLO 25-35%. Balance of new features and maintenance.
• Mature enterprise: 4-7 points/eng/sprint. KTLO 35-50%. Lots of legacy support, compliance work, stakeholder management.
• Platform / infra team: 3-6 points/eng/sprint. KTLO 50%+ by design (operations, incident response, platform support is their job).

If your team measures velocity higher than these ranges, either you're genuinely elite (rare), your points are small, or you're under-accounting for KTLO.

Burn rate & quarter projection

After 3-4 weeks into a quarter, you have enough signal to project. Burn rate = points done ÷ weeks elapsed. Project to quarter end: burn rate × total quarter weeks.

• 100%+ of target: On track. Don't add scope — bank the buffer.
• 85-99% of target: Tightening zone. Cut 1-2 lowest-priority KRs, increase focus on remaining.
• 70-84% of target: Action required. Cut scope, raise flags, reset with leadership.
• <70% of target: Replan entirely. Either target was wrong from day one, or something has gone sideways (team changes, priority shifts, unplanned crises).

Required burn rate

If you're behind, the math tells you what burn rate you need to close the gap:

Required burn = (target − done so far) ÷ weeks remaining

If this exceeds your demonstrated burn rate by 50%+, no amount of "pushing harder" closes the gap. Cut scope. A team that's been burning 25 pts/week does not suddenly burn 40 pts/week in the last 5 weeks without breaking something else (quality, morale, other work).

Why OKRs miss

Post-mortem data from ~150 OKR cycles reveals five common failure modes:

1. Target set from ambition, not capacity (40% of misses): Leadership wants X, plans for X, ignores that team can ship Y where Y < X.
2. KTLO under-counted (25% of misses): Planners assume 100% OKR time; reality is 60-70%.
3. Mid-quarter priority shift (15%): New fire drops, team pivots, original OKR gets starved.
4. Dependencies outside team (10%): Waiting on design, legal, security, another team.
5. Scope creep (10%): KR grew from "ship feature X" to "ship feature X + polish + docs + onboarding + analytics."

Turning the numbers into action

The feasibility number drives decision:

• Under 80% feasibility at planning: Don't commit. Negotiate down before the quarter starts. Committing to infeasible OKRs destroys trust.
• Under 85% burn-rate tracking at week 4: Cut scope now while there's time to reallocate focus.
• Required burn rate > 1.3x current: Replan. No team sustains 30%+ velocity increase without breaking.
• Capacity gap is tiny (< 5%): Push through. Small gaps close with focus.

Velocity anti-patterns

• Point inflation: Stories quietly get larger over time. Velocity looks stable but real output falls. Recalibrate estimates quarterly.
• Velocity as performance metric: Teams game the number by inflating estimates. Velocity is a planning tool, not a KPI.
• Comparing teams: Teams use different scales. Comparing velocity across teams is meaningless.
• Treating velocity as ceiling: Commits to exactly the measured velocity leave zero buffer. Always commit to 80-90% of measured.
• Ignoring variance: Velocity of 40 ±15 is different from 40 ±5. Plan against the low end, not the mean.

Replanning vs pushing harder

When burn rate shows you're behind, two instincts arise: (1) push harder — work weekends, skip polish, cut corners; (2) replan — reduce scope, re-prioritize. Replanning almost always wins. Pushing harder produces short-term gains followed by reliability issues, burnout, and team turnover that cost 10x the original gap. Good engineering leadership says "we're not going to hit X, here's the revised commitment" early — not "we'll grind through it" late.