In this Article and video tutorial we will learn every details of Product backlog grooming, Team members role in Grooming , whats are the benefits, Insights and Action item in the Product backlog grooming, How to Measure effectiveness of Grooming, What exactly we do in Grooming, etc.
There are many advantages of product backlog grooming, few of them are listed below.
- Increase efficiency by removing uncertainty and unknown facts of a user story.
- Identify the Dependencies (within Team and Cross functional) and Risks in advance to plan accordingly.
- Better estimation and Avoid rework (development, testing and implementation)
- Gives a clarity to developer and Tester about its requirement that saves time to the development team for further discussion during 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 Sprint planning ceremony. If the stories are Groomed and prioritized at the time of sprint planning PO or Dev team need not to spend much time to groom or estimate 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 encounter some doubts or questions and that needs more time for the POs to colaborate, then the team can park the story from that grooming session so that PO/SA/BA can update the story with more required information and cover the story on subsequent Grooming session.
- Better management of Product Goal, Sprint Goal and milestone meeting.
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 participate 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 responsibility of the team members in a Grooming session.
- Create User stories (some times with team collaboration) keeping the INVEST and Definition of ready in Mind
- Prioritize the backlog, So that team can groom the story in prioritized Sequence.
- Explain the requirement of the user stories one by one, about its Acceptance Criteria, wireframe, Expected design, Business logic, etc.
- clarify doubts of the development team, Tester or any cross functional team members.
- Split big stories to smaller stories keeping INVEST in mind.
- update the Story points after team decide the Story points.
- Update the story state once the story is identified as Groomed and meeting the Definition of Ready.
- Schedule and organize the ceremony
- Co-ordinate with Product owner/Story Author / Business Analyst to identify the potential prioritized Story to be groomed, and informed the development team to prepare accordingly.
- Facilitate the Grooming Session
- Ensuring time box and best utilization of the time for the purpose of the Grooming only
- Facilitate Estimation for the user stories.
- Ensuring definition of ready and INVEST is meeting before declaring the story as groomed.
- Note details for MOM or reporting.
- Facilitate if a story is too big and can be breakdown.
- Put the story on hold for grooming, in case further clarification required.
- Send out Minutes of meetings, with list of stories with story points to all interested parties
- Send out Backlog Health report
- Go through the stories to be groomed and prepare accordingly
- Understand the requirement
- Clarify doubts
- Participate on maturing up the story description and acceptance criteria.
- Map dependencies if any
- Map Risks if any
- Participate in Story point estimation
- Possibly Go through the stories to be groomed and prepare according to support from out side the team
- Understand the requirement
- Clarify doubts
- Provides input to the team about the need of cross functional dependencies and complexity
There is no defined time as per book to conduct your grooming session. Its not part of any Sprint / Iteration or Release. Grooming is a ongoing activity each team needs to conduct to make and keep the backlog healthy and a sustainable pace. Each team can groom once, twice or even more times per week. And can have 1 to 2 Hour per session. Its all depend 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 of your average velocity ready at any given point of time.
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 those were not committed ever, means [all SP ] minus [SP from past and current Sprint])
- Calculate the Velocity as last 6 sprints Average.
- Sprint Duration is 2 Weeks.
- Scrum Master have a log of each Grooming session’s Time and Groomed Story Points.
As Calculated, Schedule At-least
45 Min / 2 times a week
1 Hr 30 Min / 1 time a week
- If there is already some Groomed story in Backlog, Calculate it accordingly
- After Every Sprint Planning Backlog Health get reduced as Groomed Stories are being committed by the team
- You should Schedule more than the calculated time, mainly if you have big prioritized backlog.
- One Product Backlog and multiple teams
- We don’t Groom too much in advance because, Situation can deprioritize groomed story, result into waste of curtail time.
Why a team should not schedule Grooming on or just before Sprint Planning.
Many times the team encountered the following challenges during Grooming.
- Few stories may not ready as per definition of ready,
- Few stories needs more information to make it ready.
- The Product Owner needs some time to clarify some of the doubts or clarification raised by Developer/Tester
- Identified Dependencies needs 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.
- Inefficient use of capacity, lowering the Velocity by committing less number of stories then the team is capable of.
- Leaving a chance of Scoop Creep, by introducing new stories in Sprint Duration to compensate the available capacity.
- Introduce a practice of committing unwanted Technical Spikes that produce no Values to the Business.
Due to these challenges, the team use to skip the story from the grooming and park it for next grooming session. If the team commit the story with all these open questions, then
- The team is actually putting the commitment in Risk and have a high chance to hit the commitment reliability
- Developing a requirement with uncertainty, Resulting Bug is production / UAT or Test environment.
Clarify Requirement :
Clarifying the requirement is the most important goal of Grooming user story. All development team members must participate this ceremony, and understand the ask of the user story, what is the expectation of Product Owner or business user from the story. They talk about the requirement, clarify doubts if any, analyze risks and dependencies etc.
If the user story need involvement of cross functional team, the scrum master facilitate 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 most optimized time without fail and bugs.
If any doubts or questions remain unanswered, Team park this story for future Grooming session, so that the responsible party can do the homework and clarify all doubts next time. And then the team pick the next story from backlog (preferably prioritized) and start grooming
Look into each story about :
The team including SM and PO check about the characteristics of story. And if its not matching INVEST they try to make changes / add contents to the user story or break it into smaller user stories etc.
INVEST is a acronym which stands for
Independent – Negotiable – Valuable – Estimable – Small – Testable.
To Know more about Invest learn about Characteristics of User Story
Structure – 3C
The Team Check 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 Structure of User Story
Splitting Large Story to smaller stories :
The Team always try to make the story 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 or for many other reasons the team should try to make the user story 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 using to validate the development.
The Development team and the Testers must understand the acceptance criteria and find outs its feasibility, dependencies, clarify doubts, The Presence of Technical/Domain experts can provide their inputs in case its required.
Refer the Example of User Story to understand More about Acceptance Criteria
Estimate Story Points :
The team should estimate the Story points in grooming session. Estimate only the story points not the task hours or efforts.
Refer the article Story Points Estimation for details understanding of Story Point Estimation
Verify the Definition of Ready :
Many Teams maintain a Definition of Ready, The Definition mainly have the checklist. We will explain the definition of Ready in details on some other article. Here are few items from the Definition of Ready
1.The Story should have a Title
2.The Story Should have an acceptance criteria
3.The Story should have a Estimated Story Point
The team verify that the story is meeting all the checkpoints under definition of ready, before declaring the story is now groomed.
Change The State of the Story :
Finally, once all team member mutually agree that the story is now groomed, SM or PO can mark the story as groomed by changing its state. All user story have 4 to 5 different stages, different ALM tools named it separately, or you can customize the workflow based upon your need.
In Rally mark it as Defined, in TFS mark it as Approved, You can customize 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 story easily, and also utilize this state on your various reporting and metrics.
For more on user story states, refer Story State under Associations of user story
There are not much metrics 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 a better backlog health and increase efficiency of your grooming.
Assuming your organization standard is to maintain a backlog health by having groomed story of two future sprint. This can be calculated by multiplying your velocity (here velocity is calculated as last 5 sprint average) into 2. from the example below : Its calculated as current Velocity is 32. So to have a good healthy backlog you should have at least 64 story points groomed and ready for planning. Where as per this example the backlog has only 40 Groomed story. So the health of the backlog is 62.50%
To calculate and measure the team’s grooming efficiency. The Scrum Master or any one needs to maintain the 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 explained how you can calculate the trend and efficiency by taken a average of last 10 Grooming session. Its also help you to plan your future grooming to calculate how many hours of grooming you need to achieve the 100% Backlog Health.
After grooming there are couple of activities, Team can do as mentioned below
Scrum Master can send a summery of the grooming session to the team and interested party.
The sample format can be like this
Team <Team Name> Grooming Notes
Date / Time : <Date> / <Time>
Duration: <Duration in Hour>
Attendees : < List of Team member 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 schedules>.
Summary of Stories Groomed
|Story ID||Story Title||Story Point|
|1||<Story 1 Title>||2|
|2||<Story 2 Title>||5|
|4||<Story 4 Title>||5|
|5||<Story 5 Title>||2|
|7||<Story 7 Title>||3|
|8||<Story 8 Title>||8|
|9||<Story 9 Title>||2|
|10||<Story 10 Title>||2|
Summary of Stories Not Groomed
|Story ID||Story Title||Reason for not able to groom|
|3||<Story 3 Title>||Mention Reason|
|6||<Story 6 Title>||Mention Reason|
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 next grooming session scheduled on so and so date.