Monthly Archives: April 2014

On issue tracking and ticketing

I often have to help clients set up a ticketing system, or wrangle an existing one into a more useful state. Here’s what I’ve learned.

The three key items of a bug report

The first and most important step is to educate the support team to ensure that any bug report has the following before it gets assigned to the development team:

  1. Steps to reproduce.
  2. Expected outcome.
  3. Observed outcome.

It is particularly important to describe the expected and observed outcomes, so as to flush out any differences in expectations that the developer might have vis-a-vis the users and testers.

As a rule, the development team should simply bounce back any tickets assigned to them that don’t include these three items, with a request for clarification. Some exceptions can be made, such as when collating reports concerning a bug that is proving hard to reproduce in the lab.

Severity ranking

I have on occasion seen ticketing systems where the severity choices were too subjective to be useful, my favourite example being “Severely affects user experience” versus “Slightly affects user experience”. A better approach is to base severity upon objective criteria.

Without further ado, here is a severity ranking based on objective criteria that has served me well.

  1. Security leak An attacker can see or modify data for which they are not authorised.
  2. Data loss Some data that the user created is irretrievably lost.
  3. Crash/Lockup The app crashes or stops responding to input and the user must kill it, but no data is lost.
  4. Showstopper Something is not fit for purpose and there is no acceptable workaround.
  5. Painful Something is not fit for purpose but there is a workaround.
  6. Not up to spec The expected behaviour per the spec doesn’t match the observed behaviour.
  7. Confusing The expected behaviour per the spec turned out to be misunderstood by real-world users.
  8. Annoyance The behaviour is as specified, but has been found to be annoying in practice by real-world users.
  9. Change request The behaviour is as specified, but we would like to modify or extend the spec for business reasons.
  10. Work unit A job that needs to be done, typically to facilitate one of the above or to pay off technical debt, but that has no user-facing impact.

Responsibility

A ticket with your name on it should be considered a responsibility: a to-do list item, a hot potato. If it is assigned to you, that means it is on your plate and you darn well need to do something about it, or follow a defined workflow to assign it to someone else.

It is vital that nobody should have a way to hide a ticket under the carpet.

It follows that it vastly degrades the utility of a ticketing system if it has dummy accounts like “Anonymous” or “Tester 1”. Don’t do that: it serves only to create a means to hide tickets under the carpet. Every account should refer to a named individual.

If somebody leaves, then their account is closed, all open tickets assigned to them are assigned back up to whoever they reported to, and it becomes that person’s responsibility to re-assign the tickets as seen fit. The “hot potato” principle.

Monitoring

Time pressure and human fallibility are facts of life. No ticketing system can help unless there is somebody actively monitoring it, prioritising tickets that need attention. Generally, that person is the project manager. If you’re a solo shop, that person is you!

Knowing when to give up

Some tickets are intractable, for a variety of reasons, and your time is limited. It’s a judgement call to know when to close a ticket as “Will not fix”, which I can only leave to you. I’ll simply say that sometimes it’s the right thing to do.