PRODUCT BACKLOG REFINEMENT EXPLAINED — BY AGILE COCKPIT
Product Backlog refinement is typically defined as: “further refining items on the Product Backlog so that there is a shared understanding of what needs to be achieved”. While it’s a very accurate description of what it is, it is not very specific as to what that process would look like.
Product Backlog refinement is done my the Development Team and the Product Owner. The Scrum Master typically supports the process. The Product Owner makes sure direction is clear or the right people are involved in the process. It’s okay to have an expert present at Product Backlog refinement. The Development Team then ensures they get enough clarity on what needs to be done. They do this so they know what to do when they pick up an item during Sprint Planning.
My recommendation for Product Backlog refinement is typically to reserve a time box of two hours every week, same day same time. This makes it predictable and easier to plan. You don’t have to use those full two hours, obviously, as it’s a time box, but you might. I would also suggest focusing on a certain group of features during each Product Backlog refinement session. This will help to prevent context switching and allow everyone to focus on just one topic or feature.
HOW TO REFINE A PRODUCT BACKLOG ITEM
Every item on the Product Backlog is called a Product Backlog item. This is an umbrella term, regardless of which format you use to express that item. Formats could include a requirement, User Story, task or use case.
Let’s say you start with an item like this: “Reserve a hotel room”. That’s a little broad and a little vague. We could split that up (or refine that) in:
- As a business traveler, I want to reserve a hotel room, so that I have a place to work, eat and sleep while on a business trip.
- As a leisure traveler, I want to reserve a hotel room, so that I have a place to sleep and relax while on my trip.
While the result of these two backlog items might be the same reservation wizard (albeit the payment option and room selection might differ), discussing the distinction and having the awareness of multiple use cases hold value in itself. If you would not have done this exercise, you might have missed an important feature in your reservation process simply because you didn’t explore a little bit beyond the obvious.
Product Backlog refinement boils down to two things for me: why and what. The why defines the real value for a user, the reason you’re building something in the first place. The what defines the boundaries or acceptance criteria for whatever you’re building and provide clarity and transparency about the value that needs to be delivered.
The how is something you start defining at Sprint Planning, because it’s usually so specific and dependent on other factors that defining it upfront will make the how obsolete by the time you start building something. Discussing the how for the purpose of exploration isn’t a bad thing, but defining it before you actually pick something up in a Sprint is a bad idea. You are more likely to pay the price for that down the line because your how didn’t take into account any changes made to your product in the mean time.
ACCEPTANCE CRITERIA
Once your why and what are clear, it’s time to add more detail to what needs to be achieve (in other words, refine the item further). As explained in my blog post on the Definition of Done, that applies to everything done to a product. Acceptance criteria, on the other hand, are Product Backlog item specific — meaning that they exist to help you further define what needs to be achieved without going down into the how.
Let’s look at an example:
As a business traveler, I want to reserve a hotel room, so that I have a place to work, eat and sleep while on a business trip.
Acceptance criteria:
- Need to be able to pay with my corporate credit card (AMEX)
- See the details of the hotel room so I know what kind of features it has (like a desk and a mini-fridge)
- The process should to take less than 5 minutes
As you can see from the acceptance criteria, I’ve tried to limit them to non-functional requirements. (Non-functional requirements are requirements that define how functional requirements should work). I could have added these acceptance criteria as well:
- I want to receive an instant e-mail notification confirming my reservation
- If I’m a returning customer I want the same room I always have
However, these two acceptance criteria could be considered feature requests by themselves as they define a different behavior/different outcomes. Where you draw the line is up to your Development Team. In my past as a programmer the e-mail notification would have been a separate Product Backlog items because of the additional requirements and work it would bring along. The same room would have been a simple tweak and could have been part of the acceptance criteria.
IT REQUIRES PRACTICE
Becoming good at Product Backlog refinement takes time, practice and experience. It takes a while for a team to get the hang of what works for them. Both for the process of refinement itself as well as for how to balance acceptance criteria against new features. And what works for one team does not necessarily work for another.
My advice is to try a number of different things and formats to see what works for your team. Remember to reflect on it every Sprint Retrospective.
Want to learn more about Product Backlog refinement?
