How to manage an issue tracker's backlog

Question

We've been dutifully using Trac for several years now, and our "active tickets" list has grown to almost 200 items. These include bugs that are too low priority and too complicated to fix for now, feature requests that have been deferred, issues that have never really generated complaints but everyone agrees ought to be fixed someday, planned code refactorings and other design infelicities that we don't want to lose track of, etc.

As a result, with almost 200 of these issues, the list is almost overwhelming; it's no longer useful as a source of what needs to be worked on right now.

What's the best way to keep track of issues of this sort?

Part of the problem is that some of these issues are such a low priority that they may never get done. I hate to lose track of these items (similar to not wanting to throw something out of my house in case I might need it someday); do I need to throw them out regardless (by marking them as wontfix) and assume I can find them in the future if I ever do need them?

Answer 1

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 developers 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 priority 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 iteration working on these items and helping the rest of the team where necessary. This way, you are still completing work on the current iteration 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 iteration, 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.

Answer 2

Does Trac have a priority setting? Something like 1 for major show-stoppers and 5 or so for things that would be nice to have done sometime?

If you can sort on priority, you can disregard the lower priority stuff for now.

Answer 3

read: http://en.wikipedia.org/wiki/5S_%28methodology%29

Put them in the attic, wait a year, then move house. That is what I do.

Seriously if you are not going to fix it then forget about it. See Extreme Programming.

But For items about code. You could put them in a code review system, as minor observations. This system can be set up to flag up issues when that part of the system is edited. I found this did not work as co-workers, thought this is what was expected and did not address review observations.

The only way to do it is ruthless prioritisation. Do it now or don't bother.

Answer 4

This isn't really a version control question so much as a question of workflow and business priority. Tracking things that are known to be wrong is a good idea even if they are unlikely to "ever" be fixed has a few benefits. For one thing, it means that QA (if you have a separate QA team) knows not to log a new bug for it. Another benefit is that if a new issue comes up, but its root cause is due to one of these "we know about it but it's low priority" issues, any analysis on the fix is already tracked - which can make the newer, higher-priority version of the bug much easier to fix.

Another aspect of this is that there may be some leeway to tackle some of this work, either now or in the future. Maybe someday you'll get an intern, and can assign a few of the simpler ones to them as an introduction to get their feet wet in the codebase.

If the developers feel that these issues would be good to fix - for example, if they represent technical debt, and it would make the codebase easier to work with to have them fixed, but they have no business value - it might be worth discussing that with business stakeholders and seeing if an agreement can be reached where those backlog items do get picked up occasionally. I've seen scrum teams do things like block off 3-5 points of velocity per sprint for "technical backlog" items - this can require some political finessing depending on the relationship of the development team to the business stakeholders, but I've seen it work very well.

Answer 5

This really depends on a few things.

1. How large is the team: If the team is large enough you can assign tickets in a fashion that would allow the lower priority items to get completed.
2. How often do you do releases: If the release cycle is long enough you can get away with adding more things or holding off on a release until you have all the tickets resolved.