How do you handle ever-growing piles of issues to be resolved "somewhen"?

Question

We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?

Answer 1

These are good first contact bugs to fix for new developers that have just joined your company. Or for junior developers to expends their knowledge of the system.

If not, you can mark them "wont fix" if they are not serious enough to justify the time it would take to fix.

Answer 2

You should fix a bug only if the application is more valuable without the bug.

If a text field is misaligned and it takes three days to fix it, then the cost is probably too high and you should leave it. On the contrary, if the users cannot write at all into the text field then you should fix it, and quickly.

In general it is easier to fix an issue immediately after it has been discovered. If you let time pass, developers may forget how that part of the code works and fixing the bug will take longer and therefore will be more expensive.

Some companies don't write a line of new code if there are still bugs pending. Others don't bother until the testing phase before delivery.

In your company you are obviously letting to much time pass before fixing new bugs so they're accumulating. It is also bad for the morale of the team to see a huge list of bugs.

I suggest you to spend a day just to sort out the existing bugs, deciding the ones that are worth fixing and the ones that are not and assigning the ones to fix to the existing team members with the goal of resolving the issues before the next milestone.

Answer 3

In our issue-tracking, there is a status "time-barred". If an issue is several months or even years old, and no client urges or refiles the issue, then this status is used as the final status. This is not done automatically, but manually, whenever the managers ask us to clean up the open issues. During this process, it's also likely that some of the issues are fixed because they are easy to fix and/or relatively important (despite not being urged or refiled).

Answer 4

I don't use JIRA, I've got fogbugz at work but I'm sure this applies to most bug trackers. While writing this I realized that the way I work is more agile than waterfall, deadlines are not concrete for me and what matters is priority.

• If your boss cares about too many tickets being open just don't create the trivial ones in the first place. You should be prgamatic and not add any features/fixes that have no benefits. If it will make your life easier to polish some code or tweak the UI then sure, add it. Don't just make work for yourself by trying to fix minor flaws in the product, nothing is perfect.
• Put the unimportant bugs/features in the current milestone but under a low priority. If more complaints/requests are mentioned about the issue then you can bump up the priority.
• Close/resolve what you can as won't fix, can't reproduce, duplicate etc. Some bugs are too trivial to fix or they are feature requests that would take far too long. Sometimes you just need to tell the person requesting these fixes/features "No Sorry, we don't have time".
• Prioritise the bugs as required and have your ticket list sorted by priority and milestone.
• If they are not going to make the milestone then move them into a future milestone.
• If a ticket is dependent on some other ticket being completed then mark it as blocked or organise the tickets into a hierarchy so it's obvious that ticket-x and ticket-y are related.
• If a ticket requires some feedback from someone assign it to that person.

Ultimately you will always have a bunch of low priority tickets sitting about, but points above should help you minimize that.

Answer 5

We use JIRA, and have an additional resolution state called Suspended -- if a feature/bug is something that we just have to give up on for a while, it gets resolved as Suspended. That way it doesn't get mixed up with either the list of currently active issues that we have to keep our attention on, or the list of resolved issues that we know have been handled satistfactory, and it's still in the database.

The list of Suspended issues is something that I review periodically (but not very often) to reopen as necessary.

Answer 6

Not sure of the correct JIRA terminology, but consider putting an expiration date on each "ticket". If it has not been escalated, by feature needs or bug severity, to implementation within a certain amount of time, it probably wasn't that important in the first place. This should help automatically keep the pile trimmed. I often get tickets based on "wouldn't it be nice" or "this doesn't work perfectly like I want". If no-one else pushes enough for it, or that user doesn't have enough clout, it doesn't get done and I close the ticket after a couple of months.