In this video, we will discuss the difference between prioritizing
a product backlog and ordering a product backlog and why we need both.
We will discuss why prioritizing a product backlog matters, different prioritization
techniques available, and finally, how to prioritize a product backlog.
Hey friends.
Welcome back to the channel.
If you're new here, my name is Vibhor.
I am an Executive Agile and Leadership Coach based in Toronto, Canada.
And this is the 6th video in an ongoing series where I'm trying to simplify the
process of planning an Agile product, starting with the product vision, followed
by product roadmap, release plan, finally learning how to create product backlogs
for effective bite-sized user stories.
So if you are a scrum master or an agile coach consider subscribing
to learn some actionable and super effective ways to be agile.
There are timestamps available, so feel free to skip it on
the video if you feel like it.
But for now let's get started.
So what's the difference between prioritizing and
ordering a product backlog?
Scrum guide defines product backlog an an ordered list of everything
that might be needed in the product.
Scrum guide removed, prioritizing in favor of ordering as a term used for
organizing the product backlog items.
According to the scrum guide, the priority is just one component
of ordering the product backlog.
Now, when I first heard of this change, I was a bit skeptical.
For me prioritization meant stacking the product backlog
items in order of business value.
What could be more important than business value!
But it turned out that I was missing a small, but extremely
important detail, "Dependency."
For example, you might choose to work on a task that requires collaboration with the
vendor, to align with vendor's schedule.
Or you might add a small item to the backlog, that the team feels,
it can complete rather than a larger item that is unlikely to be done.
Business value is essential.
There is no doubt about that, but logically ordering the backlog items
is crucial to ensure the product's stability and future evolution.
Taking house construction as an analogy, the roof of the house could
be of the highest priority or value.
It's that feature of the house that is visible to the naked eye.
Without a roof we can't imagine a house.
But can we put a roof on the house before laying the foundation?
Probably not.
What doesn't meet the eye sometimes is more important than what does.
The feature called "Roof", is dependent on the infrastructure
item called "Foundation".
That said for us to be able to launch a product with minimum viable
functionality, we need to both prioritize and order the product backlog items.
At the stage we currently are in this video series, we have a high level list of
features in our initial product backlog.
If you haven't watched that video, a link is in this corner or in the description.
If you're watching this on YouTube.
These initial product backlog items or features are at the Epic level,
meaning that these items are too big and vague for us to be able to order
them based on technical, infrastructure or vendor based dependencies.
For this reason we cannot order these items yet.
To order the backlog.
We first have to break, or as we commonly call it SPLIT, the Epic level items
into smaller bite-sized user stories.
I will covered how to effectively split a large user story in the following video.
Next, why do we need to prioritize a product backlog?
Can't we treat everything as priority?
The need to prioritize comes from the simple fact that it's almost
impossible to manage all the resources.
The workforce, the infrastructure, the tools that are required to work on
all the items that we come up with in our initial product backlog exercise.
Backlog prioritization helps us to achieve our goal of bringing maximum value to the
customer in the shortest possible time.
The most common criteria that I have seen teams using are based on four variables.
Number one business value.
This criterion determines the economic value of the feature in question.
For example, is the feature capable of bringing in more money for the
business or can it prevent the business from losing money going forward?
Number two is urgency.
How urgently do we need to deliver the feature is a feature
part of a promise or a contract.
Is there a clear deadline or a window of opportunity coming up?
For example, if you have a big launch, even coming up where this
feature plays a significant role, the urgency in that case is really high.
Number three, opportunity enablement or a risk reduction.
This criterion helps you highlight those items that may
not bring revenue immediately, but will benefit in the long run.
For example, in the product backlog, there could be some items that may
help you eliminate technical or legal risks and save your money later on.
Others may open doors for further improvements that will
significantly increase the number of potential customers.
Like the items that are required before launching the product
in a new geographic location.
Thinking of backlog items this way enables us to think in a futuristic
manner, empowering us to eliminate risks that we may encounter moving forward.
Number four, amount of development effort required.
Development effort is the only negative factor that ranks the items in the
backlog by complexity of realization.
The cost of necessary person hours is one of the main factors that
determine the amount of return we receive on our investment.
Okay, now that we have selected the criteria that we want to use to
prioritize the backlog, let's see how we can actually prioritize the backlog.
Now, there are tons, if not hundreds of prioritization techniques available.
Each technique's usefulness, depends upon the nature of the specific
product, where it is applied.
As the criteria of the prioritization change, so does the technique.
With that in mind today, I have two techniques that I
want to talk about in detail.
The first is the simplest t-shirt sizing and the second is more
detailed, Weighted Shortest Job First.
But before we dive into the ins and outs of these two techniques, we must
understand one fundamental concept that these two techniques are based upon.
And that is relative estimation.
Relative estimation is a method to estimate items by comparing
how similar they are to each other, in terms of complexity.
Now you may be hearing the term relative estimation for the first time, or you
might've heard it before, but didn't quite understand what it was all about.
Let's use an example to understand Relative Estimation a little better.
Suppose, I have a bunch of pencils, A, B, C, D, and E
lying in front of me on my desk.
Each pencil is of a different size.
If now I ask you, those who are watching this video, to guess the size of these
pencils in centimeters, chances are that each guess will be different.
This is because it is almost impossible for two people to
accurately guess the right size of an object down to the fractions.
Now here comes the relative part.
If I give you a scale of some sort like t-shirt sizes, extra small, small,
medium, large, extra large, or a number scale, like one, two, three, four,
five, and provide you with the baseline.
For example, if I tell you that pencil D is medium or using the
number scale pencil D is a three, then you can quickly determine the
relative size of other pencils, comparing it to the size of pencil D.
Ease of estimation is not the only benefit we get from relative sizing.
The main benefit comes from the fact that it helps us to attain a consensus.
If pencil D is medium, then we all would agree that pencil A is extra small.
But why does this happen?
The simple answer is because a human brain is not designed for absolute estimation.
It is however designed to relate to similar things, sizes, emotions, and
feelings, making us follow trends, like craving for a new iPhone in the market.
We are experts in looking at things competitively and relatively.
Okay.
Now that we know what relative estimation is, let's use this technique to t-shirt
size, our initial product backlog items, that we listed in the last video.
One thing to note here is that we are still in the same meeting or a
different meeting, if required with same attendees, as in the previous video.
We need all hands on deck to prioritize the items in the product backlog.
For t-shirt sizing, we need two of the four criteria that we discussed earlier.
The business value and the development effort.
In this technique, we rank the backlog items in Dubai.
The first thing that we do is get the business stakeholders to go through
and rank the items from a business perspective, assigning a t-shirt
size from extra large, to extra small using relative estimation.
Second in parallel, we have the development team go through and
classify each item in terms of development effort required.
They'll also use the t-shirt sizes from extra small to extra large.
After the two teams are done sizing the items, the product owner can
look at the list and say, Hey, I have three or four things that
are extra large business value.
Some of these are small from a development cost perspective.
That seems like a quick win to me as a product owner.
So I would put those items at the top of my development list
because I have the opportunity to get that into the market sooner.
We can even realize revenue from getting it into the market, sooner.
The product owner makes sure that the initial product backlog is ordered in
a way that provides the best business value, the highest return on investment.
Also note that this prioritization exercise does not set the order
of the backlog items in stone.
This is not a commitment.
We don't have a release backlog or a release plan yet.
This prioritization helps us understand what is worth considering for future
investigation, more analysis, more detail, more refinement, more discussion, and
more work to build that release plan.
T-Shirt sizing is an excellent privatization technique, but if two
features in the product backlog have the same t-shirt size, it may become difficult
to decide, which one to do first.
If strict order is of concern, we use a different and more reliable technique
called, weighted shortest job first or WSJF as we all commonly know it.
This technique makes use of all the four criteria, the business value, the
urgency, the opportunity enablement or risk reduction and the development
effort to calculate a numerical score.
This score suggests the priority of the items more accurately.
The higher, the WSJF score higher, the priority of the feature.
As you can already tell, we use a numerical scale to relatively estimate
different items in this technique.
The scale we use is based on the famous Fibonacci sequence.
Okay.
Let's get back to WSJF and prioritize our backlog items.
It's actually a pretty simple exercise.
All we do in this exercise is estimate each product backlog
item in four categories.
The four categories are inspired by the prioritization criteria we
discussed earlier in this video.
Using the Fibonacci scale and relative estimation, we assign
a number in the scale to each backlog item in each category.
For example, let's say for feature A, business stakeholders concluded that
it's a five on business value, eight on urgency and a five on risk reduction.
Similarly IT teams estimated feature it to be a three for the development effort.
The first three numbers together represent the cost of delay, which is
this idea of how much revenue impact feature will have if it is delayed.
You can also think of cost of delay as the opportunity cost, which is
often the word the product managers use to discuss the impact of not
having something into the marketplace.
We then divide the cost of delay or CoD, in short, with the
number in the development effort.
And the result that we get is what is called a WSJF score for
that particular item or feature.
When calculated for each item, the WSJF score tells us which item or which
feature provides a considerable amount of revenue in the shortest amount of time.
Higher, the score, the better bang for the buck we get.
So that you have it.
This is how we prioritize the items in the initial product backlog.
But we are not done yet.
We are one step closer to having our release plan.
In the following video, we will discuss an easy way to break these initial
backlog items or features and epics into smaller bite-sized user stories.
If you like this video, then give it a thumbs up and don't forget to provide
your valuable feedback in the comments.
I'll see you in the next video.