How do you manage a large product backlog?

Asked 2008-09-20T19:49:40.803

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, ra

Edit Report

2 Answers

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.

answered 2008-09-20T21:18:22.230

Since you already are doing things in agile fashion, you could borrow some ideas from XP:

put all your stories in big pile of index cards (or some such tool)
now developers should estimate how big or small those stories are (here developers have final word)
and let client (or their proxy -- like product manager) order those stories by their business value (here client has final word)
and if developers think that there is something technical which is more important (like fixing those pesky bugs), they have to communicate that to client (business person) and make client to rise that priority (client still has final word)
select as many stories for next iteration as your teams velocity allows

This way:

there is a single queue of task, ordered by business needs
clients get best return for their investment
business value drives development, not technology or geeks
developers get to say how hard things are to implement
if there is no ROI, task stays near bottom of that pile

For more information, see Planning Extreme Programming by Kent Bech and Martin Fowler. They say it much better than I can ever do.

answered 2008-09-20T20:24:51.813

How do you manage a large product backlog?

2 Answers

Your Answer