Refine a backlog ticket

A ticket is ready when an engineer who was not in the conversation can build it, a tester can verify it and nobody needs to ask the author what they meant. Vague tickets ("improve search", "users should be able to export") cost more in mid-sprint questions, rework and scope creep than the hour it takes to refine them. Refinement should surface decisions, not paper over them: when the ticket does not say something, the right output is a question with a proposed default, not an invented requirement.

Refine this ticket so it can pass the team's definition of ready.

Only if [PRODUCT_CONTEXT] is given:

Only if [DEFINITION_OF_READY] is given: Definition of ready: [DEFINITION_OF_READY] If no definition of ready was given, use: the user problem is clear; scope and non-scope are written; acceptance criteria are testable; dependencies are known; designs or examples are attached where UI changes; open questions are answered or have an owner; it is small enough to finish in one sprint.

1. Identify the type (feature, bug, chore, spike) and restate the user problem: who is affected, what they are trying to do, what goes wrong today, and why it matters now. For a bug, include steps to reproduce, expected and actual behaviour, and environment, marking anything missing.
2. Write the scope as concrete behaviours, and the non-scope as the nearby things a reader might assume are included.
3. Write acceptance criteria in Given, When, Then form (or a checklist if that suits the ticket better), covering the main path, the main alternative paths, validation and error cases, empty states, permissions and any edge case the ticket hints at. Each criterion must be checkable by someone who did not write it.
4. List open questions. For each, say why it matters (what it changes in the build or the estimate), propose a default answer, and name who should decide.
5. Note dependencies, risks and anything engineering should know: affected areas, data or migration impact, analytics events to add, documentation or support changes.
6. Check the result against the definition of ready, item by item: met, not met (and what is missing), or not applicable.
7. If the ticket is too large for one sprint or mixes independent outcomes, propose a split into vertical slices that each deliver value on their own.

• Do not invent business rules, numbers, designs or decisions. Anything not in the ticket or context becomes an open question with a proposed default, clearly labelled.
• Keep the original intent. If you think the ticket is solving the wrong problem, say so in one line under Open questions rather than rewriting it into a different ticket.
• Write in plain language a new team member could follow. No filler.

Refined ticket

Title: a short, specific title. Type: Problem: two to four sentences. Scope: bullets. Out of scope: bullets. Acceptance criteria: numbered. Notes for engineering: dependencies, risks, analytics, docs.

Open questions

Table: question, why it matters, proposed default, who decides.

Definition-of-ready check

Table: item, status (met, not met, n/a), what is missing.

Suggested split

Numbered slices, or "Not needed".