Thread by @RonJeffries

There are many forms of estimation. Some people *cough*trolls*cough* like to win internet arguments by showing how everything we do is an estimation of some kind. Yay, them.

There is one particular kind of estimation I'd like to talk about today, backlog item estimation.

1/18

This might also be called story estimation. It consists of associating an estimate with each item in the backlog. The estimate is most commonly a single number, despite wisdom telling us that it should be a range. It is often a time in days, and sometimes a pure number.

2/18

If it is a pure number, the intention is that it be proportional to the time it will take to implement the item. If it's a time, it is supposed to equal the time to implement the item. Either way, the estimate predicts the time to implement the item.

3/18

The estimate would be quite useless, as far as I can see, if it didn't reflect time to build. Now some "experts" will tell you that the estimate represents some other nebulous idea like "difficulty" or "size". These people never tell us what that's good for.

4/18

I think that's because difficulty and size are not useful ideas in our work, but it could just be that I don't get it. So, here, we'll think of estimates as reflecting the time to build the item.

What might they be good for?

5/18

Assuming reasonable accuracy, I can see a few potential uses of value.

First, it can be useful to quickly go around the team and estimate a story, as a test of common understanding. If we all estimate pretty close to the same, we probably are all on board.

6/18

But if there is a wide variation in estimates, there's something afoot and it should be looked into. We may not understand the item, or we may see different issues in building it. Whatever is the case, we use disagreement on estimates as a trigger for deeper study.

7/18

Second, the dev team might use estimates to decide how much work to draw into the Sprint / iteration. They'd observe that they do about 20 every Sprint, and so they'd pull about 20.

In my experience this is somewhat useful but fraught.

8/18

Using the estimates this way can enable the team to just pull the next 20's worth without thinking about how the work is going to be done. This is often too superficial, leading to playing the numbers rather than actually thinking.

9/18

A third possible use of the estimates is to add them up, expecting that in so doing, we'll get a date by which we'll be "done". It's almost impossible to resist the urge to do this.

This is, in my view, almost certainly a Bad Idea.

10/18

The predicted date will inevitably become a target. Estimates mostly fail by being too small, so that the real time to build will exceed the target. This will produce pressure to "go faster", resulting in more defects and poorer code, slowing us down further.

11/18

A deeper fundamental mistake is the assumption that the current backlog contains all the items that need to be done. Never, in the history of mankind, has anyone created a complete list of what needs to be done. So the add 'em up model is fundamentally broken.

12/18

Another very human issue is that if we were to play a word association game with managers, when we said "estimate", many of them would say "actual". "Everyone" knows that when you use estimates, you should check against the actuals, and bring them into line.

13/18

When you focus on estimates of cost and actuals, you're taking your eye off the ball. The point of an iterative process is to focus each iteration on value, not on cost. You select items, each time around, to get as close as possible to something you can actually use.

14/18

The best way to manage an Agile effort is to select high value items and do them, building the most valuable possible product every day. This ensures that you have the most valuable product by any deadline, however realistic or arbitrary it may be.

15/18

So summing up, item estimates have a couple of slightly valuable aspects, which can be obtained readily without estimates. And item estimates lead quite directly to poor -- but very tempting -- management practices.

16/18

As such, I think that backlog item estimates are unnecessary for effective Agile development. As they are unnecessary, they should be eliminated until shown to be necessary.

In addition, they are often actively harmful. Again, they should be eliminated.

17/18

If I were defining a new framework, which I am not, I would include item-level estimation under the Razor Blades to Babies heading, as a practice which is quite dubious and of little value. I'd suggest not doing itemestimates unless you had to, and probably not even then.

18/18