Sometimes we get wrapped around the axle about estimating. People ask why we should bother estimating when we know that our estimates are always wrong. Some folks go so far as to say that all estimating is waste and we shouldn’t estimate anything ever.
A couple of posts ago I made the case that the real reason for estimating is to create shared understanding around what we are going to build and how we are going to build it. My point was that it wasn’t so much the number that was important, it was the process of getting to the number that was important. You should check out the post, it generated a ton of great discussion.
While I still believe that estimating is primarily about creating shared understanding, I don’t think that post went far enough. Yes, we need shared understanding, but let’s get real… our customers need to know how much something is going to cost and when they are going to get it.
It all comes down to time and money… and what I am going to get for my time and money. What am I getting for my investment.
We’ve come a long way over the last 20 years understanding how to estimate. We seem to have learned that no amount of up front planning ever really makes better estimates. We seem to be getting better at deferring decisions and estimating closer to when the actual work will get completed. All good stuff, but have our estimates really improved? Are we delivering on time and on budget more often?
Rather than give up on estimating, I want to introduce a new way of thinking about estimates. You see… we seem to think that an estimate is supposed to tell us exactly what it will take to deliver what’s being estimated. I believe that estimates are just supposed to get us close. Estimates have to get us close enough that we have a shot. Once we are close enough to have a shot, we have to manage the hell out of the work to make the estimate real.
In other words, once we are close… estimates are no longer estimates… they are budgets.
Let’s say I bring a user story into a sprint and that user story is expected to take three points. Assuming we have a stable team, the team should have a general idea of how long a three point story will take to deliver. At the moment that three point user story is in the sprint… at the moment we have made the sprint commitment… we now have a three point budget to get it done.
With our three point budget in hand, it is now up to the team to work with the product owner to negotiate the implementation of the story to make it three points. It is up to the team to implement the simplest thing that could possibly work to make the story three points. It is up to the team to manage impediments and dependencies to make the story three points.
Delivering on time and on budget is not an accident… it is an act of will. It’s a process of actively managing the implementation of whatever we are delivering to make the budget and schedule a reality.
Only at the point we learn our estimate wasn’t even close, only when we have learned that delivering something of value just isn’t possible, do we even get to consider slipping time or cost. That said, if our budget was that far off, I’d say we have a bigger problem with how we estimated, how we generated shared understanding, and how we dealt with risk… but that is a series of discussions for another post.
