Advance your Product Backlog Refinement

When developing products, there are some key techniques that are critical to success. One of them is how you define the items you need to work on to deliver value – something called Product Backlog refinement. The Scrum Guide defines it as “the act of breaking down and further defining Product Backlog items into smaller, more precise items”. [1]

In Scrum, refinement is an ongoing activity that can be done once or several times per Sprint, or even a little bit every day. The goal is to create smaller chunks of work that can be worked on within an iteration (Sprint). In the end, the refinement should prove that you are working in the right direction. As well as breaking down the work, refinement also allows you to focus on adding enough detail to the new Product Backlog items so that you know how to verify them when they are finished. This usually involves creating acceptance criteria for the items. Sometimes you also size them and even rank them.

When I join new teams as an Agile Coach, I often see a recurring pattern in most Product Backlog refinement sessions:

• The Product Owner (PO) welcomes everyone (the mixed group of product developers) and sometimes gives a high level summary of the items to be discussed.
• They then open a Product Backlog management tool (such as Jira, Azure DevOps, etc.) and start presenting the items they have created. In some cases, the items have all been created by them alone, in other cases, some other members have worked on creating these items (like a business analyst or the designers).
• After each item has been presented, there is an opportunity for the product developers to ask questions and discuss points of confusion. A few people raise their hands and ask a few questions. The answers are then documented by the PO or someone else in the Product Backlog management tool.
• Once all the questions have been answered, the Product Owner asks the team to estimate the size of the item, usually in Story Points (or something similar). If people give different estimates, there is some additional discussion to either add some clarity to the description of the item, or remove some work, until everyone agrees with the estimate.
• Sometimes a “Definition of Ready” document is used to check if anything has been left out as a “to do” for the new Product Backlog item (besides sizing, acceptance criteria, etc.) before moving on to the next items.
• Once all the prepared items have been discussed, the meeting is closed.

While this process feels efficient, and the result is often an updated Product Backlog that achieves the goal of being refined sufficient for the team(s) to have enough work to take on in the next Sprint Planning meeting, I believe that the described process misses some of the key aspects that are crucial for effective Product Backlog refinement. In this article, I would like to present some ideas on how you can improve your Product Backlog refinement to get the most out of this crucial activity:

1. Run Pproduct Backlog refinement as an event, once or several times per Sprint.
2. The Product Owner prepares and facilitates the structure of this event.
3. Incorporate the learnings from the last Sprint Review.
4. Involve actual (real) users in the Product Backlog refinement.
5. Run several diverge & merge cycles with product developers fully involved in the refinement activities.
6. Ensure that developers are trained in good product refinement techniques.

Here are the various ideas in more detail:

Run Product Backlog refinement as an event, once or several times per Sprint

This idea is particularly useful if you have multiple teams working on the same product. If you run Product Backlog refinement as an activity during the Sprint, chances are that each team will refine items related to the work they are already doing in the current Sprint, which they will be able to select in the next Sprint Planning. This limits the knowledge of which teams know which item, and you are not flexible enough to move work between teams.

In adaptive (agile) organisations, teams can help each other and even pick work that’s not necessarily related to the work they did in the last Sprint, if it’s more valuable and has a higher rank in the Product Backlog than the items related to their previous work.

In order for different teams to pick the most important items, it helps if the different teams are all familiar with the most important items. That’s why LeSS (Large-Scale Scrum) suggests having a Product Backlog refinement event, “preferably done with multiple teams to increase shared learning and take advantage of coordination opportunities”. [2] An effective way of ensuring that knowledge of the Product Backlog items is spread across the teams is to refine items in mixed groups of people from different teams.

Another important reason why I suggest running the Product Backlog refinement as an event, as suggested in LeSS, is to gather all non-sprint related work into this time-boxed event and free up the product developers’ time to focus solely on Sprint related work for the remainder of the Sprint. A key aspect for me here is that while the event should be time-boxed (so no longer than a defined amount of time – usually 10 percent of the Sprint, so one day in a 2-week Sprint), you only need to do the refinement if there are not enough refined items in the Product Backlog for the teams to take on in the next 2 or 3 Sprints.

The Product Owner prepares and facilitates the structure of this event

As I mentioned before, one of the main purposes of Product Backlog refinement (PBR) is

1. to have enough refined items in the Product Backlog so that the teams can go through Sprint Planning fairly quickly and pick the most important work from the top of the backlog without having to refine the items any further, and
2. to be able to distribute the most important work among the different teams working on the product.

