Estimates – Uses, Abuses, and that Credibility Thing Again

Posted on by

In my last post, “#NoEstimates – Questions, Answers, and Credibility”, I brought up the potential for damaging ones credibility by proposing changes without being able to explain why the change should be beneficial. Consider the following exchange on Twitter:

When the same person states “There is a lot written about this” and “The question is young and exploration ongoing” back to back, it is reasonable to wonder how much thought has been put into the “question” versus the desired solution. It’s also reasonable to wonder if this really qualifies as a “question”:

Some people latch on to ideas that tell them they shouldn’t have to do things they don’t like to do. Responsibility, however, sometimes requires us to do things we don’t like to do. It’s not a matter of being tied to a particular practice, but a matter of avoiding things that make us look foolish such as these:

[Note: I find these dismaying not because of opposition to agility, but because I am a proponent of agility.]

None of this is to deny that some misuse, even abuse estimates. That being said, abusive managers/clients are unlikely to either surrender their “stick”. The problem is not the tool, but how it’s employed. It might be useful to consider exactly how likely they are to give up being abusive even if they do agree to quit asking for estimates.

Many of the issues around estimates stem from communication and knowledge issues in my opinion. Typically, the less we know about something, the harder it is to reason about it (size, complexity, etc.). In my experience, two practices mitigate this: providing estimates as a range (wider initially, with a narrower range when the item is better defined) rather than a single point and changing the estimate when new information arises (regardless of whether the new information is an unforeseen issue found by the team or a change requested by the customer). It shouldn’t be a surprise that it’s hard to succeed by making a single estimate up front and refusing to revise it no matter what new information comes in. That’s a bit like driving somewhere by putting on a blindfold and following the GPS without question.

Another practice that can help with uncertainty is using a proof of concept. When in unknown territory, I’ve found it’s easier to estimate how long to explore something than to estimate both the exploration and the implementation of a specific feature. Additionally, this practice makes it explicit for the customer that they’re paying for the learning, not feature itself. Transparency about the risks allows them to accurately determine how much they’re willing to pay just to find out if the tool/technology/etc. will meet their needs.

This is probably a good time to repeat the way estimates are used (from Woody Zuill’s “Why do we need estimates?”):

  • To decide if we can do a project affordably enough to make a profit.
  • To decide what work we think we can do during “a Sprint”. (A decision about amount)
  • To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To decide which is more valuable to us: this story or that story.
  • To decide what project we should do: Project A or Project B.
  • To decide how many developers/people to hire and how fast to “ramp up”.
  • To decide how much money we’ll need to staff a team for a year.
  • To give a price, or an approximate cost so a customer can decide to hire us to do their project.
  • So we can determine the team’s velocity.
  • So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
  • Someone told me to make an estimate, I don’t use them for anything.

All of these are valid enough as stated, but let’s re-word a couple

  • To help the customer decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To help the customer decide which is more valuable to us: this story or that story.
  • To help the customer decide what project we should do: Project A or Project B.
  • To help the customer decide how much money we’ll need to staff a team for a year.

It needs to be really clear that the customer’s needs are the important ones here.

Another use is to help determine whether a particular issue is worth addressing. It’s hard to determine the level of technical debt without a sense of what the cost is to fix versus the cost of not fixing it.

To determine value, we need to know both benefit and cost. A feature that earns a million dollars for a cost of $999,999 is a lousy deal compared to one making $10,000 for a cost of $1,000.

Shaping our practices around our customer’s needs is a good way to create a partnership with those customers. In my opinion, that’s an easier sell to the customer than “dump the estimates and let’s see what happens”.