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.

Deadlines in Scrum

One of the topics most of the project managers and traditional organizations at the beginning of their Agile transformation journey are struggling are deadlines. How can we do Scrum and commit ourselves to the date when we don’t know the scope? Let’s make this clear. Scrum is purpose driven, not functionality driven. What does that mean? It’s not about delivery, it’s about achieving the certain outcome. And that’s a game changer. Instead of fixing the whole scope at the beginning, we spend the time to understand the purpose. Form a vision. What do we want to achieve? For whom? Where is the value? How are we going to change the world once it’s done? What makes it different?

Purpose driven

Once you have enough mutual understanding of the business value and the vision, you are ready to continue. So, we agreed that in long-term, you need to achieve this, what about mid-term? What is the most important to achieve now? Where is the biggest risk we need to mitigate by feedback? What impact do we need to get? Once you have this release agreed, you are ready to start Sprints. Again, Sprint is not about precise functionality delivery, but achieving certain impact, deliver value and learn from that. Therefore, there is a Sprint Goal – a small vision for a Sprint, answering a question what do we need to achieve in the short-term.

Finally, none of those deliveries can actually fail. Of course, you can learn that your business idea was wrong or the value was not where you would expect it. That’s why we use Scrum, to test our hypothesis. But the nice thing is, that neither Sprint nor release can actually fail the delivery if you prioritize well because 80% business value is hidden it 20% of the functionality. If you prioritize the value, you always achieve the goals.

So next time when your customer ask when it’s going to be done, you can invite him in the conversation about the value, vision, release charters, and Sprint Goals. Don’t ask what they want, ask what they need and why. Only then you are both going to be successful with Agile.

Sprint Planning in 30 minutes

How much time takes your team to finish Sprint Planning? To my experience it could be anything in between of above mentioned 30 minutes and full day. If you are closer to the second option and it feels scary, annoying, waste of time for you, let’s have a look at few recommendations how to cut it out into 30 minutes.

First, let’s see how to run the Sprint Planning itself. I recommend Product Owners to come to the Sprint Planning with physical cards for each User Story. They quickly introduce them, answer questions if needed and then let the team choose out of them. Don’t bring the exact ordered list; let them freely choose from the cards. There are two reasons for that. First, you maximize work done as they can organize themselves in a way they are most efficient, and at the same time there is higher commitment as well. Second, you build a trust between team and Product Owner. You trust them they will choose the right User Story which brings the highest value at the moment. Once the team select the User Stories witch they believe they are able to finish within the next Sprint and put them on Scrum board, Product Owner and Scrum Master can leave and let the team finish the Sprint Planning. During this second phase team will collaboratively split the selected User Stories into maximum one day tasks and revise the Sprint Backlog commitment. After 30 min they are done, have full board of cards and can start working.

If that still feel unbelievable, let’s have a look to the preparation. There are three key recommendations you should do in order to make your planning fast and meaningful. First is for Product Owner. 2-3 days before the Sprint planning let the team know what are your priorities for the next Sprint, so they can have a look and prepare themselves, ask questions, etc. Second is proper Backlog Grooming. The goal of Backlog Grooming is make sure the team understand Product/Release backlog (i.e. all User Stories, Super User Stories, Epics and vision). At this time team do the estimations and help Product Owner to split User Stories which are too big, or add Acceptance Criteria. Once understood, they are ready to be planned to the Sprint.

To summarize it, if you are not able to do such fast planning, improve your preparation (team time to prepare, grooming, pre-planning) so the planning is here not to investigate new functionality but to confirm how much we can make. Doing that, you gain motivated team who is not wasting time at never ending planning, better reliable Sprint plans and higher backlog quality as you are not pushed to do splits and changes at the last moment. Start step by step and continuously decrease your time needed. It’ll go much faster than you would imagine.