Scrum and…

The logic of #NoEstimates

#NoEstimates follows in the footsteps of Agile and Scrum

Introduction

There are several reasons to be interested in #NoEstimates:

• You feel that estimates are misused. You have been requested to come with estimates based on incomplete information and then the estimates were treated as promises.
• You are becoming so predictable that it doesn’t make sense to use story points anymore. A team knows how much it can chew without requiring story points.
• When no-one needs to know what will be built by when and when no-one requires to know upfront where the money is going to be spent on in a certain quarter or year to get budget, there is no reason to estimate.

One might argue that the effort of estimating and monitoring the actuals on a micro level is wasteful. The question is: at what level does estimation make sense?

#NoEstimates spawned some interesting alternatives for traditional estimating:

• Adopt forecasting of the number of items for a Sprint based on historical throughput, dropping story point estimation.
• Drip funding, decide how much you want to spend on the options available, drip fund & iterate.
• Slicing Heuristic, as an example: an item ready to be worked on must have only one acceptance test.
• No estimates at all as there is no need to do this.

If you find this summary too high level, see below article for more details on what the alternatives entail:

#NoEstimates — The 6 alternatives for estimating

You might think these #NoEstimates ideas are wild, but I’d argue they have a foundation in Agile and Scrum.

Agile and #NoEstimates

We all know the Manifesto for Agile Software Development:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

#NoEstimates alternative drip funding is heavily focusing on the things you learn from an iteration and discussing this with your customer: responding to change and customer collaboration. New information decides if you continue to fund. There might be a rough idea where we wish to go, but the new insights that the software brings us will lead to the decision ‘will we continue?’.

The practices of forecasting and slicing heuristics are efforts to move away from following a plan. #NoEstimates says that software development is complex and as a result it is often nonsensical to put a lot of effort in creating an upfront plan. Efforts to create schedules and plans are to be minimized as much as possible. It’s better to use readily available historical data and/or make all items about equally sized.

Dropping estimates altogether is a drastic implementation of Responding to change over following a plan.

Scrum and #NoEstimates

One of the most important parts of the Scrum Guide is the following:

“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known” — SG

This is very much in line with the arguments for drip funding. To bring this to Scrum: you can think about funding per Sprint, as described in Sjoerd Nijland’s The commercial Scrum conundrum.

It is also in line with the arguments for probabilistic forecasting and slicing heuristic: due to the uncertainties in the world of complex software development minimize your efforts in estimating and use readily available data to forecast and/or ensure that stories are roughly equally sized.

Another interesting piece from the Scrum Guide is this:

“ Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide.

Scrum works well with probabilistic forecasting (which I referred to as ‘Drop Story Points’). I have used it myself and I wrote about it too:

My first experiences with probabilistic forecasting

Within Scrum probabilistic forecasting can also work well combined with slicing heuristics, which will theoretically bring you roughly equally sized items.

Bottom Line

#NoEstimates follows in the footsteps of Agile and Scrum. It looks at ways to minimize the efforts of estimating and planning and instead wishes to focus on creating working software. It is one of the more drastic interpretations of Agile to date and works well with Scrum.

Disclaimer: with this article I tried to emphasize on practices as proposed within #NoEstimates. I am not interested in the debate whether or not these practices include estimating. This -imho- is not the point.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

Do you want to write for Serious Scrum or seriously discuss Scrum?