I’ve always had a love/hate relationship with estimation. I find the topic fascinating. Estimation is like a car wreck, it’s hard not to slow down some and take a look, even if you know it’s wrong and you are afraid of what you might see.
As my views on software development have changed over the years, so have my views on estimation. Early on, I thought I could estimate things, and I would often try and fail. After a few years of inaccurate estimates, and long before I knew what Agile was, I decided that I would only give my boss one of three answers: 2 days, 2 weeks, or 2 months.
Even then, I already knew that estimates were pretty useless to do in depth, and so I was basically just trying to answer in terms of a few buckets indicating order of magnitude. Next I learned about Steve McConnell’s Cone of Uncertainty, and realized that if I was going to have to give estimates, I should always give them in ranges. The wider the range, the more I was indicating to my customer that there was high risk and uncertainty. This was another step forward for me.
As I got into agile methods more and more, and I really enjoyed doing Scrum, I thought about how to apply range estimates to what I was doing. This led to my talk at the Agile 2010 and XP2011 conferences on range estimation techniques in Scrum. My ideas were not necessarily unique, but nonetheless, I felt like I was providing better and better estimates to my clients. And I think I was.
But now, more and more, I make sure that I question myself: “Why am I doing estimation at all? Do I really need to?”
Sometimes, the answer is yes. It could be for a variety of reasons, including one as simple as “the customer demands it.”
However, I want to make sure that I at least ask myself if an estimate is really adding any value or serving a purpose.
An example of this was a recent retrospective I conducted with a client. They brought me in to help them consider how to improve their agile process. They were regularly missing sprint commitments, and their estimates were not accurate. Since we’ve worked together before, and they know of my interest in agile estimation, they asked me to come in and recommend some changes.
We spent the day together going through a number of retrospective exercises and learning about their work so far. The “ah ha” moment though was when one of the team members pointed out that their customer doesn’t really care about the estimates, she just wants to see continual progress.
Aha! So we explored why there were doing estimates then, and after discussing it for a while, we concluded that they really don’t add any value to this customer. This customer really just values transparency and regular progress updates, and doesn’t care about estimates. They were bringing her into an estimation process that she didn’t value, which they were regularly wrong at, and it was turning into a distraction.
At the end of the day, as a team, we came up with a number of recommendations for them. But the one that would have most surprised me several years ago was that I recommended they drop estimation altogether. We instead focused on refocusing on highly prioritized lists and improved communication, and they are taking steps towards more of a Kanban methodology.
These changes are still an ongoing process for them, but the early signs are good. Here is some feedback they sent me recently:
I just wanted to tell you that we appear to be having a good deal of success with the evolving Agile process. The Product Backlog has become the guiding document for the process. At any point in time, the stake holders can tell what we’re working on and what we will start working on next. [Business Analyst] says this document makes it dead simple to complete the project documentation that he is required to fulfill. And this is a good way to help [the Product Owner] track our accomplishments, especially since she is now much less available than when she was previously…
We’ve completely done away with estimation at this point, and have decided not even to use a spreadsheet. So far this has been a good decision.
I am still of the opinion that estimates can be valuable. But we all recognize their inherent inaccuracy, and so it is best to avoid them whenever possible. When we can’t avoid them, we must still communicate their inaccuracy, which is where ranges are helpful.
What I have learned from the agile movement is to first start under the assumption that we don’t need estimates on a given project, and then have the customer prove to me why we should do them. Let’s determine what value they seek out of estimation, and then at least we can craft a solution that gives them the value they need without any false pretenses of accuracy.
