Sprint planning from budgets to outcomes
Scrum has been touted as one of the most popular agile frameworks for software development, and its popularity continues to grow. However, as with any popular methodology, there are some areas where it falls short. One such area is sprint planning, which has become a budgeting exercise for allocating engineering efforts to features or tasks rather than a tool for setting sprint goals. This has led to a lack of focus on outcomes and a treadmill of feature specifications that fail to deliver customer value.
To understand why this is happening, it's essential to define high-performance product engineering. It involves rapidly changing user behaviour to deliver customer value contributing to achieving business goals. However, few product engineering teams are anywhere close to achieving this. Instead, they are stuck on a never-ending cycle of features to deliver, often knowing that what they are coding isn't the most valuable thing they can work on.
Let’s look into that a bit further. 👀
The problem with sprint planning
The common sprint planning approach encourages defining a solution to customer problems outside of the team cadence. This approach often excludes engineers from problem-solving activities, which is a waste of their talent and investment in their salaries. To maximize the best problem solvers in the company, the approach needs to change to an outcome-led or product-led approach.
An outcome-led or product-led approach focuses on efficiently discovering and delivering the most valuable features to impact customers. This approach involves setting a sprint goal, which has become a lost concept for many teams practising Scrum. Setting a sprint goal allows the team to focus on the outcome rather than just delivering features and allows the team to prioritise work based on the value it brings to the customer.
Defining high-performance product engineering
A high-performing engineering team will focus on delivering high-quality, high-impact products in a timely and efficient manner. The practice combines expertise, technology, and effective product management to develop products that meet or exceed customer expectations and business goals.
Teams already face several challenges in delivering impactful products, including limited resources, tight deadlines, complex requirements, and changing market demands. They must balance technical feasibility with business viability and continuously iterate and improve their product development processes to stay ahead of the competition.
Being outcome-focused won’t change how difficult the product development process is, but it will change the approach to the final product. Outcome-based thinking helps teams prioritise solutions better, make data-informed decisions, and iterate quickly based on user feedback. By focusing on outcomes, teams can create a culture of continuous improvement and deliver products that not only meet customer expectations – but also exceed them.
Switching to outcome-based sprint planning
An outcome-led or product-led approach requires a change in the way sprint planning is conducted. Here are some of the changes that need to be made:
-
The sprint goal needs to be clearly defined and communicated to the team. The sprint goal should be based on the customer's needs as well as the business goals (whichever OKRs have been set). With the focus on the sprint goal rather than the feature itself, it provides focus and direction for the team and allows them to prioritise work based on the value it brings to the customer. (Bonus, you’re making your team more commercially aware!)
-
Most high-performance teams (e.g. FAANG) do not estimate stories with points. While estimation can be helpful in some cases, it can also be a waste of time. Estimates are often highly inaccurate. They encourage deciding on the technical approach rapidly with minimal information, fail to give the intended transparency and fail to inform prioritisation. Perhaps worse still, they can limit engineering innovation, impeding both value creation and quality. Reviewing organizations' hack day events shows innovative solutions estimated as multiple sprints of effort being achieved in 1-2 days. This is the power of autonomous teams and an example of restrictions created by the fixed scope and upfront estimation. Instead of overly specifying user stories, the team should concentrate on breaking them down into smaller, achievable pieces that can be completed within a sprint. This approach allows the team to focus on the outcome rather than the minute details of the specification.
-
Sprint planning should be a problem-solving exercise, not a budgeting exercise. The team should be encouraged to contribute ideas to solve the problem from the beginning, not be treated as a ‘handoff’ just to code a solution.
-
Outcomes need to be the focus throughout the product life cycle. The team should focus on delivering the most valuable features that impact customers - not just the feature that has been requested the most. Delivering the wrong thing is worse than delivering nothing: it costs money, has a huge opportunity cost, demotivates the entire company, and fails to satisfy the market.
The Importance of Outcomes
The costs of delivering the wrong product can be devastating. Not only can it result in the loss of valuable time and resources, but it can also damage customer relationships and brand reputation. In some cases, it can even lead to the failure of the product and the company (nobody wants to spend money on the wrong thing!)
In order to avoid these costly mistakes, it's essential to remain focused on outcomes throughout the entire product lifecycle. By doing so, it becomes possible to make the best decisions and trade-offs that will lead to the most desirable outcome - that is, what is the most valuable to the customer while driving positive business impact.
Conclusion
Sprint planning has become the Achilles heel of Scrum. The concept of a sprint goal has been lost, and sprint planning has become a budgeting exercise for allocating engineering efforts to features or tasks. To deliver high-growth impactful products, a change is required in the way sprint planning is conducted. The team should focus on outcomes rather than just delivering a never-ending string of features. This can be done by defining a sprint goal, avoiding overly specifying user stories, encouraging problem-solving, and focusing on outcomes.