Your product backlog is not a list!
By: Dejan Fajfar
Tags: Agile, Lists, Graph, Product Backlog

According to scrum.org the product backlog is an ordered list of everything that is known to be needed in the product. Solely responsible for the product backlog is the Product owner. Whose job it is to add items to the product backlog, assign business values, prioritize and explain the items to the “needed level”.

Contrary to the definition of scrum.org I have found that after some time the product backlog evolves into a directed graph with the nodes being the product backlog items, and the edges denote the dependencies between them. A directed graph is mathematical construct, more specifically described in graph theory, it is essentially a graph where the edges have a direction associated with them.

How did I come to the conclusion that something the majority view as a list is in actuality a graph? The honest answer, by simple observation. I’ve noticed how the initial lists became more and more of a graph system, as the ‘plan’ was confronted with reality.

But how and why would we transition from a list to a graph? After some research, the following factors contribute to the core of it all:

Product backlog items can not exist in a vacuum with zero dependencies

Splitting large backlog items creates dependent items

“Infrastructure” refactoring

One of the characteristics of a product backlog item is its self containment. Self contained in the sense that it is independent from other items in the product backlog.

From my point of view this is actually not technically feasible. Each item in the backlog relies on either the current/planed state of the application or on an item that has precedence before it. This can be visualized as a ordered list but it does not change that these dependencies exist and have to be taken into account when re-ordering items. I have seen it happen time and time again that a item was committed to a sprint only to find out that the required “groundwork” for this item has not yet been done. This happens because while reordering items in the backlog to match the business priority not all depended items were identified and reordered accordingly, an error that a graph view would easily prevent.

When development teams estimate new product backlog items, it can and it does, happen that they estimate an item beyond the capacity of a sprint. In that case the product backlog item has to be split. Most of the time splitting a product backlog item will result in sub-items which are dependent on one another, a sub-graph if you will.

It is further assumed that the new sub items can be done in parallel; sometimes this is true and other it sadly isn’t. Determining which is true, is hard if using an ordered list, but quite easy when using a directed graph.

Bad things happen. With all the ad-hoc planning and emerging architecture some evolutionary dead ends are to be expected in the development process. When these occur, fixing them mostly requires more than just a little tweaking. In most cases these turn into lengthy refactoring stories or even complete rewrites of key components or the complete application. This will block the development of new features, features that depend on said components. If we could easily determine which stories successfully circumvent the affected components we could continue to develop at least some features. This would be easily identifiable in an graph but quite a challenge in a ordered list.

Lastly some items are just dependent on other by design. A defect ,for instance, is dependent on a feature whose behaviour was found to be erroneous. The benefit is that when we fix the defect we can follow the dependencies up the graph and only test the features that are impacted by the defect, making the question of which tests to run an easy one.

This evolution of a list into a directed graph over time has been witnessed time and time again, by me and other people in the field.

I have been personally stuck in meetings where we were discussing what we could do next and not how we should do it.

Dependencies exist, whether we like it or not and ignoring them will only make our lives harder in the long run, and time to market that much longer.

A list ordered by only one key, be that business value or some other arbitrary key, will never capture the complexity that developing large scale software brings with itself. It is highly convenient to know what is possible at any given time and what the projected cost will be.

For example, it is not smart doing a 3 SP item but completely miss the fact that we have to finish a 20 SP item first, just because this is not documented and the only person knowing this abstract fact is on sick leave.

Tools nowadays enable us to document such dependencies without much of a fuss, but we have to be meticulous while creating and inserting new items into our product backlog. It will take some time and work, but in the end it eliminates a lot of unnecessary discussion session and guesswork out of the planning for the next sprint.