Jira Workflow for Software Development: Best Setup, Examples and Practices for 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

A Jira workflow for software development is the path every story, bug and task follows from idea to production. When that path matches how your team really works, the board becomes a reliable picture of delivery: anyone can see what is blocked, what is waiting for review and what is ready to ship. When it does not, developers spend their time dragging cards, managers chase status updates and the reports say nothing useful.

Most of the Jira projects we inherit from clients have the second problem. Workflows grow one status at a time until nobody can explain them, and the same issue type behaves differently across teams. When we take over delivery as part of managed product engineering teams, cleaning up the Jira software development workflow is usually one of the first two weeks’ jobs, because every later metric depends on it.

This guide explains what a Jira workflow is, which workflow fits most software teams, five examples you can copy, how to set one up, how to automate transitions from GitHub, GitLab or Bitbucket, and the best practices and mistakes that decide whether Jira helps or slows you down. It applies to Jira Cloud and Jira Data Center.

What is a Jira workflow for software development?

A Jira workflow is the set of statuses an issue can be in and the transitions that move it between them. For software development, it models the life of a work item: from backlog, through coding, code review and testing, to release. Every Jira project uses a workflow, whether the team designed it or accepted the default.

The workflow is not the board. The workflow defines which states exist and which moves are allowed; the board is a view that maps those statuses to columns. You can have several boards on one workflow, and you can hide or merge statuses in a column without changing the workflow underneath.

The building blocks of a Jira workflow

Six components make up every Jira workflow, and understanding them makes it much easier to design a clean one.

Company-managed projects expose conditions, validators and post functions directly. Team-managed projects offer simpler transition rules for restricting, validating and acting on transitions. Both can be extended with Jira Automation.

Workflow schemes and issue types

A workflow scheme maps issue types to workflows inside a project. This is how a project can run one workflow for stories and tasks and a different one for bugs. Sharing one scheme across several projects is the main tool for keeping many teams consistent, which we cover in the scaling section below.

What is the best Jira workflow for software development?

The best Jira workflow for software development is the simplest one that still shows where work waits. For most product teams that means six statuses: Backlog, Selected for Development, In Progress, In Review, In QA and Done. Each status answers one question about the work, and each has an owner and an exit rule everyone agrees on.

Two rules make this workflow work. First, allow moves back: review and QA must be able to return an issue to In Progress without admin help. Second, keep “Blocked” out of the status list and use a flag instead. A blocked status hides where the work was when it got stuck, while a flag keeps the issue in its real column and still shows the problem.

How many statuses should a Jira workflow have?

A typical software team needs 5–7 statuses. Fewer than five usually hides review or testing, so work looks “in progress” for days with no signal about why. More than seven usually means statuses that describe people or departments instead of the state of the work. A useful test: if the team cannot explain a status in one sentence, or no issue has sat in it in the last month, remove it.

5 Jira workflow examples for software development

Different kinds of work need slightly different flows, but they should share the same backbone. These five Jira workflow examples cover almost every software team; copy the one closest to your process and adjust only what you can justify.

1. Basic workflow for small teams

To Do → In Progress → In Review → Done. This is close to Jira’s default and works for teams of two to five developers who test their own code or ship behind feature flags. Add a QA status as soon as a dedicated tester joins, otherwise testing becomes invisible.

2. Scrum workflow

Backlog → Selected for Development → In Progress → In Review → In QA → Done. Sprint scope lives in Selected for Development, and the sprint board shows the four working statuses. Burndown and velocity reports depend on Done meaning “meets the Definition of Done”, so never let issues reach Done before QA. Our guide to Scrum software development covers the roles and events behind this flow.

3. Kanban workflow

Backlog → Ready → In Progress → Review → Testing → Ready to Release → Done. Kanban teams care about flow, so they add a “Ready to Release” buffer and set WIP limits on board columns, for example three issues per developer in progress. Cycle time and the cumulative flow diagram become the main health signals. See Kanban software development for WIP-limit guidance.

4. Bug tracking workflow

Open → Triaged → In Progress → In Review → Verified → Closed, with resolutions such as Fixed, Duplicate, Cannot Reproduce and Won’t Fix. The extra Triaged step makes sure someone checks severity and reproducibility before a developer picks the bug up. Verified should be done by the reporter or QA, not by the developer who fixed it.

5. Feature and release workflow with UAT

Idea → Discovery → Ready → In Development → In QA → UAT → Released. This suits epics or client-facing features where a business owner signs off. It often runs on the epic level while stories inside it use the Scrum or Kanban flow. The UAT step mirrors the process described in our guide to user acceptance testing.

How to set up a Jira workflow for software development in 8 steps

Setting up a Jira workflow takes an afternoon of configuration but should start with an hour of whiteboard work. Design the flow on paper with the team first, then build it in Jira, then test it on a few real issues before switching everyone over.

1. Map the real process. Ask the team how a story actually moves today, including where it waits. Write down every hand-off: developer to reviewer, reviewer to QA, QA to release.
2. Choose statuses, not people. Name each status after the state of the work (“In Review”), never after a person or team (“With Anna”, “Backend”). Aim for 5–7.
3. Assign status categories. Put each status into To Do, In Progress or Done. Reports, roadmaps and the issue colour depend on this.
4. Draw the transitions. Allow every forward move you need and the backward moves for rework. Avoid “any status to any status” except for an admin-only reset.
5. Add only the rules you need. Typical ones: a validator that requires a linked pull request before In Review, a condition that only QA can move to Done, and a post function that sets the resolution on Done and clears it on reopen.
6. Create or update the workflow scheme. Map stories, tasks and sub-tasks to the main workflow and bugs to the bug workflow if you use one. Publish the scheme on a test project first.
7. Configure the board. Map statuses to columns, set WIP limits for Kanban, and add quick filters such as “Flagged” or “Assigned to me”.
8. Pilot, then roll out. Run one sprint on the new workflow with one team, collect friction points, fix them and only then migrate other projects. Write a one-page guide that explains each status and exit rule.

