The backlog refinement meeting is a bit of a black sheep in the Agile framework. The Agile Manifesto gives little guidance about it; it doesn’t even specify when backlog refinement should happen.
In my opinion, this is unfortunate because product backlog refinement meetings are crucial to productive sprints and shipping quality code on time.
Table of Contents
What is Backlog Refinement?
Backlog refinement boils down to the process of assessing two things:
Your product backlog is a list of all the things that you would like to implement for a particular product. At any point in time, your product backlog should accurately capture the relative priority of each item in it and how much effort it will take to achieve each one. This information allows you to identify your highest priority, make sure that the development team is working on the right things, and that you take on the right amount of work during the next Sprint planning meeting.
Backlog refinement is simply the process of keeping your backlog up-to-date. Product owners have to be careful to not get too caught up in daily scrums and sprint backlog refinement and remember to constantly update the product backlog as well. For product backlog refinement especially it’s vital to get input from the rest of the Agile team. That’s why you need backlog refinement meetings.
By the way, you may be wondering how backlog refinement relates to backlog grooming. They’re the same thing. The Agile community is moving away from the word “grooming” because of its negative connotations in other contexts.
How to Improve Backlog Refinement Meetings
1. Establish a Consistent Schedule
You should hold at least one backlog refinement meeting each sprint and the entire Scrum team should attend. To me, it makes the most sense to meet with the team to refine the backlog toward the end of the sprint, when team members are already looking forward to the next one. But don’t be afraid to schedule it when it works best for you. You can even hold multiple refinement meetings during a sprint – a lot of teams do this.
During a refinement meeting, the Scrum team can share insights that the product owner can use to make the product backlog more complete and accurate. By holding refinement meetings regularly, a team can foster a culture in which everyone is constantly thinking about business value, relative priority, and effort.
Expecting engineers on your team to think about the bigger picture is a part of what Kathryn Koehler, Director of Developer Productivity Engineering at Netflix, described as “treating your team like adults” on the Dev Interrupted podcast:
2. Craft User Stories
User stories put the team in the shoes of the end user. They help your Scrum team stay in touch with what the product is meant to do, who it’s for, and how you can optimize it in the best possible way.
3. Assess Your Planning Accuracy
Estimating effort is notoriously difficult. But you can get better at it with the help of the right tool.
LinearB’s Project Delivery Tracker helps you to evaluate how accurately you estimated effort for backlog items tackled in previous sprints. The Planning Accuracy metric captures how well you planned in a single number. This is tremendously helpful feedback that you can use to iterate on your effort estimation methodology and drive sustained improvement.
Your CEO will love this! You can see your team’s investment profile, project allocation, and planning accuracy by boards, epics, labels or custom fields. Learn more about Project Delivery Tracker.
4. Establish a Clear Definition of “Ready”
The Definition of Ready, or DoR, is essentially a checklist of all the requirements you need to meet before a backlog item can be considered done. Your checklist can be updated as you go, but you need to ensure that it includes the user story statement, the acceptance criteria, and dependencies.
Working on your DoR with your Scrum team is a great way to make sure that everyone is on the same page. It helps you to form clear sprint goals and ensures that everyone fully understands what an individual item needs to achieve, which helps the team to accurately estimate both priority and effort.
5. Add Some Fun With Planning Poker
It works like this: You select a backlog item and ask each team member to write down the effort they estimate it requires. On the count of three, everyone reveals their figures! (If you’re the Scrum coordinator or Scrum guide, which are both updated terms for “Scrum master,” be sure to remember to bring the paper and pens!)
The product owner then facilitates a conversation around why different people had different numbers with the goal of getting consensus on one effort estimation.
6. Understand Where Your Team Spends Their Time
One of the mantras of software development is to, “Expect the unexpected.” The entire Agile framework is built on this idea!
It’s important to understand where your team is spending their time, especially if they’re having to work on unplanned issues. LinearB’s Product Delivery Tracker will break down issues by type, so that you can see how much of your team’s time went into functional and non-functional stories as well as bugs.
This data enables you to see whether you and the team are mis-evaluating business value. For example, if your team is spending a lot of time on bugs, then perhaps you need to increase the priority of issues that will pay down technical debt and de-prioritize shipping user-facing features.
The product owner should be refining the product backlog and sprint backlog constantly, but this doesn’t mean backlog refinement is a one-person job. At least once per sprint, the entire Scrum team should be given the opportunity to share their input during a product backlog refinement meeting.
The right techniques and tools will enable you to maximize the value of your backlog refinement meetings. LinearB can help you not only refine your backlog but also optimize each stage of your development process, from planning to writing code to reviewing and deploying it.
To learn about all the ways LinearB can help you ship better code faster, reach out to set up a demo.