If you’re working on a software development team, it’s bound to happen! When building tech that solves hard problems, there’s a lot of work to do. We use as few tools as possible to manage the process so we can move quickly with great alignment. The backlog then becomes a place to put all the things. Eventually, the backlog becomes a daunting place to jump into. Even worse, we spend more time onboarding new team members to help them understand what is in the backlog, how it is organized, and why.
If the team cannot get the backlog to zero stories in 3 months (assuming nothing new comes in), it’s too big.
Let’s assume you have a team that is really on top of things. Most of the time, the backlog is regularly reviewed and the team has a few sprints of work that is refined, estimated, and ready to pick up. You have already cleaned up the backlog of anything that the business isn’t going to prioritize or isn’t valuable. But, it is still too big. Let’s dig in!
Will we do this in the next 6 months?
It’s incredibly hard to predict the future. Projecting what will be the priority a year from now (let alone three months from now) is work better served by roadmap documents or planning documents, not the backlog.
The way we would segment the work to be done in stories and the requirements with them are likely to change for work that far in the future. I recommend capturing the work in planning documents at the epic level. Note why the work is important and the desired outcome. Link to documentation or resources that capture the information you know today.
If you’re the Product Owner or Delivery Lead for the project, you may even want to note when you need to revisit this . Does this work correspond with a particular milestone or dependency?
Has this always been a priority and we never get to it?
For many reasons, valuable work can get put on the back burner with the hope of making the cut “next sprint.” It’s worth asking why but if it persists, maybe this is the right time to focus on this work. It can be valuable to the product team to remove the noise in the backlog that isn’t the team’s current focus.
One approach could be to keep a running doc of valuable work that the team can pivot to on a dime. High-value work that supports the long-term maintainability of the app and gets a quick win with customers, is a great candidate for a sprint goal or focus during peak vacation seasons. Instead of keeping it in the backlog, pull it in as needed.
Alternatively, consider layering your sprint plans with an intentional focus on features, maintenance, developer experience improvements, security, etc. This will take communication and alignment with business stakeholders but can be an approach where everyone gets a win.
Is the backlog work a placeholder?
Who hasn’t created a story as a reminder? “I’ll add more details before the next refinement session.” “This needs to be broken down but I don’t want to forget about it.” It’s well-intentioned but in a big backlog, this can create confusion.
Consider turning this work into a spike – a time-boxed story to investigate the work and recommend options or approaches to solving the problem.
If the story isn’t that big, keep it as a personal to-do until you have the information to fill in the story. This ensures the work in the backlog can be prioritized alongside other stories, there are no blockers, and we can describe the value or outcome clearly.
Is your backlog too big?
The goal for a backlog is to reduce the noise and increase the focus and clarity of the product development team. Not to mention, a lot of work happens before it makes it into the backlog so it can feel precious and hard to remove. When managed well, a clean backlog can galvanize a whole team in the same direction, resulting in closer communication, more collaboration, and greater throughput. Don’t be afraid to re-evaluate your backlog often as your team and product grows.