How Backlog Refinement makes your Product grow well

Product Backlog Refinement is a crucial task that makes Sprint Planning more predictable.

Imagine you are in a Sprint Planning meeting, discussing one of the Product Backlog items with your Team. It turns out that you need to get some clarification which could significantly impact estimations. However, the Product Owner can’t provide it right now as they need to talk to the Business Stakeholders. So what do you do? You could postpone the backlog item until the next Sprint? Or you could pull it into the upcoming Sprint and hope to get clarifications as soon as possible? Or maybe you could brainstorm with the Development Team to try to cover all the possible scenarios?

Alternatively, imagine that the Product Owner is able to provide answers, but the Development Team has so many questions, that you have to extend Sprint Planning to four, six, or even eight hours to cover everyone’s questions thoroughly. Throw in some off-track debates, and you can quickly see a whole day of Sprint Planning with people totally drained by the end of the meeting.

To prevent the sudden appearance of questions and disagreements when you should be actually starting your Sprint, you might want to think about being proactive by having a Backlog Refinement meeting.

Goals and activities

The primary goal of a Backlog Refinement meeting is to make relevant items in the Product Backlog crystal clear for the Development Team. So that everybody understands all the items, realizes for what purpose each and every item exists and how they support product vision. Backlog Refinement should also be the meeting where the whole Team re-sorts items according to the latest knowledge and feedback and clarifies any issues to the level of detail required for the upcoming Sprint Planning meeting.

The term “Grooming” is often used instead of “Refinement” to help us think of the Product Backlog as a plant which requires weeding, trimming, watering and cleaning to make the product grow well. Watering (of roots) keeps the focus on the initial vision and goals for the whole product. Weeding and trimming ensure that the Product Backlog only consists of relevant and valuable items. Cleaning (of leaves) means clarification of backlog items at a sufficient level. For example, you might break some of them into smaller pieces, add acceptance criteria, identify dependencies on other Teams, define architectural, technical and discovery spikes, etc..

We can summarize this grooming metaphor into the following physical actions:

• Remove items that are no longer relevant.
• Sort the items to reflect the new priorities.
• Split the priority items which cannot be done in a single Sprint into smaller ones.
• Create new items based on new needs, circumstances, knowledge, and feedback.
• Estimate or adjust the estimates for the items on top of the list.

Best practices

How can you decide that your Backlog Refinement meetings are going well? Try focusing on the primary goal — to make the Sprint Planning sessions easier to conduct. A good practice is to have two upcoming Sprints packed with ready-to-go items. In this case, Sprint Planning becomes relatively simple because everyone is familiar with most of the items, vital questions have been addressed, and rough estimations are already provided. Just a few finishing touches might be required. Sure brand new items can also still appear in the Sprint Backlog, but normally these should be in the minority.

How can you measure the readiness of backlog items for two upcoming Sprints? From the Scrum Guide, we understand the term Definition of Done (DoD). We use this like a “gate” where every backlog item needs to pass before it can get to the Sprint Review. Similarly, we can build a “gate” for Sprint Planning. We call this Definition of Ready (DoR). It is an agreement between the Product Owner and the Development Team of how thoroughly backlog items should be defined before they can be included into the Sprint; this can be as simple as a list of conditions which need to be met before moving forward.

Items from the top of the backlog go to upcoming Sprints first. However, we need to take care of the whole list of items in the backlog. Many Teams fall into a trap here. If the Product Backlog grows faster than the Team’s capacity, you might find yourself in a situation where the bottom half of your Product Backlog is a “black hole” which you never want to get to. In this case, the Team can lose its perspective and becomes unable to suggest a better path for the product, which in turn increases demotivation.

You may find time to put things in order, but then there you also run the risk that these items will never be developed. “Black holes” can eat up the time with no return on the investment. Remember it is perfectly okay to close issues the Team are unlikely to tackle. Be brave enough to “trim the tail” of these “black hole” items on a regular basis.

Regularity

The Scrum Guide says that Backlog Refinement can take up to 10% of the Team’s capacity. But what could be this 10% in reality? The right answer is “it depends”. Every Team finds their own pace. However, I recommend to conduct it at least once a week, ideally, twice. It forces everyone to be in shape and work on clarifications instead of postponing the actual resolution until Sprint Planning. Below is an example of a 2-week Sprint schedule.

Agenda

Finally, let’s look at how to run a Backlog Refinement meeting.

1. Reiterate the vision of the product. You might find this boring to repeat what everyone should know anyway. However, our brain functions in a way that we do need recycling to refresh the right focus in mind. The vision might sometimes change according to changes in the business world. You will not be able to discover such shifts without checking new backlog items against your current vision.
2. Level down: take a look at your product roadmap for the next time period, say, one or two releases ahead. Identify the pain points you want to address and the gains you want to target.
3. Move no longer relevant backlog items to the “tail” and take everyone’s confirmation to trim it.
4. Identify new backlog items together with their value hypotheses. Attach the basic outcomes of discussion and capture questions, and, assign action items.
5. Re-sort the list. Use the approaches to prioritization negotiated with the Team. Consider the expected value, uncertainty, risks, and complexity. Weighted Short Job First (WSJF) method might be helpful.
6. Break down big backlog items (Epics) to smaller pieces (User Stories). Attach details, wireframes and architectural agreements together with any design decisions.
7. Identify dependencies with other products and Teams.
8. Re-sort the list again.
9. Ensure that you have the Product Backlog items sufficiently clarified according to your DoR to pack two upcoming Sprints.

That’s it. I wish you effective and productive Product Backlog Refinement meetings!

___________________

Alexander Postnikov (Agile practitioner, consultant, and coach) for riis.com/blog. Special thanks to Godfrey Nolan (President RIIS LLC).