The Hardest Challenges of Implementing Scrum, #3: Prioritization by Business Impact
May 12, 2014
Find out why business impact is the only way to prioritize your product backlog.
In my last two posts, I dove into two very common challenges for Scrum teams:
- empowering the whole team to take ownership of process, product and people
- embracing rapid iteration in the most rigorous manner
Today, I’d like to continue by addressing the next challenge I see on the road to effective Scrum adoption: getting the product backlog items prioritized by the impact each item has on the business/product line.
What is “Prioritization by Business Impact”?
Backlog prioritization and grooming is a central concept in agile methodology because the prioritization and re-prioritization process ensures that the team is working on the most important features, and reacting quickly to changes, both expected and unexpected. However, what is sometimes overlooked is the prioritization process itself — how do we truly know if one feature is more important than the other? How do we prioritize items with multiple dependencies? How do we prioritize between a relatively complex backlog item and an interconnected series of smaller items?
This is where the concept of “prioritization by impact” is important. It requires that the product owner assigns, to the best of his or her ability, an expected “business impact” item for each backlog item (or set of interdependent backlog items). The ideal case is when the “business impact” measure can be linked to actual business performance metrics such as increased sales, increased profit, reduction of expense, or reduced sales cycle. If it isn’t possible to establish such a direct measure, then measures of product performance or user satisfaction/success metrics should be considered.
If an item is part of a set of interdependent features, then it should be evaluated both by its impact as a stand-alone item as well as part of the whole set. If an item is a dependency of another item, then its business impact is jointly measured with the items that are dependent on it.
What we want to capture is the holistic effect on the business of getting that new backlog item/feature completed.
Why is This So Important?
As I have stressed above, we need to prioritize by a consistent measure, and business impact is as good as anything else.
Moreover, stripped of all the productivity and efficiency metrics typically reported (number of lines of code, story points completed), the ultimate way to know whether the product engineering organization is achieving its most important goal or not is by measuring the value of their product deliveries. Prioritizing by business impact aligns the product owner’s priorities with the overall team’s goals, and allows team members to feel that their efforts are being expended in the most valuable way possible.
What Makes Prioritization by Business Impact So Difficult?
However, prioritization by impact is not always easy to achieve and even harder to maintain over time. The prioritization process itself is sometimes hijacked by the teams’ tendency to multi-task — that is, to work concurrently on several threads/sets of features, which over time acquire their own inertia and bulk — perpetuating themselves at the top of the backlog priority, leaving little capacity for newly prioritized features.
More disciplined teams can manage to avoid doing such busywork, but can also fall into the trap of missing the forest for the trees when it comes to their evaluation of the value of an individual backlog item. It is easy to forget how a specific feature may fit into a larger whole, and that the business value of the whole is greater than the sum of the parts. It is also just as easy to forget the opportunity cost as well as the failure risk of committing to a backlog item and instead only focus on its value in the case when everything goes as planned.
3 Keys to Adopting “Prioritization by Impact” More Effectively
1) Make backlog items as clear as possible
First, we need to ensure that we are comparing apples to apples when we are prioritizing the backlog. Product owners need to be a lot more precise and disciplined in defining the product backlog, so that the backlog items become extremely clear to all parties, and the evaluation of business impact is as consistent as possible.
2) Get more critical in your Sprint planning
Another area to focus on is the Sprint planning itself, when the product backlog items are decomposed and pulled into the Sprint by the team according to the priorities given by the product owner. As the team knows best what it will produce, it should have its own perspective on the expected business impact of the prioritized backlog items. As such, they should be willing to reject ill-defined features that do not have clear business impact potential.
3) Keep an eye out for bloat and feature creep
At the same time, the product owner needs to be conscious of the tendency for product to bloat and features to gain inertia over time – it is just as important to define what should not be prioritized by pulling the team back from expending its energy on pet projects and needless enhancement of basic features. The team should challenge itself to define what is the optimal way to deliver the requirement of a backlog item, and whether the incremental value gained by adding more to that backlog item is worth the additional effort and resources.
Please do check out my previous posts in the series: Hardest challenges for successful Scrum adoption
- Introduction: The 5 Hardest Challenges of Implementing Scrum
- Challenge 1: Developing a truly empowered, self-organizing, and self-examining team
- Challenge 2: Embracing rapid iteration
- Challenge 3: Adopting prioritization by impact
- Challenge 4: Applying realistic but practical estimation
- Challenge 5: Managing Effective Scrum meetings
Photo by: Andrea