In Jira Software, an Agile workflow is the sequential path a work item follows

In Jira Software, an Agile workflow is the sequential path a work item follows from creation to completion. It maps out your team’s real-world processes onto a digital Jira Board, ensuring full transparency, accountability, and tracking during iterative cycles.

Whether your team uses the structured Scrum framework or the continuous delivery of Kanban, the core workflow engine runs on the same underlying components.


Core Components of a Jira Workflow

Every workflow in Jira is built using three essential pillars:

  • Status: This indicates exactly where a task sits in the process cycle (e.g., “To Do”, “In Progress”, “In Review”).
  • Transition: The one-way link or action taken to move an issue from one status to another (e.g., clicking “Start Progress” or dragging a card).
  • Resolution: The ultimate reason why a task is closed (e.g., “Done”, “Fixed”, “Duplicate”, “Won’t Do”).

The Standard Agile Workflow Stages

By default, Jira uses a simplified three-step framework, but high-performing Agile teams usually build out custom statuses to mirror their cross-functional pipelines. A comprehensive Agile software workflow typically looks like this:

1. The Backlog

The master list where the Product Owner documents all upcoming feature requests, bugs, and requirements. Work here is represented as Epics (large bodies of work) and User Stories (smaller, user-focused features). Items sit here until they are prioritized and pulled into active development.

2. To Do (Selected for Development)

Issues committed to the current active iteration—like a 2-week Sprint in Scrum. These items are assigned to specific team members, estimation points are locked in, and they sit in the queue waiting for a developer to pick them up.

3. In Progress

The work is actively being executed. In software teams, moving a card to “In Progress” frequently triggers background Atlassian Automations, such as linking the Jira task to a live branch in a code repository like Bitbucket.

4. In Review / QA

The work is complete but requires validation. This stage is critical for peer code reviews, automated builds, and quality assurance testing. If a bug is caught, a transition can send the issue back to “In Progress”.

5. Done

The work successfully meets the team’s shared “Definition of Done” and is ready for release. Moving a card to this final column automatically strikes through the issue key, triggering a status of “Resolved”.

Structuring Work Across Frameworks

Scrum Workflows: Heavily time-boxed. Issues move sequentially from a groomed backlog into active sprints. Progress and performance metrics are measured via built-in Jira Agile Reports like Burndown Charts and Velocity tracking.

Kanban Workflows: Focused on continuous, fluid delivery. Instead of sprints, teams place Work in Progress (WIP) limits on individual columns. This visually exposes system bottlenecks immediately if too many tasks stack up in a column like “In Review”.

Workflow Best Practices for Teams

  • Keep it Simple Early On: Start with minimal statuses (To Do, In Progress, Done). Only introduce custom steps like “Design” or “UAT” when your team physically hits a communication gap.
  • Leverage Transitions Wisely: Define whether an issue can transition “From Any Status” or must follow a strict, linear progression.
  • Automate Repetitive Steps: Set up rules to auto-assign tasks when they change hands, or auto-close parent User Stories once all child subtasks hit “Done”.

In Jira Software, an Agile workflow is the sequential path a work item follows from creation to completion

Unknown's avatar

Author: Mark Whitfield

Welcome to my site! After graduating in Computing in 1990, I accepted a position as a programmer at a Runcorn based software house specialising in electronic banking software, namely sp/ARCHITECT-BANK on Tandem Computers (now HPE NonStop). This was before the internet became more prevalent and so the notion of enabling desktop access to company accounts for inter-account transfers and book keeping was still quite a cutting edge idea (and smartphones only ever hinted at in Space 1999). The company was called The Software Partnership (which was taken over by Deluxe Data in 1994). I spent 5 years in Runcorn developing code for SP/ARCHITECT for various banks like TSB, Bank of Scotland, Rabobank and Girofon (Denmark) to name but a few. I then moved onto a software house in Salford Quays for further bank facing projects. After a further 23 years in the IT industry and now a Senior IT Project Manager (both Agile and Waterfall delivery), I thought I would echo out my Career Profile in this corner of the internet for quick and easy access.

Leave a comment