How to Think About Estimating
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.
Comments (8)
Bob Williams
The act of Estimating may be the most powerful process in the SDLC. It does two major things:
1. Determines if project will even move forward.
If the team comes back with a huge estimate to do work it can keep the project from even starting. I’ve see it happen. Sometimes it was deserved based on the requested scope. Other times it was complete non-sense because the estimated was bloated to keep from under estimating.
2. Creates the budget of the project.
In non-agile shops this can be very limiting. A budget is set at the project onset based on high level estimates of the team before they see or develop final requirements.
If a project exceeds budget then usually those estimating blame it on lack of clarity of requirements. Those giving requirements blame it on the estimators. To your point Mike, usually this means there was not a clear understanding and agreement on what was to be built. It’s a tough step.
So is this project request a bunny or a monster? ;-)
Hey Bob… there is a nuance here that I want to explore. Yes, estimating helps us decide if we are going to do the project. Yes, the estimate results in a budget for the project. But… what’s really happening is that the business has made a decision to invest a certain amount of time and money to receive a certain minimum ROI. If the budget is exceeded, of course depending on the projected margin, you might put that ROI at risk. We might miss a market window that is unrecoverable. So… as a team of people building the product… that’s both engineering and the business… we have to aggressively make trade-offs during the implementation of the project to make the budget work.
In my experience that is not how we look at estimates and budgets. The business things they should get everything they want, regardless of the risk it might introduce to the project. The IT teams tend to think in absolutes and don’t want to make any trade-offs. The business wants it perfect from a requirements perspective, IT wants it perfect from an engineering perspective. When the project fails we can blame the estimators, we can blame the engineering team, or the business… none of that helps recover the project.
So… we have to work together through the life of the project, realizing up front that estimates are wrong. We have to realize the estimate is not a statement that we can deliver within the time and cost necessary, but more a reasonable constraint that the project team has to operate within. It is up to us to come together and make the necessary trade-offs along the way to realize the ROI that the project was chartered to deliver. Agile gives us a great set of tools for running our projects this way. But it is way too easy to adopt agile practices without changing the fundamental mindset of a fixed time, fixed cost, fixed cost product development shop.
Thanks for your comment.
Stu Perron
Mike, I think you have a lot of good points here. I think many people forget that a particular project is just one of many that can be done. Most organizations have more opportunities and ideas than they have resources or money to do. So, they need to choose between them. To make a good choice, you need to compare what you will get out of the effort against the cost. Where do you get the cost — from an estimate. Also, at some point, when the actual costs go too far over the estimate, you have to ask if something else would be a better use of the money and resources. Not to mention that any additional money taken has to come from somewhere. So, some other plans have to be postponed, or something else is not done.
User stories are suppose to be set up so there is a conversation and negotiation. This gives some of what is needed to move it towards the estimate, when appropriate. It reminds me of one situation that actually happened, where they needed team to make a change to their service. They said it would take 1000 hours and 6 months. When the need was explained and that they didn’t have that amount of time, they said, well, if they took a different approach, they could to it for 50 hours and in two weeks. And the 50 hours solution was fine to meet the business need.
Obviously, this wasn’t a user story level. Yes, someone can go off and use this as a perfect explaination of why we need to do Agile and avoid overbuilding. I just use it as an illustration that there is often room for negotiation as we weight the time, cost and funtionality needed and focus on what is really needed to meet the business need.
Hey Stu… I’ll reply more later to your comment, but thanks for taking the time… and really good seeing you here ;-)