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

Can a JIRA issue have a done status on one board and then have an additional one in another board?

Jairo Betancur

Hi,

Here is my case: I currently have an Scrum board with multiple statuses, and because of several factors, I need to split the board into two, with the possibility of having multiple done statuses in both boards and that a JIRA issue counts in the stats of both.

This is what I already have:

Development board statuses: "open" / "re-open", "In Progress", "Dev Complete", "Ready for Testing", "In QA" and "Approved DEV", being the last one the DONE status (green color) of this board.

Staging and Production board statuses: "UAT", "Approved and Ready for PROD", and "Closed". All those 3 statuses are understood by JIRA as DONE (green color).

My goal :

When a JIRA issue reaches the "Approved DEV" status on board one, it should be always counted as a completed ticket in the Sprint Report of that board.
That ticket, then, will be moved to the second board, and when it reaches the "Closed" status, it should be counted as well as a completed ticket in the Sprint Report of that second board. In other words, if a ticket has reached those two statuses in the respective boards, it should be always counted as completed in the Sprint reports of both boards.
Any ideas how to achieve this?

I have tried with custom filters, release versions, and so far I haven't been able to achieve my goal, as the ticket always disappears from the Sprint report of board 1 when I move it to any of the statuses of the second board.

Thanks in advance for your help.

Accepted answers

All comments

Nic Brough -Adaptavist-

>That ticket, then, will be moved to the second board, and when it reaches the "Closed" status, it should be counted as well as a completed ticket in the Sprint Report of that second board. In other words, if a ticket has reached those two statuses in the respective boards

There are two incorrect assumptions in there which mean you need to think differently about how to do this (you can do it, but it is essential to understand what is really happening).

First, issues do not "move between boards". A board is a view of a set of issues, not a container. An issue is on a board when a board has a filter that includes it (and for scrum boards, it is part of the active sprint, with sprint reports able to show the historical sprints)

Second, an issue can NOT have two status. It has a single status (otherwise status would be complete nonsense and useless to us). And, the status is also NOT contained by a board, it is something a board uses to map into columns and can be used to filter as well.

So, to do what you need, you will need to adjust the boards so that they include all the relevant issues and take account of all their status.

A very simple example is easier to explain. Take a (idealised down to a linear) workflow for an issue:

Open -> In Dev -> Developed -> In Test -> Closed

Now imagine two boards, Developer and Tester. You can imagine the developers care only about the first three status, and Testers the last three. Now remember that the last column in a board is the important one, as it defines "done". Finally, I've assumed the simple "to do / in progress / done" columns are how you want your boards

In this case, set up the boards such that

Developer
- To do = Open
- In progress = In Dev
- Done = Developed, In Test and Done
Tester
- To do = Developed
- In progress = In Test
- Done = Closed

Jairo Betancur

Thanks, @Nic Brough -Adaptavist- , will review this in detail later.

Resh_5tj6ex

Thanks @Nic Brough -Adaptavist- . Nicely explained

tomicakorac

Update: Upon further inspection, this comment is not valid. Please disregard it.

@Nic Brough -Adaptavist- your answer does not quite work. You've described perfectly what I need (and what I assume @Jairo Betancur needed), but your solution is flawed. I'll try to ellaborate.

Let us take over from everything Nic has explained. In his example, the Development team only care about the 'Developer' board. Now, let's assume that developers are a separate team from testers, and that these two teams work in their own respective sprints, independent of each other.

(Note: I'm not suggesting this is a good practice, I'm only pointing out it's very realistic to encounter such a situation in real world. Additionally, I'm only using developers and testers to simplify and stick to Nic's example, while in reality there can be any number of independent teams working in independent sprints on one and the same user story, for example Business Analysts, Designers, Developers, Marketers, Sales Reps etc.)

Once a developer is done with their work, they will move the issue into the 'Done' column. As far as the Development team are concerned, this issue is done and should be represented as such in their Sprint report. The problem is - IT WON'T. While the last column in the Developer board is titled 'Done', in reality it contains only the statuses which belong to the 'In Progress' status category. By this, the Developers are effectively cheated, being misled to believe they are closing their issues, whereby they are leaving them in progress. As a result, In the end of every Development Sprint, the Development Team's velocity will remain *zero*. So far I am not aware how to resolve this problem, and unfortunately, Nic's suggestion does not resolve it either.

How can I have multiple boards, used by multiple Scrum teams which all work in their own respective Sprints, AND at the same time keep all of Jira's reports functional and accurate?

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