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:
To Do: creating an Issue, to reflect a new task
In progress: start working on the issue
Done: when the work on the issue is finished
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.
The board was compact and consisted of 5 columns. This board has two new columns compared to the default one:
Blocked/Waiting for: when a developer couldn’t progress the work on a story and waited for feedback.
Verify: when the development work is reviewed or deployed, or when the story is tested.
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:
Analysis stages (left part of the workflow): includes additional stages for business analysis processes
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.
Open: every new created issue gets this status. This status indicates that the issue is raw and may only consist of a few sentences. Needs to be prioritized by the product owner so that it can be moved to the analysis phase.
Requirements analysis: when the issue is being analyzed by the analyst
Ready for Refinement: when the issue is analyzed and provided with full functional info
In Refinement: when the issue is being refined by the whole team. In this stage, the acceptance criteria are added and the story points are assigned
Development and QA stages
To Do: issue is refined, all functional and technical info (if applicable) is filled in, acceptance criteria is clear, and has story points
In progress: work has been started on the issue
In code review: development is done, pull request is made and code is being reviewed
Ready to build code is reviewed and pull request is merged
Ready for testing: code is deployed and can be tested
In testing: issue is being tested
Resolved: issue is tested, and no bugs were found
Done: issue is accepted and ready to go to production
Blocked during in progress: issue cannot be further developed. The developer is waiting for feedback to be able to progress in developing the issue
Blocked during testing: issue cannot be tested. The tester is waiting for feedback to be able to progress in testing the issue
Reopened: happens when there is a regression in relation to the issue or when QA fails
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”.
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.
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.
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 status “Open” was added to the “TODO” column of the “Delivery” board
A new transition “Send To Development” was added between “Open” and “TODO” to skip the analysis phase.
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 :).