Backlog Refinement/ Grooming : What is it? Why & How You Do It?
- 6 mins read
-
By
Marjan Venema
- Updated on May 31, 2024
Navigate to
What is Backlog Grooming/ Refinement?
In Scrum, Backlog Refinement is an ongoing process in which the Product Owner and the Development Team collaborate to ensure that items on the Product Backlog:
👉 Are understood the same way by all involved (shared understanding),
👉 Have a size estimate for the (relative) complexity and effort of their implementation, and
👉 Are ordered according to their priority in terms of business value and effort required.
In short, Backlog Refinement is about creating shared understanding on what the Product will, and won’t, do, on the effort it will take to implement it, and the order in which you’ll do that.
Table of Contents
Why is Backlog Refinement Important?
Let’s inspect the goals of Backlog Refinement from the previous section.
👉 Without shared understanding, you risk implementing the wrong thing, wasting effort, and having to rework the implementation to get it right.
👉 Without sizing each item, you’re not taking the ‘cost’ of items into account and risk overrating high-value, high-cost items, and underrating lower-value, lower-cost items.
👉 Without ordering your Product Backlog in descending order of prioritization, you risk working on items that aren’t all that important, and missing important ones.
👉 Without ordering your Product Backlog in descending order of prioritization, you risk working on items that aren’t all that important, and missing important ones.
A few other reasons why backlog refinement is important:
👉 It improves the efficiency of the Sprint Planning meeting because most questions are already answered.
👉 It keeps the Product Backlog focused, clean, and relevant, so you won’t feel like you’re drowning in an ever growing to do list.
👉 It leverages the benefits of collaboration in detailing user stories and defects.
👉 It creates a shared understanding within the Scrum Team and the stakeholders around it.
What’s the Difference With Backlog Grooming?
There’s no difference. Backlog refinement used to be called backlog grooming. It changed because grooming became a dirty word.
It’s also called story time, pre-planning, and backlog management.
When’s the Best Time for Backlog Refinement?
There’s no best time.
Backlog refinement is an ongoing activity. Not just for the Product Manager, but for the entire team.
The Product Owner can refine items on the backlog at any time, in or outside a meeting. The Scrum Master and Development Team Members can also update items at any time. Usually under the direction of the Product Owner.
What Happens in Backlog Refinement?
Activities in Backlog Refinement
👉 Product Discovery, both initially, for example through Story Mapping, and on an ongoing basis.
👉 Identifying and removing items that sounded good but are no longer relevant.
👉 Improving clarity and preventing misunderstanding by adding details in preparation of implementation. For example adding examples, constraints, edge cases, and acceptance criteria.
👉 Splitting large items into smaller ones. Smaller items are more focused and manageable and are easier to size.
👉 Splitting large items into smaller ones. Smaller items are more focused and manageable and are easier to size.
👉 Sizing items, including re-sizing them
1. when they’ve sat in the Product Backlog longer than intended.
2. as a sanity check when they’re up for implementation.
👉 Prioritizing items, and re-prioritizing them when you add more details or gain new insights.
👉 Identifying risks and obstacles for items close to implementation.
The outcome of these activities should be a Product Backlog that’s DEEP. An acronym coined by Roman Pichler:
👉 Detailed appropriately. More detail for items that you’ll implement soon. Of course, when detailing your user stories, you’ll want to keep the INVEST criteria in mind (see User Stories.)
👉 Emergent. You can reflect new insights easily by adding, changing, and removing items.
👉 Estimated. Every item is roughly estimated, or sized. And re-sized for new information and as an item gets closer to implementation.
👉 Prioritized.
Keeping the backlog DEEP, ensures that items with the highest priority, the ones at the top of the Product Backlog, have a refinement level that’s ready for implementation.
Items with a lower priority, the ones further down, can and should have less effort invested in them and have fewer details. That’s part of how you maximize the work not done.
Nimble’s Backlog Refinement features streamline the process of grooming backlog items, enabling teams to prioritize tasks, clarify requirements, and ensure alignment with project goals, enhancing overall efficiency and productivity.
Invest in a Definition of Ready
Similar to a Definition of Done, a Definition of Ready helps you to detail user stories to a consistent level. It specifies what a user story need to include before you’ll accept it for implementation in a Sprint. For example:
👉 The objective of the item – how it will help a customer or user do their jobs.
👉 The business value it’ll provide (by the Product Owner).
👉 An estimate of the complexity and effort required (by the Development Team).
How Long Should Backlog Refinement Take?
The Scrum Guide doesn’t say anything about how much time Backlog Refinement should take. It only specifies that it usually does not take more than 10% of the capacity of the Development Team.
The Product Owner isn’t part of the Development Team and can invest as much time as necessary and can enlist the help of other members of the Scrum Team.
Turning a story into a Spike, is a way to make this explicit and keep it from eating into that 10%.
Backlog Refinement Meetings
When’s the Best Time for a Backlog Refinement Meeting?
There’s no best time.
Keep in mind that Backlog Refinement is an ongoing activity, not a meeting.
Still, many teams like to use a meeting to quickly size user stories. An initial sizing for new stories, or a re-sizing for stories that have been refined since they were added. There is no best time for these sizing meetings either.
👉 Some teams like to do it early in a Sprint, when the insights from inspection (Sprint Review) and retrospection (Retrospective) are still fresh.
👉 Others prefer it at the end, so the refinement discussions are still fresh when they plan the next iteration.
👉 And still others do it mid-iteration and alternate the Backlog Refinement and Sprint Planning meetings.
If you think you shouldn’t do it near the end of a Sprint, you’re probably cutting refinement too close. You really should have at least 2 or 3 Sprints’ worth of fully refined items. That also ensures you have ample time to answer any questions.
Who Attends a Backlog Refinement Meeting?
Potential participants are
👉 Members of the Development Team
👉 Representatives from Customer Success or Support
👉 Other stakeholders from the business
👉 Members of the QA team (if you still have separate development and QA teams)
The Scrum Master is not needed in the meeting, but is important in helping the rest of the team understand what makes a good Product Backlog item and how you prioritize them to maximize value delivered.
Who Facilitates a Backlog Refinement Meeting?
Quite often, it’ll be the Product Owner.
Though logical, it carries the disadvantage that the Product Owner has a high stake in the direction and outcome of discussions.
Getting the Scrum Master to facilitate is a step in the right direction, as s/he has no official role in the meeting and can be more objective.
Best choice for a facilitator, though, is someone without a stake in the outcome and with excellent facilitation skills. Someone that can hold space for everyone, ensure everyone feels heard, and discussions don’t run in circles.
Are You Ready to Rock Your Backlog Refinement?
It’s time to say goodbye. Goodbye to stories that are no more than titles in user story template format. Goodbye to guessing what a user story really is about.
You now know why Backlog Refinement is so important. And you know what activities to perform.
Now, it’s time to gather your troops and create a shared understanding of your user stories, and prioritize them on value and cost.
Streamline your backlog refinement process with Nimble’s powerful Agile capabilities. Our platform enables seamless collaboration, story elaboration, and prioritization, ensuring your team has a clear, shared understanding of user stories. Sign up for a free trial today and unlock the full potential of your Agile workflows. Signup for a free trial of Nimble Agile.
Share the Knowledge
About Author:
Marjan Venema
Agile 101
What is an Agile Epic? Benefits of Using Them
Learn what an Agile epic is, how it can streamline project management, and the benefits of incorporating epics into your Agile workflow.
Is Hybrid Agile Right for your Team? Here’s what you need to know
Explore the suitability of Hybrid Agile for your project needs in our comprehensive article. We delve into the benefits, considerations, and key factors to help you determine if this approach aligns with your organization’s goals and project requirements.
What is Hybrid Agile Project Management? A Short Guide
Discover the power of Hybrid Agile project management: achieve flexibility and structure for successful project execution. Learn how to harness this dynamic approach.
Dynamic System Development Method (DSDM)
Dynamic Systems Development Method, DSDM for short, seeks to do what came to be known as ‘Agile’ well before the manifesto was written. Learn more about its philosophy, principles, pillars, and practices.
Scrum is an agile project management framework that prioritizes collaboration and iterative development for efficient results.
Scrum of Scrums: A Starting Point to Scaling Agile
Scrum of scrums is an approach to coordinate multiple scrum teams working together. Learn how it works, how to get started and how it differs from competing approaches.
Pair programming is a programming method in which two people work together on a single program. The first person is the “Driver”, who writes the code, the other person is the “Navigator” who reviews each line of code as it is typed, checking for errors. They exchange their roles on a regular basis.
Code refactoring in Agile is a well-known technique to keep a codebase healthy and amenable to change. Learn what it is and a sound process to follow.
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile
