Integrate with Other Systems
Choosing a system with a flexible API makes it easy to integrate with other systems such as source control or the build system. Integrating systems increases transparency across the engineering process. For example, the tool should integrate with other code repositories, as well as the continuous integration (CI) server, and the project wiki to track an issue's progress into working software. Engineers can check-in new code to source control, and the issue tracker will pick-up on that update. The CI server can then update the issue tracker noting that the referenced issue has been built into working software. When related systems automate manual processes, everyone wins.
Categorize to Optimize
As an industry we've grown beyond bug tracking. It's now all about work management. We don't just fix bugs, we innovate through software. Some of that is writing new features. Other times, it's rearchitecting existing code. And yes, of course, we still fix defects. When we commit all of our work to our tools, we can see the entirety of what we do.
Modern work management tools can categorize issues by sprint, release, component, or theme, to name a few categories. In practice, it's much easier to implement related tickets at the same time. When issues are organized by component, it's easier to see all of the work that needs to be done in a particular area. The team can then plan when that work needs to be performed over the next several iterations, thus optimizing time spent in a certain area. Issues can also be categorized by priority. It's always helpful in retrospect to see which high-priority issues had to be dealt with in an unexpected way during an iteration.
One of the most important things to keep your issue tracker healthy is regular triage of incoming issues and grooming the backlog. Software is dynamic. Priorities change. Regular triage keeps the team in tune with the current state of the product. The backlog is the list of work that outlines the future direction of the product in priority order. When new feature requests or bugs come in, they need to be prioritized against all of the existing work. Keeping the backlog current gives the engineering team confidence that they are working on the highest priority items.
As a QA engineer early in my career, I hated closing bugs that were not fixed. A user reported i, so it must be relevant, right? At some level, yes; but feedback has a shelf life. As more and more issues get logged in the system, it becomes harder to focus on the issues that matter. Bugs that were filed five years ago are, generally speaking, less relevant than ones filed last week.
If an issue has no path to closure in the foreseeable future, close it. Closed issues are not lost. When closing an issue, always include a resolution so you can search it later. At a minimum, resolutions should include: fixed, will not fix, cannot reproduce, and obsolete. Obsolete issues those that are no longer relevant to the direction of the program. Product managers can then search closed issues in the same way that they search open ones. In the closed case, issues that got marked will not fix and obsolete represent real work that was deferred.
For years, companies have viewed the defect tracker as a tool apart. During the last decade, it’s become evident that the addition of feature requests has converted the tracker into a planning tool for team sprints and individual work. Thus, it is the central product for capturing project status accurately.
The guidelines I list here should help you move from a traditional siloed view of defect tracking to a broader view that enables team coordination, better planning, and improved delivery.