Making Better Estimates, Part 5: Relative/Arbitrary vs Absolute/Real

Part of a series on Making better estimates.

Relative estimation in arbitrary units beats absolute estimates in actual time units.

Relative complexity is easier to judge than absolute values. If you doubt this, do a quick experiment: look at two people sitting near you. Which one weighs more? Pretty easy, right? How many pounds does each weigh? Harder, right?

Estimating in relative complexity means judging how big or complex tasks are with respect to other tasks. The units of complexity to use in this kind of estimation are irrelevant. We prefer “points”. I’ve also used NUTs (nebulous units of time). You start by having the team agree on a reference point. For instance, the team might decide that task 1 is a 10 NUT problem. Now, when estimating task 2, it can be compared to task 1. 50% bigger or more complex? 15 NUTs. Half as complex? 5 NUTs.

Why not use actual values of time, even if you are doing relative complexity estimation? After all, the business needs an estimate in days, weeks or months, not NUTs or points. Part of the problem of using actual time units is the confusing accounting that will arise. If you estimate a task to take 20 hours, and you actually finish it in 10 hours, then what do you tell your manager? That you got 20 hours of work done in 10 hours? And what about in the other direction? When you underestimate a task you find yourself reporting that you did 20 hours of work in 40 hours. Really? Why were you slacking? And do you mean real hours or estimated hours?

Estimating in arbitrary units lets you report on the natural wins and losses in a less confusing manner. Great week? “We finished 30 points!” Run into some difficulties? “We only finished 17 points.” You put forth the same effort in each case, so there’s nothing odd to explain.

Tracking your project velocity lets you turn your estimation units into actual time (and hence a calendar and cost for the business). It’s really simple: you simply measure and track the amount of work the team finishes in each iteration. The team’s velocity is the rate at which they can complete work. In our experience, teams takes 2-3 weeks (iterations, in our case) to find their stable velocity. Teams that have worked together before, or similar recent projects may even shorten this stabilization time.

If you’ve estimated the project in points, and you’re tracking velocity, then you simply divide the total number of points of work remaining by the velocity to know how many iterations you expect are required to finish the project. We usually report this to the customer with a burndown chart.

The final advantage I’ll point out about using relative complexity points and tracking velocity is the way they naturally account for the difference between an ideal 8 hour workday and the hacked-up, interrupted, full-of-meetings, occasionally longer-lunch, day. Team velocity represents the team’s capacity with all the messy details of real work situations already accounted for.

Next post: False significance

Previous post: Concrete Experiments