Getting started with issue tracking is much more than deciding on a software application or hosted service. It requires taking stock of team and client culture to arrive at a smooth and productive workflow. In the first part of this 2-part post, we talked about starting with the basics of what your choice of issue tracking system offers and growing from there, as well as defining terms for describing issues consistently across the whole team. In this post, we’ll look at more high-level aspects of implementing issue tracking in your team’s practices.

Visibility

The subject of visibility in tracking issues is about how much you let your clients or customers see in the issue database.

If you’re running an open-source or public project, the decision is an easy one. Of course you need people to both see the issues that have been reported and to contribute their own findings and requests to the queue.

On a private project, the decision is more complex and comes down to knowing the relationship you have with the people you’re developing for. Let’s tackle the question in 2 stages: stage one is letting clients and customers see issues and their status; stage two is letting them add and modify issue tickets.

To decide if clients should see issue tickets and their status, ask yourself these questions:

Do your clients or customers ask for a lot of detail in how work is progressing, or only ask for periodic updates?
If clients like detail, chances are they’re just looking for reassurance, and being able to see that a ticket is logged for the fixes they care most about will go a long way towards giving them some peace of mind.

Do you receive input on bugs or feature requests from multiple people?

If you get feedback from multiple people, then you’re likely seeing duplicate issues. Enabling reporters to first search existing tickets before firing off an email can help reduce duplicate issues, but it won’t eliminate them altogether.

Assuming you’ve decided to let clients see tickets, now let’s figure out if they should touch them as well:

Do the bug reports and requests you get provide the right level of detail and clarity, or are they more like emails with a subject line saying “Help, it’s broken!”?
If clients and customers are giving you reports that pivot nicely into starting a fix or a productive conversation on how to proceed, then letting them file tickets and answer questions in the system can be a huge time-saver. It has the added benefit of allowing the reporting person to stay in touch with how the issue is being handled, and maybe even give extra guidance or details along the way.

Workflow
One of the most common causes of confusion in issue tracking doesn’t come when opening tickets but rather when closing them out. Make it clear to the team who comes next in the chain of handling issues, and what the criteria are for closing them. Some systems provide controls that only allow certain roles to close tickets, while others can mark them as resolved or ready for testing. Even in those that don’t, it’s important that the whole team plays by the same rules, or you’ll end up re-opening tickets and re-visiting bugs more often than you’d like.

As the team gets used to using the new system, you may need to gently divert them from the old channels that were used beforehand. If someone with the ability to create a ticket sends you an email about a bug, you’re going to have to ask them to add a ticket for it, or you’ll be back to dealing with email, as well as the new ticketing system.

Evolution
After you get rolling with issue tracking, schedule some time 2 weeks in and again 2 months in for a checkpoint meeting with the team about how the system is working for them. Making sure everyone understands that how you use the system can change with feedback will make the prospect of using it easier to get into.

In fact, you can create an issue category for process improvement, and invite everyone involved to log suggestions or points of friction in using the tracking system itself. That’s right, we can use the process and tools to fix what doesn’t work with the process and tools.

Conclusion

If there’s any part of good software development practices that defies a one-size-fits-all approach, it’s issue tracking. The right system for you will accommodate the idiosyncrasies of how your team works, while gently suggesting good practices to follow from its built-in business logic.