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 :)

Chaps

See also sqa.stackexchange.com/q/17385/8992 – Bartko

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.

Unskillful

I like this. How do you suggest we deal with the fact that the pile of stuff may have very different sized things in it? I mean, we're talking all the way from "move the wibble by 2 pixels" to "create a community web site"... – Chaps

Answer 2

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.

Kedron

Answer 3

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.

Gentilism

Answer 4

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

Rasla

Answer 5

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

Works

Though important from a developer's point of view, if the bug is minor, adding a new feature could get more people to buy the software which is more important to the company. – Rasla

Answer 6

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

Choreodrama

Answer 7

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.

Voltaism

Answer 8

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..

Ossifrage

Answer 9

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)

Bedrail