How To Conduct A Good Product Backlog Refinement
How To Conduct A Good Product Backlog Refinement
Part 2 is here! A guide to finding the right cadence for your team, the structure of my refinement sessions and answering common questions.
Have you ever wondered why some product teams deliver outstanding features flawlessly while others stumble along the way? The latter are not even capable of delivering anything within weeks.
The devil, as the saying goes, is in the details or, in this case, in refining the product backlog.
The point is that without a finely-tuned product backlog, you may find your team building features based on outdated or misaligned priorities, leading to wasted time, resources and opportunities.
If you missed part 1 you can go straight here👇
The Risks of Neglecting Backlog Refinement
For product managers, the backlog isn't just a list; it's the strategic roadmap that guides your product's journey. Hence, refining this backlog is pivotal to your product's success and your team's efficiency.
Otherwise you can face some of these risks within your team and org:
🌀 Loss of Focus: Without regular refinement, your backlog can become a cluttered mess of tasks, obscuring what's truly important for delivering value.
📉 Diminished Product Value: Prioritizing UI enhancements because they seem "refined" but ignoring underlying issues can result in a product that looks good but performs poorly.
🛠️ Technical Debt Accumulation: Ignoring technical debt during refinement can lead to a fragile product architecture that's expensive and time-consuming to rectify.
😞 Reduced Team Morale: Confusion and lack of clarity on priorities can lead to frustration and burnout among team members.
💸 Wasted Resources: Time and effort spent on low-value tasks drain resources that could be better utilized elsewhere.
🏃♂️ Missed Market Opportunities: Slow response to market changes due to a cluttered backlog can see competitors seizing opportunities you miss.
😡 Customer Dissatisfaction: Failing to address user needs promptly leads to poor reviews, user dissatisfaction, and ultimately, customer churn.
That's why it's healthy and useful to prevent these risks and constraints by conducting regular backlog refinement sessions. Take a look at how I conduct mine. 👇
How I Conduct Backlog Refinement Sessions
If it’s your first refinement session or have updates about the product, priority, scope, and more, I use the following structure:
1. Start with an introduction of the product goals and vision
Introduce product goals, priority or scope changes, and any updates that affect the product and what the product team is doing. Why? I love to keep my teams informed. Not only does this help them understand how some decisions are being made, but it also makes them feel part of these decisions and how they work contributes to the product.
2. Provide clear direction and expectations
Before moving to the backlog, I make sure my teams understand the expectations or direction with pictures and diagrams. For example, let's say the priority of the features we are pursuing is going to change, then create a quick diagram showing A to Z.
I love to represent an idea visually, however, this advice may not be everyone, simple bullet points can work as well.
3. Review the state of the product backlog
Then, I proceed to review the product backlog starting with an overview of the items according to the (new) priority I mentioned earlier. This help them to connect the dots. It makes the product team feel more secure and reduces anxiety about what to do next.
In my experience, I have seen how some product managers prefer to safeguard and keep this information to themselves, acting as gatekeepers. It's not necessary for your team to know all the details, but it's worse if they don't know anything at all.
4. Review the user stories in detail
I then go through the user stories one by one and show wireframes or visual examples of other applications to help express what is being asked. At this point, if you're lucky and have a team that likes to participate, many interesting discussions can happen!
This back and forth between questions, ideas, suggestions and a lot of technical considerations is great and is really the purpose of these sessions. The more information you can get to improve the work items, the better. Plus, you'll need to follow up on questions that come up with UX, analytics or other departments.
💡 Note that if this is not the first time you are doing the refinement with your team, I will suggest that you can skip the introduction part from time to time, but pick it up again when you feel it is time to do a refresher for the team even if there are not many changes.
Following this structure in the session helps the product teams identify upfront how they are going to solve some of these challenges or if they foresee risks with this new approach. I love that on the refinement calls we can talk about roadblocks or challenges, but also brainstorm possible solutions and improvements.
Finding the Right Cadence
Determine when and how frequently it is very important because you don’t want to do backlog grooming each day. That would even sound crazy, right?
But to identify the right cadence for your product you need to consider different factors and variants, like:
📏 Project Size and Complexity: Larger projects with multiple teams may require more frequent refinement sessions to ensure alignment and clarity among all team members.
For example, does the project use a new technology stack for the team? These aspects also need to be taken into account.
👶 Team Capability and Maturity: Experienced teams might require less frequent sessions as they are better at estimating and breaking down tasks.
However, newer teams may benefit from more frequent refinements. How long have they worked together and how is that dynamic?
🔄 Release Cycle: The proximity to the next release can also dictate the frequency of refinement sessions.
As you approach a release, you might need more frequent sessions to tackle emergent issues and final priorities. Are you releasing after every sprint? Monthly?
🌀 Feedback Loops: The speed at which you can gather and implement feedback from stakeholders or end-users can also affect the cadence.
Fast feedback loops might necessitate more regular refinements.
Depending on the answers you obtain from this analysis, here are some cadences that have worked for me in the past:
👣 Twice a week: I think this is necessary for teams taking their first baby steps. They have never worked together before, are starting a new product or project, and the complexity is challenging.
💡 Normally, after a month or so of working together, we can move to a weekly cadence, but this also depends on the direction the product manager can give to the team. Clear communication is key!
1️⃣ Weekly sessions: As a starting point, weekly sessions can suit many teams, particularly those following two-week sprints. In this case, the team may not be new, but the technology stack is. In addition, the project may be very complex and require a regular cadence to anticipate roadblocks.
2️⃣ Bi-weekly sessions: This is for teams with a high level of maturity and have enough time working together as long as they are very familiar with the technology stack and know the product very well. If your product is lucky, these teams can sometimes tackle very challenging projects.
Lastly, Answers to Common Questions
⏱️ How long can these refinement sessions last?
As long as you need. Within the suggested cadence I mention, I consider these sessions to be 1 hour. But sometimes they will be less or more.
📝 How many items should I refine in a single session?
Depending on the structure of your user story, your writing style and how you break it down, among other things. You may come away from this session with a good amount of material or just a revised story.
🗂️ Do I need to complete user stories before these sessions?
Not exactly. I would absolutely not recommend being too specific when creating user stories and especially if they are going to be refined. It could be a big waste of time because in the end you will get changes, feedback and other details from these sessions.
Your job is to bring to your team a problem to solve, visualized on a small card or whatever works for you. For example, you can complete this “card” in the live improvement session in front of your team.
Don’t be too specific, approach flexibility.
✅ How do you know when an item it’s refined properly?
Here I’ll reference
post about this topic.Aim for a DEEP backlog
Roman Pichler's DEEP backlog is an excellent (and my go-to) target for your refinement sessions.
DEEP stands for:
Detailed appropriate
Estimated
Emergent
Prioritised
During a backlog refinement session, I work through each ticket individually until they all reach the desired DEEP status.
If you want to know how he gets it, I suggest you keep reading here 👇.
👨🏻💻 Should I invite stakeholders to these sessions?
I remember seeing somewhere that refinements improve the sense of collaboration with stakeholders, and it can be true. From my experience, be careful with who you invite because the less thing you want is someone diminishing the team morale.
For example, you don't want a stakeholder to tell the engineering team directly that they lack knowledge or that what they are doing doesn't work. Don't let others hijack your sessions like this! 🙅♀️
That's all for today, let me know if you liked this issue and if you have any more questions on this topic. Everyone has their own way of performing this role, so hearing from you and your experiences will help us all grow!
That’s a good matrix. I’m currently working with one team where members are kind of new and they’re using a new stack. So it’s been hard keeping the pace to refine stories and backlog.
This helps. Thanks for sharing!!