Issue Trackers: An indispensable development tool

There is one application that a development team depend a lot on — to the point that it is accessed almost every hour: the Issue Tracker.

Before we go on the nitty gritty details of an issue tracker, let’s first discuss what an issue is.

What is an issue?

There is no simple answer, because every organization has its own definition. However, depending on your company’s methodologies, development cycle, and culture, an issue can be any (or all) of the following:

  • a bug
  • a feature
  • a change order
  • a requirement

In our organization, we define issue as a bug or an approved change order.

This has raised eyebrows from the most conservative project managers (PMs). However, we believe that this is necessary to provide a healthy balance between speed & process. Think about it: during crunch time, would you really expect the programmers & the QA team to constantly refer two tracking tools at the same time? Having one tool which keeps all to-do lists provides a simple yet workable system for a team.

What is an issue tracker?

From the name itself, an Issue Tracker is a system which lets you track the status of an issue. Its status can either resolved, closed, needs feedback, assigned, etc.

How does it work?

The workflow starts with a person entering an issue — he can be the project manager, a QA staff, the customer, or even one of the programmers.

The project manager or the QA then confirms it: Is really a bug, or a change order? If it is a bug, was he able to replicate it? Is the issue too vague that more information is needed?

After confirming the issue, it now has to be assigned — to designate the person responsible for it (usually the programmer). The project manager, QA, or even the programmer can assign an issue.

As soon as it is assigned, it is now included in the list of tasks of that person (“assignee”). It will keep on appearing in his to-do list, until he marks it resolved.

If an issue has been marked resolved, it is verified by the QA or the PM, and then is tagged closed.

Uses of the issue tracker

From this workflow alone, you can already guess the numerous uses of an issue tracker. It can be used to:

  • generate status reports
  • provide metrics on the rate of resolution
  • provide a basis for work breakdown structures for future projects

Issue Trackers

Numerous issue trackers are available, both commercial and freeware. If you want to go thru the open source route, there is Bugzilla, Mantis, dotProject, etc. Almost all project management applications already have an issue tracker built-in.

Things to keep in mind

In selecting an issue tracker, workability & acceptance is key. The tool must be something that your team is willing to work with. I handled an enterprise level project wherein we simply used Excel — because that was what the team wants to work with.

The biggest mistake of most PMs (this author included) is forcing a system she thinks is “cool” to the other team members. If, after a few weeks of using the tool, you sense reluctance from your team, take the hint. Reevaluate the different options available until you find one which works best for your team.

12 thoughts on “Issue Trackers: An indispensable development tool”

  1. I have been using Mantis for years and have implemented in many organisations, its a great tool – and not as complex and others mentioned. However, i recently discovered Eventum, developed by MySQL and used by MySQL – it mimics Mantis in many way, however i find that it has better reporting / charting capabilities , and those capabilities that are just being added to Mantis: Roadmap / milestones / advanced security etc.

    Take a look and try it out.

    dev.mysql.com/downloads/other/eventum/

    eventum.mysql.org/wiki/index.php/Main_Page

  2. Eventum looks okay. The problem is the setup. You need to put in a lot of crons before you can use it. I also get some weird errors in email. I am still playing with the parameters. Can\’t seem to fix it yet.

    Mantis setup was simpler for me. The user interface is a little confusing for the first-time user though.

  3. I agree that trackers should be simple and workable. We had a PM who insisted that we used a requirements tracker package from the same people who made PVC. The programmers got overwhelmed with the system, and took quite some time before the status of bugs were updated.

  4. Nothing wrong with good old Excel. Almost everyone knows how to update it. We use Bugzilla. Don\’t like it that much, though.

  5. Our former project manager used to put all bugs in little pink post its. She wanted to be cute. Some were even heart-shaped. Needless to say, noone did a lot of bug fixing … because that was her only copy of the bug ha ha

  6. I haven\’t tried Trac, but gosh, do I love the interface. I\’m planning on making my own issue tracker pretty soon. That\’s my next \”pet project\”

  7. I’ve used Excel, Trac, BugTracker.NET and BugZilla in the past and I have to say that Trac is my favorite of those. I’ve been meaning to try out dotProject but just haven’t gotten around to it yet.

    I was recently browsing around looking at different suggestions for issue tracking software (hence how I got here) and stumbled onto this website:

    http://svnrepository.com/

    It’s a hosted solution offering subversion trac as well as bugzilla (for the highest account). This offering caught my eye because it’s the first time I’d seen a hosted solution for issue tracking that wasn’t bundled with some larger service or specific to an open source account (like sourceforge or berlios). I’m going to keep looking around, but I’m considering trying them out.

  8. I haven’t experience with bugzilla but it seems to be big trouble if you are searching for user friendly tracking. Now i will try Mantis and Trac because we are switching and the moment to something better.

Leave a Reply to me Cancel reply

Your email address will not be published. Required fields are marked *