Skip to main content

Agile Workflow process for Software development

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.

  1. Developer writes a piece of code
  2. Deploys it on a branch and communicates this to the tester
  3. 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.

Popular posts from this blog

User Stories Simplified!

User story writing guide
When I was introduced to the world of Agile, I kept on hearing the words  “User Story”. I couldn’t apprehend what it meant and how it possibly could be a fit for requirements management. This was all due to the traditional waterfall methodology which was omnipresent in most of the software projects. Early in my career we totally relied on creating massive amount of documentation which included but not limited to *Business requirements document Software requirements document High level design document Low level design document Use cases
 You can clearly see where the problem lies if you are planning on to maintain all these documents. On top of that, if you are working on mammoth projects, good luck with that!
How does user story  might prove to be user full?
First of all, User story is not a Silver Bullet but a convenient way to represent requirements. More precisely what a user intends to do.
In my case study, I am going to use example of “loremipsum” which is a social …


Many people in the software industry have heard about Agile. It is ubiquitous and can't deny the fact that it is redefining the way of how software is developed.
But most of the people do not know what Agile is not. Software developers who have worked in AGILE have their own definitions. Rather, every company / organisation has their own definition for AGILE [which is good and bad at times].
Looking at the last two decades when the software industry had begun its maturity, there were few methodologies for developing softwares. These methodologies were based on Process and Principles. A lot of focus was given to documentation which led to excess and result in efforts as well as maintenance. In Agile focus is more on delivering smaller piece of software which requires very less documentation. This means AGILE is not an excuse to producing documentation. It can be in various forms such as user stories, Epics, meeting notes etc.
Software professionals often mistake Agile as a process dri…