Managing a large project backlog

Question on Programmers.StackExchange.com:

Do you have any particular style of organizing projects? LINK

Edited copy of my answer:

First have each developer look at each of the items and review/test each item to see if it is still an issue (it may work best to split these up amongst people). Then close any that are no longer an issue or have already been taken care of with other development efforts.

Now make sure that each are marked as either a large, medium, or small development effort. This is a very rough estimate just used to more easily categorize the projects and to help to pull things together. If everything is already estimated then it will help but don’t get hung up on the hours. Just go with a quick gut check. It often works to get the develpers in a room and just go through each item and use the effort that the majority of the people feel is appropriate.

Review each of the three effort groups and mark each item in the group with a priority of Critical, High business value, High Technical value, Medium value, Low value, and Never going to fix.

By this point you really know the list inside out and really understand the work that is involved in your backlog and you can start to really make a decision on what to do with the items. Take all the items that are marked as never going to fix and archive them out of your backlog.

Now when you schedule the items to go into your next release you can use the critical and high importance items as the core of your release. Review the list of medium and low priority items and add in any that can be worked on at the same time as the other items in your list because the developers will already be working in that part of the system.

The list of items marked with medium or low prioity can be used as a list of things for people to work on when they have a bit of spare time or as training for new employees. I always find that it is nice to have one person on the team during every itteration working on these items and helping the rest of the team where necessary. This way you are still completing work on the current itterateion but have someone that is flexible and can help put out fires when needed but is handling the issues that wouldn’t normally get attention.

One thing that we found was nice was that between each itteration we had a short 2 week period where the entire team would only work on items that were marked with a small development effort. We would focus closing a large number of tickets in a short time.