Glossary
By Priya Shankar
Agile estimation is the practice of forecasting work effort using relative sizing (usually story points) rather than absolute time, because engineering work contains irreducible uncertainty that traditional hour-based estimation ignores. It's being systematically honest about what you don't know.
Agile estimation is fundamentally a conversation between PMs and engineers. Engineers ask clarifying questions that directly impact point values. The real power emerges as you track velocity—average points completed per sprint. After 4-6 sprints, you have predictability: "We complete 40 points per sprint." This allows forecasting.
Bad agile estimation: teams inflate points, then work nights to meet commitments. Good agile estimation: teams honestly assess effort, consistently deliver 85-95% of committed work, and stakeholders trust forecasts.
"1 story point = X hours." Points measure relative complexity, not absolute duration.
"PMs estimate." Engineers estimate. If your PM dictates point values, your process is broken.
"Perfect velocity means correct estimates." Velocity is predictable in aggregate. Variance is normal.
Teams with poor estimation commit to impossible work, miss sprints, and burn out. Teams with sound estimation have predictable delivery, realistic roadmaps, and engineers who trust their own forecasts.
For PMs: don't argue engineers' estimates down. That 21-point estimate usually includes risks you don't see.
Velocity stability: Plot completed points over 8+ sprints. Healthy teams have ±10% variance.
Commitment accuracy: 85-95% is healthy. Below 80% means too ambitious.
Correlation strength: Do high-point stories take longer? Strong correlation means estimation is calibrated.
Q: What if team members estimate very differently? Perfect. One person sees a risk the other missed.
Q: Should estimates include testing and code review? Absolutely. The story isn't done until merged, tested, and reviewed.
Q: How do we handle unplanned work? Track separately. If 25% is lost to incidents, don't commit the full sprint.
Q: Can we use agile estimation for non-engineering work? Definitely. Design, content, infrastructure—anything with uncertainty benefits.
Keep reading
