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

[CaryJankowski]

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

[Nic Brough -Adaptavist- · Accepted solution]

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

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

[Mikael Sandberg · Accepted solution]

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.

[CaryJankowski]

Thank you both for the clarification and guidance.   My sandbox testing confirmed your guidance works for us.  Have a follow up question.   What if we've created multiple board views for our project that have different rightmost columns?   Would we need to update ALL boards or just the primary board?   For example ... my primary board has columns for all steps in our workflow with "Closed" as the rightmost column.  We also have a board specifically for our  Development scrum team that has "Done" as the rightmost column.   The difference being one indicates Development, QA and UAT have been completed (Done) and the other indicates the code has been deployed to Production (Closed).   Look forward to your feedback.