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 Getting Things Done, though. The GTD process includes the "capture" of stuff (thoughts, todos, etc) into an inbox. It then includes the processing of that inbox, creating actionable items that can be surfaced based on deadlines and/or context.
To me, the backlog is akin to the inbox, and backlog grooming is almost exactly like the review of that inbox.
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 actually rewarding. We worked from the oldest ticket to the newest (we never got 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.
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, for any future person who picked them up.
Some represented something that still needed to get done, but now in a completely different way, or with different technology.
Some were an older, smaller piece of a larger issue we were already focused on, but provided that history and 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 actually interacted with our application was still present.
A backlog is really just a collection of documents, like a wiki 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.
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.
Some of these same programmers love Getting Things Done, though. The GTD process includes the "capture" of stuff (thoughts, todos, etc) into an inbox. It then includes the processing of that inbox, creating actionable items that can be surfaced based on deadlines and/or context.
To me, the backlog is akin to the inbox, and backlog grooming is almost exactly like the review of that inbox.
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 actually rewarding. We worked from the oldest ticket to the newest (we never got 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.
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, for any future person who picked them up.
Some represented something that still needed to get done, but now in a completely different way, or with different technology.
Some were an older, smaller piece of a larger issue we were already focused on, but provided that history and 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 actually interacted with our application was still present.
A backlog is really just a collection of documents, like a wiki 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.
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.
Like i remember that time I came to you drinking the Basecamp Koolaid raving about their shapeup process and you were like 'hey this is just like a sane version of doing agile, but it's just still that.' lol