Product Backlog Grooming / Refinement

What is Product Backlog Grooming or Refinement?

Product Backlog Grooming, It’s a most useful ceremony for the scrum teams to define the stories, by maturing up its content, clarifying doubts and questions, sizing relatively, and making the story ready to start working on it anytime. Most teams/organizations get the benefits of grooming by conducting this ceremony religiously, however, few teams/organizations still in debate about using it, or not giving enough importance to this ceremony. A team can achieve a well-maintained healthy product backlog by conducting this ceremony effectively and regularly. This ceremony is also known as Product Backlog Refinement or Product Backlog Management

In this article and video tutorial we will learn every detail of Product backlog grooming, Team member’s roles in Grooming, what are the benefits, Insights, and Actions item in Product backlog grooming, How to Measure the effectiveness of Grooming, What exactly we do in Grooming, etc.

Why do we groom stories in the backlog?

There are many advantages of product backlog grooming, a few of which are listed below.

• Increase efficiency by removing uncertainty and unknown facts from a user story.
• Identify the Dependencies (within Team and Cross-functional) and Risks in advance to plan accordingly.
• Better estimation and Avoiding rework (development, testing, and implementation)
• Gives clarity to the developer and the Tester about its requirement which saves time for the development team for further discussion during the sprint cycle.
• Ensuring a story is following INVEST, which gives a better sense mature user story
• Effective Sprint Planning: by focusing on only planning during the Sprint planning ceremony. If the stories are Groomed and prioritized at the time of sprint planning, PO or Dev team need not spend much time grooming or estimating the story.
• Enforce 1st level of Prioritization to pick stories for grooming, planning, etc.
• Provide one or many chances to the Product Owner / Business Analyst / Story author to enhance the requirements with more information if required.
• During Grooming, if the Development team encounters some doubts or questions and that needs more time for the POs to collaborate, then the team can park the story from that grooming session so that PO/SA/BA can update the story with the more required information and cover the story on subsequent Grooming session.
• Better management of Product Goals, Sprint goals, and milestone meetings.

Who is responsible for backlog Grooming?

Team Member’s roles and responsibilities during product backlog Grooming.

There are three primary roles in a Scrum team, Product Owner, Scrum Master, and the Development team including QA. Every one of the scrum team participates in a grooming session, plus optionally or when invited/requested by the team cross-functional team members like DBA, UX/UI, Technical SME, Story Author, Business Analyst, etc can also participate in a grooming session to add more details and value to the grooming session.

Below mention are the primary roles and responsibilities of the team members in a Grooming session.

When should a Team conduct Backlog Grooming?

Frequency of Backlog grooming

There is no defined time as per the book to conduct your grooming session. It’s not part of any Sprint / Iteration or Release. Grooming is an ongoing activity each team needs to conduct to make and keep the backlog healthy and at a sustainable pace. Each team can groom once, twice, or even more times per week. And can have 1 to 2 hours per session. It all depends upon how fast and details analysis and discussion the team is doing for each story. I have explained a calculation that may help you, to find out how frequently and when you should schedule or plan your Grooming. Goal: Plan and execute Backlog grooming to have twice your average velocity ready at any given point in time. For example: if your velocity is 30 Story Points (SP), The backlog should have 60 SP of groomed stories ( here the backlog means the stories in backlog that were not committed ever, means [all SP ] minus [SP from past and current Sprint]) Assumptions: Calculate the Velocity as the last 6 sprints Average.

Sprint Duration is 2 Weeks.

Scrum Master has a log of each Grooming session’s Time and Groomed Story Points.

As Calculated, Schedule At-least
45 Min / 2 times a week
Or
1 Hr 30 Min / 1 time a week

Note :

• If there is already some Groomed story in Backlog, Calculate it accordingly
• After Every Sprint Planning Backlog Health gets reduced as Groomed Stories are being committed by the team
• You should Schedule more than the calculated time, mainly if you have a big prioritized backlog.
• One Product Backlog and multiple teams
• We don’t Groom too much in advance because, Situation can deprioritize groomed story, resulting in a waste of curtailed time.

Why should a team not schedule Grooming on or just before Sprint Planning?

Many times the team encountered the following challenges during Grooming.

1. A few stories may not be ready as per the definition of ready,
2. A few stories need more information to make them ready.
3. The Product Owner needs some time to clarify some of the doubts or clarifications raised by the Developer/Tester
4. Identified Dependencies need a cross-functional team’s buy-in to commit for the current sprint, The Cross-functional team may not have available bandwidth at the end moment.
5. Inefficient use of capacity, lowering the Velocity by committing a smaller number of stories than the team is capable of.
6. Leaving a chance for Scoop Creep, by introducing new stories in Sprint Duration to compensate for the available capacity.
7. Introduce a practice of committing unwanted Technical Spikes that produce no value to the Business.
8. etc.

Due to these challenges, the team use to skip the story from the grooming and parked it for the next grooming session. If the team commits the story with all these open questions, then

1. The team is actually putting the commitment at Risk and has a high chance to hit the commitment reliability
2. Developing a requirement with uncertainty, Resulting Bug is production / UAT or Test environment.

Detailed Insight into Backlog Grooming.

What the team needs to do in Grooming

Clarify Requirement:

