Backlog is not a Linear List

“It’s all about Product Backlog. Product Owner should manage it. Prioritize it. Fill it with User Stories.” Sounds familiar? It’s typical at certain stage of agile transformation to focus on building a Product Backlog. And use Jira for that. You find such linear to-do lists in almost every organization at the beginning of their agile journey. And though Product Backlog is very important tool as it brings clarity and align people around the same business goals, it’s also one of the most misunderstood and misused tools. It often starts with a good intention, Product Owner asking customer what they want. And they, in a good intention, brainstorm all the possible functionalities you can imagine. And the Backlog/scope keeps growing while the time expectations stay the same. That’s very common start of a big disappointment with Agile. “It didn’t help us. It’s not faster!” people say, and they are right. Agile is not the way how to deliver more functionality faster. Quite the opposite. It’s a way how to achieve higher business value faster, and those are two different things.

So, if you want to get more business value, start with the backlog. But this time, you’re not asking what you want to be implemented but instead ask for needs and look for a minimal functionality to be implemented to satisfy those needs. 80% of the value is in 20% of the functionality and that’s exactly what good Product Backlog should identify. The higher value items first, the rest later or never.

Good Product Backlog is co-created in collaboration with customer, stakeholders, and team members. They all need to uncover the business needs. They all need to develop an empathy for the customers. In most of the cases Product Backlog they create together is not a linear list that would fit traditional tools like Jira or Excel, instead very often we use Story Mapping technique to create multidimensional maps, or impact mapping technique to create a mind map, or visualize the product as a tree and prune the branches. Nothing that would look like a linear to do list. All the techniques have one thing in common; they focus on the business value and the customer needs. They don’t describe the solution. The how in Scrum should be uncovered during the Sprint in team collaboration. So, forget on the requirements, stop asking your customers what they want, and instead focus on uncovering their needs and together visualize the value in your Product Backlog.