Skip to main content

Detail a technical ticket

Turn the reported problem into a shared understanding of the needed outcome. Add only what is relevant to this ticket.

Approved AI tools may help inspect current behavior, draft scope, and surface likely dependencies or dangers. Record only the conclusion the detail owner accepts. See Responsible AI use.

Prerequisites​

  • A triaged ticket that belongs to this team and is not a duplicate, deferral, or closure.
  • Access to the reporter, the current product behavior, or both.

Clarify the outcome​

Talk with the reporter, inspect the current behavior, or reproduce the problem as needed. Add the smallest useful description:

Current behavior:

Expected behavior:

Acceptance criteria:
  -

Scope:
  In:
  Out:

Dependencies:
  Tickets:
  Teams:
  Design:
  Infrastructure:
  Builder work:

Write expected behavior as observable acceptance criteria: conditions a later tester can pass or fail without reconstructing the report.

The dependency and scope lines are prompts, not mandatory fields. Omit empty or irrelevant ones.

Make dependencies actionable​

Detailing exposes known dependencies before technical research begins. Research may discover more and send the ticket back for another detailing pass.

  • Tickets: Link existing work or create a ticket for an independently owned deliverable.
  • Teams: Name the team and the decision, information, or deliverable needed from it.
  • Design: Link the relevant design or state the user-flow or interaction decision that is missing.
  • Infrastructure: Identify needs involving environments, permissions, deployment, data migration, storage, networking, or observability.
  • Builder work: Identify any configuration or implementation that must be completed in Builder rather than in the source-code repository.

State what the dependency blocks: research, planning, execution, submission, verification, or release. For example:

INFRA-123 — Provision the queue before the backend integration can be tested.

Avoid entries such as “needs infrastructure help” that have no deliverable or unblock condition.

Create a linked ticket when a dependency has its own owner or can be delivered and verified independently. Recording a blocker does not mean research must wait: research what is unblocked, and name the owner of what remains.

Expected result​

Someone unfamiliar with the report can explain the current and expected behavior and the acceptance criteria. Known dependencies have an owner or linked ticket, and the technical questions that remain can be researched.

If the outcome cannot be clarified​

If the reporter is unreachable or expected behavior cannot be agreed, name the missing decision, assign an owner, and keep the ticket in detailing. Do not invent acceptance criteria to unblock research.

Next: Research the ticket.