If estimating is a core activity of traditional project management, Zuzana “Zuzi” Šochová explains to us in this article that it is not used by advanced Agile and Scrum teams. Instead, the focus should be on being more reactive to changes and responsive to feedback. We are realizing that Agile is not about plans, but planning as a continuous activity.
Author: Zuzana “Zuzi” Šochová, http://sochova.cz/
There is almost no class where no one would ask me about estimations. So why estimations are not part of Scrum? Let’s start with a bit of context. The whole idea of agile estimation comes from Extreme Programming and the early days of agile where tools like Story points, Velocity, Planning Poker, Burndown, T-shirt sizing, used to be very popular. However, if you look at current state of the art of Agile and Scrum teams, they are not using those techniques very often anymore.
Estimations were always core part of any project management, where we believed we know what needs to be done, so the whole problem is not about WHAT but HOW FAST. Therefore, tracking the velocity, showing the burndown and estimating is very useful in such predictable environments where there is only little unknown. So when people shift to their first agile project, they very often still have the same mindset – we know what needs to be done so let’s create a backlog, estimate individual backlog items, and track how fast we are delivering it. That’s the world where estimates, Story Points, Burndown Charts and Velocity are very useful.
In a contrary, the Agile world is focusing on dealing with complexity and fast changes. We start realizing our plans are failing and that we are often learning too late that something else should have been done instead. In such unpredictable world, all we can do is to change our way of working and be more reactive to the changes and more responsive to the feedback. We are realizing that it is not about plans, but planning as a continuous activity. Therefore, refinement in Scrum is ongoing effort and we discover and detail backlog items just in time. In such world it’s not about going fast (often to the wrong direction) but going to the right direction (even if that is slower). The fundamental difference is that we realized we don’t know what needs to be done and so any estimation of that unknown is kind of useless. We know what needs to be achieved, but without getting frequent feedback from customers, we don’t know how to achieve it. Of course, you can still estimate the stories that are coming to the Sprint, but you need to have a good reason for doing that (see one of my previous blogs on estimating).
Estimating the whole product is not really useful either, as the Product Backlog will change based on the feedback anyway. The value to be achieved (vision and product goal) is clearly defined, just the journey of how to get there is to be defined based on what we discover though short iterations.
The problem we are trying to solve in Agile environment is about how can we maximize the value, while minimizing the effort spent (see more about the mindset shift). It’s more about prioritization, where we try to identify the minimal functionality that need to be done now, and the rest later or never, noting that 80% of the business value is in 20% of functionality. Our backlog items are not functionality driven (telling you what needs to be done) but value driven (telling you what needs to be achieved) where the solution is up to the team to be discovered during the Sprint. Therefore, even individual story estimation makes little sense as the implementation (how) will be designed and updated during the Sprint. Scrum is not fixing the scope within a Sprint, as a Sprint Backlog is just a forecast on how we are most likely going to collaborate to maximize the value towards the Sprint Goal. While the Sprint Goal (value) doesn’t change during the Sprint, the Sprint Backlog can change any time, depending on the learnings, new ideas, and feedback we got from our customers and stakeholders. If Scrum team realize there is a better way to maximize the value towards the Sprint goal, they have to just inspect and adapt their forecast (Sprint backlog items) and continue collaborating on maximizing the value towards that Sprint Goal.
Traditionally teams were estimating what needs to be done and they were using those estimates on answering what can be done in a week, two or three. In Scrum, we set a Sprint Goal and then forecast what is to our current knowledge the best way how to achieve it. And what is based on our current experience feasible. We are ready to change it anytime if new information emerge. To plan our Sprint we are using our understanding the of backlog items (stories) and our experience from the previous Sprint. We are looking at it from a different perspective – how much can fit within a Sprint. And that’s not just about an effort but also skills & competences mix, risk, complexity, etc. It is a similar type of problem as if you are packing to the weekend and measure the volume of all items you like to put in the bag. In reality it’s not just about the volume, but also about the shape and consistency. With Sprint Backlog it’s the same.
So can we tell our customers when are they going to get their product without estimating individual backlog items? Sure. We forecast how many Sprints it might take to achieve that value (Product Goal) and then prioritize so that we deliver the most important features first, which the rest later or never. 80% of the business value is in 20% of functionality, so if your Product Owner can do the prioritization well, you can ‘never’ fail to achieve it (see more about the Product Owner role). Through that process, we focus on different direction each Sprint (Sprint Goal) and inspect and adapt based on the feedback.
Finally, there is the last question, can you estimate backlog items in Scrum? Sure. Same as you can drink coffee, which is not part of any Scrum either. But I guess the downside is, that if you focus too much on estimates, it guides you from focusing on business value. And there is no correlation between the two. Bigger doesn’t mean better.
About the Author
Zuzana “Zuzi” Šochová is an independent Agile coach and trainer and a Certified Scrum Trainer with more than fifteen years of experience in the IT industry. She started with Agile and Scrum back in 2005, when she was implementing Agile methods in the USA. From that time, she has been credited with Agile transformation and implementation for many companies and teams around the world. By creating and sustaining Agile leadership, Zuzi believes the worlds of work and life can be made happier and more successful. This article was originally published on https://agile-scrum.com/2021/09/30/forecast-dont-estimate/ and is reproduced with permission from Zuzana Šochová .