How to Estimate Performance and Optimization Work
"The dashboard is slow, can we speed it up?" sounds like a reasonable story. Put it in front of a team and the votes range from 2 to 20, because nobody knows yet what's slow, how much faster it needs to be, or whether the fix is a missing index or a redesign.
Performance work is hard to estimate for a specific reason: the outcome is uncertain in a way most feature work isn't.
A target, not a direction
"Faster" has no finish line. A story without one can't be estimated, and it can't be finished either, because there's always another millisecond.
Before sizing anything, agree on a measurable target: "the dashboard loads in under two seconds for an account with 10,000 records," or "p95 response time for the search endpoint below 300ms." If nobody can say what number would count as done, the story isn't ready for estimation, and it fails a basic Definition of Ready.
Split finding from fixing
Most performance stories contain two very different pieces of work:
- Finding the cause. Profiling, tracing, reproducing the slow case with realistic data. This is investigation, and its length depends on what you discover.
- Fixing it. Once the cause is known, the fix is usually ordinary, estimable engineering.
Estimate them separately. Treat the investigation as a timeboxed spike: "two days to profile the dashboard and identify the top three causes." Then estimate the fix once you know what it is. Voting on both together means voting on a guess about what the profiler will show.
Size the fix by what the profiler found
Once you know the cause, performance fixes tend to fall into recognizable sizes:
- Configuration and query fixes. A missing index, an N+1 query, a cache that isn't being used. Often small.
- Code-path changes. Rewriting a hot loop, batching requests, moving work off the critical path. Medium, and well bounded.
- Structural changes. Denormalizing data, adding a new caching layer, changing how a page loads. Large, and often worth splitting before estimating.
Knowing which category you're in does most of the estimation work for you.
Include measurement in the estimate
A performance fix isn't done when the code merges. It's done when you've measured the result against the target in an environment that resembles production. That measurement takes real time, especially when the slow case only appears with production-scale data.
If your estimate doesn't include proving the improvement, it's missing the step that tells you whether you're finished.
Expect diminishing returns
The first fix often gets most of the improvement. Each fix after that gets less for the same effort. When the team finishes one fix and is still short of the target, re-estimate the next step rather than assuming it will be as productive as the last. This is one of the clearer cases for re-estimating mid-sprint.
If the remaining gap is small and the next fix is large, that's worth raising with the product owner. Sometimes "under 2.5 seconds" is good enough, and knowing the cost of the last half-second is exactly what an estimate is for.
Performance work becomes estimable the moment it has a target and a known cause. Get both before you vote.
