We will discuss the Scrum Master Role in Product Backlog Refinement in this article. This article is a part of our series about a deep dive in Scrum Master Role and responsibilities.
As per the Scrum Guide, Product Owner is accountable for the Product Backlog. But the Product Owner alone cannot decide all details about the Product Backlog. They need to work collaboratively with the Developers as well as Stakeholders. Scrum Master helps the Product Owner to refine the Product Backlog. Some of the ways the Scrum Master can do help the Product Owner for the Product Backlog refinement Activity are as below
Tools and Techniques for the Product Backlog Refinement
Product Owners usually have good knowledge of the Product and Business Domain. However, they often struggle with the tools and techniques. These tools and techniques can be help to
- Different formats to write requirements – User stories is ONE way to write requirements. But there are other possible ways to express requirements. Some of these are Use-cases, workflows, BDD scenarios, spike stories. etc. Scrum Master can help the product Owner to choose right techniques to express the requirements
- Prioritization Techniques Technics to decide the priority and Order for the items in Product Backlog. Some of the famous prioritization techniques are MoSCoW, Kano Model, WSJF etc.
- Decomposition Techniques – These techniques help to break down the items in smaller manageable pieces of work. Some of the common techniques are explained in this article – How to split user stories
- Estimation Techniques – These techniques help the Developers to estimate the size of the work items in the Product Backlog. Some of the common techniques are Tshirt sizing / Planning Poker.
Facilitate the Product Backlog refinement sessions
Refining the product backlog will involve with Developers as well as Stakeholders. It is often difficult to build consensus amongst the large array of people. Some things to consider are
- Have clear Agenda – Product Backlog refinement can be very unwieldy activity. This activity will not achieve results if the agenda is not set properly. Some things to consider are
- Have short sessions – people are reluctant to commit a big chunk of their time
- Communicate the agenda beforehand with the participants. This will help them to prepare better.
- Where possible share any quantifiable data available in advance with the people
- Choosing the Right Audience – Not all discussions within the refinement activity need everybody present. Based on what is the agenda choose only the necessary participants
- Techniques for participatory decision making – These techniques help to build consensus or agreement when multiple people have to agree upon something. The Steps could be as below.
- Techniques for Divergence or getting different opinions – Specifically for refinement you can consider techniques like persona making / Gemba / Journey mapping etc
- Techniques for Exploration or discussing/analyzing the options at hand. Some techniques can be brainstorming / Sailboat (consider Pros and Cons) / SCAMPER and Design thinking
- Techniques for conversion – This is to build the agreement and consensus. Voting techniques like thumb voting / Dot voting /Fist of 5 may be considered.
- The book Facilitator’s Guide to Participatory Decision-Making provides a lot of information about these techniques
Coach Stakeholders and Developers as necessary
Often Stakeholders and Developers both are reluctant to take out time for the Product Backlog Refinement. They might need to be coached. Some areas to coach may be
- If Developers do not spend time on Product Backlog Refinement, some of the impacts may be
- Dependencies are not identified
- Developer input will not be considered while deciding estimates
- Developers do not understand the functionality well and that may hinder their ability to deliver good quality product on time
- Sprint Planning May suffer
- If Stakeholders do not spend time on Product Backlog Refinement, some of the impacts may be
- Items with lower value might be ranked higher up in Product Backlog, this will lower the final value delivered
- Developers might choose wrong items in Sprint Planning again impacting the Value delivered
- Changes will be identified later- impacting the overall costs