In the latest session of our Agile Circuit, Lesmes López, Agile Delivery Manager (ADM) at Codurance, gave us some insights on backlog management and introduced us to a few valuable tools we can adapt to our specific contexts. 

He defined backlog as an accumulation of tasks or activities to be completed. An emerging list of what a product needs or a series of elements that generate value for businesses and users. He pointed out that we must only work on the most valuable aspects to guarantee backlog efficiency. This way, we can avoid generating waste and piling tasks that add no value to the final goal.  

What kind of backlog do I have?

The answer to this question will depend on your context. In the words of researcher Simon Wardley, "no one size fits all." Lopez explains that, although it may seem obvious, the first thing to do is to know your product very well and define its environment or stage. Wardley's 'Climatic Pattern' map is a valuable method for analyzing our environment. According to this map, and based on the location of a product's life cycle - from its genesis to its transformation into a commodity - different practices can be more or less valuable in managing tasks.

If your product is on the left side of the map and is very innovative or requires a process of trial and error, then you are at the far end of Agile with XP practices. If your product has reached its maturity stage and you know what features users are looking for, then you are in a Lean and Scrum environment. And if you have a product that is ready to be commercialized, then you should use methods like the Sig Sixma method. 

Another method we can use to define our project's stage is Kent Beck's adapted iron triangle: Explore - Expand - Extract (mentioned in detail in our session about project discovery). Several dimensions of the backlog can change if we can identify where we are. 

Context is one of the most important aspects to consider when defining what kind of backlog we have and how to manage it. However, it is not the only one. Other factors also influence backlog development, to mention a few:

• The business model
• The system - on-premise/ cloud
• The cost of mistakes
• The deployment model
• The nature and structure of the team - waterfall/ agile

It's not just a list but, where shall we start?

Rather than just making a list, we are building a map of options that explains the ADM so that we can visualize the most important elements to work together as a team. For this reason, he offered us some tools that can help us define and organize our backlog:

Opportunity Tree Map

This diagram created by Teresa Torres allows us to identify different elements focused on obtaining the same outcome. If we don't set a clear objective, it won't be easy to attain real value with the tasks we carry out. Therefore, we must connect the desired outcome (goal) to a series of opportunities and look for solutions. We then can associate experiments with these solutions to determine their suitability. This is an advantageous method for mapping the initial part of the discovery. 

User Story Mapping 

It's a visual map that describes the narrative flow of users' journey through our product or service and helps them choose the method that offers the most pleasant experience. It seeks to solve customer needs with functionalities and establishes the steps to satisfy that needs and the tasks to complete those steps. This horizontally distributed map allows us to provide real value per sprint or deliverable.

OKR's - Objetive Key Results

Link your backlog to a set of objectives. Measure those objectives and align the team toward achieving them. In this way, the initiatives become the elements in the backlog. 

'Ruthless' prioritisation

If anything will help us limit waste and manage the backlog, it'll be ruthless prioritization. It is vital to exclude unnecessary tasks from our backlog. Otherwise, it will be hard to move forward if our backlog is full of functions that still need to be added. By the time we have to work on them, we will have forgotten the information regarding such tasks, or the information we had might have become obsolete. We have to focus on the last responsible moment when the cost of postponing a decision intersects with the cost of the decision itself. To do this, Lesmes presents two possible methods:

Point-based design. When we have to decide about something we are hesitant about, we choose a possible solution and apply it. If the selected solution doesn't work, we restart the process with another option.

Set-based design. Unlike the previous method, which works with only one solution at a time, this technique involves looking at all possible alternatives for the brand and testing them to narrow down the list to one final solution. It consists of postponing the final decision while we gather more information. 

The ADM compared various prioritization models that may be helpful to analyze depending on the project or product you are working with:

To conclude, López recommended making a roadmap as lean as possible, with general concepts and no specific details. For example, you could create a roadmap with three columns called 'now, next, and later' that represent each of them, a different quarter, and that will allow you to visualize a series of issues related to the general objectives. Always remember these issues should be raised and worked on as a team to encourage the exchange of ideas and team alignment.

Sources:

• Better/Sooner/Cheaper/More + tweet
• Inception Deck
• User Story Mapping
• Value Stream Mapping
• Wardley Maps