Techniques for improving Product Backlog refinement in Scrum

Techniques for improving Product Backlog refinement in Scrum

What is the Product Backlog refinement about?

The Product Backlog refinement is considered as the “act of adding detail, estimates, and order to items in the product backlog” within the Scrum guide provided by Scrum.org.

When is Product Backlog refinement held?

It really depends; given that it’s considered as “an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items”; technically it could be called whenever the Scrum Team decides it is required during the sprint.

In my experience, I prefer to keep it as a fixed act within the sprint; I mean at the same time and place, in order to facilitate that it becomes a habit for the team.

Who participates in the Product Backlog refinement and how?

Here is what I’ve found works better for each role during participation in the Product Backlog refinement in Scrum:

What techniques could be used to get the best out of the Product Backlog refinement?

Recurring weekly meetings with the Product Owner could be really helpful when getting ready for the Product Backlog refinement. Depending on how mature the Product Owner is, in terms of managing the content of its Product Backlog; it would require more involvement or less from the Scrum Master.

A Product Planning weekly meeting is a short meeting (in a two week based sprint, it takes less than (1) hour) where the Scrum Master meets the Product Owner to collaborate about:

Timeline of the Product Plan.

I like to start the conversation by asking some powerful questions about the product, for example: Where are we with the product? What are the goals? Where are we with the product goals (on or off track)? What’s next in the Product pipeline and what does he/she needs the team to do to get done? Moving on to next in the pipeline: when does he/she think it makes sense to start discussing it with the Development Team? With the stakeholders? Is there anything that needs to be added or removed from the Product road map.

2. Assess Potential Risks.

Based on the answers gathered in the previous step, I like to take the time to spot potential risks that could impact the team and the product. At this point of the conversation, if you get under the impression that something is off, please invite the Product Owner to discuss it and to collaborate with you with finding possible ways to make the issue visible for the development team.

3. How do we assess risks?

There is a tool called “Risk management assessment for scrum teams“, that I’ve learned from Cathy Axais (my boss at Seedbox Technologies); which would help a Scrum team decide what to do with a potential risk. It combines the potential risk impact level (low, medium or high) to identify in what way the issue could potentially affect the product, with the likelihood (low, medium or high) that the issue could happen.

4. Share Opinions, Issues and Ideas regarding the Scrum Team.

What’s that? Every single occasion that you have to collaborate and discuss with the Product Owner about how the team is doing; take it and say thank you, because it would be a sign that you’re in the right track to get your Product Owner’s heart, which will lead him/her to trust you. So keep it up!

Why? I’ve noticed that having a closer relationship with the Product Owner has had a positive impact on the team’s performance. So any chance for reinforcing the relationship of trust, I’m totally in.

5. Offer your help.

Ask the Product Owner what else you can do to help him/her excel owing his/her Product. Be there to support the Product Owner’s role and empower him/her to become a leader for the team. I love to see it this way:

More help accepted => closer to get her/his heart => trust you more => better collaboration => incredible results.

6. Give and take Feedback.

Don’t be shy about asking how the Product Owner thinks you’re doing and what points need some improvement. Call for action and become vulnerable and you’ll get to the point where he/she will ask you for feedback as well. Remember, the Product Owner is your best ally, and your goal is to collaborate towards getting incredible results.

More techniques

I’ve developed a tool called Team’s Roadmap template to help Scrum Masters help Product Owners to get the content of the upcoming Product Backlog refinement ready and in line with the Product Road map.

Another thing that I used to do to help the team improve and take ownership of keeping the Product Backlog updates is this: After the 5^th time after my first the Product Backlog refinement session with a new team, I like to abstain from the meeting, so the team can figure things out on their own. Let it go, observe how it goes and take notes to learn from the team habits, and then ask permission to share what’ve noticed with them. Trust me; you would be surprised about the outcome!

And last but not least, please remember to repeat, repeat and repeat. I’ve learned, by practising over and over again, that repetition gets people used to doing things and quite often ends up with these people incorporating these practices as part of their own lives.

Well I think I’m done with this part but I invite you to take the next step and get more techniques, tips and templates for transforming your teams into high-performing sustainable agile teams by visiting my website www.jesusmendez.ca. I also want to invite you openly to take some time to download your favourite template and share your impressions, opinions and ideas for improvement by joining the conversation through the hashtag #Transformingteams on Twitter or by email to transformingteams@jesusmendez.ca

Willing to get more techniques for transforming your teams into high-performing sustainable Agile teams?

Get your copy of my workbook “Forming Agile Teams” now.
Continue practising at the workplace

Thank you for reading and inspiring me to continue sharing.

Jesus

Additional resources

Mike Fishbein has offered me to share this interesting article called “How to Create a Product Roadmap” that I’ve found interested and related to the context of the article.

References