Forecast, Don’t Estimate

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, Bundowns 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’s 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 a 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 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’s 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 proiritizarition 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.