Backlog management may seem like your basic humdrum task – and that’s what it often is. In a typical scenario, the team and the product owner work on the development backlog of the product on a weekly basis. Their tasks include

• adding various requirements, features, tasks etc. to the backlog to steer the product (or project) towards the desired direction in terms of business
• reorganizing the backlog by prioritizing the task that will produce the most value in the near future, followed by the second most important task etc., and by pushing things that are less important or less urgent further down the list
• clarifying the contents of the backlog items so that the team is able to finish the things they’re working on
• dividing larger wholes into more easily manageable tasks to enable the tasks’ completion in the course of one iteration
• agreeing on things to do next, bearing in mind that the product owner makes the final decisions.

All this may sound straightforward enough, but backlog management also involves numerous challenges which can make it very difficult to successfully carry out a project.

Some time ago, I conducted an unofficial LinkedIn survey asking the people in my network to list both things that often go wrong when working on backlogs and things that contribute to successful backlog management. The following is a summary of the observations people made in the discussion (thanks to all the participants!).

The pitfalls of backlog management

Below I have listed some typical problems people encounter when working on backlogs, but the list is by no means exhaustive. Taking a deep dive into the core issues behind the problems listed here would easily add items to the list.

1. Doing work that isn’t mentioned in the backlog. This makes the work invisible, unidentifiable, unquantifiable, and vague in terms of expectations and agreements.
2. There’s no regular time reserved for working on backlogs or the time isn’t sufficient, which leads to a number of other problems.
3. The real priorities aren’t reflected in the backlog, or the priorities aren’t up to date, although some people may have a vague, not necessarily coherent, understanding of what they are. In the worst-case scenario, all backlog tasks are considered “number one priorities”. This means that the team has lost its agility since there’s no way to negotiate how the changing situations are going to be navigated.
4. The backlog contains lots of miscellaneous work, whose scope varies and whose connection to the big picture (e.g., epics or other development themes) or goal is difficult to grasp.
5. The backlog grows to be so long that its conceptualization and management becomes difficult. The backlog contains tasks which are irrelevant in terms of the immediate future (they’re either expired or relevant only in the long run) but which no one dares to delete.
6. The user stories are baffling. For example, a story that provides a good description of a user persona or goal may turn out to be too extensive for the team to tackle in one sprint. It may be surprisingly challenging to think of a way to vertically divide such a story into smaller, value-producing and potentially releasable bits without creating a task list for horizontal, technical implementation.
7. Workload assessment and work rate predictions aren’t based on a balance between work input and yield. There’s a constant need to seek answers to questions, such as ‘when are we going to finish’, ‘when is this backlog task going to be completed’, ‘what’s have we managed to complete by this date’, ‘what can we do with this amount of money’ etc. At the same time, we know that workload assessments are unreliable at best and that the value of the assessments is based on gaining a better understanding of the work. At their worst, assessments can give a false sense of security and create absurd expectations about the future of a development project.
8. Important matters and decisions are documented only in the backlog, which means they will disappear once the tasks are completed or removed from the backlog.
9. As a one-dimensional list, a backlog doesn’t help the team to gain a better understanding of the bigger picture. Management tools often hide things like objectives, priorities, dependencies, schedules, agreements, who benefits from the work and so on. In more substantial projects, forming an understanding of the whole requires something more than a mere list of tasks.
10. People are invested in narratives and storytelling. Empathy and emotions stick in our memories. A one-dimensional list doesn’t help us tell the story of an entire product but instead leads us astray and takes us from storytelling to story writing (which certainly wasn’t the original intent of user stories). When the whole story of a product is misunderstood and when we lose sight of why we are doing the things we do, prioritization becomes difficult, and we don’t understand the relationship between the content and the whole.
    
    

Next, I will present some solutions that will help with the problems listed above. Think of them as the good practices of backlog management.

Good practices for backlog management

Discuss the following with your team the next time you hit a snag with your backlog task (or, better yet, before that happens!).

1. Reserve enough time to work on and discuss the backlog. Make this a regular occurrence. The product owner does the preparations and works on them together with the development team. Successful communication and interaction are key.
2. Record all work in the backlog at a low threshold while ensuring that recording the work doesn’t fall on one individual. Team interfaces need to be made clear, particularly in bigger projects. In other words, there needs to be an understanding about how the team receives the work and everyone needs to adopt the agreed practices.
3. Clarify the teams’ internal policies (working agreements), such as Definition of Ready and Definition of Done. Everyone needs to know what things require explanations and descriptions before the work can be started and what needs to be done before the task status can be changed to completed.
4. Also clarify the way in which decisions are recorded and communicated. Development involves many decisions about priorities, scheduling, scope, architecture, contents, features etc. Think about which of these decisions need to be recorded for future reference. Who needs to be informed about them? How can the decisions be revisited?
5. Determine not only the larger objectives but also the short-term goals by, for instance, discussing what you want to see at the end of a sprint, in a release, at the end of a quarter and so on. Connect the work and tasks to these objectives.
6. Divide the work. Each subtask should become part of the system and cut vertically through the architecture, in addition to which it should be possible to release each subtask independently in a way that potentially produces value to the users. Division of work aims at the production of complete but thin slices of the whole cake, not the creation of horizontal layers or fillings.
7. The product owner should weigh and think about priorities, discuss them with the team and make decisions. Every day, the team assesses and prioritizes its own work in relation to the next goal. If a more urgent task suddenly pops up, someone needs to ask what can be left out so that the new task can be accepted.
8. Learn to use the backlog management tool at an advanced level. Create different views to examine various aspects and points of interest. The developer’s and the product owner’s favorite views may look different, but that is okay since people look at the backlog from different perspectives.
9. Clean up any irrelevant tasks from the active backlog, whether they’re outdated, belong to a distant future roadmap, or only reflect some vague wishes. The views and filters in the management tool are a great help and allow you to centralize your tasks in one place.
10. In addition to keeping a backlog, draw up a “world map” to help you work on your backlog and support any related interactions. This will help you visualize your objectives, priorities, dependencies, values, schedules, agreements etc. It can be a mind map, a user journey map, service blueprint, or a user story map, which has the closest ties to backlog work.

How to improve backlog management in your development team?

Do you get the feeling that your team could use some assistance when it comes to backlog management? There are many available tools and methods that can help you with your work on backlogs. For instance, the Lean UX Canvas method helps you clarify your product vision, and creating a User Story Mapping allows you to build a comprehensive story for your product.

No matter what your approach is, it’s good to remember that the success of any backlog management endeavor is based on high-quality interaction. The methods mentioned above offer no silver bullets but serve as tools for improving the interaction and collaboration between your team and other relevant parties. This is a topic I’m likely to return to at a later time.

For anyone who’s into reading and looking for food for thought, I recommend the following books:

• Compare the 2020 and 2017 Scrum Guides’ views on backlog management and then check out what A Scrum Book has to say about it.
• The Professional Scrum Product Owner paints a more or less complete picture of the world of backlog owners.
• 50 Quick Ideas To Improve Your User Stories contains over 50 amazing ideas on how to boost your backlog management.
  One of the ideas presented is, of course, the mapping of user stories, i.e. creating a world map. The book User Story Mapping tells you everything you need to know about using the method.
  
  

The most essential thing to remember is that backlog management is a topic that can be – and is – discussed during your team’s regular retrospectives. Continuous improvement cannot exist without continuous reflection and practical development measures.