As an early Product Manager, I’ve taken over a product with more than 200 items in the product backlog, most of which will never be completed, but I still need to regularly begin the backlog grooming exercise with the sales, BD, and implementation teams. This means that I will be attempting to guide dialogue with more than 20 call resources. I worry that both the implementation team and the sales team may become pushy with their recommendations.
I’m seeking for methods that will help me accomplish this. I must first define the topic’s scope. Should I limit the scope by selecting the top 30 items that have a chance of ever being completed and asking the team to only prioritize those top 30 items during the call?
Second, how can I choose between other callers’ divergent viewpoints?
Is there a certain tool or action I should use to reach a groomed list in a scientific way?
Do you have any specific guidelines in place for backlog grooming exercises? What are the best strategies to accomplish this?
So, request to all the senior PMs in here, your expert viewpoints, insights and guidance shall be highly appreciated.
What is your goal, or the objective you are attempting to impact? Increased adoption of a new module, or perhaps increased interaction with a particular feature. Your grooming and prioritization will be much easier and more objective once that is evident and your team is on the same page.
Also, you’ll be able to use the collective wisdom of the group to determine which epics or projects on the backlog will probably have the greatest influence on your goal. I usually do so by assigning each epic or initiative a score between 1 and 5, or I do that in groups. That will eventually bring the most effective projects to light. If your coworkers share your vision and are committed to the same end result, they will be far more likely to challenge one another rather than you and you will be able to better utilize their expertise.
In order to have a meaningful conversation, you must first establish the goal and then make sure your team understands why it is important (for example, by connecting it to your company’s goals, such as growth within a particular segment). Hence, you will experience a much more comfortable ride:)
I’m currently doing exactly the same, fortunately without 200+ items to deal with. I recently performed a first cut, eliminating things that are older than two quarters, have no connection to a business case, or lack user stories. No one will miss it, and I’m 99% certain that I don’t need anyone’s permission. In that scenario, I’ll take responsibility for it, recreate the product case, and set priorities.
Backlog grooming can be really painful, as it is the process of reviewing and refining the items on a product backlog. It is an essential part of agile development and helps ensure that the backlog is up-to-date and prioritized. I can jot down a possible process for backlog grooming for a large group:
Schedule regular grooming sessions: Decide on a regular schedule for backlog grooming sessions, such as weekly or bi-weekly. Make sure everyone involved is aware of the schedule and is available during the designated time.
Invite relevant stakeholders: Invite all relevant stakeholders to participate in the grooming sessions, such as product owners, developers, testers, designers, and other team members who will be involved in delivering the product.
Prepare the backlog: Before the grooming session, make sure the backlog is up-to-date and includes all necessary items. Ensure that the backlog is prioritized based on business value and that items are clearly defined and actionable.
Review and refine items: During the grooming session, review each item on the backlog and refine it as needed. This includes adding details, clarifying requirements, estimating effort, and prioritizing items based on business value.
Assign tasks and responsibilities: Once the backlog items have been reviewed and refined, assign tasks and responsibilities to team members. This includes identifying who will be responsible for each item and setting deadlines for completion.
Follow up and track progress: After the grooming session, follow up with team members to ensure that tasks are being completed on time and according to the defined requirements. Use a tracking tool or software to monitor progress and identify any issues or roadblocks.
By following these steps, you can create an effective backlog grooming process for your large group. The key is to ensure that everyone is involved and invested in the process, and that the backlog remains up-to-date and prioritized based on business value.
Agree to what others have written to a certain extent. But I have my own opinion. Here’s my two cents.
Ignore the backlog. Don’t start with solutions. Start with problems. You are not a feature factory. Spend some time to understand your customers and the problems they face. Dive into data, talk to them directly.
For your stakeholders, divide and conquer in detail. Never hold a call with every stakeholder you have. You will empower those with louder voices to overtake those not willing to speak up. Setup time with each of your stakeholders independently to understand them and their needs. Do not promise them anything other than that you’re there to learn and listen.
Once you do that you’ll understand your users and stakeholders.
Then begin to list out the problems you’ve found and the user pain points those addresses. Opportunity size these based on your organizations vision and mission. I personally have my teams use ICE (RICE minus the R). So impact to the business (essentially reach plus impact, confidence in delivery, effort to deliver).
This gives you a systemic way to compare many initiatives.
Each of my teams probably have around 500 items in their backlogs. We will ignore the vast majority of those because we understand our users and bubble up the items we believe are the most impactful to them and the business.
500!!! Wow. I thought 45 was too many. How can you possibly keep track? Stuff only makes my backlog if it’s going to get done soon.
Your advice is great though. Sales team will always be twice as loud as the devs which is bad. And having a way of measuring the impact of all changes against their effort is essential to prioritizing.
HOWEVER: How can 500 items manage to end up on your backlog? It seems like everyone has written down every single idea they have. Personally, I like to keep those items and use them to create a publicly accessible product case. Instead of some salesperson’s arbitrary suggestion, I want my engineers to see a backlog that has already been RICE’d and is prepared for implementation.
To me a backlogs purpose is to simply house ideas before they go on a roadmap. Once a project or idea (be it a simple improvement, epic, or saga is on a roadmap), my teams have committed to it and we ICE it. We communicate this roadmap internally and make it widely known where we are going. That roadmap is what our teams and stakeholders see.
Our process is: Backlog → Roadmap (ICEd) → In Planning → Planned (ready for dev) → In Progress (with dev) → QA/Merge (we do a lot of push on green) → Test in progress → Cleanup → Done
When you have features and products that have been around for many years with many different PMs at the helm you end up with a large list of ideas that no one ever got to. So you find yourself weighing the opportunity cost of cleaning up that backlog or declaring backlog bankruptcy. In my opinion, bankruptcy - or simply ignoring it is ideal. So you end up with a giant list of things that you simply ignore because it’s not worth your time to clean it up.
Ideas are cheap. Knowledge of your users at this point in time (right now) is invaluable. I’d much rather be spending my time with customers or digging into a problem than cleaning up the last PMs mess they left me in JIRA.
The process I teach my PMs now is that we want a living roadmap that is continually changing. I make a stupid show of an alligators mouth with my hands. The farther you get away from yourself the less certainty you will have. We commit to (and communicate) things ideally 1-2 months out, we have a a good idea of what we’ll be doing in 2-6 months, we know where we’d like to be next year, beyond that is simply hopes and dreams. You should have a general idea where you think you should go in a year plus (your vision for your product) but know that it’s almost certainly going to change.
I know this is more than what people asked. But I wanted to give some extra context for anyone still learning. I learned a lot of this through trial and error. So I hope someone else can skip some of those lessons if they find this helpful!
This. OP post has a couple of key words that could portend the untimely death of the product: sales and BD. They will put things in the backlog that specific customers demanded. You need to set the top objectives for your product vision and metrics for determining success. Align on this as prioritization framework with your boss and other senior leaders, then use it to identify and execute roadmap candidates. Some might be in the backlog, some might be things your customers didn’t know they wanted yet.
Although there will undoubtedly be differences in opinion, Product’s goal is to put the products on the path to success. Instead of trying to prioritise 200+ products only solely on opinions, you need to identify what a successful product looks like.
You must now exercise your product muscles. You must first establish a vision and strategy for your product. It is useless to attempt to review 200+ things without it.
Provide some effective product results that are in line with the product vision. Establish KPIs to gauge progress and be aware of your baselines. You are now prepared to sort through your belongings.
Handling a large group of stakeholders during a backlog grooming exercise can be a challenging task. Here are some strategies that may help you to effectively facilitate the discussion and prioritize the backlog items:
Set clear expectations: Before the call, communicate to the stakeholders the purpose of the meeting, the scope of the discussion, and the expected outcome. You can also communicate the rules of engagement and the time limit for each discussion point. This will help to set expectations and keep everyone focused.
Prioritize the backlog items: As you mentioned, it may be helpful to focus on the top 30 items that have a higher chance of getting done. You can prepare a list of these items and share it with the stakeholders before the call. During the call, you can ask the stakeholders to prioritize these items based on the business value, effort, and feasibility.
Encourage collaboration: During the call, encourage the stakeholders to collaborate and share their opinions. You can ask them to share their perspectives on the items and listen to each other’s feedback. This can help to create a shared understanding of the items and identify any issues or risks.
Use a decision-making framework: In case of conflicting opinions, you can use a decision-making framework to help the stakeholders make a decision. For example, you can use a framework such as “Decide, Consult, Inform (DCI)” to determine who should make the final decision, who should be consulted, and who should be informed about the decision.
Document the outcomes: It’s important to document the outcomes of the call, including the prioritized items, the decisions made, and the action items. This will help to ensure that everyone is aligned and aware of the next steps.
All in all, the key is to facilitate an open and collaborative discussion while keeping the scope of the discussion manageable. By setting clear expectations, prioritizing the items, encouraging collaboration, using a decision-making framework, and documenting the outcomes, you can effectively facilitate the backlog grooming exercise with a large group of stakeholders.
Kudos on taking over! It sounds like you’ll be assuming some leadership responsibilities and setting the direction for your team. Well done; that’s extremely exciting!
A “backlog grooming process,” then? Although a PM wouldn’t do this, given you’re new, it would not be a bad idea.
I guess, first isolate the FEATURES the stories belong to, so you understand the business intent. No sense looking into individual Stories. Where do these Features align to the business impact? And how does the backlog contribute to that success? How much money has the Finance department invested into these Features and where do they align on the existing roadmap? How many Stories are left and how many Stories are Featureless?
Isolate the version RELEASES that the backlog adheres to, so you can get a sense of urgency on the planned release date for these. This will show you what’s in danger, specific to release management. Find the red flags and focus on releases that are behind schedule.
After isolating the Features and Releases, ask your Product Owners (POs) to step up and explain the BUSINESS IMPACT, progress, confidence and alignment this backlog has to the existing roadmap. What are the Budget concerns on CAPEX or OPEX projects and if it is in growth, maintenance, or decay. Figure out what the Product’s strategic value.
Figure out what you’re on the hook for on the weekly PSR (Project Status Reporting), so you’re not embarrassed in front of your peers. How does this backlog relate to tracking on their PSR and what are the red flags? Number one rule in PSR is, “no surprises.”
White down the full schedule on meeting ceremonies onto a post-it and stick it to the top of your laptop. Attend every demo and monitor the burn down charts. Read up on the retrospectives prior to your PO meetings.
If the backlog is so vital to you, just look at what they contribute to. If the Summaries don’t make sense to you, have them explained by the PO. If you’re concerned about what they mean, isolate the backlog based on component. That should suggest in the general intent of each backlog item as research, maintenance, etc.
Good luck! I hope my comment to your post was ever so slightly useful.
I believe you are like us. We have a sizable 200+ backlog from the project implementation phase that we need to structure releases for one managed services team out of.
Nevertheless, I am luckily not the PO for this and have no useful suggestions. The group in charge of organizing this is employing top-20 lists.
To determine whether chances are worthwhile pursuing, look at Teresa Torres’ opportunity solution trees. There’s a good likelihood that majority of those 200 products won’t make a significant difference for your main goal.
I was going to add this if it wasn’t already mentioned. Opportunity Trees + North Star Metric makes it much simpler to organize backlog items/ideas, show how they drive business value, and communicate why random item 133 is not on the priority list.
In order to start developing your own feeling of value and influence, I concur with the other suggestions that you should actively engage with your customers and their challenges.
Here is a solution that might help manage prioritizing and stakeholders, even if it won’t solve the immediate problem of a bloated backlog.
I’ve discovered that the “purchase a feature” prioritizing exercise is quite useful in situations where one or two loud voices drown out other voices.
Shortlist possible features/enhancements to work on for the next quarter (or there abouts).
Work with dev team to estimate/size these and assign a ‘price.’ For e.g. correlate ‘price’ with story points or any other estimation technique your team like to use). Keep pricing simple and make sure there is enough price difference to distinguish the effort/complexity of each PBIs
Select core group of max 7 stakeholders (anymore and it can get unwieldy) to have prioritization input.
(Optional, depends on your stakeholders) 1-2 days prior, circulate brief feature summary info so participants know what will be for sale that quarter.
Invite all to the prioritization/purchasing session. Do not reveal prices until people are in the meeting to prevent people gaming the exercise.
In the meeting: stakeholders buy/prioritize features 5. Each stakeholder gets an amount of ‘money’ total amount of money should be equivalent to the capacity of dev team over the given planning horizon. Usually there are some large features that no one stakeholder can buy on their own. 6. Reveal prices and ::this is key:: provide 2-3mins of silent time for all stakeholders to ‘buy’ features - if possible I suggest revealing purchase decisions after all stakeholders have completed purchasing (Mural has a nice anonymous feature for this) 7. Discuss tradeoffs as a group until all money is spent. You’ll likely need to reallocate some funds that multiple stakeholders purchased (eg $5 items ends up with $10 on it) and there will likely be some larger items that do not have enough funding to deliver (eg $100 item with $75 on it). The discussion of tradeoffs between stakeholders and moving the allocated money from one feature to another is priceless!
Post meeting- Document the decision of what to work on this quarter and use these decisions to build roadmap.
Tips: Include tech lead and give them cash to participate. Include the larger chunks of tech debt/ dependencies to make this work visible and help establish realistic expectations re: delivery timeline. You can give different stakeholders different amounts of money, but think this through very carefully and get agreement on this ahead of time or the buying session can break down. Before team does this for the first time, meet/inform to introduce the process.
I recently performed a first cut, eliminating things that are older than two quarters, have no connection to a business case, or lack user stories. No one will miss it, and I’m 99% certain that I don’t need anyone’s permission. In that scenario, I’ll take responsibility for it, recreate the product case, and set priorities.