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

How do I create several workflows within one project?

Emily Loew

We want to have a different workflow for each department that an issue goes through (QA, Development, etc). How do I set up JIRA Software with Scrum boards in a way that we can move an issue through each department's process? Can I have multiple workflows all within the same project but on different boards?

Accepted answers

Nic Brough -Adaptavist-

Separate projects from boards in your mind - they're very different things.

A project is a pile of issues, with configuration for them. You can have many workflows in a project, associated with different issue types. So "bugs" can have one workflow, "features" a second, "Epics" a third, "Stories" a fourth and then "tasks", "to do", and "requests" could all be sharing one workflow. Then the next project might just have a single workflow for bugs, features and stories. That's done with the project's "workflow scheme"

Boards are a view of a set of issues. They could look at one project, or several, or all of them. A board can select almost any set of issues you want to work with.

The usual starting point for a board is that a Team will use it to manage their work. So, you could set up a board for QA and one for Development etc. But, you need to consider the board definition alongside all the different workflows. A workflow is not determined by the board, it's handled by the project. So if you've got three projects on the board with 2 different workflows in each one, your board needs to handle all 6 different workflows.

This is generally a matter of making sure all the possible status are mapped, and then JIRA does the rest for you - if a workflow doesn't include a status, or the transition can't be used by the current user, then the board won't let you move the issue into the wrong column

All comments

unknown

JIRA Workflows are specific to the JIRA Issue type. You may have a different workflow for your "Bug" issue Type and "Task" issue type so you can use that part but that's about it. In your board, you can show different issue types if you wish and associate the "In Progress" to show issues with "In Development" status and "Investigating" at the same time.

Nic Brough -Adaptavist-

Separate projects from boards in your mind - they're very different things.

Emily Loew

I should clarify that I'd like to be able to keep the same issue type but move it across several workflows. Text/Mockups/Issue Creation -> Development -> QA Testing -> Done

If each of these steps has it's own workflow within the responsible persons/departments, is there a way to chain together multiple workflows? I want to be able to track a 'To Do'/'In Progress'/'Done' process for each of the departments to better track velocity and time.

Right now we use a project for a larger area of focus and boards to separate out issues/stories from bugs. For example one of our projects is 'Website Build,' so this includes all features/bugs associated with our main website which we are constantly updating and improving. We then have a Website Issue Board and a Website Bug Board.

We are a small team consisting of 2 developers, 1 QA person and 1 project manager. So the battle is creating a clear process without creating more work than necessary for ourselves. It is also possible that I initially set our JIRA up in a way that is not conventional.

Nic Brough -Adaptavist-

Nope. You can't "move issues across workflows", it's the wrong model of thought. An issue goes through a process. Changing the workflow just means you have written separate workflows for parts of the process, and hence fragmented the process. Two basic ways to approach fixing this break: 1) If you genuinely want "issue gets to a point and is closed by one team, and passed to another", then you can either *move* the issue to a new project, resetting it back to an open status, OR you could create a new issue in the target project. 2) Make the workflow represent the actual process. From what you've said, it sounds like option 2 is going to be better for most of the work, with status explicitly representing who it is with as part of it.

Phill Fox

An alternative approach to is to use subtasks to represent the tasks undertaken by each department. So the story remains as the complete activity and then the (sub)tasks are undertaken by each department. You can then look at the subtasks assigned to each department by the use of quickfilters/swimlanes without losing the oversight of the story/bug etc. that is being addressed.

As suggested by @Nic Brough [Adaptavist] making the process and the workflow match is key to your success.
Given the size of your team I would also consider simplfying your boards down to a single Kanban board rather than Scrum board(s) that looks across all projects for issues and allows you to manage a flow of work that is always in priority order.

Emily Loew

Thanks @Phill Fox [Adaptavist]. We don't really use the tasks/sub-tasks right now and I think that may actually be the solution to where I am getting stuck.

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-software

jira-software-cloud