nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

All comments

Trudy P 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 P 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.

Screenshot 2024-04-14 at 1.47.49 PM.png

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.

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 P 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?

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management