Thursday, 27 August 2015

Good ticket guide

I wrote this guide at $job-1 (where it seems to be still in circulation) and thought maybe it could be a useful thing to share further.

-----

We love a good ticket. It makes the job easier, it gets done faster, and it keeps everyone a bit happier. Here's a quick guide to what makes good tickets.

Describe the problem - not the solution

  • Whilst ideas about what might be wrong can be helpful, the absolute best thing you can do is describe the problem in its entirety

A descriptive ticket title

  • so that we can find your ticket at a glance

Relevant information and examples

  • If something is broken, then please outline how we can test it out for ourselves. How does it normally work? What happens now? When did it break?
  • If you need something changing, what is currently configured, and what would you prefer?
  • If you need something new, is it like anything that currently exists?

What’s the timescale?

  • Any indication of due dates, or potential blockers are useful
  • Set the ticket priority as appropriate
  • If it’s urgent, it’s usually best to log a ticket and then come over in person

What’s the value?
  • If something is broken or not working correctly, what is the impact to the business?
  • If the ticket is for some new infrastructure, what project is it supporting? 
  • Can you justify your request? How does it fit into the organisational priorities?
  • This information helps us do the most important tickets first.

Other helpful things to include:

  • Error messages
  • Screenshots
  • Example URLs

What not to include:

  • A direct set of commands to run without a full explanation of the problem. 
  • You don’t need to say thank you! At least not on the ticket, as this re-opens closed tickets. You’re welcome to come and say thank you in person (or buy us a beer at the pub).