By performing the refinement as a common event for all teams, you are already able to distribute the knowledge across multiple teams. Since the Product Owner is responsible for the product’s return on investment, he or she is the best person to decide which are the most important items to tackle in the next Sprint, and whether he or she feels it is critical to have all teams working on one specific topic in the next Sprint, or on multiple topics in parallel. In the first case, he or she may want to coordinate the refinement so that there are mixed groups of team members from each team who refine the specific topic into several smaller items that can later be picked up by all teams. In the second case, he or she might want to coordinate the refinement so that a mixed group of members from some teams refine one topic, while a mixed group of members from other teams refine another topic.

In general, I suggest that the Agile Coach or Scrum Master prepares the Product Backlog refinement together with the PO in advance by inspecting the current state of the Product Backlog, considering the outcome of the last Sprint Review (for more on this, see the next idea), and checking which additional business or user problems and requirements should be discussed in the PBR.

It may be useful to include some product developers in the preparation meeting to provide input on technical issues that the PO may be missing. The preparation should result in a clear agenda of topics and timescales for the event. One item on the agenda could be to collect and add additional issues (such as problems and requirements) to the list of items to be refined.

Incorporate the learnings from the last Sprint Review

Agile product development is often equated with iterative and incremental development. But when we have a large requirement or project, breaking it down into smaller chunks and implementing those chunks iteratively and incrementally has nothing to do with agile product development because we are not taking advantage of the agility we might have. We could have done the work in the traditional waterfall model, maybe even more efficiently. The power of agile product development is that in complex product development we don’t know for sure what we need to deliver. Tim Harford in his book “Adapt” [3] refers to the Russian engineer Peter Palchinsky who in the early 20th century mentioned that there are 3 unpredictable dimensions (local, time and human) that can mean that what we think a customer might want is not necessarily the case. By using the principles of

• variation (seeking out new ideas and trying them out),
• survivability (doing it on a scale where failure is survivable) and
• selection (seeking feedback and learning from it),

we can iterate in small steps and learn whether we are on the right track or not.

As I wrote in a previous article, a great way to learn if you are delivering the right thing or not is the Sprint Review. But most of the time in the Sprint Review should be used to gather the critical feedback to adapt the next steps, so unless you extend the time in the Sprint Review to have enough time to sort, filter and evaluate all the feedback in detail, you’ll have to do this at a later time. The perfect time for me is the Product Backlog refinement event, where you deliberately talk about the work to be done in future Sprints. This is your chance as a team to evaluate customer feedback, understand customer needs and the purpose of the product.

Involve actual (real) users in Product Backlog refinement

Who better to explain the real problems and needs that the product should solve than the real users?

If you are building an internal product that will be used by an internal department – such as a marketing or sales tool – the people who use the tool are the best people to clarify open questions about the functionality needed and, more importantly, to discuss the purpose of the product’s functionality. So involving such people in your Product Backlog refinement may be the best thing you can do to improve the product developers’ understanding of the needs behind the product.

If you are building a mass-market product, it may not be so easy to get access to the real users. In some cases (perhaps the majority) the product developers may also be the users of the product. In this case, simply by creating mixed groups of developers from different teams during the PBR, you will bring different end-user views into the refinement process. In some cases, if you are building a public-facing, mass-market product, your product developers may not represent the important personas for whom the product is intended. You have several options here:

1. Create a group of real customers who match the personas quite well and include different people from this group in the refinement.
2. Include in your PBR people from your marketing or business department who know and can represent the needs of the key personas very well. This could also include your customer support people who respond to customer reviews or requests.
3. Have your user experience (UX) product developers represent the needs and wants of the key personas.

Of course, by including real users of the product in your Product Backlog refinement, you may get very accurate feedback and suggestions about your features, but you may also get very divergent opinions. It’s important that your PO is consulted on important decisions, as he or she is the person responsible for the ROI of the product.

It’s hopefully self-evident that you should keep the whole discussion in your product backlog refinement events in the customer’s language. If you find yourself using very technical language that your customer won’t understand, this should be a very big red flag that you may not be dealing with customer-facing end-to-end (or feature) teams, but with component teams that cannot deliver end-to-end value to customers on their own. In this case, the whole point of real Product Backlog refinement as described here may not make any sense at all, and you may need an organisational change first to get the benefit of real Product Backlog refinement and the ideas provided here.

Run multiple diverge & merge cycles with product developers fully engaged in refinement activities

