From Backlog Nightmare to Inbox Zero: A Path to Enhanced Team Productivity and Collaboration

Every approach to making work visible has some “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 becomes a graveyard for ideas, hopes, and promises.

It is just an illusion that the team will ever work on all those. Furthermore, keeping an overview of this gigantic collection of things will be impossible. This will lead to duplicates and eventually to more confusing than helpful entries. “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 into 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 must be updated or corrected. Even worse, that past work is wasted when the team eventually decides to close or not work on the issue.

Remark: This article is an updated version of the article "Scratch the Backlog – There is a better way to plan your work", first published on the #UnblockedEngineering blog in June 2022.

The problem we faced in the developer experience team?at BRYTER

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

Furthermore, we, of course, created tickets for our ideas, too. In our case, we had a backlog and an entire board of “Potential Platform Topics.” It was hopeless. We increasingly realized that it was impossible to keep an overview of this massive collection of things. We also learned 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 realized 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 simultaneously and together. This was highly beneficial for the team dynamic and also the output.

The Inbox Zero Method?

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

If an email needs a quick response, give it. If it takes more time, schedule it so that you can address it with more time later. The critical aspect is that every email is noticed and not 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 its issues.

We closed most of those immediately, as they were old and needed more information. Others were beyond the scope of our team, and we went into a quick chat with the teams more suited to address them and how they wanted 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 following weeks. Otherwise, we closed them and replaced them with a simple sticky on our Mural. If the ticket contained helpful information, we linked it to the sticky so that we could easily find it when we approached the topic.

The Vision & Roadmap Mural?

Our team maintained a big Mural with topics we planned 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 simultaneously.

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 had an overview of what was important.

For us, there is no value in having things we cannot work on soon 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 organizing work in your team? Share your approach in the comments!