In Defense of the Backlog

from @forrestbrazeal

Some programmers like to hate on the backlog. It’s just an endless list of tasks that we’ll never get to, they say. It’s demoralizing, they say.

Some of these same programmers love personal productivity systems, though, almost all of which maintain some kind of backlog. It might look different from the typical software development backlog, but it’s still the same thing. It’s a system that captures tasks and organizes them. One of David Allen’s main mantras was about capture, so we’re not wasting energy keeping tasks in our heads.

The goal of the control processes in GTD is to get everything except the current task out of your head and into this trusted system external to your mind. #

(See also Cal Newport on Productivity Systems.)

David Allen also recommends a weekly review, so that items in the system are regularly reevaluated and reorganized.

At the company where I was CTO, we had a significant backlog. Once a week, for an hour or so, four of us would get on a Zoom call and groom the backlog. It sounds terrible, but it was rewarding. We worked from the oldest ticket to the newest. Each ticket was like a story, like finding an old magazine at your parents’ house. It helped us understand the history of our system and the context in which our current priorities exerted themselves. Our main goal was to close tickets, but…

Some still needed to get done. Some of them were simple technological problems and needed no additional clarification. Some needed a lot of additional information added to them because circumstances or technologies had changed.

Some were an older, smaller piece of a larger issue we were already focused on but provided additional context to the current project.

Some represented user experience issues that we never addressed, and while the user interface had evolved since the ticket was written, the underlying misunderstanding of how our users interacted with our application was still present.

A backlog is just a collection of documents, like a wiki, or system documentation, or a “digital garden”, and requires the same constant care, editing, and weeding of those other kinds of information repositories. But items in the backlog are the best kind of documents—actionable ones. A backlog is just a shared “trusted system”.

In mid-2020, about a month before I left the company, a developer completed a ticket that was originally written in 2014. It was our oldest ticket. It was for the replacement of our queuing solution. The old one was fraught with reliability and performance issues, but we limped along with it for six more years despite those shortcomings. But the time had finally come, and because of that work, the system was instantly more reliable, performant, and its additional features opened up new opportunities for the system to serve our customers. And it was a great excuse for a big celebration.