With any bug tracker, the primary goals are two-fold.
- Capture and record bugs and issues. If they don’t get into the system, they can’t get fixed.
- Facilitate issue resolution. You can capture every detail in the world, but if it isn’t focused on accountability and forward progress, things still slip through the cracks.
So if a feature doesn’t make it easier to capture a bug or facilitate resolving it, then it can easily be more of a distraction than a benefit. It’s important to get one thing straight. Some teams do truly need some of these things. However, most teams do not.
A field for everything and everything in its field..
We receive a lot of requests for additional fields or custom fields. Web developers might ask for a browser and system field while iOS developers might want a system field but couldn’t care less about browser issues. Ultimately, the browser and system are only relevant for a handful of bugs and issues anyways. By adding extra fields, you’re creating extra friction for every bug even though there’s only a benefit for a small portion of the bugs. Always remember, extra fields means extra friction.
While some software projects are complex enough that they need an incredible amount of detail, the majority of projects just need to capture the basics. However, more often than not, people are so focused on being thorough, they fail to think about the big picture. You can always record additional data in plain text and search for it later. It doesn’t need to be stored in a custom field for that. If every field is important, then none of them are.
All data must be gathered up front.
While more data is usually better, a bug entered with only partial information is better than a bug not entered at all. Bug tracking is tedious enough, if logging a bug takes too much time or overwhelms non-technical users, they’ll avoid the system entirely. The result is bugs emailed or instant messaged to the development team instead of logged in the issue tracking system.
If someone is expected to provide every detail that you need up front, there will be times when they’re filling out information that’s simply not relevant. Logging bugs becomes tedious, and people begin to question why they have to provide a slew of data every time.
What’s truly valuable is making it as easy as possible to capture bugs. Sure it’s nice to have all of the data up front, but following with the opener or submitter is just as useful, and sometimes it’s even more powerful because it opens the dialogue and helps people get to the bottom of the real problem.
Everything needs to be very carefully and precisely classified and organized.
One could easily make a full-time job out of organizing and classifying issues. Our philosophy is that the only classifications that truly matter are the facets that answer the question, “What should I be working on at this very moment?” Status answers whether it needs to be worked on. Assignee answers who should work on it. Priority and milestone should be used jointly to determine the order in which the issues should be fixed.
There are dozens of other facets that could be tracked, but they don’t do as good of a job at telling you what needs to be worked on right now. Every additional field means one more filter, one more bit of data that needs real estate, one more detail that needs to be kept current and accurate. Before you know it, you’re spending more time organizing than you are fixing.
Dependencies and blockers must be closely monitored.
We get a lot of questions about how to put issues on hold or how to specify when an issue is blocked so that it’s out of the way. We feel this is risky. Just because it’s blocked doesn’t make it any less of an issue. If it’s open, it’s open. Brushing it under the rug just removes the constant reminder that another issue is in the way. By leaving it open, visible, and present, it serves as that constant reminder that something needs to be done.
If it’s truly out of your hands, and it’s somebody else’s fault, reassign it to them. It’s amazing how quickly people will take care of something if others are actively letting them know that they’re the bottleneck.
Summary
With issue tracking, it’s easy to get caught up in classification and organization. Unfortunately, there are some unintended consequences of over-organizing issues. For most small teams, it’s just as useful to make it easier to capture issues and worry about the details later. It’s not perfect in every scenario, but it keeps things simple and keeps the issue tracking process from becoming overwhelming.