Skip to main content

Technical ticket workflow

Use this method to move a frontend or backend ticket from an initial report to a production release. The work has two pathways:

  1. Prepare the plan — turn a bug, story, feature request, or customer request into a ready implementation plan.
  2. Execute the plan — once the plan is ready, split it into phases, then code, publish a branch, test, pass acceptance criteria, and deploy to production.

The reporter provides the signal. The team adds only the information needed for the next decision. Approved AI tools and MCP-backed agents may help find detail, scope, dependencies, dangers, and decision candidates; a named human remains accountable for what is recorded and built. See Responsible AI use.

This is the ticket-level path for engineering work. It sits under How We Build; it does not replace product discovery, design, or the go-live decision. These pages do not define how to operate framework agents. Follow the LogicBee AI coding guide for that.

Prerequisites​

  • Access to Jira, the current project-management system.
  • For pathway 2: access to the source-code repository, Builder when the change needs it, and the team's approved test environment.
  • For AI-assisted detailing or planning: a company-approved tool and the LogicBee guide linked above.

The specific test environment and production pipeline are team-owned. This workflow names the checkpoints, not a single shared URL or deploy command.

Scope​

This workflow covers frontend and backend tickets from the first signal through the Definition of Done.

It does not cover:

  • product discovery, concept exploration, or interaction design — use How We Build;
  • documentation defects in this repository — use the documentation bug report;
  • how to operate coding agents — use the LogicBee guide.

Pathway 1 — Prepare the plan​

Move the reported problem through triage, detailing, and research until the expected outcome, scope, dangers, accepted decisions, and known dependencies are clear enough to execute. Pathway 1 ends when the ticket meets the Definition of Ready.

Pathway 2 — Execute the plan​

Pathway 2 assumes the plan from pathway 1 is ready and can be executed. The Planning Phase owner first splits that plan into a phased approach. Then implement the current phase, publish the branches, run automated and published-branch tests, complete human testing against acceptance criteria, and release to production.

A ticket may return to an earlier stage whenever new evidence invalidates its current understanding or plan. Add only the information needed for the next decision.

What happens at each stage​

StageQuestion answeredResult
ReportWhat appears to be wrong or worth changing?A problem signal exists.
TriageShould we pursue it, and what happens next?The ticket is classified, prioritized, routed, and split if needed.
DetailWhat outcome, scope, and dependencies are needed?Expected behavior and known dependencies are visible.
ResearchWhat must we understand before choosing an approach?Important uncertainty and decision candidates are resolved or assigned.
PlanHow will we implement it, which data and contract decisions are accepted, and what are the dangers?The smallest credible plan meets the Definition of Ready.
Phased approachWhat ordered phases will carry those decisions?The ready plan is split into executable phases.
ExecuteIs the current phase implemented and locally verified?The code, Builder work, automated tests, and documentation are complete locally.
SubmitIs the work available for branch testing?Source-code and Builder branches are published and a pull request is open.
TestDo automated checks and published-branch tests pass?Branch tests pass and the pull request is ready for human testing.
AcceptDoes human testing pass the acceptance criteria?Review, QA, and UAT evidence support a release decision.
ReleaseIs the change in production and done?The change is deployed, observed, and closed against the Definition of Done.

Ownership​

Responsibility moves with the ticket:

Reporter: problem signal
Triage owner: classification, priority, routing, and splitting
Detail owner: expected outcome, scope, and dependencies
Research owner: technical understanding
Planning owner: approach, accepted decisions, dangers, and verification
Planning Phase owner: split the ready plan into phases that carry those decisions
Implementation owner: execution of the current phase, submission, branch tests, and evidence
Reviewers and testers: human review, QA, and UAT
Product: go-live decision with the required technical input

Every active stage must have one accountable owner. Other people may contribute, review, design, or deliver dependencies without making ownership ambiguous.

Keep the process proportional​

The stages stay the same; the depth changes with uncertainty and risk.

A contained, reversible bug may move through detail, research, and planning in a few lines on the same ticket, use a single phase, then ship with peer review and an easy rollback.

A customer-requested workflow, a cross-team dependency, or a difficult-to-reverse change needs stronger evidence: dependency tickets, named dangers, and the matching delivery risk tier. It may also require design work or an RFC.