Ah, the English language! It is rich, yet full of little nuances that can create difficulties. For example, what is the difference between a prioritized Product Backlog and an ordered Product Backlog?
For those who may have overlooked it, the 2011 Scrum Guide changed from referring to the Product Backlog as being prioritized to it being ordered. And since this wording was retained in the 2013 version of the Scrum Guide, just what is an ordered backlog, and how is it different from being prioritized?
Let’s start with prioritization, which can be a challenging thing to do because I’ve come across managers (stakeholders) who desire multiple “number one” priorities. Yes, this is a case of not prioritizing at all. Enough said on that point.
When it comes to actual prioritization, you rarely prioritize a product backlog against a single attribute. User value, time, effort, risk reduction and opportunity enablement are all factors – and moving targets. For example, a feature may have high perceived value before the holiday season, but zero afterwards.
Prioritizing against multiple attributes requires a weighting system, and fortunately we have a great solution to the problem: the Weighted Shortest Job First (WSJF) as put forth by Don Reinertsen. A short discussion on this can be found on the Scaled Agile Framework web site in an abstract: The Economic Prioritization with Weighted Shortest Job First (WSJF).
After working through a weighted prioritization using the WSJF, the end result is a prioritized Product Backlog. This introduces another subtlety. Drawing from the Merriam-Webster dictionary’s definition of prioritize, we find that prioritization is the act of listing or rating items in their order of priority.
Prioritizing is thus an act, and our result of this act is a prioritized Product Backlog. The order represents what has been agreed to from a prioritization perspective, but most likely we aren’t finished.
Let’s say that as a Scrum Product Owner, your backlog primarily (but not exclusively) consists of User Stories. As we all know, User Stories should be crafted so that they are as small and independent as possible. But in product development some things must naturally be in place before other things can be worked on, creating dependencies…
…so, if you have a User Story Q that is in and of itself is NOT a priority based on your existing weighted prioritization, but there is both value and a need to implement it because User Story F requires the functionality, then you would go ahead and insert User Story Q ahead of the other, dependent User Story F, right?
What have we done in this case? Have we re-ordered the backlog or re-prioritized it?
We’re talking about an additional refinement to the order of the prioritized Product Backlog. The extra step of moving things around creates an ordered list that doesn’t necessarily reflect our prioritization criteria.
That is how – at least as I figure it – we got to ordered Product Backlogs instead of prioritized Product Backlogs. The need for this extra ordering should be minimal in actual practice, provided that we have a good weighted prioritization scheme in place.
Can the argument be made that we’re really prioritizing all the way through, even with the ordering step? I think so. Based on how I read the Merriam-Webster dictionary, I’d argue that the final ordering step was effectively elevating the priority of certain items that fell outside of our usual prioritization criteria, creating the final, prioritized list of work.
If this is the case, then why make the distinction?
Because the weighted prioritization criteria should be something that is visible, communicated, discussed and agreed to by the stakeholders and the Product Owner. The wording creates a clear distinction between establishing product priorities as agreed upon on versus the needs of the product in total to meet those priorities, which is ordered.
That’s my take. I’m interested to hear your thoughts!
18 hours ago