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.