In my time coaching teams and organizations, I have found that a few things keep arising that are challenges for the product owners – especially when they work in an environment where there are multiple product owners and multiple teams and/or a product manager for one product. Usually, this setup means that there is a product manager who is focused on the higher-level product strategy while the product owners are focused on tactical implementation of that strategy. With so many things coming through the backlog it is often a challenge to decide what gets done and in what order. The product manager likely has authority over the higher-level backlog (often called it the product backlog or program backlog) that gets populated with items that serve product strategy and meet business goals. Sometimes the product manager works in a vacuum and decides what features will be prioritized in the next release. This usually means that product owners don’t get visibility into the big picture of the product and don’t get input into what work should be prioritized. The information they hold is valuable as are their insights and opinions. It sometimes means that product owners end up working in silos that focus on their own responsibilities instead of sharing information and working together for the overall success of the product.
The product owners should have authority over the team backlogs which gets populated with items prioritized from the product/program backlog and often also includes work from internal stakeholders to meet their business and technology needs. Product owners bringing work directly to the team backlog from internal stakeholders can create a bit of a problem if that stakeholder is talking to multiple product owners. I’ve seen this result in 2-3 teams trying to solve the same problem and not knowing other teams were already working on it. That’s a lot of waste being created. It also means that this work can be out of the line of sight of the product manager who has responsibility for the whole product. Making this work visible is important.
In this article, I’ll be introducing a few techniques that can help solve this transparency problem and create a collaborative product team that has the overall product success as their primary focus. These techniques will help you more clearly connect product backlog items to business strategy and goals by 1) using a comparison template for features/epics that paints the picture of how a proposed feature is connected to product strategy and goals or filtered off the backlog as necessary. 2) filtering and ordering by relative business value, and 3) filtering and ordering by relative Return on Investment (ROI).
First, it’s important to understand that the product strategy should be contained in the product roadmap that shows the goals and outcomes the product manager wants to achieve quarter over quarter (usually for the next year) and higher-level strategy of less defined goals and outcomes beyond the first year (often a total of 3 years). The roadmap is intended to be revisited and changed and should be refined at least quarterly to ensure that the product strategy is still competitive. Product owners and teams should have visibility into the roadmap and understand the product strategy, goals, and desired outcomes.
Based on the product roadmap that is in alignment with the current market and business needs, the product backlog is populated. Techniques such as feature mapping can be helpful to determine the product roadmap and populate the product backlog with proposed features and/or epics and capabilities. (Insert your company’s terminology.)
Since there is a whole product team that needs to understand and contribute to the success of the product, product manager and all product owners should be collaborating to understand how proposed features are aligned with product strategy and worth the investment to build them. I have found that this is often not the case due to internal politics, pecking order, or just not realizing that this step needs partnership since these product backlog items will be pulled by the product owners for execution on their team backlogs.
Determining business value
For the purposes of this article, I will define product backlog as the high-level backlog that contains the features and other large backlog items that align to the product roadmap. I will assume that this is a scaled environment with a product manager or chief product owner who owns the overall product. The assumption is that after the techniques described in this article, the product backlog items will be pulled by product owners into their respective team backlogs for further refinement. I will not be addressing team backlogs in this article.
However, if you are not working on a larger scale product with multiple teams and product owners and you are solely responsible for the product back, these techniques are still applicable. The proposed techniques are simply a way to align the product backlog to product strategy and goals and to ensure that the most valuable work is getting done and unvaluable work is not.
To determine the most valuable work, you must have a consistent way of looking at the backlog items so they can be compared. This is a critical step that is often missed. Since it’s hard to compare apples to pineapples to see which ones are the best quality – you want to compare apples to apples and pineapples to pineapples.
Technique #1: Feature Comparison Template
The following is a good model template created by Bryce Evans you can use for your backlog items in a way that enables you to see how they align with business strategy and the value they contain. Some of these categories may not apply to your work so modify it as needed. The key is to make sure that you compare consistent information across all items.
Feature/Epic Business Value Determination Template
Overview: This is a general review or summary of the feature.
Stakeholders: Identify who is actively working on this project or with this customer, or whose interests may be affected positively or negatively by the execution of this project. If your product strategy prioritizes specific clients, users, or stakeholders identify the business priority of the stakeholders.
Risk Score: This is a risk score from the business perspective (10=Negligible, 30=small, 50=medium, 100=high, 250=very high). The intent is to determine the risk in not doing the work.
Category: The following categories communicate the justification for a specific feature. (Your product may have different categories)
- New Business – every feature that will potentially bring new customer or new markets, will also bring a fresh flow of money.
- Up Sell – every feature that will potentially bring money from existing customer and could be sold as add-on, upgrade, or plug-in.
- Retainment- every feature that will avoid losing customers and will avoid the company losing money as well.
- Operational Efficiency- every feature that will allow the company to save money (costs)
Revenue Opportunity: What if any revenue opportunities will we have if we deliver this feature?
Contractual Obligations: Are we contractually obligated to complete the work? If so, when does it need to be completed by?
Corporate Strategy: Does this feature align with any corporate strategies?
Product Strategy and Goals: Does this feature align with current product strategy? What product goals does this feature help meet?
Customer Impact: How many customers does this feature impact? Is it a narrow, mid, or broad customer impacting feature?
Customer Complaint: Does this feature address any specific customer complaints?
System Health: Does this feature improve the keep system health or keep it from deprecating?
Competitive Advantage: Does this feature give us any unique competitive advantages?
Market Opportunity: Does this feature provide us with any additional market opportunities and if so, what are those?
Mashup Value: Does this feature align with any other features in our backlog?
Filtering every product backlog item using the Feature Comparison Template ensures a consistent method of evaluating product backlog items and using consistent criteria to determine what stays on the backlog and what comes off. As a team, compare the features and how closely aligned they are to the product strategy and goals. Use this information to filter items out of the backlog that do not align with product goals and strategy. Remember, there are lots of great ideas. You shouldn’t do them all. Great ideas that do not align with your product strategy drag you away from your goals. Some great ideas are not feasible due to a lack of return on investment. Focus on the most valuable work that brings you to the outcomes you want to achieve. The most powerful thing a product owner can do is say, “No,” to great ideas that shouldn’t be on the product backlog.
Technique #2: Relative Business Value
The Feature Comparison Template provides the product team with relevant, consistent data that can be used to understand PBIs to determine their relative business value. One technique I propose for determining relative business is a simple, real-world working version of The Business Value Game created by Vera Peeters and Pascal Van Cauwenberghe. The entire product team should participate in this activity so all product owners and the product manager have insight into what’s happening with the product. All product backlog items should go through this process before being placed on the team backlog. This means technical and architectural features, business focused features, and user focused features should all be on the backlog and looked at for overall value to decide the order of the product backlog.
You can decide on relative business value a few different ways. Your process is up to you – what’s important is that you are consistent. Here are a few things I have seen to be successful and helpful in the collaboration efforts needed to determine relative business value.
Suggestions:
- Use planning poker and add two zeros to the number on the card. So, a 1 becomes 100, a 13 becomes 1300, etc.
- Use a spreadsheet or comparison table to put the information for the items where they are all visible to compare one to another easily.
Steps:
- The product manager/owner proposing the item debriefs it with the group and answers any questions.
- When the group knows enough to decide value the do an initial vote.
- If the values are not aligned, have a discussion to hear and clarify any considerations from the group that they used that may have caused them to vote for lower or higher business value than the rest of the group.
- When the group has enough information and seems to be in alignment on the value of the work, revote as needed.
More Suggestions:
- I like to use an electronic Trello board (or similar tool) as a place to hold the backlog items and move them around as the group discusses the work. This gives everyone a visual of where they sit relative to one another.
- Throughout the process and after all items have been discussed look at the holistic picture of how the items are laid out next to each other. Make sure the values assigned compared to one another make sense. Re-discuss and revalue any items that seem out of place.
Ordering and filtering the product backlog
Order the backlog with the most valuable items first. You will need to make a business decision about if there is a cut off, “Anything below ____ value will be filtered off the backlog.”
Feature #7: BV 2000
Feature #5: BV 2000
Feature # 2: BV 1,300
Feature #3: BV 1,300
Feature #6: BV 800
Feature #1: BV 200
Feature #4: BV 200
Feature #8: BV 100 Removed
Technique #3: Relative Return on Investment
I recommend adding an additional step to further filtering and order process your product backlog. Determining a relative return on investment of the surviving backlog items to make sure that they are feasible and worth the investment.
For the purposes of this exercise, you can use a relative cost generated through a t-shirt size estimate given by the development team(s) who will be taking the feature into their backlog. Remember that these items are still very high-level, and the team is making assumptions about the work to give a gut feel size. Later, when the items are closer to being done, they will need to be refined and may get resized once more is understood. This process works well for initial high-level decision making and in situations where you may not have access to all the financial data needed to make more informed data-based determinations of ROI. Best case, you have that information, however I have consistently seen that this is not the norm in many companies.
Step 1: Decide on a consistent scale for t-shirt sizes and relative cost and use that scale consistently. For example, if a small feature in general takes 1-2 sprints the cost is relative cost of a team for 2 sprints. We’ll say $80,000 for the purpose of this example. If a medium feature usually takes 3-5 sprints the relative cost of a team for 5 sprints is $180,000. And so on…
Step 2: The next step is to divide the cost by the business value to generate a ROI score:
Feature #7: 2000 / 80,000 = .025 or 2.5%
Feature #5: 2000 / 180,000 = .011 or 1.1%
Feature # 2: 1,300 / 80,000 = .016 or 1.6%
Feature #3: 1,300 / 180,000 = .007 or .7%
Feature #6: 800 / 80,000 = .01 or 1%
Feature #1: 200 / 80,000 = .0025 or .25%
Feature #4: 200 / 180000 = .0011 or .11%
Step 3: The higher the score the greater return on investment per point of business value. You will need to make a business decision about a cutoff point where the investment is not worth making and the item should be filtered off the backlog.
In the example above, assume there is a business decision that anything with a score lower than .9% ROI is not worth doing. Order the backlog items by highest to lowest relative ROI. In this example, the order highest to lowest they would be:
Feature #7: 2000 / 80,000 = .025 or 2.5%
Feature # 2: 1,300 / 80,000 = .016 or 1.6%
Feature #5: 2000 / 180,000 = .011 or 1.1%
Feature #6: 800 / 80,000 = .01 or 1%
Feature #3: 1,300 / 180,000 = .007 or .7%
Feature #1: 200 / 80,000 = .0025 or .25% Removed
Feature #4: 200 / 180000 = .0011 or .11% Removed
In this example the last two items are deemed not worth the investment and removed from the backlog. Please note that the examples used in this article are simply examples with random numbers to help you understand a few simple techniques to filter and order your product backlog considering product strategy and goals, business value, and return on investment. These examples are not intended to suggest where cutoff points are – that’s a business decision for you to make.
