To estimate or not to estimate


Even if Twitter wanted to let the hashtag die, there is one in the agile world that went crazy. If you are searching in Twitter for the hashtag #noestimates you will get overwhelmed. There are books, workshops, meet-ups and a lot of blog posts out there just dealing with #noestimates.

What does #noestimates mean? Not giving your product owner any estimate? Leaving the time column of the time and material table in your contract blank? Does it mean just starting before getting any more details on the requirement?

From what I have learned in Gil’s workshop at Agile Testing Days #noestimates is a way to learn how to give educated forecasting. It is a toolbox. I will rephrase some of the tools today and will provide a checklist at the end.

But before we go into practice, I need to prepare you. This might upset you.

We all suck at estimation and btw we also suck at predicting the future.

“Prediction is very difficult, especially about the future.“
Niels Bohr, Danish physicist (1885 - 1962)

The other truth is: We don’t know! Watch the Unknown, unknown speech by Donald Rumsfeld: “…we know that there are things we do not know…”.

So we know that we are really bad at predicting time and effort to a task, we know that we do not know everything beforehand, we know that we can not count in all risks and we know that we do not have a clue about a requirement in a particular field. We know that there are higher chances to win the lottery rather than to get an estimation correct. Why do we keep doing it?

Because we can. It helps us to plan, to deal with uncertainty and we feel more on the safe site with an estimation. With an estimate we feel in charge and confident to handle the project. To make plans and prepare for the future is a very important human behaviour. The homo sapiens probably developed this behaviour around 130.000 BC in the early stone age. If this behaviour to plan and to estimate is so natural for us humans does #noestimates mean to stop estimation?

No. Otherwise the hashtag would be named #stopestimates.

In Daniel Kehlmann's book Die_ Vermessung der Welt_ (engl. “Measuring the World”) he lets Alexander von Humboldt say the following: “…if you are afraid of something you have to measure it.”.

What does this mean for our daily routine on estimating our tasks and user stories?

We need to measure them, we need to understand them, we need to ask questions and we need to compare them, so that we can take our experience into account.

Gil refers to the following tools. The best is to pick them up in his slide deck:

Let's take a closer look to measurements. My favourite is guessing complexity. Scrum uses story points for example by playing scrumpoker. I prefer t-shirt sizes. T-shirt sizes are a more haptic way to imagine how big or complex a story is. It makes the amount of the unknown visible.

Time effort and guessing working days has its eligibility, but in our case it drives the discussion in a totally different direction. Can you work faster? Why does it take you that long? The discussion is not about the story anymore, it is more about time and effort and get the story done as it is.

The benefit of estimating with complexity tools is that you keep focus on the requirement itself. The outcome of a discussion why a task is XL is much more valuable. You can nail down problems, uncover uncertain parts and remove redundant parts.


To estimate or not estimate is not really the question. I personally think we should move away from buzzword bingo and stop discussing how we should estimate. Let's focus on the stories to be achieved and open the room for questions. Allow everyone in the team to be part of the understanding and add a section in your user story for the unknowns.