How many stories are in your team’s backlog? How many items are on the To-Do list? Count them.
If you’re like most other teams, the answer is: way too many.
What’s up with that? Why do backlogs only grow?
There are three forces at play here that are innocent on their own but create a diabolical interplay.
Creeping is the nature of scope
Before the whole Agile thing became mainstream, we had project managers guarding the scope. The idea was simple and flawed: scope was fixed and we needed a knight to fend off those that wanted to sneak in more work. Scope grows because complexity increases and we estimate overly optimistic. And because humans are generally bad at predicting the future.
Adding features is trivial
We’ve seen that BUFD doesn’t work and most companies have embraced this concept. Instead of analysis documents, we’re drafting quick User Stories. Adding a feature to the scope used to require in-depth research and loads of prose. Adding a new Story takes a minute. I see places where they even capture “ideas” in the backlog.
Too many waiters in the kitchen
Software development these days involves plenty of stakeholders, users and “business people”. That’s a Good Thing ™. But often, the kitchen is overcrowded. The wait staff is adding order after order and the cooks can’t keep up. There is still the prevalent mindset that Business orders stuff and IT builds it. Adding more Business equals adding more orders.
This makes for a highly combustible mix. Not only does the list grow, but most items are added by those who aren’t going to build them. There is no penalty for adding another quick ticket to the backlog. I often see these “idea committees” that churn out vague JIRA tasks.
Those that take up the Project Manager role have no more tools to fend off the extra load. There are no Change Requests in Agile. Sure, they can keep tickets out of a sprint, but keeping them out of the backlog is difficult. Every idea, no matter how old and vague, is somebody’s baby. People are overly invested in the nice-to-haves they came up with. So we keep them in. Just in case.
We have Business people churning out JIRA tickets, a PM that doesn’t get to say No and a dev team with naturally limited capacity. The never-ending backlog is inevitable.
Unless…
The backlog should be a tool for the development team. It’s not a Product Breakdown Structure. It’s not The Scope. It shouldn’t be a roadmap for all kinds of features that we might want to build one day.
Here are some guidelines for a healty backlog.
- Keep it clean. Everything that’s in there is going to be built in the short term. No vague ideas. No nice-to-haves. Throw away what isn’t a high priority anymore.
- Keep it proportional. If your team delivers 3 tickets per sprint, 40 tickets are half a year worth of backlog. That’s crazy.
- Keep it short term. There is no need to cram more than two months of stuff in a backlog. Ever.
- Keep it private. Only the team should work on the backlog. The more people are involved, the more it becomes a never-ending wish list.
- Aim for Backlog zero. A to-do list that never gets depleted is a demotivational hamster wheel. Allow your team to finish the backlog a few times per year. Bake cake when that happens.
We’re all in favour of transparency and stakeholder involvement, but ideas are cheap. Give your teams the tools to focus on those features that do matter.