Jan Krüger provided this Guest Post. Jan is @j_hkrueger in Twitter.
Jan recently attended the Global Scrum Gathering in Berlin and held an Open Space session on No Estimation. and asked if I would post these notes.
Notes from the No Estimation Session at the Global Scrum Gathering in Berlin
Recently I attended the Global Scrum Gathering in Berlin. On the last day there was “Open Space”. Open Space is a meeting pattern for large groups who want to work on their own topics. Anyone can contribute topics and conduct a half-hour session about it. My topic was “no estimation”. There was applause at the market place, and someone shouted “Good Luck!”.
Fig: One of the mottos of “Open Space”
My thesis is:
- Estimates are waste (defined as work which delivers no value)
- Even worse, estimates are harmful because they build a bridge into the non-agile planning world and thus prevent the transition to an agile product development.
It doesn’t matter whether we estimate in story points, man days, euros or whatever, if we do magic risk surcharges, etc. These are workarounds to the planning fallacy. Some work better than others but an estimate is always an estimate. I take #noestimates literally. Simply don’t do it and see what happens.
The Open Space session was very enlightening for me (and hopefully for the other participants).
The first topic was the definition of “estimation” and if it were at all possible, not to estimate.
Somehow you always implicitly estimate, e.g. if you are planning a sprint, you will estimate what fits into it.
There was an interesting consensus of the participants: “All estimates are wrong”.
A Product Owner, who participated in the session, stated he needed to estimate to determine the benefit / cost ratio. By that he gets a kind of mini business case for every backlog item which allows him to prioritize.
Someone emphasized, estimation is great to foster communication about new stories.
One participant argued that the Scrum Guide requires the backlog items to be “estimated”. (That’s correct; it is written black on white)
Someone told from his team they hide the estimate in the story size by simply slicing all stories to the same size. (This is hardly #noestimates, if you take it literally as I do).
“All estimates are wrong”.
I can confirm that from my own observation. There is one saying that estimates are particularly difficult if they relate to the distant future – e.g. for release planning. In the Scrum team I serve it often happens that the PO asks for estimating an implementation detail to decide whether to build it or not (the mini-business case says hello). A short-term and easy to overlook estimate. Even with these I regularly hear afterwards, “that was more complex than I thought.” Even worse there are the many unknowns from peripheral systems, interfaces, sick leave, team coordination, individual performance, on-boarding, foreign activities and similar hardships of life.
Also you might ask yourself, what happens to the mini-business cases, if I underestimate the benefits and overestimate the effort? Will I possibly never build an important feature? What if I overestimate the benefit (which happens quite often)?
Let’s do a thought experiment: Estimating does not work. What would be the optimal strategy for steering software development? Why do we need the estimate? What is missing, if we can’t do it, how do we solve the problem otherwise?
Everything we build has a cost. As the team builds one item after the other, each item the PO prioritizes for implementation moves all the other items cost- and time-wise into the future. How far? No idea. We will have to act purely evidence-based. The only way to knowing what the item will cost and how long it will take, is to actually build it. Is this a risk? Yes it is, that’s why we need to slice to the smallest possible units that move us forward. Ideally, the items of highest value first. “Highest value” is uncertain – a hidden estimate? Absolutely, so we need evidence as soon as possible about the actual value of the items.
“Smallest possible” sounds like a size comparison. Is there always less effort in less functionality? In my experience, yes. Is there a hidden estimate? Maybe – at least it’s good to involve the DevTeam in the story slicing. It also improves communication about new stories.
For our risk management, we need to define the “done” (and then comply). The popular “80% complete” is an estimate and these are always wrong.
As a software service provider it’s not our job to change our customer’s project management process. If the customer, however, decides to take the agile way of product development, we can support this transformation by stopping to estimate. It never worked anyway.