Making Your Backlog Work For You
How to take control of the giant backlog beast
These days, it is almost impossible to work in software development and not hear about the backlog. If you're not familiar with the term, here is what it means:
an accumulation of something, especially uncompleted work or matters that need to be dealt with.
The backlog is exactly what is described. Backlogs in general turn into a giant pile of ideas and projects, that you and your team believe will be accomplished somehow, someday. However, if well managed, keeping a small backlog list is a great tool to help guide your team's development progress.
Below are some ways to keep control of your backlog size and make sure it works for you, and not that you work for the backlog.
Adding items to the backlog
In general, developer teams used to manage their sprints, using boards with different columns that represent each stage of a task (to-do, in progress, done, etc.).
A few modern companies make usage of spreadsheets, using columns to add descriptions for the tasks and projects that need to be done. Sometimes they even use those spreadsheets to schedule the development cycle.
Board or spreadsheet, both always have a space dedicated to receiving all ideas that literally anyone may suggest.
At Ingresse, we do not use our backlog as a repository of all the ideas commented at the company corridors. Instead, we see the backlog as the list of next steps that will help us to answer the following question:
What are the next 3 to 5 steps that the developer team needs to take?
That is why our backlog is managed using a simple whiteboard on the wall. Since we use Road Framework as workflow, we divide our tasks into "roads" that allows a maximum of 5 already prioritized projects.
It may seem to be too few projects to keep registered, but if your projects are aligned with the main company goals, 5 projects are more than enough to keep you busy for the next few months (at least).
All other suggestions for backlog, that will not be prioritised between the next 5 projects already chosen, will not be registered anywhere.
It means that the giant list of projects will not be fed. Your team will be able to keep a clear view of what is relevant to be prioritized.
What if I forget that amazing idea?
The truth is: we never forget what really matters and what keeps hurting.
Nobody ever reads their entire backlog to decide their next project. They will just already know it.
What about when the backlog grows because of interrupted projects?
Depending on how you manage your team's workflow, or if the company you work is creating something really new, unexpected changes can affect the priority list.
In many situations, teams will leave work in a partially complete state to handle changing priorities. And that is ok if that is what your team or your project really needs. But when it does happen, you probably do one of two things with the dropped tasks/projects in your board:
Just leave it somewhere on the board, probably at the stage, they were dropped
The task is moved to the backlog
If you, for example, are applying the Road Framework to manage tasks and projects, this dropped task in the middle of the board will only create a jam and blur the visibility of what is really important.
In order to avoid this situation, we recommend:
If the project is dropped only for a short, predetermined, amount of time because of some emergency, move the task back to the "To-do" stage, so you can pick it up again in the next sprint.
If the dropped project is not relevant anymore, in other words, it does not fit with your 5 most relevant projects, just delete the task.
What about the bugs?
Bugs are the exceptions that validate the rule. All bug fixes must be addressed and moved to production as soon as they can.
Even in the case of bugs, we recommend separating bugs from other general tasks. Create a different list from your backlog, or if you prefer to only use one list, create a different label in order to easily differentiate bugs.
Critical bugs must be fixed right away. All the other bugs will be probably managed by new team members or people who need to gain more experience with that specific part of the code.
Why it is challenging to tackle the backlog this way
First, when the management has no experience dealing with technological products, it is common for them to change the development pipeline on a different pace than the team's velocity.
To handle that problem, you can find here a series of tips about how to have better conversations with the people who decide what goes into active development or not.
The second common problem is when management is having a hard time deciding where to focus. In this scenario, backlog should not be your main concern, but prioritization may help you to find where to go.