Clarifying the requirement is the most important goal of the Grooming user story. All development team members must participate in this ceremony, and understand the ask of the user story, and what is the expectation of the Product Owner or business user from the story.  They talk about the requirements, clarify doubts if any, analyze risks and dependencies, etc. If the user story needs the involvement of a cross-functional team, the scrum master facilitates the availability and presence of the external team member to take part in this grooming session, so that the development team gets the transparent clarity of the requirement. So that they can develop and test as per expectation with the most optimized time without fail and bugs. If any doubts or questions remain unanswered, the Team Park this story for a future Grooming session, so that the responsible party can do the homework and clarify all doubts next time. And then the team picks the next story from the backlog (preferably prioritized) and starts grooming

Look into each story about:

INVEST

The team including SM and PO checks the characteristics of the story. And if it does not match INVEST they try to make changes / add content to the user
story or break it into smaller user stories etc.
INVEST is an acronym that stands for
Independent – Negotiable – Valuable – Estimable – Small – Testable.
To Know more about Invest learn about the Characteristics of User Story

Structure – 3C

The Team Checks the structure of the user story. A good user story should have
three-part: Card, Conversation, and Confirmation. To Know more about 3C
learn about the Structure of the User Story

Splitting Large Story into smaller stories:

The Team always tries to make the story the smallest possible, keeping in mind each story should be potentially shippable and following INVEST.
Many times a User story requirement is too big to estimate or fit into one sprint or capture the details in one user story for many other reasons the team should try to make the user story the smallest possible, for easy management, tracking, and execution.

Check the Acceptance Criteria:

The Acceptance Criteria must exist for a user story. Those are the criteria the tester will be used to validate the development. The Development Team and the Testers must understand the acceptance criteria and find out its feasibility, and dependencies, and clarify doubts, The Presence of Technical/Domain experts can provide their input in case it’s required. Refer to the Example of the User Story to understand More about the Acceptance Criteria

Estimate Story Points:
The team should estimate the Story points in the grooming session. Estimate only the story points not the task hours or efforts.
Refer to the article Story Points Estimation for a detail understanding of Story Point Estimation

Verify the Definition of Ready:

Many Teams maintain a Definition of Ready, The Definition mainly has a checklist. We will explain the definition of Ready
in detail in some other articles. Here are a few items from the Definition of Ready
1. The Story should have a Title
2. The Story Should have acceptance criteria
3. The Story should have an Estimated Story Point
4….
The team verifies that the story is meeting all the checkpoints under the definition of ready, before
declaring the story is now groomed.

Change The State of the Story :

Finally, once all team members mutually agree that the story is now groomed, SM or PO can mark the story as groomed by changing its state. All user stories have 4 to 5 different stages, and different ALM tools named separately, or you can customize the workflow based on your need. In Rally mark it as Defined, in TFS mark it as Approved, you can customize the Jira workflow and have a state named Groomed. The ultimate goal here is to mark the story in a way so that you can filter out all your groomed / non-groomed stories easily, and also utilize this state on your various reporting and metrics. For more on user story states, refer to Story State under Associations of a user story

Metrics to measure backlog health or grooming state.

There are not many metrics that can be required for grooming. You can analyze your grooming practice and target to increase your backlog health and grooming efficiency. I have explained two metrics that can help you achieve better backlog health and increase the efficiency of your grooming.

Backlog Health

Assuming your organization’s standard is to maintain backlog health by having groomed story of two future sprints. This can be calculated by multiplying your velocity (here velocity is calculated as the last 5 sprint average) by 2. From the example below: It’s calculated as the current Velocity is 32. So, to have a good healthy backlog you should have at least 64 story points groomed and ready for planning. Whereas per this example the backlog has only 40 Groomed stories. So the health of the backlog is 62.50%

Grooming efficiency

To calculate and measure the team’s grooming efficiency. The Scrum Master or anyone needs to maintain a record of each grooming session, Date, Number of Story points groomed, and time taken for the session. The record will eventually give you the trend of story points groomed per session and the grooming efficiency based on the average. The example below explains how you can calculate the trend and efficiency by taking an average of the last 10 Grooming sessions. It also helps you to plan your future grooming to calculate how many hours of grooming you need to achieve 100% Backlog Health.

Post Grooming Activities.
After grooming there are a couple of activities, Team can do as mentioned below
Scrum Master can send a summary of the grooming session to the team and interested parties.
The sample format can be like this

Team <Team Name> Grooming Notes

• Date / Time : <Date> / <Time>
• Duration: <Duration in Hour>
• Attendees: < List of Team members attended>
• Total Stories Groomed: <Count of Stories Groomed>
• Total SP Groomed : <Total SP Groomed>
• Total Stories attempted and skipped: <Count of stories discussed but not groomed because of any incomplete data or information, and parked for next groomed>
• Next Grooming Scheduled: <Date and Time for the next Grooming if already scheduled>

Total Stories attempted and skipped :
Next Grooming Scheduled:
Summary of Stories Groomed
Story ID Story Title Story Point
Summary of Stories Groomed

Summary of Stories Not Groomed

The team needs to work on the parked story because of incomplete data or information
Scrum Master, Product Owner, and the development team can work on the stories to gather required information or update cross
functional team member, that the team may need their presence, on the next grooming session scheduled on so and so date.