The Story Map

Hi Justin,
yes I do use a Story Map very similar to the one displayed there and we made very good experience with it.
The second dimension gives you a better overview of a big product than an ordered list, and the "hardware solution" supports discussions with stakeholders more than an electronic tool.
Before each sprint planning, the product owner selects some of the top items and orders them. The resulting list with defined priority is the part of Product Backlog relevant for planning.
Best, Ludwig

> When it comes time to prioritize stories, I don't prioritize the backbone. It just "is." I do prioritize the ribs...

A variant of this principle is the MoSCoW prioritization of user stories where each epic may be compulsory, but only some of the constituent leaf node stories will be. This is how the "everything is a must" problem can be resolved. Once you get stories that meet the INVEST criteria, less than half are likely to be mandatory and contribute to the MVP.

Some other observations:

- In Scrum, Product Backlog Items (PBI's) have both order and value. The composition of a "one dimensional" backlog can therefore be more nuanced than the article implies
- It is potentially wasteful to define the ribs of a walking skeleton application before those stories or tasks are ready to be progressed. The added detail may depreciate in value, as it will no longer be current at the time of actioning. Giving clear order to a backlog allows such details to be elucidated in a more just-in-time manner.
- You don't want pull to be exerted on an item that has not been given business priority for actioning. To do so will increase WIP and lengthen the lead time. This is why a Product Owner is jointly responsible for ROI and for giving order to the Product Backlog.