Product Backlog Prioritization with multiple stakeholder's

 In an agile product development, the key component is Backlog prioritization. Multiple stakeholders involved in a product/project make individual and multiple requests to add in the backlog to implement, while the product owner must spend long hours to negotiate what items will make it to the next sprint. The result is often wasted time and resources.

To save the time and align on the backlog items, the best possible solution is to call for a workshop for prioritization. The workshop will enable the stakeholder to understand what to be implemented first and can work together to agree on the plan and roadmap.

Problem Scenario:

Let’s consider a common scenario: A company’s product team found itself in a problematic situation with the company’s core product with stakeholders' requests. 

Stakeholder request 1: The product which was build and maintained in a Jenkins environment to be migrated to Azure cloud.

Stakeholder request 2: The units test cases need to be adapted which was not in scope initially.

etc etc...

The developers and architects have these challenging goals which are moving slow because they are occupied on feature enhancements and fixing bugs of a product.

Now there is great deal of technical dept which restrain the team’s ability to work on the improvements and complete their planned sprints. Meanwhile, the stakeholders are also pressurizing team by asking a status on migration from Jenkins to Azure even though the stakeholders are aware of the backlog items and team works on the priority items, stakeholders still felt abandoned and ignored for their request. Important aspects to note are lead time is high for any request which is not an immediate/emergency and firefighting was all too common. Also, stakeholder’s requests are conflicting regularly.

The stakeholders are unhappy and feeling like their request are considered. The customers are also frustrated on how long a bug can be resolved and the new features or enhancements will be live. This results in the developers to feel demotivated being diverted in multiple direction and cannot make the improvements in faster delivery and lead time to keep up with stakeholders and customer needs.

The developers needed direction about where to focus their energy and how to deal with the technical dept against new requests coming from multiple stakeholders to prioritize the work.

The product owner must call everyone for a workshop to solve these problems.

How to sell a workshop:

The first step, the product owner approaches all the stakeholder’s and explain the benefits of having a workshop. He/she communicates the goal is to prioritize the backlog items in a ranking order that all stakeholders could agree upon by explaining below aspects.

1. Saving time
2. Common understanding
3. Collaboration
4. Alignment
5. Transparency
6. Forum to talk and listen everyone’s opinion.

Allowing stakeholders by proving a forum where they can express their requirements and align with all members in workshop empowers them and a better understanding of what to be built first in the product.

How to facilitate a workshop:

The main intension of the workshop is to achieve its objective and it should influence by who are available in the workshop. The product owner needs to make sure to invite all the key members and experts.

1. Key stakeholders of the product
2. Product Owner
3. Scrum Master
4. SME’s (Subject matter experts)

The product owner to make to send an invite with detailed agenda what will be discussed and time. By doing this will give stakeholders and people with an opportunity to ask right questions and make suggestions.

Roles:

Stakeholders:

Client, Project manager, Product manager, Customers service manager etc, who can drive the priority setting on the features in the backlog.

Product Owner:

The Product Owner is the main facilitator for the workshop, guiding prioritization by providing context from the product vision. The Product owner should avoid getting involved in the discussion and let stakeholders drive the priority setting.

After the stakeholders agree upon a decision, a product Owner can still move backlog items as needed to accommodate other priorities that arise over time. Product owner retain their decision-making power over the backlog, but this exercise helps them to gather information to make future priority decisions.

Scrum Master:

The Scrum Master is to monitor the time and note participant’s feedback in the workshop. It will be helpful for future improvements.

Subject matter experts:

SMEs in the workshop provides an additional information on the features and details on the technical requirements for stakeholders.

How to Prepare the workshop:

First the product owner must present the backlog items on the board in a sticky note before the participants join the meeting. This should make the participants dive right into the workshop exercise.

The sticky notes should have features and improvements which team plans to implement in future sprints. All these notes are arranged in current backlog in raking order from high priority to low. Possibly the product owner should be prepared with detailed description of any feature or improvements where anyone in the workshop would like to understand.

How to facilitate prioritization:

Prioritization can be done in two phases.

Phase 1 prioritization, discuss with the stakeholder to decide what feature/improvements are not critical or immediately required. Nest them to low priority and allow stakeholders to dedicate and spend their valuable time on high priority features/improvements. If items are hard to decide on the priority, the product owner should suggest setting the feature/improvement aside for a more in-depth discussion.

Phase 2 Prioritization, a simple and a powerful tool is the Effort Impact Matrix. A great method for helping stakeholders to align and agree by conversation that clarifies priorities.

If stakeholder keep moving any backlog item back and forth, the product owner can or should have the final say on its priority.

Before ending the meeting, the product owner should recheck with the stakeholders and ask their final thoughts. After the meeting the product owner is to make sure to number or colour code the agreed upon request and later transfer them to product backlog so developers can start with one as high priority.

Continuous improvements:

Scrum:

In Scrum, the workshop should be as regular meeting. If the workshop is called in mid-sprint, the product owner will have priorities ahead of sprint planning.

Kanban:

The workshop can be conducted weekly or whenever best to realign on the roadmap to prioritize the list.

Make sure to find a fine line between stakeholders need and actual market demands. Check regularly with stakeholders about the current frequency meets their needs. Also create a teams channel where stakeholders can provide the feedback on the workshop. A scrum master dedicates to take notes about future improvements to the workshop is helpful.

Document the workshops improvements to show the dedication to achieving a smoother experience and aligning team’s vision. Having regular workshops can help team and stakeholders to be more agile and can achieve better results faster.