Who should write the Jira ticket a frontend developer builds from?
A screenshot and a one-line title is not a ticket, it is a bet that nobody will ask about the empty state. Who should actually draft frontend tickets (product, tech lead, or the assignee), how much detail is realistic on a team trying to ship fast, what a good one contains, and how it should get validated before anyone starts building.
A ticket lands in the sprint: one screenshot, a title, and "match the design." The frontend dev who picks it up can see what the happy path looks like at one viewport, in one state, with fake data that never truncates. Everything else, loading, empty, error, what the icon does on hover, what happens at 320px, is a guess made under a deadline. Multiply that by a team shipping fast and "the ticket was unclear" stops being an excuse and starts being the actual root cause on the incident timeline.
A screenshot specifies one pixel-perfect moment. It says nothing about every other moment the screen will ever be in.
Who should actually write it#
The honest answer is that no single role has the whole picture, so no single role should be the sole author. Product knows why the work matters and what outcome counts as done. A tech lead knows what is risky, what already exists to reuse, and what sequencing avoids a rewrite next sprint. The assignee, once they actually sit down with it, is the one who finds the questions the other two did not think to ask: what does this icon do when there is nothing to click, what's the copy when the count is zero.
In practice this rules out two common failure modes. A PO writing tickets alone, with no technical input, produces tickets that are clear about the business goal and silent on every state that goal touches. A frontend dev writing their own ticket from a design file, with no product input, produces tickets that are technically thorough and occasionally solve the wrong problem, because nobody who owns the "why" reviewed it. Neither should happen in isolation. The assignee should always be able to push a ticket back before starting, that right matters more than who held the pen first.
What a screenshot alone leaves out#
This is the concrete version of "unclear," the list of decisions a picture cannot make on its own. None of these are exotic. All of them are the kind of thing that ships wrong, gets caught three sprints later, and gets filed as a new bug instead of traced back to the ticket that never mentioned it.
Icons are the sneaky one. A screenshot shows an icon at rest. It does not say which icon library it came from, what weight or size, what it looks like disabled, whether it needs a tooltip, or whether it is decorative and should be hidden from a screen reader versus interactive and needs a label. A dev fills that gap with whatever is closest at hand in the codebase, and the fill is invisible in review because the screenshot still matches.
How much detail is realistic when a team is shipping fast#
Full detail on every ticket does not survive contact with a real roadmap, and pretending otherwise is how "process" gets a bad name. The fix is not more documentation everywhere, it is matching the effort to what is actually at risk. A copy tweak and a new money-touching flow do not need the same ticket.
| Ticket weight | Example | What it actually needs |
|---|---|---|
| Trivial | Copy change, spacing tweak | A sentence and a before/after screenshot |
| Small | New field on an existing form | Acceptance criteria, validation rule, one edge case |
| Standard | A new screen or flow | States, contract link, acceptance criteria, explicit out-of-scope |
| High-risk | Payments, bulk actions, permissions | All of the above, plus a QA/PO session before dev starts |
Most teams fail this not by skipping detail everywhere, but by using one shallow template for everything, so the payments ticket gets the same three lines as the copy tweak. Weighting tickets is itself a five-minute decision at grooming, not a new process to adopt.
What a well-specified ticket actually contains#
- Acceptance criteria in behavior terms. Not "matches the design" but "shows a spinner while loading, an empty-state message with zero results, and a retry action on error."
- Every state, not just the happy one. Loading, empty, error, partial, permission-denied, each named, not implied by omission.
- The real contract, linked. The actual API response shape or a
curlthat proves it, not a paraphrase of what someone thinks the backend returns. See what the backend owns, what the front end owns. - What is explicitly out of scope. The fastest way to stop scope creep mid-sprint is writing down what this ticket is not trying to solve.
- Who to ask. One name for a product question, one for a technical one. Silence is what makes a dev guess instead of asking.
How tickets get validated before anyone starts building#
Detail on paper is not the same as detail that survives contact with the person building it. A regular, short session, refinement, grooming, three-amigos, the name matters less than the habit, where product, a technical voice and ideally QA or UX look at the next batch of tickets together, catches more than any template. The question worth asking out loud every time is simple: could someone build this without pinging anyone? If the answer is no, that gap gets filled before the ticket enters a sprint, not during it.
This does not need to be heavyweight. Fifteen minutes twice a week covering the next five tickets beats a two-hour meeting nobody prepares for. The point is a fixed cadence that exists whether or not anyone remembers to ask for it, because the tickets that most need a second pair of eyes are exactly the ones nobody thinks to flag.
How tickets get tested once the work is under way#
Validation does not stop at grooming. A mid-build check-in, even an informal one, where the dev shows the actual states they built against the ones that were specified, catches drift while it is still cheap to fix. Waiting for a final QA pass to be the first time anyone compares the build against the ticket means every gap surfaces at the most expensive possible moment, right before ship.
- QA tests against the acceptance criteria, not the screenshot. If the criteria did not mention a state, that is a ticket bug, not a build bug, and it gets logged as one.
- UX reviews the states that were not in the original file. Loading and error states are usually designed after the fact, if at all. Someone should look at them before ship, not discover them in production.
- The assignee demos before calling it done. A five-minute walkthrough surfaces "wait, what about..." questions faster than any written checklist.
# definition of ready, before a ticket enters a sprint
✓ acceptance criteria are written as behavior, not "matches design"
✓ every state is named: loading, empty, error, partial, permission-denied
✓ the real API contract is linked, not paraphrased
✓ out-of-scope is written down, not assumed
✓ one name is attached for a product question, one for a technical one
✓ the assignee has read it and had a chance to push backThe honest bill#
- Writing states and acceptance criteria into every ticket is real time that does not show up as shipped work, and it competes with velocity metrics that only count the shipping part.
- A grooming cadence only works if it is actually protected on the calendar. The first sprint under deadline pressure is exactly when it gets skipped, which is exactly when it is needed most.
- Weighting ticket detail requires someone to make a judgment call about risk, and that call is sometimes wrong. A "trivial" ticket occasionally turns out not to be.
- None of this replaces trust. A team that argues about ticket quality every sprint has a process problem. A team that never argues about it has probably stopped noticing the gaps.