How Do You Design Jira Workflows for Complex Software Development Projects?

Question

What is your approach to designing Jira workflows that support code reviews, QA testing, approvals, and production releases without adding unnecessary steps? Do you use separate workflows for different issue types or a common workflow across teams?

I’m also interested in how teams structure workflows to improve visibility, manage dependencies, and maintain consistent development processes. [Promotional external content removed]

Lucija Maric · Accepted Answer

I think this really depends on the client's needs and how their teams work, so I wouldn't say there's one approach that fits everyone.

When working on something like this, I usually start with a few meetings with the client to understand their business needs, existing processes, and what they actually want to achieve with Jira. From there, we work together to define the necessary steps and build workflows that support those processes without adding unnecessary complexity.

In my experience, it's important to involve all relevant stakeholders from the beginning and agree on a set of standardized workflows that cover the different needs across teams. This helps avoid a situation where every team develops its own process, making it harder to maintain consistency, report across teams, and manage dependencies.

Once those workflows are defined, teams can choose the one that best fits their way of working while still following the agreed standards.

The goal, at least for me, is to find the right balance between standardization and flexibility. 🙂

Josh · Accepted Answer

Hi @Subhrajit Giri , here's the approach that has held up for me on larger software projects.

1. A status is a place where work waits, not an activity. Add a status only when work sits in a different queue or with a different owner: In Progress, In Review, Ready for QA, In QA, Ready to Release, Done. "Writing tests" or "Fixing review comments" belong inside In Progress, not as separate statuses. This one rule removes most workflow bloat.

2. One shared workflow for Story, Task and Bug. In company-managed projects, put them in one workflow scheme and share it across teams. Only give a work type its own workflow when its lifecycle really differs. Epics are a common example: they usually need just To Do, In Progress and Done.

3. Approvals as rules, not extra statuses. Instead of an "Awaiting approval" status at every gate, use transition conditions (only a release manager can move work to Ready to Release) and validators (for example, Fix version required before Done). For Jira Service Management requests, the built-in approval steps do this properly.

4. Let the tools move the cards. With GitHub, GitLab or Bitbucket connected, Automation can transition work when a PR is opened (to In Review) and when it's merged (to Ready for QA). Statuses then stay accurate without anyone dragging cards.

5. Releases and dependencies outside the workflow. Use Fix version and the Releases page to track what ships together. Use "blocks / is blocked by" links for dependencies, and view them on the timeline or in Plans. Avoid a "Blocked" status: flag the work item instead, so it keeps its real position in the flow.

6. Map statuses to columns. Boards can put several statuses in one column, so a team that only wants To Do / Doing / Done can have that, while the shared workflow still gives you consistent cross-team reporting.

A good test: if you can't name who owns the work in a status and what gets it out, delete that status.

Tomislav Tobijas · Accepted Answer

One thing I'd add is to avoid creating a separate status for every activity. 🙂 (although that's pretty obvious 😅)

I usually prefer introducing a new status only when it represents a meaningful change in the process, responsibility or reporting needs. Smaller activities can often be handled through subtasks, checklists or automation.

It makes workflows much easier to maintain in the long run.

Btw, MCP recently introduced new permissions to read and write Jira admin things, including statuses (I believe) — so my goal would be to simply ask AI first of what it would recommend based on existing configs such as workflows. 🤔 It could speed up the process extremely if you gave it your requirements + access to existing CIs 👀

Robert Hiles · Accepted Answer

One thing I'd add from experience is to resist modeling your process 1:1 in the workflow. Keep the workflow to the real handoffs (dev, review, QA, done) and handle the rest — checklists, approval conditions, notifications — with automation and issue fields. Separate workflows per issue type are fine, but shared workflows across teams save a lot of admin overhead when the actual steps are the same.