Is Defect Tracking Dead in an Agile World?

by Damon Poole

There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost. The problem of creating a defect inventory is completely orthogonal to the user of a defect tracking system.

A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from an issue tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.

Posted in: Agile, Best Practices

Leave a Comment (5) ↓


  1. Cory von Wallenstein January 6, 2008

    I’ve heard of folks say the same… from my experience, it’s often only when multiple reports in the issue tracking system come in that we have enough information to actually reproduce the problem and fix it. If we were to just dive right into the code on the first report of a problem, it would take multiple times the effort to fix the problem than if we were armed with a handful of scenarios that can be used to reproduce and isolate the problem.

  2. Scott Rosin February 8, 2008

    So, lets see… A bug gets reported, a programmer starts working on it. Then another bug is reported. The programmer writes it down on a piece of paper so he won’t forget it. Then another one is reported. The programmer, says to himself “Ya know, instead of writing all these bugs down on a piece of paper, I’ll put them in a database somewhere. And I’ll write a web interface to it so I can get the bugs at home too.” Thus a Defect Tracking System is born into an Agile World.

  3. Adele Adam March 28, 2012

    In our office Agile is often discussed. I’ve heard the office colleagues saying that pure agile does not deal much with bugs/issues/defects. So we have to manage bugs separately from agile. For this purpose we are using a tool Yodiz in our office for managing Agile and bugs in a handy way.

  4. Rob April 27, 2012

    I agree that a bug tracking system is very handy, mainly for tracking details about bugs.

    One problem though is that the system can over time become out-dated, full of hundreds of bugs that no longer exist. Working on new features we may remove old code (and hence bugs) or fix bugs without knowing and the system isn’t updated. Time then has to be spent confirming each bug and removing them from the tracking system. You can in effect created work for yourself that won’t make you any money.

    Arguably, if you have good enough reporting and feedback from your customers you shouldn’t need a bug tracking system. If something is really wrong, you’ll know and it’ll jump up the work queue as higher priority.

    I don’t believe in fixing a bug when you find one. It should enter the work queue like any other piece of work. Software is written by humans so there will always be bugs. Just make sure you’re getting on with the piece of work that will benefit your customer (and in turn your business) most.

  5. mark May 9, 2012

    Yes it was dead for me ! The most hard thing for me was to manage our bugs in our sprints but i just recently start using a new tool Yodiz and what i loved about it is that it allows you to add bugs in your sprints and releases and you can also associate a bug to user story this is one killer feature for me i think so it is the first agile project management tool which is allowing you to handle your issues in agile project and in your agile scrum

Leave a Comment

Anti-Spam Protection by WP-SpamFree