The Unordered Product Backlog

An unordered product backlog can become a trash heap of PBIs that doesn’t give the development team any indication of which items they should work on next. Sprint planning becomes a random grab of what the Scrum team feels is important in that moment. Stakeholders may start lobbying for their pet project, even if those things shouldn’t be the team’s top priority, and the loudest voice may get precedence.

The product owner determines the order of the product backlog. However, some misguided POs do this by assigning priorities to PBIs, which isn’t the same as ordering them, and is an approach that always leads to headaches. For example, Ryan recently worked with a company that was struggling to figure out which product backlog items to work on next. Every PBI in the product backlog was assigned the highest level of priority, 1. What the organization quickly learned is that when everything is important, nothing is important.

Product backlogs should be ordered, not prioritized. The Scrum Guide clearly states that a product backlog is ordered—in other words, the product backlog items are in a specific order. The value of each PBI is indicated by where it is ordered on the product backlog.

There are some really good reasons for preferring ordering over prioritization:

• The term “priority” implies a level of certainty that we simply don’t have in a complex environment. If your product owner gives a PBI a priority of 1, that implies that the item will get done, and your stakeholders will hear that implicit message loud and clear. And why shouldn’t stakeholders assume that PBI will get done—it’s of the highest priority!

• If ten PBIs have a priority of 1, how does the development team know which one they should work on first? In short, they don’t. But if PBIs are ordered instead, the development team knows exactly which ones to work on, and in what order.

• If your product owner has multiple top-priority PBIs, he should know which one delivers the most value to stakeholders—and therefore, he should be able to order the items appropriately. If the PO doesn’t know which PBI is most valuable, how can he possibly know whether the sprint should be funded in the first place?

A clearly ordered product backlog creates transparency to stakeholders and helps the dev team know exactly what they should be working on at any given time. So if your product backlog is turning into a trash heap, talk to your product owner about ordering the product backlog items, and offer to help them do so.