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; } } }

Best practices mutiple processes inside 1 workflow

Remi Arts

Hi,

Right now I'm using 1 pretty big workflow with stepts of different teams. Right now the first state has category "To do" and the last state "Done" and everything in between "In Progress". In actuallity there are a few moments that issues are waiting for the next person in the next team to take it on. So there should actually be multiple cases where the state category goes from "Done" back to "To do". The only issue here is this messes up the progression of a release/sprint and makes that unusable.

Is there a different/better way to do this? I've looked into making seperate workflows for each process/team with a more simpel clearer workflow with the categories. But in order to use this, issue types need to be changed so it can go into a new workflow. This seems like to much hassle which shouldn't be needed.

A short description of our process:

First a analist makes an issue, which waits in a "To do" until the user has time to fill all details of the issues. Then the user sets it "In Progress" and after to Done. Then it goes to the developer which has the same steps and after that a tester with again bassicaly the same steps.

I hope someone can help

Accepted answers

Remi Arts

As I mentioned in a reply.

I've created a subtask issue type for each sub proces. Each with a very basic workflow: Backlog > To do > In Progress > Done. And the main issue has a few steps more for the design process.

By using the JIRA automation the subtasks are created, assigned and transitioned in order to help the overall process.

All comments

Mark Segall

Hi @Remi Arts - You can handle this a few ways:

KEEP THE PROCESS SIMPLE

Keep the initial issue "pure" and create sub-tasks for each team to complete then after the last issue is complete the parent is moved to done
Create linked clones of each issue and similar to sub-tasks, take each through the process to done.

MORE COMPLEX FLOW

You could capture every possible step as a long linear process. Have a status like Ready for Dev that signifies it's ready for a dev team member to pick up and Ready for QA when QA is ready.

In the end, it all depends upon your reporting needs. I'm a proponent of keeping the process simple with specific issues for each team's activity. You can always use automation to relieve the overhead associated with multiple issues.

John Funk

Hi @Remi Arts

You should change your workflow to have statuses that match the work being done at each step. So it would look something like this:

Backlog > To Do > Design > Development > Test > Done

Basically, you should have a step for each team, however many there are and related to what the team does.

Remi Arts

Thanks for your answers @John Funk and @Mark Segall ,

They only don't really answer my question. My main issue that the status category does not correspond the actual status per team. I would like to be able to do this without messing up any release/sprint progress. The workflow we use is pretty big in the sense it also has a lot of small steps we like to keep for reporting purposes. And I've made a lot of transitions easier by using automation. But it seems like there is no good way to use the categories in sub processes within a workflow.

Mark Segall

Hi @Remi Arts

If your focus is on status category, then it would help to understand how reporting is important to you:

As it transitions to each team, is the expectation that the status category is back to To Do?
- In this scenario, you'll want to simplify the workflow to something like To Do >> In Progress >> Done and use the simple approach I mentioned in my previous answer where a new issue or sub-task is generated for each team.
Do you want to maintain that an issue is in progress from the time someone picks it up until all teams have addressed it?
- You'll want to go with something similar to what @John Funk proposed where Design, Development, and Test are all share the In Progress status category

Remi Arts

I think I'm going to create the sub processes for different teams within sub tasks and keeps the work flows simple. And with the use of automation help the transition/creation from 1 team to the next.

John Funk

We actually use the Kanban framework and have implemented a Pull system in the workflow.

So we have a status called Design Underway and Design Pullable. When the designers are ready to work on it, they pull the issue into the Design Underway status (this is an In Progress status category). When they are done, they move it to Design Pullable, which is a To Do status category.

That lets the Development folks know that the design is done and is ready for them.

Remi Arts

As I mentioned in a reply.

I've created a subtask issue type for each sub proces. Each with a very basic workflow: Backlog > To do > In Progress > Done. And the main issue has a few steps more for the design process.

By using the JIRA automation the subtasks are created, assigned and transitioned in order to help the overall process.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

workflow

status-category