What is required to prevent rollover of an issue when a sprint is completed?

Question

We've created an issue workflow for our SDLC.   Included is a standalone state named "Invalidated" for issues we deem no longer necessary.  This state can be used anytime during the workflow.  When used we also flip the Resolution flag to Done thinking this will effectively close the issue in current sprint and prevent it from rolling to the next one when the current sprint is completed.  Unfortunately, that is not the case as we are seeing the "Invalidated" issues move from sprint to sprint as the sprints are closed.   Would greatly appreciate an explanation as to why the state continues to roll and a recommendation to address the issue.    Thank you

Mikael Sandberg · Accepted Answer

What controls if an issue is considered done in a sprint it when it is moved to the column furtherest to the right on the board. So you would have to configure your board so that the Invalidated status is in that column together with any other statuses that you consider as done.

Nic Brough -Adaptavist- · Accepted Answer

Welcome to the Atlassian Community!

Ending a sprint with incomplete items is not ideal, your teams should be talking about why they failed to complete the items they missed.

"Invalidated" in this case is a good thing to use - you've obviously looked at the issue and made an active informed decision to not do it.

In Scrum and Kanban though, there's no concept of "invalidated", and Jira's boards are heavily focussed on those two methodologies.

You need to tell Jira that "invalidated" is "done".  On the boards, the resolution is irrelevant, Jira only recognises the last column as "done".

So, TLDR: You need to map your "invalidated" status into the last column on the board.

Nic Brough -Adaptavist- · Accepted Answer

Multiple boards can work very well, if you set them up carefully with a holistic view of the whole process.

Using your example status, I would imagine a workflow (simplified, I'm imagining a person would move an issue into the next status when they've done their work on it, but I imagine a real workflow would be a bit more complex):

To-do -> Dev -> QA -> UAT -> Deployable -> Closed

Imagining a standard Scrum team, and then another team that deploys their output, you'd have one board per team

* Deployers board would have two columns* To-do: Deployable
* Done: Closed

* The scrum developer team would probably want* To-do: To-do
* Dev: Dev
* QA: QA
* UAT: UAT
* Done: Deployable, and Closed

If you're going to use multiple boards in the same team, then you should, for almost all uses, make sure that all the boards have the same definitions of the "done" column.  The others can be whatever you need them to be, the boards only need to agree on "done".