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.

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

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?

[Nic Brough -Adaptavist-]

Nope, that's not right.

You have missed the point that the boards are a representative view for each team, not a view of everything.

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

It absolutely will.  If the issue is in the last column on the developer's team's board, then it is done, and will be represented as such in the sprint report.

The overall status of the issue across many teams is irrelevant.  The developer's don't care if it's "to do" with another team, it's "done" for them.

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

Yep, so?

>By this, the Developers are effectively cheated, being misled to believe they are closing their issues, whereby they are leaving them in progress.

No, they're not.  Their part of the work has been done, they don't care that there's more things that need doing on the issue.  They did their part and the sprint reports reflect that.

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

Just use the boards as I stated.  And stop pretending that you have a simple process where "done" is absolute for every team - it's not - one team's "done" is another team's "to do" here.

[tomicakorac]

My god, you are right! I'm so sorry for bringing this confusion. Some time ago I know I've experimented a bit with the exact same approach, I have no idea how I concluded that it wouldn't work. It does, @Nic Brough -Adaptavist- is completely right.

There is one thing that bothers me though: Once an issue gets moved to the last column on one board, its ID number gets a strikethrough. Can this be changed/modified?

[Nic Brough -Adaptavist-]

No problem - it's one of these problems where if you misunderstand one tiny little part of it, the whole thing looks like it needs framing differently.

I'm not saying you've missed anything about your process, nor that you have misunderstood what it does, but that there was a small flaw in how you meld them together.  Which then impacted everything else you were looking at, in the sense that it was a bit misleading.

The strikethrough is down to whether the resolution field is <empty> or having a value - any value = resolved (and struck out).  You'll need to work through how/where your resolution is being set and cleared.