Scratch the Backlog – There is a better way to plan your work

Every approach of making work visible has some kind of “Open Column”, “Backlog” or something similar with a more fancy name. This thing tends to fill up over time, while more and more ideas and tasks get added. Eventually, this container turns into a graveyard for ideas, hopes, and promises.

It is just an illusion that the team will ever work on all of those. Furthermore, it will become impossible to keep the overview about this gigantic collection of things. This will lead to duplicates and eventually to entries that are more confusing than helping. “Didn’t we solve this already?”

Most systems I know to manage such collections are extremely limited. In GitLab, for example, I can link similar issues, but I do not have any way to see them clustered graphically.

The tragedy of having tickets in the Backlog does not end there. Often, people would put quite a significant amount of work in creating the ticket, adding additional information, references, description, comments and so on. Usually, this is immensely helpful, when work on that ticket starts within a couple of weeks. But five to six months later, most of the information is outdated or wrong. Even worse, when the team eventually decides to just close or not work on the issue, that past work was waste.

The problem we faced in the developer experience team

The above scenario sounds vague, but it was precisely the situation we faced in the developer experience team at BRYTER half a year ago. When we initially formed the team, we inherited many tickets where people believed, that this topic could fall into our area of expertise.

Furthermore, we of course created tickets for our ideas, too. In our case, we had not only a backlog, but an entire board of “Potential Platform Topics”. It was hopeless. More and more, I realised, that it was impossible to keep an overview over this massive collection of things. I also realised, that it was not helping us at all. Furthermore, I trust that important topics will come up again, even without a backlog.

Why did we have a backlog? Were we afraid to suddenly run out of work? Of course not. There was always something new that was more significant than 99% of the things we had in our backlog.

Furthermore, we also realised that jumping between tiny tasks in very different areas was neither most effective nor helping to create the feeling of being a team. Thus, we started to cluster topics so that we all would work on similar topics at the same time and together. This was extremely beneficial for the team dynamic and also the output.

The Inbox Zero Method

The Inbox Zero Method initially revered as an approach for email management. In this approach, you would keep your inbox always empty. New emails are processed immediately.

If an email just needs a quick response, give it. If it takes more time, schedule it so that you can address it with more time later. The important aspect here is, that no email is unnoticed or gets drowned in an overflowing inbox.

We followed a similar approach for our backlog.

How we got rid of the backlog

Our backlog consisted of different input channels. The “Potential Platform Topics” board, our GitLab backlog, and of course, a Slack channel for a low-barrier entry point for colleagues to ask questions and raise their topics.

The Slack channel was not the problem, as we process frequently and assure once a week, that every message is either answered or has a ticket attached, if it is something to address soon-ish. Thus, we started with the board and scanned all the issues on it.

We closed most of those straight away, as they were old and did not have much information. Others were beyond the scope of our team, and we went into a quick chat with the teams more suited to address them, how they want to proceed with those topics. Then we either closed them or moved them to the board of the other team. We moved the remaining ones to our main backlog, which we processed next.

For the tasks in our backlog, we either moved them to the refinement column if they were relevant and important within the next weeks. Otherwise, we closed them and replaced them with a simple sticky on our Mural. If the ticket contained useful information, we linked it to the sticky so that we can easily find that information, when we would approach the topic.

The Vision & Roadmap Mural

Our team maintained a big Mural with topics that we plan to work on in the future. We sorted topics by priority and clustered them by area and scope. This made it easy to structure work in a way that we work on similar topics at the same time.

It also helped because it made it easy to communicate, what we will work on any given quarter and other teams could expect significant improvements in that area, regarding developer experience. It also made alignment and work planning much easier, as we set an overall objective for a quarter and would dynamically figure out, what specific tasks had the most impact.

The “closed ticket stickies” were merely an inspiration rather than concrete tasks. Whenever we figured out what the actual task should be, we created a new issue in our refinement column, refined it and started working on it within the next 2-3 weeks.

Summary

Closing all the backlog items was a great relief for us and brought us into a position where we have an overview of what is important.

For us, there is no value in having things we cannot work on in the near future, on the board. For high-level planning and scoping, a tool that provides at least two dimensions (such as a Mural) is far better suited and gave us the necessary flexibility.

How are you organising work in your team? Write me here in the comments or via LinkedIn or Twitter.