Triage a technical ticket
Make the next decision quickly. Triage confirms the ticket's classification and assigns the work needed to understand it; it does not produce a full technical specification.
Prerequisites
- Permission to route work for this team.
- The reported signal in Jira. If it is unreadable, ask one specific clarifying question instead of rejecting it.
Make the routing decision
Answer:
- Is the problem understandable enough to detail?
- Is it a duplicate?
- Does it belong to this team?
- Are its type and priority appropriate?
- Should it become multiple tickets?
- Who owns detailing it?
Choose one outcome and follow its next action:
| Outcome | Use it when | Next action |
|---|---|---|
| Detail next | The signal belongs here and is clear enough to clarify outcome and dependencies. | Detail the ticket. |
| Split into linked tickets | Parts have different owners, delivery, priority, or blocking order. | Create the linked tickets, then detail each. |
| Request one specific clarification | One missing fact from the reporter blocks even a detailing pass. | Leave the question on the ticket and wait. |
| Move to another team | Another team owns the problem. | Transfer it; do not detail it here. |
| Link as duplicate | The same signal already exists. | Link the original and stop. |
| Defer | The problem is valid but should not start now. | Record why and when it may be reconsidered. |
| Close | It is not a problem this team will pursue. | Record why and stop. |
Defer when the work is real but not in the current window. Close when the report is out of scope, not actionable, or will not be done. Do not close a valid request only because the plan is unclear — that is a detailing or research problem.
Do not send a ticket back merely because it lacks information that the team can discover during detailing or research.
Decide whether to split the ticket
Split work when its parts:
- have different accountable owners or teams;
- can be delivered and verified independently;
- have different priorities or release timing; or
- must be ordered through a blocking dependency.
Keep one parent ticket for the shared outcome and link the resulting tickets.
Use a Sub-task when the child is part of the same owned outcome and will not be released on its own. Use linked tickets when ownership, delivery, or verification is independent.
Do not split work into frontend and backend tickets only because it touches both layers; split it when separate ownership, delivery, or dependency management makes the work clearer.
Expected result
The ticket has a confirmed type, priority, disposition, and owner for the next stage. If it was split, the relationship and blocking order between tickets are visible.
If triage cannot decide
Ask one specific question, name the owner of the answer, and leave the ticket in triage. Do not start detailing, researching, or coding around an unowned routing decision.
Next: Detail the ticket when the outcome is to proceed or split. Otherwise stop at the action in the table above.