In one of my project we experienced instances of “Push vs Pull”. Confused? Teammates had to tell other teammates that they have done certain tasks or they had to ask for certain tasks.This creates a lot of confusion when you are working on medium to large size projects. These tasks are more like “I have pushed the code, please review it” or “You got some support tickets, and as a manager, you have to assign it to developer”
For smaller projects “Excel/Spreadsheet” worked fine. Issues can be tracked properly and is maintainable. But on medium to large size projects there are some set processes which need to be followed. These can be Linear processes where things mostly move in 1 direction or multidirectional.
You need some basic processes to make the project successful. Well begun is half done! The way you lay down your foundation, database structures, Infrastructure, the team and the development process gives solid direction to the project . I have been using JIRA since its early days and have seen it evolve. It’s an exemplary tool if used properly.
In this article, I am going to explain how JIRA workflow helps in streamlining the processes.
What is a workflow process in JIRA?
Consider that you are working on a small project where the team size is 2 developers and 1 Tester. Simple, right ? This is how the process will be.
- Developer writes a piece of code
- Deploys it on a branch and communicates this to the tester
- Tester tests it and gives a remark. If test passed, deploy to another environment else raise it as a bug and send it back to the developer. This is communication again.
Now the above steps are nothing but a process for your project. Every thing works in tandem initially.
A JIRA workflow consists primarily of Statuses, Transitions and Issues.
Statuses can be anything like Open, In progress, In testing, Done, Resolved, Closed.etc. An Issue will always have a Status. Based on this we search an issue/task. It could be like search something which is “In Progress” status.
When the issues or tasks move through these statuses they are called as Transitions. JIRA is highly flexible where you can create your own workflows based on your project needs.
Simply imagine the Workflow as a Subway map, statuses as Stations, Train as an Issue or task. The way train moves from 1 station to another is a Transition. This is how the workflow works
But how does the workflow help in defining the process?
Now you know what the workflow is, imagine this process applied to your project. For this we will take an example of a project. Let’s call it “ACME”. The stakeholders and the management team decides that they are going to use SCRUM as a development process for this project. There is a team of 8 which includes 2 Testers , 1 Product owner , 1 Scrum master and 4 Developers.
As the team size increases there is lot orchestration needed. It could be meetings, emails, chat tools etc. How do you make sure that you respond to each thing? In one of my project, the dev team mentioned that they had no idea if a feature is being tested and at the same time the testing team mentioned that they had no idea of what is being deployed so that they can start testing. We did get to know in the status meetings at times that a particular feature has been made available for testing.
So we decide to have a simple workflow.
There will be Issues like user stories, tasks, bugs and epics.
All the statuses are in Open state. When a developer picks up the task, he changes the status of the issue from Open to In Progress. Once he is done with the task, he changes the status to Ready for Testing. The testing team tests it and changes the status to Closed which means the code passed. Else the tester changes the status to Open again and tags it as a bug.
The best part is that JIRA is highly configurable so when you change the status, it gets automatically assigned to a defined person in the project or else you when changing the status can assign it manually.
Depending on your company processes/culture you can create the JIRA workflow.
Here is a sample workflow.