How do you manage a large product backlog? [closed]

Question

We have a large backlog of things we should do in our software, in a lot of different categories, for example:

• New problem areas for our products to solve
• New functionality supporting existing problem areas
• New functionality requested by our existing users
• Usability and "look" enhancements
• Architectural upgrades to the back-end
• Bug fixes

Managing all of these in a sensible fashion is a job that falls to Product Management, but it is tricky for a lot of reasons. Firstly, we have a number of different systems that hold the different things (market requirements document in files, bugs in a bug database, customer requirements in our help desk system, enginering's wish-list on our intranet, etc). And secondly, many of the items are of wildly different size, scope, complexity and of course value, which means that choosing isn't as simple as just ordering a list by priority.

Because we now are fairly large, have a complex product and lots of customers, the basic solutions (a spreadsheet, a google doc, a basecamp to-do list) just isn't sufficient to deal with this. We need a way to group things together in various ways, prioritise them on an ongoing basis, make it clear what we're doing and what is coming - without it requiring all of someone's time to just manage some tool.

How do you manage this in a way that allows the business to always do what is most valuable to existing customers, helps get new ones, and keeps the software innards sane?

Note that this is different from the development-side, which I think we have down pretty well. We develop everything in an iterative, agile fashion, and once something has been chosen for design and implementation, we can do that. It's the part where we need to figure out what to do next that's hardest!

Have you found a method or a tool that works? If so, please share! (And if you would like to know the answer too, rate up the question so it stays visible :)

Addendum: Of course it's nice to fix all the bugs first, but in a real system that actually is installed on customers' machines, that is not always practical. For example, we may have a bug that only occurs very rarely and that it would take a huge amount of time and architectural upheaval to fix - we might leave that for a while. Or we might have a bug where someone thinks something is hard to use, and we think fixing it should wait for a bigger revamp of that area. So, there are lots of reasons why we don't just fix them all straight away, but keep them open so we don't forget. Besides, it is the prioritization of the non-bugs that is the hardest; just imagine we don't have any :)

Answer 1

Managing a large backlog in an aggressive manner is almost always wasteful. By the time you get to the middle of a prioritized pile things have more often than not changed. I'd recommend adopting something like what Corey Ladas calls a priority filter:

http://leansoftwareengineering.com/2008/08/19/priority-filter/

Essentially, you have a few buckets of increasing size and decreasing priority. You allow stakeholders to fill them, but force them to ignore the rest of the stories until there are openings in the buckets. Very simple but very effective.

Edit: Allan asked what to do if tasks are of different sizes. Basically, a big part of making this work is right-sizing your tasks. We only apply this prioritization to user stories. User stories are typically significantly smaller than "create a community site". I would consider the community site bit an epic or even a project. It would need to be broken down into significantly smaller bits in order to be prioritized.

That said, it can still be challenging to make stories similarly sized. Sometimes you just can't, so you communicate that during your planning decisions.

With regards to moving wibbles two pixels, many of these things that are easy can be done for "free". You just have to be careful to balance these and only do them if they're really close to free and they're actually somewhat important.

We treat bugs similarly. Bugs get one of three categories, Now, Soon or Eventually. We fix Now and Soon bugs as quickly as we can with the only difference being when we publish the fixes. Eventually bugs don't get fix unless devs get bored and have nothing to do or they somehow become higher priority.