The qualities of a good Jira/Linear ticket
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 technical detail and high-level context. Let’s use a bug report as the example. It needs enough technical detail to reproduce the issue, and enough plain language for non-technical stakeholders to understand why it matters.
What to include in a bug report
If you have an error tracking tool like Sentry, Bugsnag, or Airbrake, link to the event directly. Pull in the relevant details:
- Specific code lines
- How many times it occurred
- Function/method arguments
- URL
- IP address
- User or organization IDs
This information makes it easier to reproduce the bug, search logs, and group related errors.
Describing the issue
Once you have the error context, describe the issue itself. Answer:
- What is happening?
- Why is this happening?
- What was done to prevent this in the past?
- What should be happening?
That last question is the most important. The product owner or manager’s perspective matters here too.
Link any related tickets, especially ones that introduced or previously attempted to fix the issue. Include permanent links to the relevant code, not branch-specific URLs that will disappear.
Fill out any custom fields your team uses: affected organization, affected service, severity, and so on.
Acceptance criteria
Acceptance criteria (AC) are the most important part of the ticket. The background section explains what went wrong. The AC defines what done looks like.
Each criterion should be specific enough that a developer can verify it independently. There will usually be more than one. Write them so anyone on the team can read them and understand exactly what needs to be true before the ticket can be closed.
In closing
Hope this helps with writing tickets that give your team everything they need to get started. A well-written ticket is one of the easiest ways to reduce back-and-forth and keep work moving.