Time to read: 9 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 many times in the Scrum Guide, Product Backlog refinement is only mentioned a couple of times and is made even less prescriptive in the Scrum Guide. There is nothing (more) on estimation and how to order this. There is no more word on the "10%" etc. etc. The only mentions are:
- During the Sprint: "The Product Backlog is refined as needed"
- Topic two of Sprint Planning: "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence."
- "Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work."
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 Backlog, because there are many practices to do so. Scrum is a framework and therefore incomplete on purpose.
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 breaking down and further defining Product Backlog items into smaller more precise items.
Although the explanation is limited, it becomes clear that Product Backlog refinement is a summary of all activities that relate to Product Backlog items. For this reason, Product Backlog refinement 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 involving only a couple of (senior) Developers;
- 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 Developers: 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 starts with having a vision for this product. Start with the "Why" of the product before anything else. Make sure you are transparent 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 Developers 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 storyboard;
- Creating personas for the product;
- Defining assumptions that can be validated (i.e. using an MVP by the Developers);
- 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 Developers
Often I encounter Developers that complain about the information stored in Product Backlog items. They say: "There is far too little information to be able to work on 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 Developers do not feel ownership on Product Backlog refinement activities.
In these specific cases, that I encounter on regular basis, I explain that there is a different need for information by different people. Not only between roles, but also between people having the same role (i.e. Developers). 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 the primary responsibility of Developers:
- 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 Developers (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. The most important first step in this is to create transparency on all levels and teach where needed. In the example of the Developers 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 the 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 the 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 Scrum 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 Developers on self-organizing (anti) patterns, like the example given earlier;
- Help the Developers 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 lose 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 teamwork, building a product that customers really enjoy!
- Scrum Facilitators is partners with Scrum.org and we’re accredited to teach all the Scrum.org courses. Check out our Scrum.org courses here.
- Scrum Facilitators podcast on demand! Now you can listen to us at your own pace, in your own time.
- Check out our free products that can help you improve your Scrum.
- Join our Scrum Facilitators Community and interact with 100+ Scrum Professionals from all over the world
- We have occasionally organised interactive meetups. Sign up and we’ll see you there ;)