hang around a scrum team for more than a
few minutes and you'll probably hear the
term product backlog grooming this is a
concept that has gotten very popular
among scrum teams over the past few
years it refers to the idea of keeping
the product backlog well maintained
since a well-maintained product backlog
can solve a lot of problems let's see
exactly what grooming the product
backlog means in the early days of scrum
the product backlog was treated pretty
much like that drawer we all have in our
kitchens or somewhere in the house you
know the one full of all sorts of junk
you don't have any better place for the
product backlog was just the place early
scrum teams but anything they needed to
remember to do the items weren't
necessarily written in a way that the
team would later remember what the items
meant and team certainly didn't have
regular time devoted to clean up these
messy early product backlogs
well team soon learned that Sprint's
went a whole lot better if the product
backlog was looked after and kept in
good shape or in other words groomed
let's see what type of activities make
up product backlog grooming here we have
a typical product backlog grooming a
product backlog usually involves a
handful of separate actions first new
items can be added to the product
backlog usually this will be something a
product owner will do but product owners
often have questions for the rest of the
team that affect where the new item will
be put in the product backlog minimally
a product owner will usually want at
least a guess from the team about how
long a product backlog item will take to
develop if a particular product backlog
item isn't going to take long to develop
the product owner may want it
immediately but if that same item is
going to take a long time to develop it
will usually go further down on the
product backlog second and along the
lines of adding new items is
reprioritizing product backlog items we
may have an angry customer who needs
some feature now so that gets moved up
in the product backlog or usage data on
a released feature may tell us that
something in the product backlog isn't
needed as urgently as once thought so
that item gets moved down a third action
that could be considered part of backlog
grooming is splitting larger product
backlog items
to smaller ones as items at the top of
the product backlog are developed and
removed from the product backlog the top
priority items are ones that were
previously lower as an item nears the
top of the product backlog it is
important that it is small enough that a
team can finish it in a single sprint so
part of backlog grooming involves
discussing any items that are nearing
the top of the product backlog and it
may be too large to complete in a sprint
those items are split and the new
smaller stories put back into the
product backlog where they belong they
often belong in different places as
shown here because these sub items can
be of differing priorities along the
same lines is splitting up a product
backlog item is adding detailed with
those product backlog items that will
soon be brought into a sprint when
working with user stories those product
backlog items these details are commonly
called conditions of satisfaction or
acceptance criteria but whatever they're
called they are essentially high-level
tests for a product backlog item many
teams had discovered the benefit of
establishing a definition of ready
before any product backlog item can be
brought into a sprint it must comply
with the team's definition of ready
product backlog grooming is where top
priority backlog items are assessed
against the definition of ready by doing
this in advance of the sprint planning
meeting the product owner is given a
chance to add any missing details before
that meeting one last action that makes
up product backlog grooming is throwing
away product backlog items that will
never be done that old item in your
product backlog about adding support for
extended memory on dos 5.0 get rid of it
if you haven't done it by now you're
never going to I'm the first to admit
that for many product owners throwing
items away is easier said than done I
think I'm finally cured but for years I
would just store old product backlog
items in a spreadsheet I never looked at
the items again but they were there if I
needed them now I've learned to just
throw them away so if you're
uncomfortable getting rid of things
completely create a spreadsheet and call
it your long-term product backlog
separating things that realistically
will never get done
from the higher priority items can make
a big difference in keeping the product
backlog from reaching an unmanageable
size in this video I've talked about
five things that make up
like backlog grooming I haven't talked
though about who does it and win there's
a bit of debate about that in the scrum
community which I'll address in the next
video