It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.

In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.

Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.

What’s Wrong With Flat User Story Backlogs?

So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;

We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.



After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.



That’s what a flat backlog is to me. A bag of context-free mulch

How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?

Shortcomings of a Flat Product Backlog

• The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
• Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
• The flat backlog provides no context or ‘big picture’ around the work a team is doing
• A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
• Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?

User Story Maps

A story map is a visual representation of the journey a customer takes with a product, including the activities and tasks they complete. This visualisation helps the team to focus development on providing the most value to customers and their desired outcomes.

It provides context for teams by answering the following questions:

• Why are we building this?
• Who are we building this for?
• What value will the solution provide for the customer and when?

The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.

What A User Story Map Achieves that a Flat Product Backlog Can’t

• Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
• Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
• Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste

Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?

Easy Agile TeamRhythm

Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.