What estimation accuracy tells you that velocity does not
Velocity describes a team's throughput against its own story points. Estimation accuracy describes whether you can promise anything to a client and be right. They answer different questions, and treating one as a stand-in for the other is a common and expensive mistake.
Velocity measures how much a team gets through relative to its own estimates, which can stay flat or even rise while those estimates quietly inflate. Estimation accuracy measures how close actual effort came to what was promised, in real hours, which is the number that determines whether a delivery date or a fixed-price quote can be trusted. A services firm needs both, but only one of them protects a client relationship.
Velocity is the most watched number in agile delivery, and for team-internal purposes it earns that attention: a stable or rising velocity is a reasonable signal that a team's throughput is healthy relative to its own recent history. The trouble starts when velocity gets asked to answer a question it was never built for — whether the firm can be trusted to say when something will be done.
What velocity actually measures (and what it can't)
Velocity is story points completed per sprint, and story points are themselves an estimate, set by the team, in units that mean nothing outside that team. A team can hold velocity steady at 40 points a sprint for a year while the actual hours behind a point drift upward, because nothing in the velocity chart checks a point against a clock. The chart will look identical whether the team is getting faster or simply getting more generous with its own estimates.
Velocity answers 'are we keeping pace with ourselves?' It cannot answer 'were we right?' — and a client only ever asks the second question.
Estimation accuracy, defined
Estimation accuracy compares estimated hours to actual approved hours on the same unit of work, in real time, not story points. A ticket estimated at 8 hours that took 9 approved hours is 89 per cent accurate. Averaged across a sprint or a project, this produces a number that means the same thing every time you calculate it, which story points cannot promise.
| Velocity | Estimation accuracy | |
|---|---|---|
| Question it answers | Is our throughput stable relative to our own history? | Were our estimates close to what actually happened? |
| Unit | Story points (team-defined, not comparable across teams) | Hours (fixed unit, comparable across teams and projects) |
| What gaming it looks like | Inflating point estimates so the same work scores higher | Padding estimates so they are easy to beat |
| Who it actually protects | The team's own sprint rhythm | The client relationship and the fixed-price quote |
How estimates drift without anyone noticing
Estimation drift rarely happens as one dramatic miss. It accumulates from a handful of quiet, individually reasonable-seeming habits.
Using estimation accuracy without punishing honesty
The risk in measuring estimation accuracy is obvious: if the consequence of a wrong estimate is worse than the consequence of a padded one, people will pad, and you will have traded one form of dishonesty for another.
Where to start measuring it
You do not need a new estimation methodology to begin. Take the last completed sprint, compare each ticket's estimated hours to its approved hours, and average the variance. Do this for two or three sprints before drawing any conclusions — a single sprint is noise, not a trend.
Keep velocity. It still tells you something real about sprint-to-sprint rhythm. Just stop asking it to do the one job it cannot do, and start tracking the number that actually protects the next date you promise a client.
Goalz tracks estimated versus approved hours on every ticket and rolls it up per sprint and per project, so you can see estimation accuracy trending without building the comparison by hand.