As mentioned earlier, the goal of Product Backlog refinement is to gather a list of work items that the team(s) will work on during the next iteration to deliver the highest value, or to prove what needs to be delivered to create the highest value. Furthermore, the items need to be detailed and clear enough that the product developers who will be implementing them know roughly what they might have to do and how long it will take to implement them if they have to do the work in the next Sprint. This is what some people call “the items are ready (for the next Sprint)”. From my point of view, this is an art! It’s about finding the right balance between discussing it too much and creating too much detail, and not understanding the things that need to be done enough. The former would lead to a lot of waste in the scenario where the PO realises he or she doesn’t want the team to work on it (and that’s always a possibility). The latter would also lead to waste in terms of building the wrong thing, or spending much more time during the Sprint than originally planned, and not having enough time to do other work.

The best way to understand something is not to read or listen to it, but to discuss it with others. One of the best techniques for refining things I’ve come across is “Specification by Example” by Gojko Adzic [4], where you discuss and write down clear examples of how you would know that what you’re implementing is exactly what you need. You can do this using the Gherkin syntax of Given-When-Then or tables where you write the start and end state and in between the action that will happen. By creating small groups of product developers with different skills (testing, front-end development, back-end development, business analysis, design), discussing and writing examples together, you ensure that you get different views on your test or acceptance criteria, and also that everyone remembers the purpose of implementing the element. I suggest creating several smaller groups (of 4-6 people) to refine the items so that

1. you include many different skills, views and insights in your discussions and
2. the group is not too large so that everyone is involved in the discussions.

If you’re working with multiple teams on a product, it’s a good idea to mix the groups with people from different teams (as mentioned in idea #2), so that in Sprint Planning, multiple teams can pick items because they have developers with a good understanding of the items.

Sometimes it even makes sense to refine the same items in different groups for a timebox period of 30 to 40 minutes and then let each group share the results. This could lead to different approaches which could enhance learning and lead to a better understanding of the problem to be solved and the best way to do it. The sharing of the group work could either be done by one member sharing the findings with everyone or by the groups rotating to the next booth and one person staying and explaining the findings to the others.

Creating mixed small groups of product developers with different skills, having time-boxed periods where the groups refine and then share the insights with others will allow the product developers to be fully engaged in the refinement process and have a better understanding of why and what needs to be developed to meet customer needs – the main purpose of refinement.

Ensure that developers are trained in good product refinement techniques

This is obviously a very big topic in itself. If you’re not refining in a useful way, you may be wasting your time refining the Product Backlog, rather than using it to be successful in your product development activities. Getting everyone involved in the product development effort, training everyone in advanced techniques (not just breaking large requirements into smaller ones), defining acceptance criteria and sizing and ranking them, and good product discovery are all critical to success.

I strongly recommend that you take a closer look at books like “Inspired” by Marty Cagen [5], “Impact Mapping” by Gojko Adzic [6], the Product Backlog & Product Backlog Refinement guides from “Large-Scale Scrum” by Craig Larman & Bas Vodde [7] and the aforementioned “Specification by Example” by Gojko Adzic.

Final thoughts

You may have noticed that these ideas are not optimised for work efficiency, as there may be more efficient ways to optimise the time a single developer spends understanding a requirement than discussing it with multiple groups of product developers, or evaluating different ideas for solving a customer problem and creating small experiments for that.

It will definitely be more time efficient for everyone involved if someone (e.g. the PO) spends time understanding user problems and coming up with requirements that the product developers just need to understand and implement. However, I’m convinced that the time saved by focusing on more efficient ways of refining the Product Backlog will result in more time being wasted on implementing things that the customer doesn’t need or that could have been done much better. If product developers spend more time understanding customer problems and needs much better, I’m sure you’ll increase effectiveness by implementing the right things in the right way.

Notes:

Robert Briese is curious to hear your thoughts and if you have any other suggestions on how to improve Product Backlog refinement efforts. And if you are interested in getting more insights from him, sign up for the Lean Sherpas LeSSons Learned newsletter.

[1] Scrum Guide
[2] LeSS Rules
[3] Adapt: Why Success Always Starts with Failure
[4] Specification by Example: How Successful Teams Deliver the Right Software
[5] Inspired: How to Create Tech Products Customers Love
[6] Impact Mapping: Making a big impact with software products and projects
[7] Large-Scale Scrum: More with LeSS

If you like the post or want to discuss it, feel free to share it with your network.

Robert Briese has published two more posts on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.