How can we create a good ticket that has all of the information needed to start working?

An important part of ticket management is the trade off between being technical and high level details. Let’s use an example of a ticket that is classified as a bug report. This ticket should have technical details to reproduce this bug. It should also have high level details for non-technical people to understand why it’s important.

When creating a ticket for a bug report, there are some things we can do to ensure it hits the mark of ‘well-defined’.

If there is an error tracking tool used such as Sentry, Bugsnag, Airbrake, link that. Consider also using the description from that error and relevant details such as:

• Specific code lines
• How many times it occurred
• Function/Method Arguments
• URL
• IP address
• User or organization IDs.

This information can help to reproduce, but also look through logs or more errors later on. It can also help for grouping similar issues.

Once we’ve included that, we want to describe the issue. What is happening? Why is this happening? What was done to prevent this in the past? What should be happening. That last one is very important, the opinion of the product owner/manager can help here too.

We want to attach similar tickets, like ones that introduced or attempted to fix this issue.

We want to include permanent links to the code in question, ones that won’t go away.

After this, we can fill out all fields related to this issue. There are likely some custom fields such as affected organization, affected service, etc.

Acceptance criteria (AC) are a vital part of this ticket. We have information on the background of the issue and what happened. Now we focus on what should be happening. Here, the AC should be descriptive enough to understand the action needed. It’s likely there will be more than one AC.