Estimating work has always been a subject I’ve hated. The truth is that estimates are always wrong. So, what do you do when the business demands you have them? I’ve included a section on estimation in my upcoming book, Agile Discovery & Delivery: A Survival Guide for New Software Engineers & Tech Entrepreneurs. The book is coming out in July and the pre-order link should be here really soon. Here’s an excerpt from that section on estimation.
Estimation
Estimation is a necessary evil. I take estimates with a grain of salt because they are always wrong. It doesn’t matter whether you’re a seasoned developer with 25 years of experience or a new hire right out of college. Estimates are wrong. They are guesses and we ought to treat them as such. The best way to go about making an estimate is to use the fastest, most accurate method of estimating you can. You know it will be wrong, so do the best you can in the shortest time possible. There are two types of estimates: absolute and relative estimates.
Absolute Estimates
Absolute estimates are fairly straightforward. How much time will this work take?
Four hours.
Two days.
Five months.
A year and a half.
Absolute estimates are time-based estimates. Teams estimate each piece of work. Then they add them all up and come up with a project timeline (which, again, will be wrong). In many organizations, upper management will internalize that estimate. They’ll assume it is infallible and plan everything around this date. Then, they’ll get upset when the team inevitably misses their estimate.
It’s better to acknowledge that estimates aren’t perfect and work with time ranges. For example, “this work will take 2-4 months” and/or relative estimates.
Relative Estimates
Relative estimates don’t have a time-based component at all. Instead, teams look at all the work before them and estimate it relative to all the other work they have to do. To start, they find the smallest, easiest piece of work they have. Then they base all the other estimates on how much larger that work is than their smallest piece.
The team gets to decide what values to use for estimating. Two of the most common sequences teams use are T-shirt sizes or the Fibonacci Sequence.
T-Shirt Sizes
Example T-shirt sizes look like this: S, M, L, XL, XXL, …
Your smallest unit of work would be “S” for Small or “XS” for Extra Small. Work that’s a little larger would be a Medium (M), work larger than that a Large (L), and so on. T-shirt sizes work well because most people have a frame of reference for how much larger a Medium is than a Small. We’ve worn clothing all our lives and these sizings seem intuitive.
Fibonacci Sequence
You might remember the Fibonacci Sequence from a math class long ago:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34…
Each number is the sum of the numbers that came before it. When estimating product work, we tend to simplify this range of numbers and limit how far up they can go. A common range might be:
1, 2, 3, 5, 8, 13
Anything over 13 is so big that it must be broken down more before it can be estimated. Using the Fibonacci Sequence method, your smallest piece of work is labeled with a “1”. Anything approximately twice as large is a “2” and three times as large is a “3” and so on. The Fibonacci Sequence gives us more separation between the various sizes of work. The larger the work, the more error there likely is in its estimate, so the larger its value relative to the others.
Story Points
We have a name for the relative, numerical estimates we use on agile teams, they’re called Story Points. Story Points have no time-based equivalent. Many teams try to translate story points to time (“A 1 is equal to 4 hours, a 2 is equal to a day”). Those teams are missing the point (pun intended). Remember: estimates are always wrong. Take the time-based approach away and we’re forced to talk about timelines in the abstract and as ranges. This is a much healthier practice.
Teams can measure their Velocity based on the number of story points they get done each sprint. Over time, team velocity stabilizes but usually varies by a few points here and there each sprint. Once it does, we’re able to understand the range of time over which a project might be completed. Take the total points left, divided by the average number of points completed each sprint. Multiply by the number of weeks in a sprint and you’ve got a guess for how long a project might take. Present that number as a range (+/- a sprint or two on either side). Now you’ve got a decent understanding of when a project will be done.
Estimating is generally done during backlog refinement and sprint planning. Many companies do a rough round of estimation at the beginning of a project. This gives them a sense of how long everything will take and helps them decide whether to move forward. Teams can use relative estimation wherever they estimate. The more the work has been broken down and examined, the more accurate the estimates will be. But, again, estimates are always wrong.
No Estimates
Which is what leads me to touch on No Estimates. Once teams get good at breaking down their work, most stories will be approximately the same size. If that’s happening, you don’t even have to estimate the work at all. Count your tickets and use the sum as a measure for Velocity. It’s simple, quick, and gives your team a decent idea of how long work will take.
I go on to talk about Planning Poker and offer a couple of survival tips for surviving estimation. I’d love feedback on the above. Add a comment below or reach out to me via the Contact Page.