Scrum, one of the most popular Agile frameworks, suggests building software in iterations, aka Sprints, which last from two to four weeks. As a result of each Sprint, the team releases a product increment. Added to one another, increments eventually make up a complete software application.
Scrum roles include a Scrum Master, a Product Owner (PO), and a development team. They collaborate with each other through the five formal events: Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. However, there’s also another event during the Sprint called Backlog Grooming or Backlog Refinement. That’ll be the focus of our article.
Why does the Scrum Team need backlog grooming? How do you prepare for this event and which techniques can facilitate effective discussions within the team? Let’s find the answers.
What is product backlog grooming?
As defined in the Scrum Guide, product backlog grooming or refinement is an ongoing process of validating requirements. A backlog is a document where all the requirements are collected and managed. The requirements come in the form of use cases or user stories. Some tasks performed during backlog grooming are:
- removing user stories that are no longer relevant,
- reordering the priority of items,
- adding and correcting estimates, and
- splitting user stories to fit the scope of the upcoming Sprint.
As a process, backlog grooming is a continuous activity of a Product Owner. As a Sprint event - backlog refinement meeting - it’s a workshop aimed at formulating the scope of the upcoming sprint and clarifying details of backlog items.
The place of Backlog Refinement Meeting within the Sprint
When to run the refinement meeting
The backlog refinement meeting takes place before the Sprint planning. Without a properly-groomed backlog, the planning session won’t be as productive as it could have been.
However, there are different variations. For example, some teams hold the refinement meeting during the Sprint Review. All the necessary people are present, so after they are done reviewing the increment, a Product Owner can gather feedback to update the backlog. This way the sprint backlog is ready even before the Sprint starts.
But this approach won’t work if your product backlog has a significant amount of uncertainty that requires thorough discussions. In this case, it’s better to have a separate meeting for that.
How to prepare for the grooming
Not all items in the backlog are equal and that should be reflected. A backlog requires constant maintenance because of the volatility of needs, priorities, and dependencies that will inevitably emerge. So, before the grooming session, a Product Owner must
- prioritize the items based on the project needs and
- make sure that those with the highest priority contain all necessary details.
The PO ranks user stories in order of their importance applying different techniques. User stories at the top of the list are to be implemented in the nearest Sprints.
Prioritization techniques for backlog grooming
Now, let’s observe some handy prioritization techniques to identify the backlog items that should be addressed the soonest.
Multi phased prioritization approach. That’s broad prioritization of the initially added items. Every requirement is assigned the 1st, 2nd, or 3rd priority level:
- The 1st items help solve the problem in the most impactful way.
- The 2nd items are medium priority items that add to the problem.
- The 3rd items are nice-to-haves.
Numerical ranking based on some criteria. It’s a granular approach used to specify the relative priority to other high priority items. You do that by assuming that #1 is more important than #2, which in its turn is more important than #3.
Rank-prioritizing the entire backlog can be quite overwhelming. If there are over 50 items on the list, the difference between them starts feeling fairly subtle. That’s why Laura Brandenburg, a Certified Business Analysis Professional, suggests first breaking backlog items up into releases according to their general priority and then rank-prioritizing “the product backlog items that might be addressed in the next few sprints.”
The following criteria directly affect backlog ranking:
- constraints like the timeframe and the budget that goes into implementing a requirement,
- dependencies between items,
- their value in contrast to their complexity, and
- the cost of delay as opposed to the job duration.
MoSCoW method. It’s a simple technique that doesn’t require a deep understanding of the user stories, which makes it very suitable for initial refining. You need to sort all user stories into four groups:
- Must-haves or mandatory,
- Should-haves or less impactful,
- Could-haves that introduce small-scale improvements, and
- Won’t-haves that don’t serve the immediate project needs, so we’re leaving them out for now.
Kano Model. Named after its creator, Japanese researcher Noriaki Kano, this model is similar in a way to MoSCoW since it also classifies the backlog into categories. But Kano has five of them and they are mainly based on the final user’s satisfaction:
- must-be functionality,
- extremely desirable according to the foreseen customer needs and expectation,
- extra value features,
- no-value features, and
- features that are better to be avoided as they can have a negative impact on the customer.
So, the Kano technique can be quite time consuming as it requires conducting surveys and user interviews before getting to prioritizing.
You can read in more detail about these and other prioritization techniques in our dedicated article.
Detailing out backlog items with the highest priority
Backlog prioritization works on the principle: The lower the order of the item, the fewer details it needs. So, a Product Owner must ensure that the prioritized user stories contain all the relevant information behind those stories, including acceptance conditions that must be passed in order for the story to be considered “Ready.” That’s necessary for the team to better understand each user story and as a result - make more accurate estimations.
How to hold a backlog refinement meeting
After a minimal amount of work is done on each item on the backlog - enough to understand the resources involved to complete it — the Scrum Team has a refinement meeting.
The refinement meeting is facilitated by the Product Owner or the Scrum Master. The dev team reviews the prioritized items in the backlog before accepting them. They make necessary adjustments for clarity and estimate the effort and time it will take to complete each user story.
Typically, they perform estimations with the most popular Agile technique — planning poker. It’s basically voting with a deck of cards. Planning Poker cards have story points written on them.
Story points rate the relative effort of work in a Fibonacci-like format where each number is the sum of the preceding two numbers (1, 2, 3, 5, 8, 13, 21, etc.) It's a more convenient way to distinguish the estimates. Check our article about story points for more details.
Key steps of a refinement meeting
So what exactly does the refinement meeting with the planning poker cards look like?
Step 1 — user story discussion. The Product Owner presents a user story and the Development Team asks questions to get a common understanding. They also discuss what needs to be done and how it needs to be done to satisfy the acceptance criteria. The meeting is usually recorded so that the Product Owner can document the summary afterward.
Step 2 - decompose. Items must be sized appropriately. This means that they can be realistically "Done" within the Sprint time-box. If discussions reveal that a user story is high level and complex, the Product Owner alone or together with the team should break it up into more precise and detailed atomic parts to better understand and estimate them.
Step 3 — voting with Planning Poker cards. Everyone in the Dev Team makes up their mind about the number of story points for this user story. When ready, they simultaneously reveal the cards with the corresponding story points. If the estimations differ within the team, the members discuss their concerns until they reach an agreement. Usually, there are up to three voting rounds for each user story.
Step 4 — looking for trade-offs. The Product Owner should influence estimation by helping the dev team understand and select trade-offs, but the final decision is theirs. If the agreement still can’t be reached, the facilitator (either Product Owner or Scrum Master), can go with the highest, the lowest, or the most common estimation. But a better way is to remove this user story from the current agenda as most probably it needs to be reworked.
Step 5 - Follow up with additional questions. If some user stories lack information, Laura Brandenburg advises addressing stakeholders with some open questions to elicit the necessary details and better prepare the story for estimation at the next grooming meeting.
Designed for colocated teams, the backlog refinement meeting can also work for distributed teams using tools like Planning Poker for JIRA and Hatjitsu.
Recommendations for Product Owners
Here are useful tips for Product Owners functioning as facilitators of the backlog refinement meeting.
Encourage the team to express their opinion. Refinement sessions are meant to discover requirements collaboratively. Conversations are so important because they forge user stories into concrete tasks and items of the backlog. So, invest more in discussions and motivate the participants to express any concerns they may have.
Add flexibility to comfort the team. Developers can be stressed out if they believe these estimations to be their last call. The PO should explain to them that their allocations still can be modified after the meeting before adding them to the Sprint Backlog.
Be at the forefront of product development. The PO should stay a step or two ahead of the dev team. That way, the PO can inform them of tasks to expect in future Sprints and set for discussion stories you’re planning to include within two to three Sprints in the future. But don’t pull too far ahead of the current project needs.
Build on the feedback. A good practice is to consult the former Sprints within the production process. How much cost and effort did previous items take to be completed?
What are the grooming meeting deliverables?
The Product Owner adds new information that popped up during the session. The PO may have to re-order the backlog priorities given the newly obtained details. Finally, the PO seals the deal with the stakeholders updating them of any changes and obtaining their approval.
The outcome of the backlog refinement is the Sprint Backlog or a list of items that are due by the end of the Sprint. User stories involved should be clear to all team members and be ready to be implemented in the upcoming Sprint. Later, at the Sprint planning event, the Scrum Team finalizes a set of user stories for the Sprint and plans the tasks it will take to complete them.
How Agile backlog grooming improves productivity
Grooming your backlog at planned intervals, you keep the backlog aligned with the changing stakeholder priorities. It’s an intrinsic aspect of dealing with the fuzzy uncertainty of defining a new software system.
Also, backlog grooming practices balance out the workload: The team elaborates and estimates in detail only the top of the backlog, devoting less attention to the bottom items
The refinement meeting itself is an effective communication means within the Scrum Team. It accumulates a shared, comprehensive understanding of requirements among the dev team reducing the level of unplanned rework.
As a result of the refining activities, the next chunk of backlog items is ready for delivery meaning that it has the necessary level of transparency for its accurate implementation.