How do you manage a large product backlog?

Answer 1

I'm not sure if the tool is as critical as the process. I've seen teams be very successful using something as simple as index cards and white boards to manage fairly large projects. One thing that I would recommend in prioritization is make sure you have a comprehensive list of these items together. This way you can weigh the priority of fixing an issue vs. a new feature, etc..

Answer 2

I think you have to get them all into one place so that the can be prioritised. Having to collate several different sources makes this virtually impossible. Once you have that then someone/a group have to rank each bug, requested feature and desired development.

Things you could prioritise by are:

• Value added to the product
• Importance to customers, both existing and potential
• Scale of the task

Answer 3

You should fix all the bugs first and only then think about adding new functions to it.

Answer 4

We set up a table with our tasks, their perceived difficulty in one column (lower is harder), and their value in another column (higher is more valuable). Multiply the two to get a quick look at your "bang for your buck". Start a third column with the time spent on each task, and you have yourself a nice "Burn Down" list.

Regardless, bugs first, features last.

Answer 5

A simple technique is to use a prioritization matrix.

Examples:

• http://erc.msh.org/quality/pstools/psprior2.cfm

• http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Also useful is the prioritization quadrants (two dimensions: Importance, Urgency) that Covey proposes: http://www.dkeener.com/keenstuff/priority.html. Focus on the Important and Urgent, then the Important and Not urgent. The non-Important stuff...well.. if someone wants to do that in their off hours :-). A variant of the Covey quadrants that I've used is with the dimensions of Importance and Ease. Ease is a good way to prioritize the tasks within a Covey quadrant.

Answer 6

Beyond any tool and process, there should be... some people ;)

In our shop, he is called a Release Manager and he determines the next functional perimeter to ship into production.
Then there is a Freeze Manager who actually knows about code and files and bugs (he is usually one of the programmers), and will enforce the choices of the release manager, and monitor the necessary merges in order to have something to test and then release.

Between them two, a prioritization can be established, both at high level (functional requests) and low-level (bugs and technical issues)

Answer 7

All of this stuff could be tracked by a good bug tracking system that has the following features:

• Ability to mark work items as bugs or enhancement requests
• Category field for the region of responsibility that the work item falls under (UI, back-end, etc)
• Version # field for when the fix or feature is scheduled to be done
• Status field (in progress, completed, verified, etc)
• Priority field

Answer 8

The key is aggressive categorization and prioritization.

Fix the problems which are keeping customers away quickly and add more features to keep the customers coming. Push back issues which only affect a small number of people unless they are very easy to fix.

Answer 9

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.

Answer 10

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.