You do not need a bug tracking system. In fact, a bug tracking system is a symptom of a deeper problem—insufficient focus on quality.
In general, I fix bugs the moment they appear—not in a drop-everything sense, but as soon as I can get to it—usually within a few hours, but sometimes in a day or two when I’m done with the current story. Of course, if I’m working in the code when I notice a bug, I just fix it right then. The software I write has no known bugs in it as a consequence (and yes, I never don’t use TDD and I always add real tests as I work—these are two different things). I can trust the code as I’m working, and I can verify that I haven’t broken anything as I work by running the tests every few minutes. Takes all the pressure off and radically improves development speed.
I don’t use a bug tracker because I don’t need to. There are no bugs to track.
I know that people who haven’t tried it will be skeptical that writing a bunch of tests increases your speed, but programming has never been about the speed at which you type. Time spent typing a test is nothing when compared to overall development time, which is mostly thinking. Having the tests in place eliminates all the staring-at-the-code-wondering-if-it-will-work time and lets you focus on the problem you’re solving rather than whether the code works or not.
If you have so many bugs that you need to track them, it seems to me that you have serious problems in the way you do development. Fix that first. You can start by throwing away every bug report older than a month. If it’s important, it will come back. Then distribute the bugs out to the teams. In other than a very small organization, the teams will need to work out some way to fairly route bug reports. Throwing dice works pretty well. Assign a number to each team. Throw the dice. You can round robin, too. The team can fix it whenever it’s convenient, but there should be an upper limit on that—a few days, maybe. If your stories are properly sized, that means you can finish the current story before you move to the bug fix. If you’re interrupting people, you’re doing it wrong. A bug is rarely a crisis.
Once the existing bugs are dealt with, fix your process so that the problem doesn’t arise again. Learn TDD and testing (two very different subjects), and make a rule that nothing gets pushed unless it passes all tests. Every bug is the absence of a test. When you find a bug, don’t write a report, write a failing test, then get it to pass. It’s not rocket science.
Finally, put aside the canard that you don’t have time/money to fix bugs and write the tests you need to prevent them. The higher the quality of your code, the faster you’ll work and the easier it is to make changes. (You cannot refactor safely without tests.) Defects are waste. The easiest way to increase profit is to remove waste. That bug database is just a black hole where essential work goes to die. Dump the database and do the work.
I brought this notion up over on Twitter, and there was an impressive amount of pushback from people saying that “in the real world” you can’t possible do this because there are so many bugs and you have to prioritize the work and you need a tracking system for that.
Putting aside the fact that there are real companies in the real world who successfully do exactly what I’m suggesting (e.g. Hunter Industries), I’d argue that the solution to the too-many-bugs problem is to change your process to one that doesn’t churn out such buggy code. When you use TDD, test-first development, continuous code review through ensemble/mob programming, merciless refactoring, plenty of automated tests, a CI/CD pipeline that runs them on every check in, a no-known-bugs-on-release policy—in other words, take agility seriously—the code won’t have very many bugs in it. As I said earlier, my experience as a CTO is that not doing all that is way more expensive than doing it. More to the point, when bugs come up once ever few months instead of of once every few minutes, a dedicated tracking system isn’t really required to manage them. Just fix them when you get a chance.
Also, basic Lean theory tells us that you need about 30% slack time in your schedule to handle the unpredictable. Working at “100% capacity” slows you way down. Think of a road at 100% capacity. We call that a traffic jam. Fixing an occasional bug is exactly what that slack time is for. When a bug comes up only every few months, finding time to fix it is not a problem.
Addendum to the Addendum
Most, but not all, bugs are amenable to a story approach. If the bug prevents a user from doing some bit of domain-level work, a description of that domain-level work is a story. You can put that story in the backlog in the normal way, sort it by end-customer value, and flush out the details just before implementation, all like any other story. No need for a bug tracking system, which will get that workflow backwards and not show you the other stories in waiting. The trackers collect details up front when the bug is reported, way before you’ll be working on the code. Of course, changes to the code that happen while the report gradually rots in the tracker could render those details (or the entire bug report) irrelevant. Best to delay capturing details until the last responsible moment, as you would with any story.
And of course, if a bug isn’t stopping a user from doing domain-level work, I would wonder if it’s worth fixing, so maybe those sort of bugs don’t need to be tracked, either. Solve those problems by just removing the code that contains the bug from the system entirely—a standard refactoring to remove unnecessary code.