[Music]
What is up awesome people! Welcome back to
my channel. Joshua Partogi here.
So before we start today's video I would
like to give everyone a massive thank
you! Especially to those of you who just
subscribed to my channel. Just a few days
ago I reached another milestone that is
2,000 subscribers. It never crossed to my
mind that I would reach this many
subscribers when I started my own
YouTube channel around mid last year. So
thank you everyone who has supported me
in this journey towards Scrum mastery. So
let's start today's video. In today's
video let's talk about Product Owner
stuff. In today's video, let's talk about
how to order the Product Backlog. This is
important because there are still a lot
of misconceptions out there. There are
still a lot of articles and YouTube
videos that says that the Product
Backlog is prioritized. According to
Scrum Guide the Product Backlog is
ordered instead of prioritized. There are
reasons why the Product Backlog is
ordered and there are multiple aspects
that Product Owner need to consider when
ordering the Product Backlog. So if you
are curious what are the aspects that
the Product Owner need to consider
when ordering the Product Backlog don't
go anywhere stay on this video.
[Music]
As written on Scrum Guide the Product
Owner is responsible to order the
Product Backlog and accountable for the
value of the product. The order of the
Product Backlog will reflect the roadmap
and the value that the company will likely
get from the product. Before we talk
about how to order the Product Backlog,
let's talk about what's inside the
Product Backlog. There's a lot of
misconceptions in the market that the
Product Backlog only consists of User
Stories or just the features of the
product. So let's find out what's inside
the Product Backlog. According to Scrum
Guide the Product Backlog consists of
all of the work known to be needed in
the product. The keywords here are all
the work, which means other than User
Stories and features, the Product Backlog
also consist of but not limited to
defects, technical debt, product
architecture, technical specification,
user experience design, non-functional
requirements, urgent work from the CEO,
hypothesis, etc. The other keywords here
that we have to notice here are: 'known to be
needed', which means the Product Backlog
consists of our current assumptions. If
you're interested to learn how to write
your Product Backlog item other than User
Story format, I have made a video on
how to write the Product Backlog item
using the hypothesis format. If you are
interested to learn more about it click
the link up here to watch the video.
Another thing we have to keep in mind is
the Product Backlog is ordered rather
than prioritized. There is a reason why
Scrum Guide chose the word order rather
than priority, so let's learn more about
it. First because semantically two items
can have the same priority but no two
items can be at the same order. Priority
reflects the level of urgency and often
times it can be very subjective. This is
very important for Scrum Masters and
Product Owners to know especially those
who works in a very political and
bureaucratic organisation because in
that kind of organisation many people
will just say that everything is high
priority just to get their stuff done
first. So that's why we don't use the
word priority in Scrum.
Secondly, because there are other
attributes to consider besides priority.
Some of the attributes the Product Owner
must consider when ordering the Product
Backlog are dependencies, the age of the
Product Backlog item, the size of the
Product Backlog item, perceived value,
risk and also learning. Let's talk about
dependencies between Product Backlog
items. When talking about dependencies
there are two types of dependencies that
are business dependencies and technical
dependencies. Two items may be on top of
each other because it is dependent on
one another. In the context of Scrum we
strive to remove dependencies at
technical level and make the
architecture of the product to be
loosely coupled as possible so multiple
teams can work on the Product Backlog
items independently. The size of the
Product Backlog item is another
attribute that is considered when
ordering the Product Backlog. Many Scrum
teams use story points in Fibonacci
sequence or t-shirt size to size their
Product Backlog items. Ideally on the top
order are the items that has been sliced
and refined as such it can be completed
in one Sprint and on the bottom order we
have all of the items that are
coarse-grained. The Product Backlog items
on the top order are refined and ready
for the next two to three Sprints. The
rest are coarse-grained and open for
change. In Scrum we do not slice and
refine all of the Product Backlog items
as that will be expensive and there is a
risk that not everything in the Product
Backlog is going to be needed.
According to Scrum Guide awesome Scrum
teams spent at least 10% of their Sprint
to refine the large size Product Backlog
items continuously. Slicing and refining
is a collaborative work between the
Product Owner and also the development
team. The next attribute to consider when
ordering the Product Backlog is risks.
When we're talking about risks its risk
of failure because the product is
delivered too late. One known example
here is Windows Phone. Another risk is if
customers don't embrace our product even
though we deliver the product early. One
known example here is Friendster. Ideally
we want to deliver the product at the
right time. Not too early, not too late.
Because both have risks.
Ideally risk is quantified to numbers
or dollar value. Awesome Product Owners
quantify risk and map it into cost of
delay. On top order of the Product
Backlog ideally are items that have
risks that are worth fighting for.
We should leave silly risk at the bottom
order of the Product Backlog. The next
attribute to consider when ordering the
Product Backlog is perceived value. We
call it perceived value because the real
value can only be generated after the
product is released and being used by
the customers. So until the product is
released and in the hand of customers we
only have perceived value. To avoid
decision making based on political power
ideally perceived value is quantified in
numbers to help Product Owners to order
the Product Backlog. Even better if we
can provide a spreadsheet on how we came
up with the perceived value to the
Product Owner. Ideally on the top order
are the high perceived value items and
on the bottom order are the low
perceived value items. Ideally you have
more high perceived value items than low
perceived value items on the top order
of the Product Backlog. Amount of
learnings is another attribute that the
Product Owner must consider when
ordering the Product Backlog because
it's related to risk and also perceived
value. Product Owners want to create
small experiments that will result in
learning to avoid the risk of losing
tons of investments. Many awesome Product
Owners will also argue that value is
unknown and fuzzy, so the only way to
identify where value is located is by
creating small experiments. Ideally
learnings is also quantified to numbers
so Product Owners can create delivery
strategy easily. Ideally on the top order
of the Product Backlog are items that
will give the organisation many
learnings while on the bottom order
are the items that do not give the
organisation much learnings. So if we
consolidate all of these Product Backlog
item attributes and create a Venn
diagram between the Product Backlog item
size, perceived value, risk and learning.
Ideally the ones on the top order of the
Product Backlog are the one shown on
this orange area. Besides the attributes
on the Product Backlog item, the Product
Owner decision on the order of the
Product Backlog may also be influenced
by the customer and the consumer
expectations, market conditions and the
competition landscape. The Product Owner
should also be open
minded and considers feedback from the
development team. If the current product
is in a bad state
the Product Owner will put defects and
technical debt on the top border of the
Product Backlog.
[Music]
Product Owner is trusted to be able to
do an awesome job to optimize the value
of the product. The order of the Product
Backlog will reflect the value that the
organisation will obtain. No one in the
organisation can override Product
Owner's decision regarding the order of
the Product Backlog, even those with
highest political power. Otherwise the
Product Owner cannot really take
ownership of the product and the product
owner is not more than just a proxy. So
that is all from me today folks I hope
you found that this video helpful.
Especially if you are an aspiring
Product Owner. Hopefully today's video
helps you create strategies to optimize
the value of your product. If you liked
today's video don't forget to smash that
like button and don't forget to
subscribe to my channel so that you
won't miss any of my videos in the
future. See you until my next video!
Stay safe and Scrum on!
[Music]