- To keep the product backlog healthy,
the team needs to continuously refine it.
Backlog refinement is when the product owner
and some, or all, of the rest of the team
review items on the backlog
to ensure that the backlog contains
the appropriate specifications.
They need to make sure that those requirements
are prioritized, the right items on the top
of the backlog and are ready for delivery.
This activity occurs on a regular basis
and may beneficial the scheduled meeting
or an ongoing activity.
The overall intent of backlog refinement
is to ensure that the backlog remains populated
with items that are relevant, detailed, and estimated
to a degree appropriate with their priority.
And also, it's important to keep the backlog up to date,
meaning in line with the current understanding
of the project or product and its objectives.
Some of the activities that happened during the refinement,
include, first, removing user stories
that no longer relevant,
second, creating new user stories
in response to the newly discovered needs,
re-assessing the relative priority of stories,
assigning estimates to stories
on the top of the backlog,
correcting any estimates in light
of the newly discovered information,
and finally, splitting user stories
or decomposing user stories
that are high priority but too significant
in effort to feed the upcoming Sprint.
Product backlog refinement
usually was called backlog grooming.
The earliest recorded use of the term backlog grooming
is from Mike Cohn, who is the guru
of agile requirements management,
and he started using it in 2005.
Grooming was originally used to reflect
on organic approach to product backlog maintenance.
And the use of the word grooming
had some negative connotations in some cultures.
So this specific activity has been renamed
to backlog refinement,
but many practitioners still use the word grooming.
If you hear backlog grooming,
it is a synonym to backlog refinement.
There are overall different practices
in terms of frequency of product backlog refinement
and ownership of this event.
This practices differ between organizations.
Some teams schedule refinement sessions
as part of the Sprint cadence
and have all team members participate in those sessions,
discuss user stories, align on estimates
and take action items to find the missing details.
In some other organizations,
the ownership is with the product manager
and product manager will make decisions
upon consulting with the relevant stakeholders
and make their backlogs available to team members
for review and feedback.
And product manager could be the same person
as the product owner or could be a separate person
for a large products,
where there are several sub-products involved
that needs coordination and alignment
in terms of decision making.
Overall in my experience, the more collaborative
and structured the approach is,
the more well defined it is,
the less room is there for scope creep.
For any misunderstanding,
any confusion, any change in scope.
Overall, there are several principles to follow.
Number one, product backlog refinement
is not limited to the refinement session.
The product owner has to set clear vision
communicated to the team,
aligned with the stakeholders
and continuously remind them what is the true north.
What is the objective they want to achieve?
The second is that product owner is in constant contact
with the business and also the technology stakeholders.
This means that there are no surprises
that specific user stories are getting deprioritized
and a business stakeholder is upset about it
because they need this functionality.
And some of those are not included in the backlog
and that's even worse misalignment situation.
So overall I do not suggest deleting ever
any user stories that you have on your backlog.
If they're no longer needed, cancel them,
and put in comments why you have chosen to do so
and let's keep them there for the record.
The third principle is that the workload
for the backlog elements
has to be very well-defined and communicated.
This includes your intake mechanism,
any categories, any expected format,
approvals, and so forth.
Usually it is done off the working agreement of the team.
In the working agreement, the team defines
the rule and practices and behaviors
how they want to work together,
and putting your intake and decision making
for your backlog in the working agreement
is usually a good idea.
And remember, if a requirement is not in the backlog,
it does not exist.
Always resists the anti-pattern of doing work of the books
even if can be absorbed within the current Sprint
and even if it is the right thing to do for your product,
put it in the product backlog.
Your backlog is the documentation for your product.
So if any undocumented work will go into production,
it'll create issues with extending
or removing any related functionality in the future.
So remember the mantra,
if it is not in the backlog, it does not exist.