Workflow and Statuses in Jira: Aligning Process Without Over-Engineering

Why workflows and statuses matter (and how they go wrong)

A Jira workflow is the set of statuses an issue can be in and the transitions that move it between those statuses. For project managers, the goal is not to model every micro-step of work; it is to make the flow of work visible, predictable, and reportable. Over-engineered workflows usually fail in three ways: (1) too many statuses that nobody uses consistently, (2) transitions that require too many clicks or fields, and (3) “approval” steps that do not represent real decisions, creating queues and stale work.

Use statuses to answer a small set of questions that stakeholders and the team actually ask: What is not started yet? What is being worked on? What is blocked? What is waiting for review/decision? What is done? If a status does not clearly change how people act or what decision is made, it is a candidate for removal or consolidation.

(1) Map current process steps to a small set of statuses

Start from reality, not from an idealized process

Before touching Jira, map how work actually moves today. Do this quickly with the team in a short workshop. Capture steps as verbs (e.g., “build,” “test,” “review,” “deploy”) and identify where work typically waits (handoffs, approvals, external dependencies). Then compress those steps into a small set of statuses that still preserves the key waiting points.

Recommended baseline status set (works for many teams)

• To Do: not started, ready to be picked up
• In Progress: actively being worked on
• Blocked: cannot proceed due to an impediment
• In Review: waiting for peer/QA/product review or a decision
• Done: meets the team’s definition of done

This baseline is intentionally small. It supports common reporting needs (cycle time, WIP, throughput, blocked time) without forcing teams to choose between 12 similar options.

How to compress real steps into statuses

Use this mapping approach:

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

• Group “doing” steps into In Progress unless a step represents a meaningful queue or decision point.
• Represent waiting explicitly: if work often waits for review, use In Review; if it often waits due to dependencies, use Blocked (or a flag plus a reason field).
• Keep “Done” strict: only use Done when the work is truly complete for the team’s scope, not “dev done” unless that is the only scope you track.

Example: mapping a messy process to a simple workflow

Suppose the current steps are: “Ready for Dev” → “Dev” → “Dev Complete” → “Ready for QA” → “QA” → “QA Complete” → “Ready for PO” → “PO Review” → “Approved” → “Ready for Release” → “Released”. If the team releases continuously and QA/PO review are the only meaningful waiting points, you can compress to:

• To Do (covers Ready for Dev)
• In Progress (covers Dev, Dev Complete, QA work if QA is part of the same team flow)
• In Review (covers QA/PO review waiting states)
• Done (covers Approved/Released if “released” is not a separate reporting requirement)

If “Released” is a required reporting milestone (e.g., regulated environments or release notes automation), keep a separate status like Released or use a Release/Deployment field and automation, but only if it changes decisions or reporting.

(2) Define what must be true to move between statuses

Status changes should be meaningful and consistent. The simplest way to achieve this is to define “entry/exit criteria” for each status and enforce only the minimum necessary checks in Jira. Think of this as lightweight governance: enough structure to keep reporting reliable, not so much that it slows delivery.

Define status meaning with a “status contract”

Create a short table that the team agrees on. This can live in a Confluence page, a Jira project description, or a shared doc. Keep it short and operational.

Practical transition rules: enforce only what protects data quality

In Jira, you can add validators/conditions on transitions (depending on your Jira edition and admin setup). Use them sparingly. Good candidates for enforcement:

• Require a resolution on Done: ensures completed work is measurable and searchable.
• Require a blocker reason when entering Blocked: use a required custom field like “Blocker reason” or “Impediment type”.
• Require reviewer when entering In Review: a field like “Reviewer” or use Components/Approvers if your process supports it.

Avoid enforcing fields that are frequently unknown at the time of transition (e.g., exact fix version early in the lifecycle), because teams will enter placeholder values that harm reporting.

Step-by-step: define and implement transition criteria

1. List transitions between your chosen statuses (keep it minimal: To Do → In Progress → In Review → Done, plus Blocked as a side path).
2. For each transition, write one sentence: “We move to X when…”
3. Identify the smallest set of fields needed for reporting and accountability (e.g., Blocker reason, Reviewer, Resolution).
4. Implement only critical validators (e.g., Resolution required on Done; Blocker reason required on Blocked).
5. Test with real issues: move 5–10 existing issues through the workflow and see where people get stuck.
6. Adjust wording and rules until transitions are fast and unambiguous.

Using statuses to signal blockers and review states (without creating a maze)

Blocked: status vs. flag

