A Healthy Product Backlog

A Healthy Product Backlog

by Dirk Depré - May 12, 2021

In an ideal agile world, I’m engineering amazing stuff and I have an end-user or customer sitting right besides me. The feedback loop is very short, providing me with tons of new insights. You could even say that we actually co-create towards a working solution. But reality is sometimes not what the ideal state looks like. And so we have processes in place to come as close as possible to that ideal world: it’s simply said: “the next best thing”.

In case of solution development this is that ‘man in the middle’ owning the product and bridging gaps between two worlds. Let me be clear, that is a hell of a job and you might turn towards running from one side of the bridge to the other expressing desires and wishes, ending up in order taking and running marathons to get a result. There simply has to be a smarter way.

A healthy product backlog is something that needs constant attention and despite we would like to see it as something stable, it actually is ever evolving. Talking about things in a conceptual way gives first ideas, but it only becomes clear when a first increment is build and feedback can be gathered. When it becomes tangible, first ideas most likely evolve and the priorities in a backlog might change. It means we have to constantly work and rework that backlog and there actually is a simple way of doing this: refining the backlog or product backlog grooming. Regular backlog grooming sessions help ensure prioritizing the right stories, so that the product backlog does not become a black hole, sucking in everything it possibly can suck in.

A tool to manage a healthy product backlog

The idea of having a DEEP product backlog was explained to us by Roman Pichler and Mike Cohn. DEEP is an acronym for: Detailed appropriately, Estimated, Emergent, and Prioritized.But what does that mean?

explained through the words of Mike Cohn:

• Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.

• Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.

• Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.

• Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed.

What you gain if you put in the efforts

The philosopher and great Captain Jack Sparrow said it: “The problem is not the problem. The problem is your attitude about the problem”. So if you think about building the right thing, you need to put in the efforts. Maintaining a healthy product backlog is hard work but also comes with a strong (shared and understood) vision. It’s all about clarity and transparency. And it might seem logical to you as a reader, but often forgotten, yet ‘communication is key’. We all know that communication consumes a lot of time and opens the door to make assumptions. That’s why you need to think about the level of detail that is necessary for the engineering teams to be able to move forward. And so when you approach your product backlog, make sure you take the 4 attributes of DEEP into account. As a surplus, you also end up with nice evolving product roadmap. What more can you dream for?