How should a Jira workflow connect to Git, code review and CI/CD?

A Jira workflow for software development should be driven by development events, not by manual dragging. When branches, pull requests, builds and deployments update issues automatically, the board stays accurate and developers stay in their editor.

• Link everything with the issue key. Put the key, for example PAY-142, in branch names, commit messages and pull request titles. Jira then shows the development panel with branches, commits, pull requests, builds and deployments on the issue.
• Use smart commits sparingly. With Bitbucket and other connected tools, commit messages such as PAY-142 #comment fixed rounding or PAY-142 #time 2h update Jira directly. Transition commands work too, but automation rules are easier to govern.
• Connect GitHub or GitLab through the official apps. GitHub for Jira and GitLab for Jira Cloud send development data and deployment information to Jira, which also powers the deployments view and release tracking.
• Report builds and deployments. When CI/CD posts build and deployment status, the issue shows whether its code is on staging or in production, and Done can mean “deployed” rather than “merged”.

This is also where the workflow meets your delivery pipeline. If you are still building that pipeline, our guide to CI/CD in software development explains the stages that should report back to Jira.

Which Jira workflow transitions should you automate?

Automate transitions that follow a predictable event and keep human judgment where a decision is required. A good rule of thumb: if the transition always happens when something else happens, a rule should do it; if someone has to decide, leave it manual.

Keep approvals, QA sign-off and UAT manual. Atlassian’s built-in AI features can now summarise issues and suggest next steps, but a status that represents a quality decision should still be moved by the person accountable for it. Automation is most effective after the workflow itself is clean; automating a messy workflow only makes the mess faster.

Jira workflow best practices: a 7-point checklist

The best Jira workflows share the same habits: few statuses, clear ownership and regular review. Use this checklist when you design a new workflow or audit an old one.

1. Keep it to 5–7 statuses and name them after the state of the work.
2. Give every status an owner and an exit rule written in the project’s one-page guide.
3. Make rework explicit with backward transitions instead of reopening tickets or creating duplicates.
4. Use flags and labels for side states such as blocked, needs design or waiting for client, instead of extra statuses.
5. Set resolutions correctly: every issue in Done needs a resolution, and reopening must clear it, or reports will count unfinished work as done.
6. Share one workflow scheme across teams that build the same product, and allow local variations only at board level.
7. Review the workflow every quarter using cycle time, time in status and the cumulative flow diagram.

These habits matter because tool friction is expensive. Atlassian’s State of Developer Experience report (2024) found that 69% of developers lose eight or more hours a week to inefficiencies, and unclear processes and status chores are part of that bill. For the wider set of tracking metrics, see our guide to software development KPIs and DORA benchmarks.

Common Jira workflow mistakes and how to fix them

Most broken Jira workflows fail in the same few ways, and each has a simple fix. The table below lists the problems we see most often when auditing client projects.

How do you scale Jira workflows across multiple teams?

Scale Jira workflows with a shared backbone and local freedom only where it does not break reporting. All teams working on one product should use the same statuses and status categories, so a portfolio view, a release plan or a cross-team dashboard means the same thing everywhere.

• One workflow scheme per product line, shared by all its projects, owned by one Jira admin or a small working group.
• One project with several boards when teams work on the same codebase: each team filters its board by component or team field while the workflow stays common.
• Local variation at board level: WIP limits, swimlanes and quick filters can differ per team without touching the workflow.
• A change process: workflow changes go through a short request with a reason, are tested on a sandbox project and are announced before release.
• Regular clean-up of unused statuses, custom fields and inactive workflows, which slow down Jira and confuse new team members.

The same principle applies when you work with an external delivery partner or extended team: they should work inside your shared workflow, not a parallel one. Our guide to managing software development teams covers the operating rhythm around it.

How do you audit a Jira workflow? A quarterly health check

Audit a Jira workflow every quarter by measuring where issues wait, not how many statuses exist. Three built-in reports are enough to find most problems, and the whole check takes about an hour.

1. Cumulative flow diagram. A band that keeps getting wider shows a bottleneck; a widening In Review band, for example, means reviews are the constraint.
2. Control chart or cycle time report. Look at the average and the outliers. Issues that take three times the average usually reveal unclear requirements or hidden dependencies.
3. Time in status. Statuses where issues sit idle for days are candidates for automation, WIP limits or a process change.
4. Unused statuses and transitions. Anything not used in the last quarter can be removed.
5. Team feedback. Ask which transitions people work around. Workarounds are the most honest signal that a workflow no longer fits.

Key takeaways

• A Jira workflow is a set of statuses and transitions; the board is only a view of it.
• The best Jira workflow for software development has 5–7 statuses, each with an owner and an exit rule.
• Copy one of five proven patterns: basic, Scrum, Kanban, bug tracking or feature with UAT.
• Use flags instead of a Blocked status, and always allow backward transitions for rework.
• Drive transitions from branches, pull requests, builds and deployments with Jira Automation.
• Share one workflow scheme across teams on the same product and review it every quarter.

FAQ

Published 30 October 2026. Sources: Atlassian Support, working with workflows; Atlassian Support, smart commits; Atlassian, Jira Automation; Atlassian, State of Developer Experience Report 2024. Workflow patterns reflect YuSMP Group delivery practice and are recommendations, not Atlassian defaults.