Gratis demo

Developer? Do you use Scrum and Jira? Check this Jira workflow + boards

Azzeddine Daddah

If you use Jira, you surely don’t use it only as a bug-tracking system, but you may also use one of its other components to ease your software development. This article is meant for the development teams who use Scrum and Jira and maybe want to try a new proven workflow. I’ll share the Jira workflow that we use for development for a project of one of our customers.

When I joined the development team, one of the things that I’ve noticed, which could be improved, is how the sprint process cycle was. We worked in sprints of 2 weeks according to the Scrum cycle: planning → sprint → demo → retro. We did 1 refinement session of 1.5 hour each week. But often, the 1.5 hour wasn’t enough to discuss the stories planned in the refinement session and we had to plan another session to further refine the remaining stories. Also it was not always clear beforehand which stories will be refined during these sessions.

Firstable, what are Jira Workflows?

A Jira workflow is the way how tasks and processes are managed in Jira. A workflow maps out the steps and statuses that a task can go through and defines process. The easiest and basic known workflow is the default Jira workflow. It consists of 3 stages: 

  1. To Do: creating an Issue, to reflect a new task
  2. In progress: start working on the issue
  3. Done: when the work on the issue is finished

Old Workflow

In the old situation, there were a lot of statuses which could be assigned from any state to any other state. There were no transitions defined but also no validators. So as a user, you were free to assign every possible status to your story – which was fine.

Old Jira workflowOld Board

The board was compact and consisted of 5 columns. This board has two new columns compared to the default one:

  1. Blocked/Waiting for: when a developer couldn’t progress the work on a story and waited for feedback.
  2. Verify: when the development work is reviewed or deployed, or when the story is tested.

Old Jira board

As you can see, when an issue has reached the “Verify” column, you didn’t have any clue what the status of the issue was. Is the code being reviewed? Is the story deployed? Is it being tested? Those questions could only be answered if you ask the assigned person, if the issue had an assignee.

It was doable for me to continue using this process, but I thought we as a team can do better! That’s why I’ve proposed to come up with a new workflow which I first presented and discussed with the team, got the feedback and processed it.

The New Workflow

The new workflow version is a workflow which helped our development team to adopt the best software development practices. It also helped the whole team (product owner, analyst, tester and developer) to get a better insight of the backlog and sprint.

It helped the business analyst to get a clear idea about which issues should be picked up for analysis, and in which analysis phase a certain issue was.

It didn’t only helped the product owner to easily see the progress of the current sprint, but also it helped her to pre-plan the future sprints.

 The new workflow consists of 2 stages:

  1. Analysis stages (left part of the workflow): includes additional stages for business analysis processes
  2. Development and QA stages (right part of the workflow): includes development and QA stages processes

So, let’s go and explain each step of this workflow.

Analysis stages

Development and QA stages

From 1 to 2 boards

In the old situation, we had one board “Sprint board” which includes a backlog. We used this board for the daily standups and during the development. Refinements and planning were done in the backlog.

The new workflow introduced 2 boards “Discovery” and “Delivery”.

  1. Discovery: a Kanban board which is used during the analysis phase. This board gives the team a clear overview of the upcoming stories next sprint(s). Every story that reaches the “Ready for implementation”, will automatically appear in the sprint board backlog. In this backlog, the product owner can plan and manage the upcoming sprints.
  2. Delivery: a sprint board which is used during development and QA. This board gave us, as a team, a clear overview of the progress of the sprint we’re working on. You can easily, for instance, tell whether a story is waiting to be tested or is being tested.

Discovery board
Discovery board

Delivery board
Delivery board

We cannot quickly create an issue and see it directly on the board

The first week when we started using the new board, a question raised: I’m not able to create a support issue and see it directly on the board. Why do I have to go through all those workflow steps (Analysis stages) to get this done?

After some discussion with the team, we agreed to make the transition between the status “Open” and “TODO” possible without going through all the analysis stages for support or production issues that happen during the sprint.

The solution was not that difficult:


The new workflow and the new boards helped our team to get a better insight of the sprint process. It also helped us to better structure our refinements, planning and sprints. Does it also sound good for you? Don’t hesitate to try it out :). 

Azzeddine Daddah

Read all my blogs

Receive our weekly blog by email?
Subscribe here: