- We're taking a look at Scrum piece by piece,
and today it's the turn of this hot mess:
The Product Backlog.
Hi, my name is Gary Straughan,
welcome to Development that Pays,
the number one Agile channel on YouTube.
If you like what you see here,
please do consider subscribing,
and hit that bell icon so you don't miss a thing.
The Product Backlog is an ordered list
of everything that is known to be needed in the product.
Not my words.
- Not my words, Michael.
- The words of the Scrum Guide.
And, the Scrum Guide goes on to devote
a fair few column inches to the Product Backlog.
The Product Backlog is one of the three Scrum Artifacts
along with the Sprint Backlog and the Increment.
You'll find episodes on both of those,
and many other aspects of Scrum, at this link,
and this is probably also a good time to remind you
that there is a cheat sheet to go along with this series,
the imaginatively named Scrum cheat sheet.
You will find a link to that in the description below.
The Product Backlog sits here outside of the Sprint Loop,
but a key input to it.
Without the Product Backlog,
there'd be nothing to plan in Sprint Planning,
and there'd be nothing to put in the Sprint Backlog.
If I zoom out further to the overall Agile flow,
we see that the Product Backlog is a vessel,
a collection point for feedback received from the customer,
as well as from stakeholders, and from the development team.
As we covered in the first episode of this series,
this flow is not unique to Scrum,
nor is the Product Backlog a construct
that is unique to Scrum.
It's common to all of the Agile frameworks
that I'm aware of.
There's a very well-defined way of getting items
out of the Product Backlog.
That's the ritual, the event, that we call Sprint Planning,
the point where items are taken from the Product Backlog
into the Sprint Backlog.
Getting items into the Product Backlog
is a little less well-defined,
but at least there's one thing that is defined
about the Product Backlog,
and that is it has a very specific owner, the Product Owner.
I have more to say about the Product Owner
in a separate episode, but when it comes to the relationship
between the Product Owner and the Product Backlog,
well, the Scrum Guide couldn't be more clear.
The Product Owner is the sole person responsible
for managing the Product Backlog.
So, no pressure then.
But, that's not to say that it's a job that she does
completely on her own, as we shall soon see
after I get my animation fix for this week.
Let's jump inside the Product Backlog.
Hmm, little bit dull, let's add a spot of color.
Oh yeah, very nice.
I'm not attaching any meaning to these colors,
it's just to help you keep track of them
as they move around, and move around they will.
The Product Backlog is in a constant state of flux.
The Product Owner's job is to maximize the value
of the product over time, and she does that by making sure
that the most important items in this list
appear towards the top.
Most important, is that right?
I've been saying that the most important items
appear towards the top of the Backlog for so long
that I've maybe lost track that that's not exactly right.
Maybe it's the most valuable items
that appear towards the top.
Well, that's better, but there's still the problem
that a high value item often depends on a lower value item,
and, in this list, the lower value item
would therefore be pushed up for earlier development.
I'm beginning to see why the Scrum Guide says
that the list is prioritized and leaves it at that.
So, prioritized, certainly, but priorities change.
What was important or valuable, or something else, yesterday
may not be so today.
And, new items arrive all the time
and can be slotted in at, well, at almost any point,
even towards the top of the list if the item merits it
and if it is sufficiently refined.
Refined?
When an item arrives in the list it might be nebulous,
fuzzy, a little rough around the edges,
which is fine for low, even for mid-range items,
but if it's gonna reach the top echelons,
it's gonna need sharpening up a bit.
This sharpening up falls under the general umbrella
of Backlog refinement.
Here's the Scrum Guide again.
This is an ongoing process in which the Product Owner
and the Development Team collaborate
on the details of the Product Backlog items.
Finally, a little bit of help for the Product Owner.
Let's just check that we've got
this refinement thing covered.
Back to the Scrum Guide once more.
Product Backlog refinement is the act of adding detail,
estimates, and order to the items in the Product Backlog.
Oh no, estimates, more work to do,
work that's not required for every Agile framework,
but is required for Scrum.
If an item is gonna reach the top echelons
of a Scrum Product Backlog,
I'm afraid it is gonna have to be sized.
Why?
Simply because during Sprint Planning
we're gonna be selecting a Sprints worth of work,
and we're gonna be doing that
based on the size of the items selected.
So far I've talked about Product Backlog items
without actually saying what constitutes an item,
and I'm gonna go back to the Scrum Guide one last time
for a ruling on this.
Here we go.
The Product Backlog lists all features,
functions, requirements, enhancements,
and fixes that constitute the changes to be made
to the product in future releases.
I'm curious, is that a list that you agree with,
or would you suggest amendments?
Let me know in the comments below.
And, get ready to comment on
what I'm about to tell you to think.
I'm about to stray into controversial waters.
Zooming out a little bit to look at the Product Backlog
as a whole, the items towards the top of this list
we now know are ordered, they're detailed,
and we have estimates from them.
Being in a well-refined state is a consequence
and a condition of their elevated status.
As for the remaining items in the list,
they may or may not be well-refined,
depending upon their history.
But, and here's the point,
while these items in the mid-range
are targets for Backlog refinement,
the items towards the bottom of the list are not.
As far as Backlog refinement is concerned,
these items should be ignored.
Why?
Well, chances are that this item
will never move up the list,
that it will never be developed.
And, that being the case, why waste time on it?
Should the item rise up the list
at some point in the future,
and of course I do wish it all the best,
then it will find itself in the mid-range
and become subject to refinement.
But, until it does, it should be ignored.
And so, my question for you is do you agree?
Is that what you do, or in your team
do you refine and estimate the entire Product Backlog?
I would be very curious to know.
Please let me know in those comments below.
Thank you very much for watching.
If you enjoyed this episode, please do give it a thumbs up,
and continue watching this series on Scrum,
starting with this one right here.