One of the most challenging activities in Scrum is Product Backlog Refinement. During training courses I get many questions on this activity. What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidelines for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts:
- Before you bring an item into a meeting
- What do you typically do during a meeting focusing on refinement?
- Facilitating a meeting on Product Backlog refinement
‘Ready state’
The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’. What does this mean? This basically means that the Developers have the idea that an item is:
- Clear enough, so they understand what stakeholders are asking for and why they are asking for it.
- Small enough, so the items should be small enough to get done within a sprint (typically a few days of work) to comply with the definition of done.
This activity is all about interaction between the Product Owner, Developers and stakeholders. If you were expecting a blueprint for a ‘ready’ item you clearly need to do some homework on agility. When an item is ready depends on many different aspects like experience of the Scrum Team or knowledge about the product. It even differs per item when Developers considers it to be ready. This activity takes time and doing this right saves a lot of time in Sprint Planning.
Before you bring it to a meeting
The most important part of Product Backlog refinement actually is before you start refining. The most ineffective use of a Scrum Team's time would be to refine an item that doesn’t contribute to the product vision. For a Product Owner, one of the first steps when a stakeholder has an idea is to find out what this person would like to have and why they need it. A common pitfall is that a stakeholder asks for a solution, the 'how', and a Product Owner in all it’s enthusiasm fails to retrieve what they would like to have and why they need it. Numerous times I have seen stakeholders ask for an iPad app. This sounds incredibly valuable and any developer would like to spend time on this over working on some legacy application. However, when the reasons behind the solution are unclear it will most likely end up somewhere hidden in the app store.
So, knowing the reasons behind the idea makes it easy for a Product Owner to judge whether this idea contributes to achieving the long-term vision of the product. If not, a Product Owner might consider to work on it anyway since it opens up a new market opportunity but most often it would be better to focus on those items that contribute to the team’s reason for existing. If these boxes are all checked then comes the most important decision. With the knowledge the Product Owner has, is it a valuable idea to create? Does this item have a fighting chance to be picked up by the team or will it end up somewhere at the bottom of the Product Backlog. I have seen Product Owners collecting every question ever being asked over a course of 8 years ending up with 12,000 items on the Product Backlog. A complete waste of time and effort. Even a product backlog with 100 items might be too much for a single team. As a Product Owner, you should ask yourself, how big is the chance of this item being picked up if it initially will be placed on the 40th position on the Product Backlog?
Wouldn’t a stakeholder be happier in the long run, if you spare him the false hope of his idea ever to be picked up? As you can see in the image above, there will be a lot of conversation between a Product Owner and stakeholder before it ends up on a product backlog. If the Product Owner does not consider the idea to be valuable, the stakeholder has two options, provide a better business case for the idea or just accept it just wasn’t a good idea to begin with. Our best advice for good Product Backlog refinement is to prevent everything to be discussed in Product Backlog refinement.
Stages of Readiness
One of the key pillars of the Scrum framework is ‘transparency’. For managing the Product Backlog, this means that it should be visible for the Scrum Team and stakeholders what the order is and in what stage of readiness a particular item is. The image below shows an example of a Product Backlog Kanban board.
Typically a Product Backlog item goes through three refinement meetings before it is considered to be in a ready state. First, when a stakeholder comes with an idea or wish, the team would roughly estimate the size of the item. A very fast way to do this is by 't-shirt sizing'. Nobody knows the exact size of a small sized t-shirt but everybody has an idea about the relative difference in size between a small and medium sized shirt. It is the first input for a Product Owner to get an idea on the effort involved in realizing the item. The second part is to assign story points to the item but again in a quick and dirty way. The format often used is Magic estimation or Silent estimation. This is estimating effort without having long and in depth discussions on the item. The final stage before an item is considered to be ready by the Developers is to do planning poker. This is a frequently used technique for estimating items. This technique is time consuming so preferably you would only apply this for items you actually want to be realized and based on previous estimation you have considered to be valuable enough to spend the effort.
Hopefully, this post has provided you with some ways of improving the efficiency and effectiveness of Product Backlog refinement. In the next blog, which will be posted next week, I will explain what typically happens when you set up a meeting to refine a Product Backlog item.