Product Backlog Prioritization With Multiple Key Stakeholders: A Case Study
Backlog prioritization is a key component of agile product development. However, it can get overwhelming when there are multiple stakeholders: They all make requests independent of one another and asynchronously, while the product manager spends long hours in one-on-one meetings, negotiating with them over what items will make it into the next sprint. The result is often wasted time and resources.
To bridge this division and save time, the best solution is a prioritization workshop that enables them to come to a consensus on the relative priority of their requests. In this intensive session, all the stakeholders can work together to agree on a plan that charts the path forward.
Let’s consider a common scenario. A company’s product team found itself in a problematic situation with the company’s flagship product. The development team and the architects had set a challenging goal to move the product to a cloud-based platform. However, progress was very slow because developers were busy with product feature enhancements and bug fixes. There was a great deal of technical debt to pay down, which stifled the team’s ability to make improvements and proceed with their planned sprints. At the same time, the stakeholders, who were all account managers and worked directly with end users, continued to request feature enhancements to satisfy the customers they represented. Although stakeholders were aware that the development team pulled items from the backlog only when they became available, stakeholders still felt abandoned and ignored. Lead time was high for any request that was not an emergency, and firefighting was all too common. On top of that, stakeholders’ requests regularly were in conflict.
Stakeholders were unhappy and felt like their requests mostly went into a black hole. Their customers were frustrated with how long it took to address simple bug reports and for their requested enhancements to be delivered. As a result, the development team felt like it was being pulled in many directions and simply could not make the technical improvements to enable a faster cycle and lead time to keep up with stakeholder and user needs. The development team needed direction about where to focus its energy, how to balance tech debt against new requests, and how to prioritize the work.
The product owner decided to put everyone in one room and see what happened.
Selling the Workshop to Stakeholders
The first step is to gain buy-in from the stakeholders. In this case, the product owner approached the stakeholders’ manager and explained the benefits of the proposed workshop. He communicated that the goal was to prioritize the backlog items in an order that all stakeholders could agree upon. These were the selling points:
- Saving time
- Driving collaboration
- Aligning communication so that everyone hears the same information and leaves with a common understanding of what the development team will deliver next
- Giving stakeholders a forum where they can speak and be heard
Providing stakeholders with a structured, facilitated forum in which they can express their needs and align with one another empowers them and gives them a better understanding of the entirety of what goes into building a great product. In my own work, I found that my stakeholders were far more likely to notify me of a request, provide details, and answer my questions after I hosted several product backlog prioritization workshops.
How to Run a Workshop
The workshop’s ability to achieve its objectives is heavily influenced by who is in the room. Make sure you invite all relevant experts:
- Key stakeholders of the product: account managers, account director, customer service manager, etc.
- Product manager (or product owner)
- Scrum master
- Subject matter experts
Be sure to send out a detailed agenda ahead of time explaining what will be discussed and when. This will provide the stakeholders with an opportunity to ask questions or make suggestions beforehand and keep everyone focused during the meeting.
How to Prepare the Room
Before the participants arrive, prepare the meeting room so that participants can dive right into the workshop exercises. First, you will have to present the product backlog items on the wall—print out the backlog items or write them down on index cards.
These cards represent the features and improvements that your team plans to implement in the near future. Tape them on the meeting room’s wall and arrange them in the current backlog order—from highest priority at one end to the lowest priority at the other. Be prepared to display more detailed request descriptions and additional details on the projector or TV screen.
Roles of Participants
The product manager is the main facilitator for the exercises, monitoring the time and guiding prioritization by providing context from the product vision. Product managers should avoid getting involved in the discussions and let the stakeholders drive the priority-setting. After the stakeholders agree upon a decision, a product manager can still move backlog items as needed to accommodate other priorities that arise over time. Product managers retain their decision-making power over the backlog, but this exercise helps them to gather information to make future priority decisions.
If a scrum master attends the workshop, ask them to note participants’ feedback on the exercise itself while you are facilitating the event—it will be helpful for future improvements. Subject matter experts participate in the workshop to provide context and additional information for stakeholders.
How to Facilitate Prioritization
Prioritization can be handled in two stages.
In the first prioritizing stage, encourage the participants to decide what items are not critical. Putting the low-priority items aside will allow the group to spend its valuable time on higher-priority items. If there is still no consensus, a product manager should suggest setting the item aside for a more in-depth discussion.
During the second prioritizing stage, a great method for helping people reach an agreement is to utilize the Effort Impact Matrix—a simple yet powerful tool for facilitating a group conversation that clarifies priorities. Items that require the lowest effort for the highest impact rise to the top of the list, and items that require greater effort but will have a lower impact sink to the bottom. You can find several variations of this technique and how to improve it.
If stakeholders keep moving a backlog item back and forth with no consensus, the product manager should have the final say on its priority.
Before closing the meeting, the product manager should check in with the participants and ask for their final thoughts. After they leave, make sure to number or code the agreed-upon requests so that you can easily transfer them to the product management product backlog tool—start with one as the highest priority.
Continuously Improve the Workshop
The product backlog workshop should be a regular meeting in your Scrum cycle, and it can fit into a Kanban team’s ceremonies. If you can conduct this exercise mid-sprint in a Scrum cycle, you will receive stakeholders’ priorities ahead of sprint planning. For a Kanban team, the workshop could be conducted weekly or in whatever cadence is best to realign a roadmap to prioritize the Kanban list.
For my team, having a prioritization workshop every three weeks was sufficient to refresh the backlog’s priorities. Finding the right cadence is critical for the workshop’s success—make sure you find the fine line between participants’ needs and actual demand. Check in regularly with participants about whether the current frequency meets their needs.
Also, create a channel for participants to provide feedback on the workshop. Having a dedicated person to take notes about future improvements to the workshop is helpful—a scrum master can fill this role perfectly. Document the workshop’s improvements to show your dedication to achieving a smoother experience.
Regularly employing a dedicated workshop for backlog prioritization can benefit a company on several different levels. Product managers can use their time and resources more effectively and efficiently. The company can be more agile and achieve better results faster. Asking stakeholders to participate early on can be an incredibly powerful tool to gain their support for product initiatives and get valuable feedback. Executives could also use this workshop to evaluate priorities on a tactical and strategic level in order to advance employees’ alignment with the company’s goals, team processes, and overall communication.
Further Reading on the Toptal Product Blog:
Understanding the basics
What is the difference between product backlog and sprint backlog?
The difference between a product backlog and a sprint backlog is the urgency of their implementation: The sprint backlog is used by the Scrum team to develop the most urgent items in the upcoming sprint(s), while the product backlog is a long-term master list of features, some of which might never reach the implementation stage.
Why is a product backlog important?
A product backlog is important because it lays out all the product’s potential features in one place so the development team can see them; it can also be used to set the expectations of product stakeholders.
Who creates a backlog?
The product manager is responsible for creating, prioritizing, and maintaining a product backlog. Requests for backlog items come from various sources: sales, the QA team, customer support, and product stakeholders.
Who prioritizes a backlog?
A product manager prioritizes the backlog and defines product direction. There are many sources for backlog requests, but often, they come from product stakeholders. Product managers have to find a consensus among stakeholders with sometimes conflicting requests, and a backlog prioritization workshop is the best way to do it.
What is a good product backlog?
A good product backlog is a well-prioritized plan that converts a high-level vision into the working details of creating a product.
Located in Madison, WI, United States
Member since April 17, 2020
About the author
Chris is a passionate agile practitioner and a waterfall professional.