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

[Remi Arts · Accepted solution]

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.

[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]

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. 

[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. 

[Mark Segall]

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

KEEP THE PROCESS SIMPLE

1. 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
2. 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.