Jira Workflow and Status Design Audit
Check that statuses and transitions match how work really flows.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
Review our Jira workflow. Statuses and the transitions between them: [WORKFLOW_DESCRIPTION]. How work actually moves, according to the team: [ACTUAL_PRACTICE]. Issue types using this workflow: [ISSUE_TYPES]. Metrics we care about (cycle time, blocked time): [METRICS]. Maximum statuses: [MAX_STATUSES]. First describe the designed flow as a numbered list of how a typical issue travels from creation to done, with time in each status if I gave it, so I can correct your reading. Then go through five lenses: purpose of each status, ownership at each step, waiting and blocked time, rework loops, and reporting (which status changes feed which report or board column). Check for statuses nobody can explain, statuses that collect work, missing blocked or waiting statuses, transitions that skip review, and duplicate statuses. A status nobody owns usually means a handover nobody has agreed; suggest who should own it and what they must do before the issue moves on. Return a table with Status, Purpose, Problem and Fix, the smallest change that fixes each problem ranked by effort and benefit, a simplified workflow within the status limit, a before-and-after sketch in plain text arrows, and the reports or board settings that would change. Avoid redesigning the whole workflow unless the evidence demands it, and pilot larger changes on one project or issue type first. Workflow edits can affect existing issues, automation rules and integrations, so list who to consult and check the effect before publishing [VERIFY admin permissions].
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.
See an example result (fictional data)
Invented workflow with 9 statuses: Open, Triage, Ready, In progress, Code review, Testing, Blocked, Ready for release, Done. Average days in status over 40 issues: Triage 4.5, Code review 3.2, Testing 5.8, Ready for release 6.1. Two statuses, Triage and Ready, are used inconsistently; 15 percent of issues skip Testing. Proposal: merge Triage and Ready into 'Ready', keep Blocked as a flag rather than a status, and add a rule that release waits are visible. New workflow: 6 statuses. Pilot on one project for two sprints; measure median cycle time.
Illustrative only, made-up data. Your results will differ and must be reviewed.