Getting Started with Issue Tracking

Getting Started with Issue Tracking | ActiveState Blog

Got issues to manage? Most software teams do. They’re to-do lists
that get angry when they don’t get done, and they can make teamwork
flow through the day or end up in an unmanaged state. If your email
inbox is the only tool you’re using to track issues, you’re more likely
treading water than swimming. And it’s just that feeling that brings
many development teams to an issue tracking system to get a handle on
bugs and feature requests. With that in mind, we have a 2-part post of
guidelines for getting started with issue tracking.

Too Many Fields?

When you dig into your issue tracking tool of choice, you’ll likely see
a lot of fields. Just the thought of filling them all out for every
issue you log might make you think email isn’t so bad. But as the
Hitchhiker’s Guide says, “Don’t panic!” When getting started, look for
the fields that map comfortably to the way you and your team currently
talk about issue handling. Start with those, but keep the other fields
in mind as you work. As you get used to seeing them, you’ll likely find
good ways to incorporate them into the workflow.

Defining Terms

Without setting some definitions, you’d be leaving your team to bring
their own definitions to a system meant to get people communicating and
working together smoothly. There are 2 specific places where a strong
definition set from the start will solve a lot of uncertainty and
confusion, and maybe even prevent some arguments as you go forward.

Bug vs. Feature Requests

While this might sound like an easy and obvious distinction, it often
gets lost in moments of frustration, which are exactly the moments that
both bug reports and feature requests are born from. Making the
distinction clear in your charter for a new issue tracking tool will
help everyone understand these categories clearly.

• A bug is something that was asked for but doesn’t work in the way
  it’s supposed to. It can only be used to describe existing
  functionality, or something that the software does but does not do
  correctly. If it’s broken, it’s a bug.
• A feature request is a request for new functionality or a change to the way something in the software works.

Severity or Priority

Your issue tracking tool will use one of these terms to express ‘how
important is this issue?’. Some systems use both, and while that can be
useful, in most cases you will only need one or the other. When
reporting an issue affecting them, people are likely to see it as more
important than it really is in the grand scheme, because that issue is
topping them from getting things done. Some objective criteria can help
set some perspective.

I tend to favor the Priority label, and depending on whether an
issue is for a bug or a feature request, we’ll need different criteria
to evaluate it.

Bug Priority

• Urgent or Critical: The problem prevents the
  software from operating or key requirements from being met. People
  cannot do their work with an urgent or critical bug.
• High: The problem prevents key requirements from being met, but there is a workaround that will suffice in the short term.
• Medium/Normal: The problem does not prevent key requirements from being met and can be worked around or lived with in the short term.
• Low: The problem is an annoyance but is not preventing any requirement from being met.

Feature Request Priority

• Urgent or Critical: The feature is needed as soon
  as possible. Not delivering it will severely impact the relationship
  with clients or customers. Other work needs to stop to make this
  feature happen.
• High: The feature is strongly desirable and should be given priority, but does not disrupt any current work.
• Medium/Normal: the feature is nice to have and can be assigned into an upcoming milestone
• Low: The feature is nice to have and can be added to milestones with some time available.

Alternatively, you can use Severity and Priority to indicate
relative importance for users and developers respectively. For example,
end users could be allowed to set the Severity of a bug, but not the
Priority. Developers could then set the Priority based on the Severity
assigned by the user, while taking into account the development road
map, time constraints, and technical considerations.

None of these definitions are air-tight, and you’ll likely need to
reassign or discuss the priority of specific issues from time to time.
The important thing is that the whole team starts from the same page,
and over time you can refine the definitions to fit how you see the
world.

In the next post, we’ll look at considerations for getting started
with issue tracking for the team and client culture that your team
works in.

Getting Started With Issue Tracking - part 2 | ActiveState Blog

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.