My way to #noestimates

The other day I received the paper copy of Vasco Duarte's book about #noestimates and it seemed a good time to write an article about the book and how I became interested in the #noestimates movement.

It was a coincidence that during the elaboration of this book I could interact with Vasco by sending him some comments and doubts. When I say it was a coincidence it's because I never really thought that not estimating was an option at all. For me, it was impossible to manage a project without estimating the work to do it. So, how did I get in touch with #noestimates? I am a regular reader of the blog of Javier Garzas in which he writes daily about different trends in the agile world. One day he wrote about #noestimates and initially I thought it was a crazy idea. But since I am a person of insatiable curiosity, I decided to investigate how it was possible for someone to propose, and affirm, that he could plan software development projects successfully without estimating.

Initially I was very skeptical about the validity of #noestimates

Keep in mind that I had a lot of experience in management projects in an agile way and for me, the estimation through story points using Planning Poker was a pretty good estimation strategy and I was comfortable with it. Therefore, for me it was unthinkable not to make estimates when planning projects. Obviously the accuracy of the estimates, as good estimates, were questionable.

But here we are, with an approach that was shaking one of the basic pillars of my way of managing projects. If it was just a new trend or fashion, then I could let it go. If it works, it meant that I had managed the projects in the wrong way or at least not optimal for a long time. This doubt corroded me inside so I could not let it go and forget about it.

I started my research looking for presentations, talks, webinars ... on YouTube about the subject and I found a talk given by Vasco Duarte about #noestimates. I can't tell what was the first talk I saw, I suspect it was this:

What I saw in that presentation shocked me. Everything he said made a lot of sense. I expected that upon seeing that presentation the conclusion would be that everything was a hoax. But it was the opposite.

He began to convince me that he was right and that I had been wrong all this time. It's hard to assimilate.

Immediately, I got in touch with Vasco, getting interested in the subject. By that time he was finishing the book "No Estimates, How to measure project progress without estimating". Only chapter 1 was available and Vasco kindly sent me the rest so I could read the book before it was published. At the end, Vasco included my recommendation phrase of the book that made me feel very proud.

What I read there fascinated me. I'm not going to spoiler the book and I recommend reading it but I'll give a some comments about it.

Brief review about the book

The book follows the style of the book “The Goal” by Eliyahu M. Goldratt in which through a fictional story based on a project called "Big Fish" it introduces the different basic concepts that support the #noestimates movement. The difference with “The Goal” is that not everything is fiction. It has a novel part and a more formal descriptive part of the concepts, something that is appreciated. The novel part, like “The Goal”, uses the Socratic method in which the character Herman guides Carmen, the main character, through questions towards self-discovery of the #noestimates approach. This use of the Socratic method seemed brilliant to me, because it also guided me. The same questions that the author did to the character I did to myself. Actually, my self-discovery of the approach was parallel to the character in the novel. In fact, the similarity of what happened to the character and what had happened to me a lot of times with some projects was really surprising.

The book describes different elements of Lean, Critical Chain, different laws that describe the behavior of work, complexity, important statistical concepts, how to elaborate INVEST user stories, etc.

It also describes the steps to follow to implement #noestimates. (For the impatient the section is "1-2-3: Step by Step Towards #NoEstimates")

What #noestimates proposes is simple. It says that the precision obtained doing estimations using story points and the precision obtained only counting the number of stories without estimating and making use of the past statistical data is very similar. If this is true, all the time making the estimates is waste.

In fact, the use of estimates can have a negative psychological effect by giving a sense that the uncertainty associated with software development projects has been eliminated. Also it limits innovation because, at the time you estimate, you fix the possible implementations.

The approach described here seems too simple to have any background. But what makes it possible to stop using estimates is how the work is managed and organized. For example, the use of really INVEST user stories, vertical, small and similar size, is what makes this approach work. For this, the concept of slicing the user stories is fundamental.

The continuous delivery of value is what makes it work. If you deliver at any time and continuously what is most important or valuable for the client, what does the estimate really contribute?

The interesting thing about #noestimates is that it aligns very well with other approaches, such as #DevOps in which continuous delivery is a common practice. In fact, many of the elements that make #DevOps possible, are the same, such as the use of small batches and the continuous delivery of value.

My own experiments with #noestimates

One thing that Vasco always says is that there is no need to believe him and that we must believe in the historical data we have. This was what finally convinced me.

I had a lot of historical data to analyze and I could see if what he said was true. I will post some real examples. In these examples I use jira. This tool allows you to easily change the mode of estimation from story points to number of stories and predicts the date of completion of a certain version.

In this first example we have a project in which the forecast for delivery through history points is 12/14/2015 and the forecast only telling the stories is 12/03/2015. As we can see, the forecast is quite similar.

A more recent and larger example can be seen in the following pictures: In the first picture we have that the forecast of publication of the release using story points is on 03/30/2018 while in the forecast using the number of stories is on 03/29/2018. Almost identical

These are just some examples that show that the forecasts based on the history points and the number of stories do not differ too much. This should make us think if the estimates really add value or they are only waste.

What happens if we analyze the burn down chart of a sprint and compare that graph when we use story points or number of stories? In the following screenshots we see an example.

We see that the form is basically the same, the only thing that changes is the scale.

You do not have to believe the data of my projects. As Vasco does in his presentations, I encourage you that if you have historical data, try and experiment with them.

So far my brief analysis of #noestimates, I can only recommend that you read the book and, like me, take the red pill.

 Photo: Courtesy of Warner Bros.