Yes, estimates are wrong, especially if we consider them to be right.

We could say that estimates are a good indicator of a team’s maturity, of a department’s, in a modern approach.

At the beginning, we estimate everything, for big projects. We estimate everything and precisely. And as twenty years of observation confirm, our estimates are wrong and very often useless. Well, what’s useless is the precision of the number and the time spent calculating it. The conversation and reflection that took place around it may have taught us many things. But often we learn more by trying than by imagining. With time, therefore, with experience, what I called maturity, we realize that estimates are wrong, but that the conversations and reflections initiated may have proven interesting, but that reality has never been as we had imagined it and therefore that the value of these conversations remains limited. We realize that we waste a lot of time. Estimating, especially with precision. Discussing things that will turn out to be different ("no plan survives first contact with the enemy – Von Moltke"), especially if these things occur in the non-near future.

Another problem: by delivering estimates we respond to a need to project, which is understandable, but also often to a need for contractualization. The latter much more incomprehensible as soon as we discover that our estimates are not accurate. But with experience (very quickly on this subject), we also guess that regardless of the accuracy of the estimate, it’s more a lever of pressure and shirking of responsibility that emerges here. Who will be guilty? Who commits to what on a scope that we don’t control? Or especially the opposite: it’s not my fault, they said that…

It’s always a problem when the answer doesn’t actually answer the question. Are you following me? It’s a problem to ask for estimates – which will be wrong – to know “approximately” the time and resources engaged, when often part of the question is: who will be responsible? So it’s always a real problem to have a purchasing department. They’re not asking the same question. And the same answer serves two very different questions…

In short, at first it will be difficult to get these people to let go of estimates (which will protect them, which will allow them to put pressure, etc.), so we will probably reduce the big project into small projects that we will estimate by sub-parts. We keep the estimates. We arrive at these agile iterations. Small spaces in which we estimate user stories or other. This already allows us to no longer estimate things that are too unknown (which will happen later), or too useless (which we will discover will never be done). That’s already progress.

We start to deliver (or not) things regularly. And if precisely it’s not regularly, it will itch… In this dynamic, estimates will help us break things down into small elements to allow us to deliver things, avoid the tunnel effect. Since we’ve entered an incremental/iterative approach, estimates help us perceive if it’s big, medium, or small. And we tend to aim for “small”, or even “medium”, to ensure we can finish things. If we keep precise estimates, we’ll realize that even in the coming weeks surprises and changes will be present. Precision therefore proves to be a waste of time. And precision (or rather the number), pursues hidden goals:

  • Which team scores the most points? (even if this question is absurd, because isolated like this this notion makes no sense).
  • Our client pays for so many days/men, or so many points, are we providing them? (it’s always absurd, you can clearly see how we make something very vague into something very precise, wrongly, but so easy to negotiate).

Here we can have the chance to get out of numbers. Since the point is to break down into small elements, and to have a conversation, a reflection on what needs to be done. And that we’ve learned that we wasted time being too precise (reminder for the absent-minded: estimates are wrong especially if we think they’re right). We then manage to break down into elements without number or figure (t-shirts: XXL, XL, L, M, S, animals: Mammoth, Rhinoceros, Bear, Dog, Cat, Mouse, macro: unthinkable, very big, big, medium, small, etc. Invent your own). There are always people who think they’re clever and do conversions for a while. If they have power, you’ll quickly see that you haven’t yet left the previous system (the dialogues will revolve around time, estimation, and not content, value). Let time take its course? Limit the reading even more: too big, big, medium, small. We save time by not going into useless details, and our estimates are more realistic, because vaguer.

If this works, you start to deliver “medium” and “small” user stories or other. Having spent much less time on useless things like estimating precisely, we raise our heads and we have time to ask ourselves other questions. Like prehistoric man was able to launch into many new activities, because he started cooking his meat, and therefore his chewing and digestion time were greatly reduced. Cave art? Philosophy? We’ll never really know. Thus by saving time the right questions arrive: why this feature? And why not this one? Which one works as expected? etc. We slowly move from a project approach to a product approach. The goal is not to deliver a set of requests, but to work on a dynamic between your product and its use. Another effect of this period: we stop estimating in advance, we perceive a cadence: look, we deliver 4 “smalls”, and 2 “mediums” per iteration, on average. From this cadence we project a capacity. We have a production capacity relative to our product, and no longer an estimated sum of deliverables for a time t. (Hence also the disappearance of backlogs, which are also pits of wasted time as soon as they become a bit loaded).

The reflection having moved toward the product, the value. The estimation has been reduced on one side to: What is our production capacity? What would be most interesting to deliver? How to deliver something usable as quickly as possible (therefore, knowing how to break down into small autonomous pieces that carry meaning)? And the real estimation has grown: what has value for us, for the product? How to validate our hypotheses in the best way? At this point we prioritize by value with respect to the product, and we break down into small pieces our first priorities (and just that) to have enough flexibility, to make possible an articulation that allows us to easily benefit from this investment: validate our hypotheses, and potentially gain value. Before taking the next step. We maximize learning, we minimize wasted time. We keep a vision, a direction. We obtain schedules by observing our cadence, our capacity.

We could summarize four phases:

  • Big lie and waste of time.
  • Small lies among friends.
  • We’re more efficient without numbers.
  • What does my product need?

Finally, some related articles: