Stop estimating, start forecasting.
A couple of days ago, an old post of Jeff Sutherland himself resurfaced on social media. He wrote about estimating stories and how it slows down teams instead of improving performance. One of the most common misunderstandings about agile is you need to estimate the work you will be doing. How could you otherwise predict the future? Today, I want to dive a bit deeper into why estimating your team's stories with story points, hours or apples is not doing you any good. In contrary.
With the help of your team’s historical data you can detect a lot. From certain trends in cycle times, to detecting bottlenecks which need to be resolved. Even forecasting the future is possible. Today, we’ll use that same data again to solve the question of why you should not estimate stories. And certainly not with story points or hours.
At In The Pocket, we have a lot of data. Tons of projects to analyse. Some teams working with and other teams without estimates. We were particularly interested in the ones that do use story points for estimating stories. With the help of one of our Machine Learning Engineers, I dived into some data about these teams. From one of our projects, we extracted a big list of completed stories, together with their assigned story points and the cycle time — You can read more about Cycle Time, what it is and how it can help you here — .
We plotted this on a scatter plot and calculated the correlation coefficient. This number tells you how large the statistical relationship is between two variables. When you do that, you get something like this:
Each blue dot represents a completed story. On the x-axis, you can find the story points that were used in estimating these. It is very common for teams that use story points to use the Fibonacci series. This is why there are some gaps between eg. 3 and 5. On the y-axis, you can find the cycle times of those stories. One of the first things you can notice is that there is no big difference in cycle time for a story that has 2, 3, 5 or 8 story points. We can state that for this project, there is almost no correlation at all between story points and the resulting cycle times. Perhaps only for the smaller stories. But the effort of estimating everything does not weigh up against that.
In an ideal world, if there would be any correlation at all, we would see a graph like this:
To understand why this phenomenon happens, we need to have a look to what cycle time consists of. Cycle time is the time it takes for a ticket to complete. So the time between the moment someone starts it until the moment someone completes it. The definition of the start and end status can be different for each team or context.
Between the start and the completion of a ticket, three things can happen: someone can be actively working on it. It can be sitting there, waiting for someone to be picked up (eg. a handover stage between a developer and a quality engineer), or it can be blocked. These three combined give us the cycle time of the ticket.
Cycle Time = active time + waiting time + blocked time
Nobody knows what will happen in the future. There are tons of variables that influence these times. A sudden dependency can block a ticket with a snap of a finger. Someone who gets sick can cause waiting times because the team needs that person's expertise, and so on. Thus by definition, these are impossible to estimate. This leaves us only the active time to try and estimate.
Humans are notoriously bad at estimating things. Active time consists out of development time, testing time, code reviewing time and a lot more other value adding activities. It is impossible to have insights on all these activities and know upfront how long they will take for each ticket. Moreover, the active time almost always is the smallest one of the three.
Some teams use reference stories to score new ones relative to these. As these reference stories often have a different context in which the team completes them, this also is a dangerous approach to take.
In short, estimating stories is impossible. As a development team you are ignoring waiting and blocked time. It is not that you are doing this on purpose, it is just impossible to do it. Nobody can predict the future, you merely can forecast it. Use the data you generate by completing items to gain insights and forecast the future. Don’t try to do it based on gut feeling. How? Read more about it here.
