ActiveBlog

Getting Started with Issue Tracking - part 1
by

, July 8, 2009

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.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: ActiveBlog

Comments

2 comments for Getting Started with Issue Tracking - part 1
Permalink

The dividing line between feature request and bug can frequently be a thin one and is only really important to a developers ego rather than how good the software is.

For example take the Microsoft calculator. If I copy the following number 111111111111111111111111111111112 into Windows Vista's calculator program I get 11111111111111111111111111111111, clearly the wrong number. This kind of behaviour *could* cause extreme frustration with the customer. Now the developer would say, hey that's not a bug the design spec said only allow entry of 32 characters so this is a feature request.

Now for the sake of an example what if the calculator program had a tiny rounding error when you divided a specific number 1028 times.

The developer's mind the first one is a feature request, the second one is a bug, the developer feels good that the first one is not a bug and feels bad that the second one is "their fault". To the customers of the program however, the second issue could never occur or have no significance even if it did and the first issue could make the software unusable.

I feel the distinction between feature and enhancement is not important the importantance is to have a record of issues and effectively schedule these issues. I find by using the terminology bug and feature / enhancement leads to potentially unfair weighting of the importance of bugs over features.

Developers and their Managers feel their software should be perfect and so focus on bugs, the users of the software should be considered and issue tracking's main purpose of identify and scheduling issues should possibly avoid the use of the language of Bug / Feature as in many ways it is simply a waste of a field and can adversely distort the scheduling process.

I am sure any developer has experienced the situation when a customer says "when is this bug going to be fixed?" and has though, hey that is unfair "it's a feature by design". If you try to have some empathy you will realise hey maybe the design was "buggy" and the "feature" should also be considered a bug, just the fix needs to be applied further up the chain.

A program without bugs simply does not have enough features ;)

Permalink

[...] Getting Started with Issue Tracking [...]