Konubinix' opinionated web of thoughts

#NoEstimate

Fleeting

A hashtag meant to start a discussion on what we actually want to get done and how estimating are actually helping.

There are two aspects of estimations that appear to be discussed here:

  1. whether estimation help or not predicting the time the work will take. Some argue that just counting user stories is enough and that the time spent in estimation stuff is mostly waste,
  2. provided that estimation actually bring prediction value, whether or not people tend to forget that an estimation should never be a target (estimer != s’engager). In that case, it might be better to avoid a supposedly useful technique due to the abuses that are correlated with it.

Estimation should not be a final objective. If your team is doing estimations and it believes it helps it deliver value, then it is ok for the NoEstimate state of mind.

If on the other hand, estimations become targets (see estimer != s’engager), then you are likely subject to measure-objective inversion and should revise your method.

Estimation should follow a scientific method, using bayesian thinking.

  1. estimation are hypotheses,
  2. you do some works
  3. you measure the time spent,
  4. you learn whether the hypothesis was correct or not,

Estimation is a system 1 process, it needs some experiences.

One bad habit around estimates that needs to be fought against is estimation negotiation (see scope creep). It is also sometimes used (even unconsciously) to “shame” people and incentivize them to work extra time to meet their estimations.

Some people argue that those are bad estimate, not actually estimation. Somehow, this is a straw man fallacy1 and those actually already have the NoEstimate state of mind, because it is not at all about not doing estimation, but rather making sure that people understood that it is a instrumental objective and in that sense should be challenged with regard to whether it helps fulfilling the final objective or not.

No estimation is not a method or a set of rules and principles. It is more a way to have people put estimation into question and start a discussion toward a more ethical way of working. It is in reaction to bad management, supposedly like any other common method like agility or lean.

The idea is not to say that people should stop doing estimations, but that for some guys, it did not prove itself and then they just stopped doing it and they did good afterwards. It is a way to tell this and start a discussion about that.

Estimation have become a deontological value, considered good by definition. NoEstimate aims to suggest a change in the state of mind of considering estimations good by default and rather suppose that the most sensible hypothesis is rather that estimation are wrong and consider that using them by default is like reversing the burden of proof.

They warmly suggest to work with the data, to make some statistical analysis and try to find out whether estimation help predicting or not2.

Actually, Vasco Duarte supposedly found out after playing with data that user story number that a better work predictor than estimation and story points where in his situation. At several occasion, he indicates that #NoEstimate is based on the Build, Measure Learn supposedly from lean.

It is also the realisation that we keep trying to estimate, while there is little evidence showing that it provides value.

The author of the hashtag himself acknowledges that the title is a click bait and explains that it is often the case that people don’t answer to more nuanced discussions.

I just need X yeah and can you give me a rough estimate for when that would be available okay

[…]

I can tell you when we can start working on it and I can tell you how long similar functionality has taken in the past

[…]

I don’t need to get five developers in the room do or argue with each other before I give you a number so look at the data and give it the number to you

—

To me, vasco Duarto tells that when being asked “how long will this task take?”, he can answer how long a similar task did take in the past, but putting five developers in the room does not help much answering this question.

if we remember it it’s important and if we don’t remember it it’s not important you know what backlogs are they are a mental disease that prevents us from forgetting bad ideas

—

I partially disagree with this one3.

People that work together long enough end up slicing stories of the same size, being a possible reason why the number of stories becomes a good estimator for work done4. (https://youtu.be/c1gXaAO0JRY)

Notes linking here

  1. Most likely caused by the click bait name #NoEstimate that actually is about something much more nuanced

     ↩︎

  2. the data tells me more about the future than the estimates tell me about the future

    — a guy at runtastic (https://scrummastertoolbox.libsyn.com/bonus-noestimates-interview-with-the-runtastic-app-team)

     ↩︎

  3. To me, this one is more about the product owner not being appropriately engaged and trying to remember all the things. If per reflected, per would naturally remove obsolete stuff. Also, using some kind of maybe list would help keep track of what is current and what is just some idea for later time. Because if you don’t capture it in a trusted system, chances are you will remember it anyway, even though it is not important. ↩︎

  4. Saving time on estimations

    If the Development Team delivers 6-10 small stories during a Sprint, it is very likely that those are approximately equal in size. This means that over time the Development Team will not have to estimate each story individually, just calculate the number of them.

    — https://www.scrum.org/resources/blog/9-reasons-slice-user-stories-better

     ↩︎