Backlog Refinement or Backlog Grooming
Backlog refinement should help you in your quest to have a permanently relevant set of items in your backlog. Learn more in this article.
Join the DZone community and get the full member experience.Join For Free
In order to get everybody on the team aligned, teams plan the work that should be done in the next sprint. The purpose of sprint planning is to agree on a goal for the next sprint and the set of backlog items to achieve it. Sprint planning is about prioritizing backlog items and agreeing on the number of backlog items in the sprint based on team capacity. Sprint planning kicks off every sprint. Scrum suggests investing two hours per sprint week in planning sessions. Experienced teams will be able to cut this down to an hour per week or less. Mostly because they are comfortable with less detail upfront and more uncertainty in their definition of ready. The meeting is attended by the entire team. Outside stakeholders are invited if they can provide additional expertise for specific backlog items. Today we will discuss a very important topic: backlog refinement vs backlog grooming.
Backlog Refinement or Backlog Grooming
Backlog refinement or backlog grooming stands for keeping the backlog up to date and getting backlog items ready for delivery. This involves rewriting backlog items to be more expressive, deleting obsolete ones, re-assessing the relative priority of stories, splitting big items into smaller ones, resorting them, and correcting estimates in light of newly discovered information.
Product refinement starts with having a vision for the product. Start with the “why” of the product before anything else. Make sure you are transparent about this vision, talking about it all the time both with the team and all your stakeholders.
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”
Product Backlog Refinement Benefits
- Gives product owners, managers, or business analysts more chances to enhance the requirements with more information if it’s required
- Removing uncertainty and unknown facts of user stories increase the product’s efficiency
- Save time for the development team for further discussion
- Avoid rework in development and testing
- Identify the dependencies within the team and help to foresee risks
- Effective sprint planning
These events are meant to be collaborative. That means the entire cross-functional team should be represented at refinement sessions. You need the combined expertise of the various functions on your team to effectively flesh out your user stories. For optimal results, and to minimize workflow disruption, backlog grooming meetings should last no more than an hour.
It is also important to develop a definition of "done" as well as a definition of "ready". There should also be a shared understanding of the acceptance criteria and agreement on a structure for the full description of different kinds of items. Additionally, it is important to define a clear view of dependencies between items, to identify the subject matter expert for each item, and refine high-priority items first, as those are the ones developers will implement first. One interesting thing to mention is that officially, backlog refinement doesn’t have a time-box. According to the Scrum framework, it is not one of the Scrum events. Instead, it is a continuous crusade, not necessarily a meeting, although it is better to have one.
Checklist To Evaluate if the Backlog Needs Refinement
- Are there any backlog user stories or other kinds of items that no longer make sense?
- Are there any user needs that are not yet in an appropriate form of backlog item?
- Is there any urgent item that’s at the bottom of the backlog?
- Did the importance of delivering any item change since the last time you looked at the backlog?
- Does the backlog have any item for which no agile estimate exists?
- Is any estimate outdated?
- Is any backlog item too broad to understand what developers should implement in the next sprint?
You can only claim to have a refined backlog when you answer “no” to all the above questions. Also, remember to document your decisions, as this is extremely important.
Backlog refinement should help you in your quest to have a permanently relevant set of items in your backlog: complete, valuable, detailed yet straightforward, recently estimated and correctly ordered.
I hope you found this post useful.
Published at DZone with permission of Ekaterina Novoseltseva. See the original article here.
Opinions expressed by DZone contributors are their own.