Your Backlog is a Hoarder House

A theme I return to a lot in my head is the difference in friction between "creating" and "destroying" work to be done. It's much much easier to dream up another thing to build, a new feature, heck even a new product than it is to actually make the thing. As such, most backlogs tend to be out of balance and hopelessly overloaded. This goes for both net-new development work and bugs.

How bad this is can range from subtle (there's just a big list of ideas we probably won't get to) to insidious (actual planning and design have gone into a project that you have no free capacity to assign to it. Or worse, it's been promised to some important stakeholder before you figured out who was actually going to do the work).

The cheaper and in some ways braver way to destroy some of that work is to admit you're not going to do it. Not just to yourself, but to everyone in the organization.

Prioritization

Over the years I've participated in approximately 1 billion meetings with the goal of deciding what the dev team should work on in over the next month/quarter/year. This usually starts with the making of a list. The list is all the things the team could possibly do according to customer support, advisory boards, the execs or anyone else in the company with an idea.

Then you try to rank the list with your favourite scheme:

• Weighted Shortest Job First
• ICE (Impact x Confidence ÷ Effort)
• RICE (Reach x Impact x Confidence ÷ Effort)
• Value vs. Effort Matrix
• MoSCoW
• Kano
• Eisenhower Matrix
• SWOT
• Risk vs. Reward Matrix
  ...etc. etc. etc.

These are mostly bullshit because they rely on made up guesses for the inputs (Impact: 7.5/10!) then do math on them and produce what looks like a scientifically determined order for the things you should do. But, like all planning exercises, the value is in the discussion and the act of going through the planning itself. You could probably bring a set of dice to the meeting and use that to generate the scores and still have a useful planning session as long as you talk through the results.

In smaller orgs the theatre is even more obvious. You often just end up ranking things in terms of the preferences of the founder/CEO/CPO/Most Important Person. The scoring either bends to their will or they just explicitly pick the order.

However you get there, you end up a ranked list! Hooray! B you mustn't stop there!

The most important step

The most important step is now culling the stuff they're not going to do. Like I said, it's really really easy to make a list of everything you could be doing. If the only way to get something off the list is to complete it, you've got a pretty big problem.

Now the trick becomes understanding your capacity. This is probably another area where dice could be useful as you likely don't have good, rigourous estimates for most of the stuff on the list at this phase. So, even if you know how much you can do, you probably don't know how much there is to do with any kind of accuracy. That's fine. Just do your best and try to keep in mind that some of the things you want to do are going to be harder than it looks and some might be easier. If you want to apply some form of rigour you could try to use T-Shirt size type estimates and match that to your historical velocity. You'll be wrong, but maybe less wrong than if you just straight up guessed.

Once you've figured out your cut line, you need to be clear. Everything below the line is not getting done inside whatever horizon your planning is taken. Don't leave it as a "nice to have if we get to it" or a "stretch goal". You need to ruthlessly destroy people's hope. Ninety nine times out of a hundred you're probably going to draw the line below too many projects anyway because of optism bias and the planning fallacy.

Do this with your bug backlog too

Most of the teams I've joined have had so many open bug tickets that when I did the math based on how many they typically closed in a week or a sprint that were more than a few days old (the 'fresh' ones that get closed right away are often about feature work in progress), the timeline for finishing them was infinite. Essentially, more tickets were being added than were being removed.

In those situations I usually pick an arbitrary cut-off (a couple sprints) and advocate for closing the tickets with some sort of "Won't Fix" status. This usually results in much wailing and gnashing of teeth. People really don't like admitting the reality that those bug tickets are not going to get fixed. And for some reason they assume that changing the status field on the ticket from "open" to "won't fix" is somehow destroying valuable information or something. The bug report is still there, you're just being honest about its status.

Your bug backlog should be a working queue, not a museum of defects.

Why does this matter?

Who cares if there are long lists of things we don't really do? What does it matter if the execs want to lie to themselves? It matters because a big backlog of features and bugs can make your team feel perpetually behind. Worse still, it gives your stakeholders that same impression. "Why is the dev team so slow" is a question I've been asked way too many times. I've even been asked it by a VP in their first week at the company. It's easy to look at a huge todo list and assume that whoever is responsible for doing the things on it must not be very competent or motivated.

It also has the tendency to encourage feature-factory style behaviors in execs. If you're always "behind" there's a strong drive to take the next item off the pile and start working on it because it makes the pile smaller. This comes at the cost of measuring the success or failure of the things you recently finished and iterating on them to make them better. Or worse, your existing team members get skimmed off your well formed teams in order to start a new thing with a new team. The fallacious thinking there being 6 teams of 5 will get more done in total than 5 teams of 6.

Free yourself and your teams.

Everyone I know who has gone though some sort of life event that required them to purge a lot of their stuff (moving, downsizing, divorce, etc) talks about how good they felt afterwards. A lightness comes over you when you shed the cognitive load your belongings silently put on you. The same is true of all of the work in your backlog. Be honest with yourself, your team and your stakeholders and you won't feel like you're carrying around a 80 pound backpack of undelivered promises all the time.

Don't worry, the important stuff will come back.

Image Credit: Baltimore Heritage - Public Domain - (Via Flickr)