Ordering/Prioritization
Dear all,
In this article https://www.scrum.org/resources/ordered-not-prioritized, it is written that "Usually, the best orderings are not priority orderings".
Can someone kindly explain this with an example please? There could be many factors that come into play to prioritize; say, ROI, dependencies, business value etc etc. So, I do not get the real meaning of that statement.
Thank you in advance.
Best Regards,
Noor.
A priority ordering is an ordering that is based exclusively on priority.
The article goes into several reasons why this doesn't work.
Although priority may be an input, it's ambiguous. In my experience, most teams work with a broad spectrum of stakeholders. Different stakeholders or stakeholder groups may have different ideas about the priority of a given Product Backlog Item. At a minimum, the Product Owner needs to distill these priorities into something actionable and usable to order the Product Backlog.
Even if there's a single priority given to each Product Backlog Item, that is insufficient to strictly total order the Product Backlog. In Scrum, the Product Backlog is an ordered list. You don't have an ordered list if you don't have a strict total order. Often, with priorities, you end up with broad buckets, such as "High", "Medium", and "Low" or "P0" through "P5". This means multiple Product Backlog Items may end up with the same priority. An ordering function can consider priority but cannot exclusively rely on priority.
The Product Owner tends to consider several attributes when ordering the Product Backlog. Some examples are the perceived or estimated business value, return on investment, and product parity or product differentiation. The Developers may also provide input about technical dependencies or risk reduction that can be satisfied by doing the work in a different order.
I don't think it's safe to say that priority isn't an input. However, any consideration of priority is often transformed from the priorities of each stakeholder group and considered with several other factors. A Product Backlog ordered based only on priority is a poorly ordered Product Backlog that isn't likely to optimize for rapid feedback and value delivery.
Prioritization alone isn't typically good enough to manage value delivery. That would be too blunt and instrument. There could be dependencies (e.g. business, technical, workflow, human) which a Product Owner would be foolish to ignore, as well as risks and differences in projected Return on Investment.
All of these things, and more, ought to be considered when ordering and organizing a Product Backlog.
An ordered backlog provides guidance for a team on how the work could be done in order to provide the best deliveries and efficiency. A prioritized backlog list items in specified order ranked upon a single criteria. For example ...
Delivering a new user interface that will work on a future version of mobile operating systems might be a high priority. However, some infrastructural updates might be required in order to do make that delivery so they would be a higher urgency. Which of these would come first in a prioritized backlog? Which would come first in an ordered backlog?
Priority is only one of many considerations that are considered when ordering items.