This excerpt from the Kindle pocket guide, Practical Estimation, discusses how estimating with abstract units does not necessarily mean that you are doing relative estimation.
Traditional Absolute Estimation
As a software developer, I may not really know how long in absolute terms (e.g. hours, days) a particular piece of software will take to develop. If you are a software developer, it is likely that you have experienced this first-hand.
Manager: “How long is this project going to take?”
Developer: “Three months.”
That exchange is an example of absolute estimation. One person has asked for an estimate in terms of calendar time, and another has responded in kind. Nothing wrong with that, on the surface—it is perfectly natural for the developer to answer a question the way it was asked. A difficulty arises, however, if the developer doesn’t yet have sufficient information to answer the question, but answers it anyway just because it was asked.
Early on in my own career, I did software development work on a fixed-price contract basis. That could be a tough game because if I didn’t bid a contract appropriately, I ended up making less (sometimes a lot less) money for the time spent. Working as a programmer making minimum wage wasn’t a career goal, so I had a very good reason to get good at estimating.
Here’s the basic technique I used:
- Break down the work assigned into as many small tasks as I could think of
- Estimate each of those tasks, in hours
- Add up the task estimates
- Pad the sum of estimates by 50 to 100% to account for unforeseen work
- Present the estimate to my manager
- Resist my manager’s attempt to negotiate the estimate downward
- Do the work, which would take more time than either of us had imagined
I hoped that repeating the above process on each new contract would eventually help me get better at the estimation part, but it never really did, even though I was highly motivated. (Later on I overheard my manager telling someone that he usually took my estimates and doubled them in order to get an idea of schedule.)
I never really got good at this kind of direct, absolute estimation, and it wasn’t until many years later that I learned another way.
Relative Estimation vs Absolute Estimation
Manager: “How long is this project going to take?”
Developer: “The project has been estimated at 720 points, and we’re currently averaging 60 points per week, so 12 weeks.”
That conversation is an example of the ultimate use of relative estimation. Even though the manager has asked for an estimate in terms of calendar (absolute) time, the developer has responded, at least initially, in terms of some different, abstract units called “points,” then performed a quick calculation to convert those points to something the manager can use.
The assumption here is that the project in question consists of a number of individual development tasks, that each of them has been assigned its own estimate (in points), and that those have been added together to arrive at a single estimate for the entire project.
Relative estimation also necessarily implies indirect estimation, meaning that estimates are expressed in some abstract units, such as the points described above. This doesn’t work both ways, however. Using abstract units does not necessarily mean that you are doing relative estimation. It’s entirely possible (and fairly common) for development teams to engage in what might be called indirect, absolute estimation. This occurs when point values are merely substituted for their absolute equivalents.
I’ve worked on and with several development teams that believed themselves to be practicing relative estimation, but who were actually performing indirect, absolute estimation. The telltale sign in every case was that team members mentally mapped point values to calendar values while estimating. The typical thought process was something like, “Well, I think this task will take a full day to complete, and 1 point equals half a day, so this task is 2 points.”
So it’s possible to estimate in abstract units while actually engaging in absolute estimation. This is not especially useful, in that it adds an unnecessary level of indirection to the estimation process, which is no better than estimating directly in absolute units (e.g. hours, days).
Telltale Signs of Absolute Estimation
Relative estimation is always done using abstract units, so it’s easy to believe that, if you’re estimating in abstract units, you’re doing relative estimation. But units alone aren’t enough of an indicator—it’s entirely possible to estimate using abstract units (e.g. points) while still only doing absolute estimation.
Here are some ways to know if you’re just doing absolute estimation:
- Relative estimation relies on comparison, therefore it requires at least two items (task, features, etc.) to work properly. If you find yourself assigning point values to individual items, without comparing them to other items, then you’re probably engaging in indirect, absolute estimation.
- If, when you’re estimating, you find yourself thinking of point values as mapping to a specific amount of clock or calendar time (e.g. 1 point = 4 hours), you’re probably engaging in indirect, absolute estimation. At estimation time, estimates should be thought of as relative to each other, not mapped to clock or calendar time.
- If you find it necessary to introduce new values (such as “½”) into the Fibonacci sequence in order to make some estimates fit, you’re probably engaging in indirect, absolute estimation. The ”½” that is sometimes used in estimation sessions to indicate a small effort is a clear sign of mapping points to clock or calendar time. In true relative estimation, you can simply re-scale your estimates to make room for a smaller estimate.
See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”
Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.