The Difference between Priority and Order in Your Agile Work
During a conversation about Scrum planning with a VP of product at a small company, they asserted that we needed to order the backlog by priority. I mentioned that the Scrum Guide talks about an ordered backlog, not a prioritized one, and that while business value is the main driver for how a team organizes its backlog, you still need to agree on an order. We ended the conversation with a vague agreement that the backlog is “ordered, but with the order informed by priority,” which seemed to be a poor resolution of the discussion.
While order and priority are related, they are not the same, and understanding the difference and why people focus on one over the other can help your team be more effective at delivering business value.
The main difference between priority and order is that priority is about values, and order is about how to work. One reason to prefer order to priority is that the values that inform priority are often fuzzy, and it can be difficult to get organizations to order product backlog items based on priority. Some teams prioritize in MoSCoW fashion or create lists with clusters of items at each level. Talking about order makes the problem more concrete and forces the important and practical question “What shall we do first?“ much more than a list or forty “P1” items can.
At the product backlog level, order allows you to quickly identify what work to add to a sprint. Business value should be a factor in the ordering, but item size or even availability of specific resources can also inform the order. For example, you might choose to work on a task that requires collaboration with a vendor to align with the vendor’s schedule. Or you might add a small item to the backlog that the team feels it can complete, rather than a larger one that is unlikely to be done.
At the sprint backlog level, where the team is organizing how it will complete the product backlog items, order is even more important. While backlog items are supposed to be independent, a team may realize that starting work on a lower-priority item sooner will simplify work on other items.
At the sprint level, even order can be a bit flexible: The team may decide that starting a smaller task at the end of the week makes more sense than starting a larger one and having to pick it up after the weekend. If the team is consistently meeting the sprint goal, then product owners and management should not feel compelled to enforce any work order.
In a well-functioning Scrum team, the team decides how to organize the work to get everything that is part of the sprint goal done, and the product owner trusts that the team knows best how to reach the goal. Business value—and, thus, priority—are a consideration, but not the only one. Thinking about order will help the team deliver value more quickly than focusing solely on priority.
