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 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
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:
- Cone of uncertainty;
- Hofstader’s Law;
- Cost of delay;
- Estimate on value;
- Complexity Scale (Liz Keogh’s);
- Task break down.
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.
- Understand the task, user story or requirement (ideal is a refinement session with the involved team members);
- Does anyone in the team, in the company, in the community have experience with that requirement? See the blog post by Liz Keogh to educate your guessing on complexity.
- List of required knowledge and skills;
- What is needed in order to build this requirement?
- List of possible preconditions;
- Is this requirement a precondition itself?
- What are possible dependencies?
- What are possible risks?
- Task Break Down. How can we break it down?
- Which is the lowest hanging fruit?
- Guess for every task a complexity and break the biggest ones down even further;
- Sort tasks by logical order, depending on mutual requirement (e.g. do not build second floor before the ground floor!).
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.