Scrum from the trenches - Product Backlog refinement is a Scrum Team responsibility

Time to read: 6 minutes

In the "Scrum from the trenches" blog post series I like to address topics that I encounter in practicing Scrum in the real world, with real Scrum Teams. Sharing where theory comes into practice, what challenges teams encounter along the way and ways to help Scrum practitioners use the power of empiricism to overcome these challenges.

Product Backlog refinement

In the previous "Scrum from the trenches"-blog I talked about the Sprint Goal. The Sprint Goal is mentioned 27 times in the Scrum Guide, Product Backlog refinement is only mentioned in the following piece (about the Product Backlog):

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

This tiny bit of text contains a lot of useful information that can guide you. In this article I'll provide you with some guidance and practices. The Scrum Guide (deliberately) does not tell you how to refine your product, because there are many practices to do so.

Definition

The first sentence in this definition in the Scrum Guide could be seen as a definition on Product Backlog refinement:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Although the explanation is limited, it becomes clear that Product Backlog refinement is a summery of all activities that relate to Product Backlog items. For this reason Product Backlog is not a time-boxed Scrum event. Because all time-boxed Scrum events have a specific sequence within the Scrum framework, Product Backlog refinement does not. It cannot be captured within those constraints. And more so, restraining it within a time-boxed event will not make this activity effective. This constraint is something a lot a Scrum Teams I work with struggle with: the "Refinement Meeting".

The "Refinement Meeting"

Often, Scrum Teams come together once per Sprint, or once per week to have their "Refinement Meeting". The Product Owner shares what Product Backlog items (PBI) need to be refined and the whole team discusses them. After the discussion (which can take a long time and often involves only a few), the planning poker cards are drawn to give an estimation to the PBI (Product Backlog Item).

Without condemning these type of meetings as a whole (they can be part of a healthy refinement practice), they are not part of the Scrum framework events and often a couple of dysfunctions come into play here that lead to ineffective results:

• The Product Owner takes a lead in this meeting, drawing the ownership of refinement onto themselves;
• Endless discussions taking place, without really gaining more knowledge on the topic;
• Discussions evolving only a couple of (senior) Development Team members;
• Decisions made are not documented for future reference;
• Discussions on effort are often held because of the fact effort has to be given to a PBI and is not held because of gaining more insights.
• ... and so on ...

Again, it may not be a dysfunctional meeting by default. Often teams need to gather to share insights and discuss effort to be able to empirically discover the work that can be handled. But it's something that I come across on a regular basis.

The first step is to realize Product Backlog refinement is not a meeting, but a series of different activities. Meetings can be included.

Every member of the Scrum Team is responsible for Product Backlog refinement:

• The Product Owner: building the right thing;
• The Development Team: building the thing right;
• The Scrum Master: ensuring feedback and empiricism throughout these activities.

Let's look at different activities that might be helpful in regards to refinement from the perspective of the different Scrum roles.

The Product Owner

If you're a Product Owner working on a product, refinement start with having vision for this product. Start with the "Why" of the product before anything else. Make sure you are transparant about this vision, talk about it all the time, with the team and all your stakeholders.

As a Product Owner, you have authority and responsibility over the Product Backlog. Every activity that affects the state of the Product Backlog can be seen as refinement. From the very early stages of product development, setting out a vision, strategy and projected impact of your product, to the Development Team estimating Product Backlog items that can be selected for the Sprint in a Sprint Planning.

The following are some examples (not exhaustive) of activities that can be used for Product Backlog refinement. They are all optional, but can be useful. In these examples it makes sense that the Product Owner initiates these activities, but often the other Scrum Team members are also involved:

• Setting up a product vision;
• Creating a product road map;
• Making a story board;
• Creating persona's for the product;
• Defining assumptions that can be validated (i.e. using an MVP by the Development Team);
• Defining acceptance criteria or satisfaction criteria;
• Organizing a user story writing workshop (with customers and stakeholders!);
• Talking to customers and stakeholders about their use of the product;
• Doing market research;
• Setting out goals to achieve.

The Development Team

Often I encounter members of the Development Team that complain about the information stored in Product Backlog items. They say: "There is far to little information to be able to code this!", ...or... "There is so much information in this PBI, I can't make sense of this!".

There is a lot to be said about quotes like this, but maybe you recognize this behavior. A lot of this behavior can be related to the fact that the Development Team does not feel ownership on Product Backlog refinement activities.

In these specific cases, that I encounter on regular basis, I explain that there is different need on information by different people. Not only between roles, but also between people having the same role (i.e. Development Team member). I tell them this is normal and easy to solve.

If you have too little information to go on: obtain and record the information you need the way you want. Make sure though it's understandable and usable for others as well.

If there is too much information the solution is likewise: have a conversation with the person who recorded the information and find out what's needed or may be adjusted.

The key here is that the Product Owner is not the only person responsible for refining the Product Backlog.

The following are examples (not exhaustive) of Product Backlog refinement activities that are primary responsibility of Development Team members:

• Finding creative solutions for meeting the Sprint Goal that can be worked out during the Sprint;
• Estimating, so there is an idea of the work that can be done in a Sprint;
• Discussing and collaborating with other Development Team members (possible also of other teams) to establish sound architectural guidelines;
• Do little experiments / MVP's to validate assumptions and test hypothesis;
• Document possible solutions to work out in the Sprint;
• Set up measurements for the product to measure behavior of customers;
• Slicing large PBI's up into smaller functional units of work.

The Scrum Master

The biggest challenge for the Scrum Master in Product Backlog refinement is to make sure everyone understands the challenges of refinement. Most important first step in this is to create transparency on all levels and teach were needed. In the example of the Development Team members wanting more information it could be, besides having a one-on-one chat on the spot, to organize a mini-workshop on Product Backlog refinement to explain everyone's role and making sure the shared responsibility is understood.

Also, the Scrum Master can help in facilitation of all kinds of activities mentioned already in this article to help everyone focus on their role.

The following are examples (not exhaustive) of Product Backlog refinement activities that are primary responsibility of the Scrum Master:

• Facilitate Product Backlog refinement workshops;
• Facilitate estimation workshops on value and effort;
• Teach the importance of shared responsibility in Product Backlog refinement;
• Teach on metrics that can help the Development Team raise their transparency on the way they deliver and collaborate, i.e. lead time, cycle time, flow, time to learn, time to market etc.;
• Teach and coach the Product Owner and Development Team on self-organizing (anti) patterns, like the example given earlier;
• Help the Development Team in slicing PBI's in various ways, while still being able to deliver a "Done"-increment within the Sprint.

Closing

This article on Product Backlog refinement shows that refinement is more than just a meeting where the whole Scrum Team is having a discussion. It requires and involves everyone with shared and special responsibilities. It's easy to loose sight of the importance of Product Backlog refinement because of your focus on the Sprint. But making time for healthy Product Backlog refinement makes way for an awesome collaboration and team work, building a product that customers really enjoy!