Product Backlog Refinement (Grooming)

Purpose
The purpose of PBR (Product backlog Refinement) is to make improvements to the product backlog.
Though there is no official detailed in the Scrum Guide the activity of refining the Backlog is

Who Participates?
Backlog Refinement is collaborative effort involving

 Scrum Master keeps the session moving towards its intended goal
 Product Owner Team (Business Analyst) Clarifies the details of the backlog items
 Development Team define the work and effort necessary to fulfill the completion of agreed
PBI. It is recommended to have at least one developer and one tester when refining the
backlog, to ensure alternate view point of the system are present

When do we Backlog Groom?

Before development of user story in the current sprint (Iteration), generally sometime during the
previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to
add details, because the delay will slow the team down. Do not refine your stories too far in
advance, because the details might get stale. Depending on the delivery rate of your teams you
should be meeting once week to review the backlog.

Prerequisites
We need to ensure:

 Top order the PBI to reflect the greatest needs of management team and the product owner
team.
 Candidates for grooming includes stories identified as not ready to complete with in the
next sprint or will require multiple days of research.
 Periodically review epics, feature are other items on the management team road map

Backlog
The product backlog can address anything deemed valuable by the product owner team. For the
purpose of sprint planning, when you use scrum as the delivery frame work, product backlog item
must be small enough for the team to complete and accept during the sprint. Verify items are
implemented to the satisfaction of the owner team. This is the time for the team to get clarification
from any details regarding stories in the backlog. This will be the first time the team has seen the
story to have a chance to clarify and get the PO to address any issues in the stories.

Estimate -Poker Planning

The team has whole should be using poker planning cards to estimate each of the stories. If there is
a disagreement b/w why a story might be an 8 vs 3 then the individuals need to explain why they
think it’s a 3 or an 8. Once they plain from their point of view then team can revote. The poker
planning cards goes from a 0 to 100, the whole list of numbers is 0, 1, 2, 3, 5, 8, 13, 21, etc. Most
teams only go up to an 8, since any story that is sized a 13 is usually a good candidate to broken up
into a multiple user story.

Inspect and question user stories

Ensure stories have acceptance criteria. All stories require acceptance criteria. Without it, you
cannot define the boundaries of the user story and confirm when a story is done and working as
intended. Ensure acceptance criteria is testable. This is what your tester should be writing test
against. Rewrite or breakup large user story. Ensure the user story format is consistent, meet INVEST
criteria, and you write from a business not technical perspective. Know who the customer is. It may
not be an end user. Rather, the story may be for something like a service for another team to
consume.