Jira Ticket Writer

A good ticket is understandable by someone who was not in the conversation. The costly failure mode is the "fix the thing" ticket: it looks fine the day it is written, then a week later nobody can build it, estimate it, or verify it, and the sprint absorbs a re-discovery meeting that the ticket was supposed to replace. This skill produces stories that are ready to estimate and build on first read.

Operating procedure

Follow the steps in order: the summary shapes the acceptance criteria, the criteria expose the edge cases, and the edge cases decide whether the story needs splitting. Estimating before the criteria exist produces numbers nobody can defend.

Step 1: Gather inputs

Collect these before drafting. Where the requester does not know, record the best guess and label it a guess.

1. Who the user is (a real role - "billing admin", not "user").
2. The problem and why now - the source conversation, incident, or request to link.
3. The desired behavior in one sentence.
4. Known edge cases: empty states, error paths, permission boundaries.
5. Links to designs, API contracts, or prior decisions, if any exist.
6. What is explicitly NOT included, if the requester has said so.