Product Backlog in The Scrum Framework Poster

Hi Laura,

To the best of my knowledge, as long as you use digital tools (ie JIRA, Trello), your backlog would appear "ordered" sequentially, so PBIs would be listed one below another, with the most relevant (order-wise) right at the top. I'm not aware of any digital tool that allows a parallel ordering.

On a whiteboard with post-it notes, a PO could order a few PBIs on a parallel level as a sign to the team (or stakeholders) that they are considering two or more PBIs as the most important ones, but they're awaiting results or a phone call before making a decision (and order accordingly).

All said, I'm of opinion an "ordered backlog" is best attained through sequential rather than parallel listing.

My opinion is that a properly ordered backlog would be linear for the items at the upper levels.  If you order multiple items at the same level it becomes difficult for anyone to make decisions on how to address them. I have never encountered a situation where there was no way to order one item over another if they are at the top levels of the backlog.  That rule does not apply for items lower in the backlog.  As @Eugene mentioned, there could be items that are still in discovery stages where the ordering criteria has not emerged. 

That rule also might not apply if there were multiple teams working from the same Product Backlog.  In that case the multiple teams could focus on different items that are ordered at the same level at different levels of the backlog.  It wouldn't be my first choice but I could work with teams in that situation. 

I have seen electronic tools that allow parallel ordering.  Asana is an example. The lightweight tools tend to be less stringent in their implementations. 

Good question. I honestly never looked at the diagram that close to notice it.  

Until now, I thoght that this means that the Product Backlog is always in one order, so one PBI is always after another PBI, and they can't never share position in the Product Backlog

Scrum is minimally prescriptive, and the idea of “one order” might perhaps introduce a constraint inappropriate to certain contexts.

As an extreme example, you might have a Product Backlog ordered in terms of “ready” and “not ready”, or perhaps even “stuff to think about now” and “stuff to sort out later”. Anything more structured might be too hard to manage in a complex and uncertain environment.

Dear Laura, 

Scrum does not prescribe how the Product Backlog is made „visible, transparent and clear to all, and shows what the Scrum Team will work on next“ (Scrum Guide). 

The Product Owner can choose any visualization that works best for the Scrum Team and its stakeholders. While some Product Owners use a one-dimensional, top-to-bottom visualization, others might find a more-dimensional, left-to-right, top-to-bottom format (e.g. a user story map) more useful to reflect the Product Backlog.

The visualization of the Scrum Framework poster reflects the flexibility of choosing a visualization that works best in a given context.

I hope this helps.

My interpretation of that graphic is that it's highlighting how items closer to the top of the Product Backlog are more likely to be well refined, and therefore broken into smaller deliverable items (with a lot of the waste, uncertainty and complexity removed); whereas it would often be wasteful to apply such extensive refinement to the bottom of the backlog.

I mean, It's like if diferents PBIs can stand in position 1 on the Product Backlog.

I would say even if two items were next to each other, an order would likely be assumed (either implicitly or explicitly). The frames on this comic strip are just one example of there still being a logical order, even though the boxes are of varying shape and size, and spread both horizontally and vertically across the page.

Thank you everyone for all the answers!! 

It’s help me a lot to open my mind and think about the Product Backlog from other perspectives.