Here’s a Shocking Revelation: You Can Create Long-Term Plans with Scrum
It’s just another way of planning
I wholeheartedly agree with this statement from the Scrum Guide:
“In complex environments, what will happen is unknown” — Scrum Guide 2020
Scrum is a framework for creating value in complex environments.
That settles it, right? If you don’t know what will happen, you also don’t know what you need to do. You can’t create a plan. End of article.
Except, it is not that simple. What’s more, it is not true. You CAN create a long-term plan even if you don’t know what will happen. It’s another kind of plan.
Complex environments and traditional plans
A traditional plan is output-oriented. You break down the work into smaller pieces and plan them accordingly. You know what you need to do, either because it is clear or because you uncover this with a thorough analysis.
You may gather new insights along the way, but these don’t have a massive impact on your plan. You can stick to the plan by making small adjustments. The endeavour is relatively straightforward.
Traditional plans don’t work when you don't know what needs to be done. When thorough analysis will not help you and you need to learn from doing. In complex environments, you need to run experiments to advance.
Objective instead of output
We just established that in complex environments, you don't know what will happen. You don't know what you should do to succeed. Output can’t be a means to plan and measure our progress.
There’s an alternative. Regardless of the nature of the product environment — whether it’s complicated or complex — there’s always a reason to undergo this journey. There’s always an objective you wish to achieve. For example, you wish to increase the user experience, uncover new markets, or stabilize the product.
Your actions are successful when you achieve your objective, regardless of whether you managed to do everything you planned to do. If you completed all tasks to improve the UX of your product and your customers are still unhappy, you failed in your objective.
In complex environments, you know your objective. You know the outcomes you wish to achieve. You can also assess whether you are progressing to your desired objective. Your objective, your desired outcome, is what determines your decisions. In the military, this is called commander’s intent: Commander’s Intent. Larger than the plan is the objective (thank you Harry S Long).
The objective and Scrum
Scrum is all about achieving your objectives. This is why the Product Backlog has the Product Goal as its commitment.
“The Product Goal is the long-term objective for the Scrum Team.” — Scrum Guide 2020
This Product Goal has the desired future state of the product. It should be clear how the team and its stakeholders can determine if the future state of the product is met. It can also include a due date. Here are some examples of Product Goals:
“At the end of the second quarter, we have increased the customer satisfaction rate of product X from 50% to 75%”
“Within two months, we have reduced the number of priority incidents from 15 per week to 2 per week.”
For more on the Product Backlog, I recommend this article from Maarten Dalmijn and this one from Sjoerd Nijland.
The alternative long-term plan
Your Product Goal is the Scrum Team’s commitment. The Product Backlog has all the things that the team believes they need to accomplish to progress towards the Product Goal.
The Product Backlog constantly changes. Whenever the team gains new insights, items are added, removed or changed. The Scrum team constantly refines the Product Backlog.
The Product Backlog and its Product Goal form the long-term plan to improve the product. The Product Backlog items serve as a means to progress towards the Product Goal. But not in a traditional way.
A Product Backlog can’t have a complete plan to achieve the Product Goal. That doesn’t make sense because you don't know. The most important thing is to have an understanding of the progress towards the Product Goal and an idea of what the team will aim to achieve in the next Sprint. A Product Backlog can be super short and/or purposely vague.
Finishing the items on the Product Backlog doesn’t guarantee the team gets closer to the Product Goal. In complex environments, it is vital to inspect regularly. You need to inspect at least every Sprint.
The Importance of the Sprint Review
The Sprint Review is the event to inspect the outcome of the Sprint. The team and its stakeholders need to answer the following questions:
“What have we learned from our experiments and how does this impact the progress towards the Product Goal?”
They inspect the product Increments and any other new insight that may have an impact. These insights could be user feedback, technological developments, new opportunities, and competitor information.
This inspection leads to adaptations to the Product Backlog. The team will make changes to maximize the chances of achieving the Product Goal. At a minimum, they should have a good idea of what they wish to achieve next Sprint.
The Sprint Review is the formal event to update the Product Backlog. Naturally, you don’t limit yourself to this event. You refine the Product Backlog with every insight that changes your view on how you can maximize the chances of reaching the Product Goal.
Plan on Sprint level
I find it important to stress that on the Sprint level, detailed plans also don’t work. This is why teams create a Sprint Goal. The selected Product Backlog items are a forecast of the best way to reach the Sprint Goal. Daily Scrums are about the progress towards the Sprint Goal and changing the plan if needed. They are not about finishing all the planned items.
Change the narrative!
Scrum works with long-term plans. It is wrong to state it doesn’t. In fact, this belief is damaging to the reputation of Scrum. It is a reason why organisations look for other ‘agile’ ways to create products. Ways that are about planning multiple Sprints in advance. Which doesn’t work in complex environments.
The narrative needs to change from output to objectives. Once you have done this, you will be able to create long-term plans in Scrum, in the shape of the Product Backlog.
These plans revolve around the Product Goal, the long-term objective of a Scrum team, and the future state of the product. The Product Goal serves as the commitment for the items on the Product Backlog.
Teams and stakeholders should have their focus on the Product Goal. They should discuss how they conducted experiments to gain new insights and learn if they progressed towards the Product Goal.
Complex environments call for an approach that defines an objective, frequent inspection and adaptation, and constant replanning. The key to success is close collaboration between the team and its stakeholders. It calls for relentless commitment.
Original article February 2022