Single project, same issue type, multiple workflows for different teams.

[Eventbuizz]

We are working on a software development project and I want to create a customized workflows for my team considering different environments.

Here is my scenario

Development team:
Team pick an issue from "To Do" and move to "In Progress" after completion of work change status to "Resolved". Next step for them is to deploy task on development server so that QA team can pick and start testing on development servers. So there might be a status "Deployed on dev"

Possible statuses
Open, Reopened, In Progress, Resolved, Deployed on Dev, Deployed on Stage

QA Team:
After task is being deployed on development server, QA team can start their work and after successful testing on "Development server" they again need the relevant developer to deploy task on "Staging server". Means we need another status here "Deployed on stage" for development team.

Possible statuses
In QA, QA verified on Dev, QA verified on Stage, Ready for production, Deployed on production, Closed


I am doing R&D on how I can achieve this keeping different boards for both teams and different workflow and in my case same issue will be processed by both teams mean issue type is the same?

Or is there any other better way to implement this in JIRA?

[Ste Wright]

Hi @Eventbuizz 

Is this all within one issue? Or are multiple issues a possibility?

---

Single Issue

You'll need to use one Workflow in this instance - with hand-off points for the teams.

I do think this would be too many Statuses though - I'd consider...

• Splitting their Board views, so there's not too many Statuses in one view
• Consider using Sub-tasks for some of these tasks - for example...
  • In QA could be the status - and Verified on Dev, Verified on Stage would be sub-tasks
  • A similar grouping could be done for Deployed, and potentially Deployed on Production into Closed
• Look to simplify the Workflow where possible. You don't need every process step to be a status - especially if these steps are short-lived - for example...
  • Do you need Reopened? Couldn't the issue just go back to "Open"?
  • Do you need Resolved? Couldn't this be surmised from the issue being in "Deployed on Dev"?

---

Multiple Issues

This would allow you to have two different Issue Types (eg. Story and Test), and have two separate Workflows.

I'd make one of the two issues the master - and often this is the Story.

The Test would then be a linked issue, and would be done either in parallel with the Story, or whilst the Story remains in a "holding" status.

For example, Workflows might be...

• Story: Open > In Progress > Deployed > In QA > Ready for Production > Closed
• Test: Open > Dev QA > Staging QA > Closed

...and Stories would remain "In QA" until the Test is closed.

---

Let us know your thoughts!

Ste

[Eventbuizz]

Yes it's a whole project with multiple issues.

In your solution we will have to make tasks sync among two teams, like a task gets reopened then QA team will reopen their test task and also the relevant developer team task.

And what about the comments and communication, I think having parallel tasks is not an optimal solution.

[Ste Wright]

Hi @Eventbuizz 

It depends how your teams work, both options (single and multiple issues) are possible to implement.

For example, some testing teams will complete testing as multiple executions where a Story is reopened or delayed - so you'd have multiple QA issues. 

But if you don't think this would work that's fine - what are your thoughts on the Single Issue notes above?

Ste 

[Trudy Claspill]

Hello @Eventbuizz 

Are the teams using scrum boards or Kanban boar

Are you working with a Team Managed project or a Company Managed project?

The answers to those questions will impact your options.

A given issue type can have only one workflow applied to it a given project. You could consider having a primary issue that moves through the higher level statuses while having subtasks for each trams' work. However, even with subtasks for each team, you would have to have different subtask types to be able to have different workflows.

If you are working with Kanban boards for each team, then you could have one long workflow for the issue that progresses through each team's flow. You could then create kanban boards based on filters for each team, selecting the issues based on the statuses relevant to each team

If the teams are working with scrum boards this method won't work.

[Eventbuizz]

Hi @Trudy Claspill we are using scrum boards along with Company Managed project.

Right now I have a one big workflow covering both development and QA team but I find it inefficient.  As I have to add more statuses for each team based on environments and it will get even bigger.

[Matt Parks]

There are really only two options, so you have to determine whether it's more important to keep everything in the same issue (and issue type) with a complicated workflow or if you want to have separate workflows assigned to each individual issue type.

Jira doesn't allow you to have separate workflows for the same issue type within the same project.

At my company, we have a similar problem and we wanted to use a single standard issue type across all projects so we created a custom field that determines which 'path' of the workflow is taken, depending on which statuses each team wanted to use in the workflow.

[Trudy Claspill]

Hello @Eventbuizz 

Does all the work by both Development and QA need to be done to consider the issue complete at the end of a sprint?

Are you working with a Company Managed project or a Team Managed project?

I recommend you give some consideration also to reducing the number of discreet statuses you are trying to use. Do you really need to track the issue in each status you have specified? Do issues routinely sit in the Resolved status waiting to be Deployed to Dev? Do you need to track that an issue has been Deployed to Dev, but QA hasn't actually started testing? Is value added by tracking to that level of detail?

[Eventbuizz]

Hi @Trudy Claspill ,

Thanks for your questions, answers will help me to explain my scenario more in detail.

Yes I am using a company managed project and same issue is considered to be completed all the way from Open to Closed stages.

My software is a combination of different technologies, like PHP, Node, React, NextJs. You can say sub project or modules are in different technologies. So right now there is lot of time waste between team communication. QA have to confirm from dev team that particular issue is deployed on particular environment before they start testing.

I have multiple developer teams that work on different modules/sections/issues in parallel so yes issues remain in different statues.

In our case Resolved means developer has completed development on his/her local development machine. In order to deploy task on an environment there are specific steps, like deploying API changes, making builds etc. That's why I introduced new statuses to confirm task is deployed and ready for QA team to work on.

In recent past lots of cases happened where QA reopened the issue stating not fixed and upon checking found that issue is indeed fixed but not deployed on given environment. This wastes lot of man hours and I want to avoid it and make a crystal clear workflow where status clearly indicate current stage of issue in our development cycle.


Also our product is in production mode, so we have some fast paced improvements/bugs/support tickets from our customers along with regular development of new features.

I hope above explanation will help you to suggest a better solution to me.

Thanks