How is Jira Agile "completed" issue status determined for multi-board setups?

[Scott_Lantz]

When using 2 scrum boards that have the same issues, but different column arrangements, how is "completed" status determined?

As further context, the following article claims that stories in the right-most column are considered "completed" for a sprint, but a sprint can appear on more than one board and the right-most column can have different criteria across those boards.

https://confluence.atlassian.com/jirakb/how-does-jira-agile-decide-when-an-issue-is-complete-for-reporting-purposes-779158578.html

[Nic Brough -Adaptavist-]

Now this is a really interesting question, because it brings in "relativity" which is something a lot of people don't get in many ways.

The article you have found is right, but does not explain that different people might look at the data in different ways.

I tend to reach for a simple example for development.  When you have a non-Agile process with two teams - Dev and Test - you can set up an idealised (generalised, over-wordy and very simplified) process like:

Open -> in dev -> dev done, so ready to test -> in test -> passed (so go live)

5 status in the process.  You could stick that on a board, and try to sprint, but your teams will be fragmented - developers lose interest in the middle of it, and testers don't care before the middle.

Easy answer - relativity.  From the relative point of view of Dev, give me a board that shows me the first three status. From the relative point of view of Test, give me a board that shows me the last three status.   Both views get "done" wrong to the other.  One team's "open" is "somebody else's problem".  One team's "open" is the other team's "done".  One team's "in progress" and "done" are "somebody else's problem".

TLDR:  What you call "completed status" means different things to different people.  You need to design your boards and sprints to handle that, and more importantly, be clear with your people that there are different views on the same artefacts.

[Scott_Lantz]

That does make sense to me, and thanks for responding!

Specifically, I'm less interested in things like burndown, and more interested in what happens to issues that may (or may not) rollover at the end of the sprint. 

When a sprint is closed, "completed" issues are not rolled over, while "not completed" issues are rolled into another sprint or back into the backlog.  But if there are 2 different boards with different criteria, which is used?  Does it use the criteria from the board you closed from?

It's a bit irrelevant, but in case anyone is curious as to why this is relevant for me...  I just joined a new team as PM.  Their existing process is a bit of a mess.  They have a single board with 7 states, combining dev/QA/deployment states, much like those you outlined above. 

I created 2 new boards as a proposal to them, one being a scrum board that focuses on dev workflows/states, and the second board is a QA/deployment board that I'm using Kanban for.  

The issue isn't from that, but rather the competition between their current/old 7-column board vs. my new prototype dev-focused scrum board built against the same project.  My new board crams more statuses into the rightmost column on that board.  So while both boards exist, I'm unclear what's going to happen to the "completed" stories, given that the two boards have different ideas of what "completed" means.

[Nic Brough -Adaptavist-]

Sprints look at the board they were created for, so the move to the next sprint looks at the right-most column on the board that "owns" the sprint.

[Scott_Lantz]

I think that's the answer I was hunting for.  Thanks!