When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them. One of the puzzles was “How to Anticipate Quality of Estimates.”
I suspect this item was inspired by the characteristic of the game that introduced a little bit of uncertainty by having different values for Story Points and Business Value points on the front of the card versus the back. It may have also been sparked by some comments regarding estimates are generally going to be wrong.
If I had to sum up all the different perspectives regarding dealing with estimates, I’d suggest the following:
1) Base your understanding of estimates on a historical perspective.
This can be true in a couple of different ways. First, when you are trying to estimate something new, spend most of your time comparing to things that you have already done. For example, I have found that the last couple of times I added a the pages for a new conference to the agile alliance website, it took me about half a day to get them all posted. The time varied based on the size of the conference and how much information we were posting, but half a day is generally how long it would take. So, the conference I have to add, once I get around to doing it (time in queues is often the thing that screws up time to completion estimates the most) I know it’s going to take me about half a day.
Second, take into account the typical error involved in your estimates, or your team’s estimates. Before I started working in an agile setting, I used to apply the rule of pi to estimates from a particular Architect. Every estimate I received from this architect was usually way low, and I found that if I multiplied his estimate by pi (3.14159265359) I would usually end up with a much more usable estimate. I used historical experience to influence what I did with current estimates.
2) Don’t worry too much about precision.
“But wait!” you might say.
“You just said that you would multiply an estimate by pi and listed it out to 11 decimal places, and now you say ‘don’t worry too much about precision’? WTF?”
That was a joke.
I didn’t multiply the estimates by pi to the 11th decimal place, I usually just tripled them, which was good enough. I use pi when I tell the story because it’s funnier. Kind of like 42 makes a good Ultimate Answer to Life, the Universe, and Everything.
Estimates are based on small amounts of information, a lot of assumptions (stated or unstated) and just some plain old guessing. Extreme precision doesn’t add much value and can be misleading. Instead of providing very precise estimates – “it will take me 27 days” you’d be better off by going with a little bit less precision such as “a little bit more than a month” or better yet as a range “1 – 2 months”. The more you can signal your appreciation for uncertainty, the more honest you are being with the people who asked for the estimate, and the more honest you are being with yourself.
3) Understand what the people are using the estimate for.
When people ask how long something will take, or how much it will cost, they are often trying to determine whether or not it’s worth doing. If that is the decision they are trying to make, order of magnitude estimates – this will take days versus this will take months – will often be sufficient. If they are using the estimate to start planning corresponding activities, or to set aside the proper amount of money, then you may need to be a little bit more precise, or you could ask more questions.
Let’s take the example where you are asked for an estimate so that your team can plan the corresponding activities that go around product launch. Instead of providing an estimate or worrying about more precision, ask how long those other activities usually take. Many supporting activities usually are a bit more consistent, and as a result have a more stable time line. Find out how long those other activities usually take. If you sense whatever you are doing is going to take longer than those other activities, agree to do some work and then provide a more informed estimate later, or just give a heads up that the other steps should start happening.
Another question you can ask when you are asked how long is something going to take is “when do you need it?”. Then if the time frame in which the new work is desired is way shorter than what you can deliver the work in, find out if there are ways to reduce the amount of work you do while still meeting the desired outcome. You may be only able to meet the outcome for specific scenarios, or assume a very simple way for addressing the problem. A similar question comes about from a budget perspective, and you’ll find that more often than not, people have a number in mind of how much a particular change is worth to them. I call this approach “movie phone estimating“. It allows you to change the conversation from estimating limbo where you’re constantly being asked “how low can you go” and guessing what number to match and instead work with known constraints and can apply some creativity to delivering the desired outcome within those known constraints.
4) Put the appropriate amount of work into doing your estimates.
If you follow the first three pieces of advice, you’ll find you have a good guideline to know how much work to put into getting your estimates. The general answer is “not much.”
You usually put estimates together at the beginning of a project when you know the least, so it doesn’t make too much sense to spend a lot of effort estimating. You’re not going to learn a bunch of additional information that way.
That’s why James Grenning suggested planning poker and it’s variants. That’s why the #noestimates folks suggest that counting stories may be an appropriate alternative to spending a lot of time even doing planning poker. That’s also one of the implied findings from a study that Todd Little describes in his post To Estimate or #NoEstimates that is the question.
I wouldn’t worry about the accuracy of your estimates as much as whether they are providing useful information for making decisions. If you find you are consistently making the wrong decision based on the information that estimates are providing, then I’d look into how you are doing your estimates. If the flaw comes from other sources, then don’t try and fix what ain’t broke.