Claiming Backlog Bankruptcy

Background

When I first started as a product manager, I spent several weeks orienting myself with how to manage my team’s product process. At first, my priority was just to keep my head above water and make sure that I could be effective for my team. However, once I got my bearings, I started to put some attention to improving our product processes. My first objective was to refresh the product backlog. ?

The backlog had become an enormous list of epics, placeholder stories, unprioritized bugs, and wish-list items. We used Trello at the time to manage the backlog. I remember having to stare at it for what seemed like an hour just to digest all the stories and epics. I probably was the only person on the team who had any big problem with how the backlog was represented. To me, all the stories and epics were creating a lot of mental noise. It was like a firehose of problems and I felt like I was expected to do something about all the stories to be successful as a new PM. ?

Process

Claiming backlog bankruptcy

It eventually came to a point where I need to make a change for my own sake. The first step I took was to communicate to everyone that I was going to be doing some major reorganization of the backlog. This was immediately met with questions and concerns. Others had been using our backlog as a place to store their ideas for future reference. There was a concern that if I just deleted all those stories, there could be valuable context that could be lost should we prioritize those things in the future?.

To navigate these concerns but also not allow it to be a blocker to the reorganization, I created a new board in Trello to store all these ideas. I called it the “Graveyard.” It was a bit of a misnomer since it wasn’t like I writing off all these stories for future consideration. I just no longer wanted all these ideas taking focus and attention away from the things we were actively prioritizing.?

Rethinking the backlog

With the backlog cleared out of all the noise, I could now start to reorganize how it was represented. The next step I took was to conceptualize the backlog as a more a snapshot in time rather than an exhaustive record of things we needed to get done. To me, a backlog is most effective as a shorter, detailed visualization of the product roadmap. The roadmap generally tells you, based on what you know today, where you want the product to be in 12 months. On the contrary, the backlog generally should tell you where you intend to be in the next three months. ?

By focusing on the backlog as more a function of time, it makes it easier to be more disciplined in maintaining it as a tool for your team to quickly understand priorities and what will soon be coming up for feature development. It also makes it much easier as a PM to clearly think about prioritizing stories against where you want to be in a shorter time frame. It doesn’t let ideas and suggestions distract you from keeping the team focused on what is most important today. ?

Realigning with the team

After I reworked the backlog into a more manageable structure for myself, I shared it with the team to get their feedback. I wanted to make sure I didn’t miss anything we had agreed to prioritize over the quarter. I also wanted to touch base to make sure the team understood what the highest priority items were for the future. After talking with the team, there thankfully weren’t any “gotcha” moments and everyone was happy to use the new backlog. ?

Result

At the end of this, I had a backlog that now communicated the short-term product priorities. This change wasn’t earth-shattering and it didn’t suddenly increase our development velocity. It was a change that just made my life a little easier. By making the backlog shorter and more a function of time, I felt like I could better communicate our priorities to my team. Additionally, I felt more confident with this new backlog communicating to management what was on the horizon for feature development.?

Conclusion?

If you feel like your backlog is getting out of hand, it probably is. Start to get comfortable with the idea of claiming backlog bankruptcy and reorganizing it. As a PM you need to be a ruthless prioritizer and this thought exercise is helpful to reconsider your product priorities. Your backlog is an important communication tool for the entire organization. It is not an idea junk drawer.?

Finally, sometimes it is fine to make a change that is just about improving your own process. Our devs and designers probably would have been fine to continue using our backlog process the way it was. However, as a PM you are allowed sometimes to shape some of the process around your personal needs. Just make sure you communicate those needs to your team before making too many changes.

This article first appeared on my personal blog [https://unproductive.blog/2020/04/29/claiming-backlog-bankruptcy/]