Estimation Purposes

Mike Cottmeyer’s post about How to Think About Estimating is freakin’ brilliant. I applaud him for speaking his mind, and telling us how professional software delivery can get done.

Why?  Because he gets down to the guts of why estimation is hard for so many teams, and while it seems to me that half of the agile community is ready to give up on estimation altogether, Mike hangs in there with a reminder that the customer has a right to a rational contemplation of cost and delivery schedule.  Why – because they are paying the bill.  Period.  Maybe there are cases (startups, or companies with more money that sense), where the budget or the schedule are not constraining the delivery of software, where the customer doesn’t ask how much or how long.  I have never been in that situation.

The building a house analogy is overdone, but it works from the customer perspective.  You would not engage a builder to build a house for you if he told you, well, all my estimates have been wrong before, so I have stopped bothering to estimate.  You would hire the builder who said “My estimates are usually within 30 percent, so we may have to make some tough decisions along the way…”,  because you would know whether 30 percent was a reasonable margin for you.  If it were not, you (the customer) could ask, what decisions can we make now, that will add certainty to your estimate.  That is how a customer thinks.

I totally agree with the use of estimation to drive shared knowledge, because it confers committment around the approach to delivery.  It doesn’t mean that we can’t change that approach, it exposes that if we change the approach, it invalidates parts of the estimate.

I don’t use abstractions (story points, or fibonacci numbers) to reduce the fear in the estimates because I use a confidence factor to “adjust the raw estimates”.  This confidence factor is not confidence in the developers ability to code, it is confidence in the understanding of the story and an implementation approach for the story that will “stick”.  It is pure margin.  If the developer tells me that a story will take 8 ideal days and he has 75% confidence, because the story was similar to three other stories and should follow similar implementation approach then I divide by .75 efffectively adding (2.66 ideal days) to his estimate.  If he says the confidence is 50% because this story could cause a ripple effect through other aspects of the system, then I would divide by .5 effectively doubling his estimate.  Recently, we had a couple stories that had estimates at 25% confidence, because the team felt that the customer didn’t actually understand what they were asking for, and we were sending a message – “get your story straight, or it will likely cost you waaay more than you want” – how true that message is.

I have a different practice around defining assumptions for turning developer estimates into a project estimate, including team size, onboarding resources, story refinement, testing, releases, and the rest of the practices that add cost and time to a project.  That is not what this post is about.  This post is about how estimation creates committment, highlights risk a informs our conversation with the customer.

While those confidences sound discouraging, they also allow the team to feel that we have their back.  Mind you, the stories we are talking about are in the backlog, and in this case we are estimating the backlog as a whole, to give our customer a sense of the potential cost of the entire product.  The low confidences help focus our customer on the more risky aspects of the application, and allow us to structure the conversation about them.

In working through the estimates, the team actually put together a strawman design framework, came up with high level tasks according to the components required for the framework, contemplated through the integration process, and worked toward a shared understanding of the applications business domain.  We drew diagrams of each story on a whiteboard, and after we got that to a good place, we assigned effort numbers to components, and added them up.  We generalized where we could and contemplated technology options.  In truth, we constructed a high level design that we were happy with, and hung some estimates off of that.

Estimation implies a level of committment.  I use confidence to manage the level of committment, to reduce the fear of committment from the developers.  That’s my practice. I use that level committment or confidence to inform my conversation with my customer about risk, and what the riskiest aspects of the product are, and that has been helpful.

We don’t all have to agree on how to estimate, but our customers expect us to have the conversation with them about cost, schedule, and risk from an informed position.  If we can’t do that, then we are just saying, “trust me”. 

 

No Comments

Leave a Reply