Using Checklists to Battle Backlog Bloat

In product development (as in life!), it’s much easier to think of things that need to be done than to actually do them. That’s one use of a backlog. You can store those ideas until you’re ready to work on them. But do this for a long time and your backlog can become bloated, making it difficult for the product manager to get a visual representation of future work.

There may be issues, and even epics, in your backlog that you know you’re not going to develop in the next few sprints - or maybe even the next few months. Rather than cluttering your backlog with all of those issues - why not store them in one place with a checklist?

Let’s say my company has a cloud app that we want to take to data center. We’ll have a lot of work to do; writing new code, testing, applying for data center approval from Atlassian, etc. Our goal is to have the data center app available by the end of the year, but before we can get started we’re going to need to expand our team.

Hiring takes time, so it’s easier for the Product Manager to see what’s going on if the backlog isn’t cluttered up with issue that we’re not going to start on for weeks or maybe even months. On the other hand, the team may have some ideas that they want to keep track of before work on the data center app actually starts.

Using a checklist allows you to collapse an epic into a single issue, until you’re ready to start developing it.

Later, when the PM decides that it’s now time to work on the topic (in this example the data center app), he/she can create an Epic and comb through the checklist items to see if they are appropriate stories.

A checklist item can be converted into an issue in a single click, allowing the PM to quickly build the Epic. For checklist items that aren’t appropriate, or aren’t ready, the PM can delete them from the checklist, or leave them for later consideration. This ensures that epic only contains stories that are truly ready for development.

Users can comment on the Epic and the PM may write new checklist items, or team members can add items to the checklist themselves.  The list format allows the potential stories to appear as individual items, rather than be lost or lumped together in the description field. However, they do not get made into issues until the PM determines that they will indeed be developed in an upcoming sprint.

This strategy keeps the backlog from becoming overwhelming. Sometimes, you can even delete stories in the backlog and regroup them into one story with multiple checklist items underneath it.

In a previous post, I compared a product backlog to a garden. Both require regular tending to optimize growth. Using a single issue with a checklist as a placeholder for future epics is sort of like doing successive plantings. When you’re planting your garden, you have to remember that you don’t want more than you can eat to be ready for harvesting at the same time.  In development, your PM doesn’t want more than can be visualized in the backlog at the same time. It’s better to stagger your plantings a few weeks (a few sprints) apart.