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?

[Nic Brough -Adaptavist- · Accepted solution]

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

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

[Phill Fox]

@Emily Loew

I would suggest start simple and then build in complexity as you need it. Subtasks may well be the way address your requirements along with the different views for different people.

[Sara Watson]

@Nic Brough -Adaptavist- I have a similar problem I am trying to solve but I am not sure if it's possible. I am trying to create a complex workflow in a single project with multiple boards that allows for a "Done" resolution in one board but not in another? For example, I need a way to resolve a ticket in the Department 1 backlog then move the same issue to the Department 2 backlog. I'm not seeing a way to mark an issue as resolved in department 1 and still have it visible for department 2 to pick up. We want to track a "preliminary" done when department 1 completes it (and allow for reporting/burndown in department 1) and a "final" done when department 2 completes it. Can that be handled on multiple boards in a single project? If not, how can I most efficiently "move" the issue to a new project for department 2 without making copies of everything and creating an administrative nightmare? 

[Nic Brough -Adaptavist-]

I think this is "solvable", but not by trying to do it with the software.  The computers should be trying to help you, not get in the way.  Jira can very easily set up to be complex, but when people do that, it's a symptom of them not working together well, not bad software (and there's a lot of other software we can all totally misconfigure to fail in the same way Jira does - I spend a lot of time explaining to people that while Jira is bad at supporting the way they want to work, the other two options are to do it wrong or select even worse software that tells them they can do it that way and then leave them in a worse mess six months later)

TLDR: @Emily Loew has it right - try what she said.  Alongside a review of what you see as "done".

[GabrielleJ]

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.