Scrum teaches us that the “single-threaded, ordered list of work” is the correct way to prioritize the work of the future. Innumerable articles—including one from this very site—tell us that a single, stack-ranked list is the simplest way to clarify priority.
I find, however, that this is unsatisfying at best, and fails to achieve sensible prioritization at worst. It also doesn’t solve the political challenges of prioritization with stakeholders.
Product Managers typically conflate these, trying to do both with a single process, and a single backlog. A traditional backlog efficiently encodes the answer to the second question, but isn’t the right tool for answering the first question.
You might say, “But we should work on whatever is most important, right?” By unpacking the subtle answer, we’ll arrive at a better way to prioritize, and a better way to plan work.
If prioritization answers “What is most important,” it begs another question: What do we mean by “important?”