The word “backlog” literally refers to a log stashed at the back of a fire for later use. Most often, the term is used figuratively to mean an accumulation of tasks to start or resume in the future.
In the Agile world, backlog grooming refers to the process of refining and prioritizing a list of tasks to ensure the product development team has enough work to pick up in the next sprint.
In this guide, we’ll give a comprehensive overview of the backlog grooming (also called backlog refinement) process, explain how it differs from sprint planning, and outline tips and best practices to ensure you’re getting the most out of your backlog grooming sessions.
Backlog grooming is a process in which the product owner and product managers review, discuss, and prioritize the list of user stories in the backlog with the entire team. A backlog is a prioritized list of tasks for the team to work on. The backlog might consist of product bugs, new features, technical debt, UI changes, etc.
The items in the backlog need to be defined in painstaking detail, then groomed — i.e., discussed with the team to ensure everyone understands what needs to be done. The backlog grooming session also affords the team an opportunity to consult with the product managers and product owners. Product managers and owners then detail next steps, reinforce the overall product strategy to which the backlog items level up, and outline goals the team should aim to achieve after completing a set of backlog items.
Now that we understand what backlog grooming is, let’s review where it fits into the scrum process.
Scrum is an agile framework that defines a set of rules, roles, responsibilities and meetings to develop a software product in an incremental manner. The objective is to deliver in smaller chunks more quickly and adapt to feedback as you progress toward the final stage.
As per the scrum framework, the team goes through following events:
Before a sprint can begin, the team needs a product backlog. Backlog grooming is the process that ensures the product backlog is ready for the team to work on.
It’s important to understand the difference between sprint planning and backlog grooming. Sprint planning is a scrum event conducted by the scrum master to set a sprint plan and goal for the upcoming sprint. Sprint planning happens before a sprint starts and after the backlog grooming session and is time-boxed (maximum of eight hours for a month-long sprint).
Backlog grooming happens before sprint planning. In a backlog grooming session, the team prioritizes the backlog of tasks to be discussed during sprint planning. Based on that discussion, the developers commit to work on a selected set of user stories.
The scrum master ensures that enough user stories are planned for the next sprint based on the sprint velocity, team members’ vacation plans, etc. Once sprint planning is complete, the sprint is ready to be kicked off.
The table below illustrates the key differences between backlog grooming and sprint planning:
Backlog grooming occurs before the sprint planning session.
For an example scenario, let’s say a sprint starts on Monday and is two weeks long. Here’s when the following events would happen:
The product owner usually conducts the session as soon as user stories are ready from a product, design and technical perspective. If a sprint starts on a Monday, backlog grooming can happen anytime between Monday and Friday before the sprint starts. If it happens on a Friday, then sprint planning might get pushed to Monday morning before a sprint starts.
The following chart shows the timing of the backlog grooming, sprint retrospective, and sprint planning meetings for a sprint starting on a Monday under the three scenarios described above:
This timing for backlog grooming guarantees that the backlog items are prioritized, discussed, estimated, and ready to be discussed during sprint planning. Without a backlog grooming session, the team cannot conduct a sprint planning session and therefore cannot begin the sprint.
The entire team participates in backlog grooming. As such, the product manager, product owner, scrum master, developers, designers, QAs, and all other stakeholders are required to attend the grooming session. A backlog grooming session is generally led by the product owner.
In a typical backlog grooming session, the product owner walks the team through new features and designs based on the user stories in the backlog. The session is also an opportunity for the team to discuss the product vision and strategy, product roadmap, or any outstanding questions or issues that need clarification.
Backlog grooming is done to ensure that user stories in the backlog are prioritized, up to date, and ready for developers to work on. Your backlog grooming session agenda should be designed to get developers on the same page about what they need to do once they start working on the user stories in the backlog.
The objective of a backlog grooming session is to position the team to deliver a better product more efficiently. The product owner who is spearheading the team has the crucial responsibility of maintaining the product backlog and conducting the grooming sessions to communicate next steps for the team.
The end goal of the backlog grooming session is twofold:
Backlog grooming is an ongoing activity undertaken by the product owner in collaboration with other key stakeholders. While grooming the backlog, the product owner must remove any unnecessary items, prioritize the remaining items, define the user stories with clear and concise acceptance criteria, and provide the necessary technical details and designs before the session takes place with the engineering team.
A backlog can include hundreds of items or more, so it’s important to categorize them using labels and epics. A well organized and categorized backlog will makes the jobs of both the product owner and engineering team infinitely easier for upcoming sprints.
Below are some tips and best practices for running a successful backlog grooming session.
The product owner will define user stories to the best of their ability, but occasionally developers still require further explanation. The backlog grooming session gives the team an opportunity to ask questions and seek clarification about user stories to avoid any confusion.
Not being on the same page about the description or acceptance criteria of user stories can lead developers to implement half-baked stories or stories that lead to unexpected results. In situations like that, during review, the product owner would provide more clarification and send the user story back to the developer to revise and implement it as expected. It’s not hard to see how this back-and-forth might delay the delivery of the feature.
Sometimes during a grooming session, the team discovers another task that must be completed before executing a new feature. Therefore, it must create a new user story. Adding new user stories in this situation ensures there are no gaps or missed steps as the team works on tasks in the backlog.
The team evaluates the groomed user stories using story points. Developers estimate the effort required to complete the tasks associated with the user story. Generally, one story point represents one day’s worth of effort. Based on a consensus established between the developers, user stories are assigned a story point value.
The team breaks down user stories that are estimated to take more than three days to complete. Larger user stories are broken down into smaller parts because it goes against agile principles to spend too much time working on a single, long user story. User stories that are divided into multiple smaller, independent stories are more testable than longer user stories.
The product roadmap is a fluid document. It may evolve based on a wide range of parameters, such as a change in organization’s strategy, a shift in the market or user behavior, or the arrival of a new competitor.
The backlog needs to be regularly updated and realigned to keep up with changes in the product roadmap. It’s common for user stories and tasks to become outdated during this process, so you should remove these irrelevant items from the backlog as soon as you receive clear-cut direction from the stakeholders.
The product owner reprioritizes user stories based on changes to the product roadmap. During a backlog grooming session, the team may discover steps or tasks that need to be done prior to starting work on a user story.
For example, a feature that needs API integration with another platform might need to be completed before the UI can be developed on the application. This additional task of API integration must therefore take priority. In this scenario, the task for API integration is created and placed above the actual feature to be implemented.
As the team discusses a backlog item, it’s crucial to identify any roadblocks that might impede progress. Depending on the type of issue, it may be advantageous to dedicate an entire, separate session to a roadblock or set of roadblocks.
The team must aim to resolve any foreseeable obstacles as soon as possible before a sprint starts. If this is not done, the item should be removed from the prioritized user stories list. Including a roadblock-addled item in a sprint would prevent the team from seeing the user story through to completion.
In 2010, product management luminaries Roman Pichler and Mike Cohn came up with the DEEP framework for backlog grooming. DEEP stipulates the following:
To ensure that the product backlog is DEEP and stays that way, you have to groom or refine it regularly. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team.
The DEEP framework serves as a guide to help product managers and owners manage the product backlog effectively. DEEP stands for:
Let’s zoom in on each of these four attributes:
Every item in the backlog must be thoroughly explained with all the appropriate details.
For example, let’s say a user story describes the functionality to be implemented along with the acceptance criteria. The description of the feature and acceptance criteria are not sufficient; the user story must also have all the relevant designs attached and technical details written by the tech lead.
That said, not all backlog items are created equal. The DEEP framework stipulates that higher-priority items should be described in more granular detail than lower-priority ones. This helps keep the backlog concise and ensures that features that are most likely to be implemented in the next sprint are ready in time.
For a user story to be complete, it must also be linked to other stories blocking it. Otherwise, other dependencies must also be completed.
The team must estimate the time and resources require to complete all the items in the backlog. Rough estimates provided initially can be revised later during sprint planning; this is often necessary when developers come across some additional information that could impact the sprint.
A backlog is a dynamic artifact that constantly changes as per the product roadmap. New stories are added and outdated user stories are removed as the need arises.
For example, let’s say you have a set of features from the roadmap and you receive a requirement from the stakeholders to include another feature. Based on this change, the product owner needs to place additional stories in the backlog. At the same time, there might be another feature that previously appeared earlier in the prioritized list but now takes a back seat as per the updated product roadmap. Hence, this item needs to be removed from the backlog.
Backlog items must be listed in a prioritized order. The product owner is responsible for determining which backlog items should be completed in what order. This tells the team how to approach the backlog and which tasks must be completed before starting other tasks.
A healthy backlog is a prerequisite for efficient, stress-free, and incremental software product development. With the tips and best practices discussed in this guide, you should have all the tools you need to run effective backlog grooming sessions that lead to successful products (and timely delivery).
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
What’s Agile really about? In this blog, I explore the history and implementation of the Agile Manifesto and uncover how its values drive product innovation and collaboration.
A product wedge strategy is a smart way to enter a competitive market, focusing on solving one specific problem exceptionally well.
Mikal Lewis talks about how a product’s value proposition also encompasses the experience customers feel when they use it.
Learn how Fiedler’s contingency theory helps leaders adapt to different situations. Discover practical examples, key benefits, and step-by-step guidance.
Learn more →