Teams often debate whether “Blocked” should be a status or a flag. A practical approach:

• Use a Blocked status if you want blocked time and blocked count to be visible in workflow-based reports and if blocked work should be excluded from WIP limits or treated differently.
• Use a flag (or label/custom field) if you want the issue to remain in its current status (e.g., still “In Progress”) while signaling an impediment.

If you choose a Blocked status, keep it as a side path: In Progress → Blocked → In Progress (and optionally To Do → Blocked for pre-start dependency issues). Avoid multiple blocked variants (e.g., “Blocked - External”, “Blocked - Internal”); capture the reason in a field instead.

Review: one status, multiple review types

Instead of separate statuses like “Code Review”, “QA Review”, “Security Review”, consider one In Review status plus a field that indicates review type. This keeps the workflow simple while still enabling reporting.

Example fields:

• Review type: Code, QA, Product, Security
• Reviewer: person or team
• Review outcome: Approved, Changes requested

This approach prevents the workflow from ballooning as new review needs appear.

(3) Add approvals/review stages only when they add decision value

Approvals are useful when they represent a real decision that changes risk, scope, or release readiness. They are harmful when they are used as a proxy for “someone should look at this eventually.” Add an approval/review stage only if it meets at least one of these criteria:

• Decision value: someone must explicitly accept risk or confirm requirements before work can proceed.
• Control requirement: compliance, audit, or contractual obligations require traceable approval.
• Queue visibility: work frequently waits at this point and you need to measure and improve it.

Approval anti-patterns (and what to do instead)

• Anti-pattern: “Ready for Review” and “In Review” and “Review Complete”
  Instead: use one In Review status; use comments or a field for outcome.
• Anti-pattern: separate approvals for every role (PO approval, QA approval, Dev lead approval) when they happen informally.
  Instead: keep one review status and define who must review in the issue’s checklist/criteria.
• Anti-pattern: approvals as a gate to start work when the team already has sprint planning or intake triage.
  Instead: use To Do with clear readiness criteria; manage prioritization in the backlog rather than with extra statuses.

Step-by-step: decide whether to add a review/approval stage

1. Name the decision: “What decision is made here?” (e.g., “Accept requirements,” “Approve release,” “Confirm test pass”).
2. Identify the decision maker: person/team accountable for the decision.
3. Define evidence: what must be attached/linked (test results, spec, risk assessment).
4. Choose the lightest implementation: a single In Review status plus required fields, or a dedicated approval status only if reporting/audit requires it.
5. Timebox the queue: define an SLA expectation (e.g., “Reviews within 1 business day”) and track it with filters/dashboards rather than adding more statuses.

(4) Exercise: simplify a sample workflow while preserving reporting controls

Sample workflow (over-engineered)

Backlog → Selected for Development → Ready for Dev → In Dev → Dev Complete → Ready for QA → In QA → QA Complete → Ready for PO Review → PO Review → PO Approved → Ready for Release → Scheduled → Released → Closed

Assume the PM needs reporting on: (a) lead time from start to done, (b) how much work is blocked/waiting on review, (c) what is released vs. not released.

Your task

1. Circle statuses that represent the same state (e.g., “Ready for QA” vs. “QA Complete” may be redundant depending on how QA is performed).
2. Mark true decision points (e.g., PO approval might be a real decision; “Scheduled” might be a release milestone).
3. Identify waiting points that you want to measure (review queues, release queue).
4. Propose a simplified status set of 5–7 statuses maximum.
5. Define entry/exit criteria for each remaining status (one line each).
6. Decide how to represent release: status vs. field (e.g., keep “Released” as a status if it is a key milestone).

One possible simplification (example answer)

To Do → In Progress → In Review → Done → Released

With a side path for impediments:

In Progress ↔ Blocked

How this preserves controls:

• Lead time: measured from first transition into In Progress to Done (or to Released if that is the true completion point).
• Waiting on review: everything in In Review is a visible queue; you can filter by reviewer or review type.
• Release reporting: Released remains explicit; if releases are batched, issues can sit in Done until deployed.

Checklist to validate your simplified workflow

• Each status has a distinct meaning that changes what someone does next.
• No status exists only to hand off work (handoffs are handled by assignment and clear criteria).
• Transitions are reversible only when it reflects reality (e.g., review can go back to in progress; done should rarely go backward).
• Reporting needs are met with the fewest statuses (blocked time, review queue, release milestone).
• Teams can use it without training: if people need a cheat sheet to pick a status, it is too complex.