Cancelled issues dragged on from sprint to sprint

[Liz_Pat]

We cancel an issue and then close the sprint. The issue keeps marching on from sprint to sprint endlessly until somebody notices it (cancelled issues are not visible in any of the normal views). How can we stop this from happening? Cancelled issues should not carry forward as "unfinished work" when closing a sprint. 

[Jack Brickey · Accepted solution]

you need to make sure "cancelled" equates to Done in Jira scrum terms. Preferably "Cancelled" should be a "Resolution" value when marking an item as Done and "Done" should be the final status and in the right-most column of your scrum board. By doing this Jira sees these issues as done w/in the sprint and therefore will not put them back into the Backlog when closing the sprint. Now, if your current workflow has "Cancelled" as an independent status then you need to ensure that status is mapped to the right-most column on your board just as "Done" is.

[Liz_Pat]

I can try this. I had thought it only affected cancelled items but there are 5 unused statuses in the unmapped section. I'll keep a closer eye on it with this in mind to see if the problem affects all 5 of those statuses. 

[Jack Brickey]

@Liz_Pat , i'm trying to follow you here. Any unmapped status simply means that if any issue in the project(s) associated w/ the board are transitioned to any of the unmapped statuses then they will not be shown on the board. Of course the issue are still there they simply are not shown on the board because the board has them "filtered out". You original question is about how to treat "Cancelled" issues as "Done" as far as them not being carried forward from sprint to sprint. In short - any issues that you do not want to move back to the backlog/future sprint must have a status that is mapped to the right-most column on your scrum board.

[Liz_Pat]

The point is very clear. Thanks for the reply. I will continue to monitor. I'll close this issue since my guess is there is something else going on too. Our system has a lot of inconsistencies and it's tough to disentangle them enough for me to troubleshoot. Thanks for the tips. 

[karim.belhadj]

Hello team

I planified my sprint v01.

In this sprint i have one issue that it's cancelled (status = cancelled).

I do not see more my issue in my sprint , it's removed from sprint i can not find it in the baklog .

Note if i reopen my sprint i can find my issue .

Regards 

[Robert YK]

This doesn't make sense... In my right most column I already have the "Done" status mapped. If I also map the "Cancelled" status there it means there is no proper visual differentiation when actually dragging items meaning that team members start to cancel instead of complete issues....

[Jack Brickey]

In CMP and traditional boards if you have multiple statuses mapped to a single column then when you drag an issue into the column you will see dotted lined boxes for each status and you can drop them into the appropriate one

[Robert YK]

Well my teammembers don't haha. And after it's been dragged there's not visual indicator anymore. 

I'm now trying to just filter cancelled out of the board entirely and see if I can complete the sprint monday even though there are cancelled issues linked to the sprint (but not filtered on the board) that are not in the "rightmost column". 

[Jack Brickey]

Couple thoughts….

• include Status on card layout
• consider not having multiple done category statuses. Rather use the resolution to indicate cancelled. This is what I do most of the time. 

[Robert YK]

Changing card layout is smart, never used the feature.

I'm using resolution of "Done" when "Cancelled", but you don't mean that I think...

[Jack Brickey]

No I mean use Done as your only done category status and leverage Resolution for the variants of Done: done, cancelled, won’t do, cannot reproduce, etc.

while there are scenarios where I use more than one done category status they are rare. 

[Robert YK]

Oh right, already had it set to "Won't do" resolution. However this still blocks sprints from being closed...

[Robert YK]

Extremely frustrating, I'm now blocked again from closing the sprint because there is a task that has a subtask which has cancelled state :/

[Jack Brickey]

Is “cancelled” status in right-most column? 

[Robert YK]

That was the thing I wanted to avoid as teammates accidentally drag the issues in the Cancelled column. ;)

But I'll go for editing the Card layout to better illustrate actual status.

[Jack Brickey]

Agreed that is why I almost always opt for a single done status and allow the resolution to specify the type of done i.e. it can be done-canceled. In this way they can drag the issue to the done column and the pop-up will require them to specify the resolution.

[Robert YK]

But I'm using my Done status to set resolution to "Done" and my Cancelled status to set resolution to "Won't do".

However "Won't do" isn't considered "Done" (resolution/status) and I can't set "Won't do" and "Done" simultaneously as resolution right?

[Jack Brickey]

Let me reiterate- My suggestion is to get rid of the canceled status altogether and replace it with status done and a resolution of canceled in this way all completed issues will have a status of done and the resolution of those issues will vary depending how/why it is considered done.

if you want to maintain cancelled as a status then that is fine BUT you must put that status in the rightmost column to have those issues completed as part of the sprint. I simply prefer the other solution.

[Robert YK]

Ahhh i can do two transitions to "Done" obviously :)

[Robert YK]

This is working horribly. I have so many developers just cancelling stuff... Let me show you where this goes wrong:

[Jack Brickey]

Done in scrum or Kanban is the right-most column always without exception. If you don’t want “cancelled” to be a Resolution value for a Done status the then you can have a Cancelled status of type Done status category. You just need to be sure to map Cancelled status to the Done column. Finally if you don’t like Cancelled to appear as Done then rename the last column to something else: Complete, Addressed, Nothing Left To Do, Abyss, Fred…..

[Robert YK]

Hmm, then I don't understand what you said here:

> No I mean use Done as your only done category status and leverage Resolution for the variants of Done: done, cancelled, won’t do, cannot reproduce, etc.

[Jack Brickey]

@Robert YK ,

Let me first state that this thread has become messy as we have sort of hijacked Liz’s post resulting in two discussions.

I’m not sure how else to state my point (opinion) here but will try to do so once more via, hopefully, some clear bullets.

• Issues that are to be considered complete must appear in the right most column. For scrum completing a sprint will only consider issues in the right most column as complete in the sprint. For Kanban, using the Release button results in a very similar behavior, removing all issues in the right-most column and adding the designated release version to the issues.
• there are two methods of dealing with different reasons you would consider issues to be complete (terminal state). You can use multiple statuses each being designated in the Done Status Category (green) OR you can use a single Done status and leverage the Resolution field to signify the type of done (resolved, won’t do, cancelled, duplicate…). Using the first method requires you to place all done statuses I too the right most column and you must rely on the user to drag and drop an issue into the proper status that appears in the rightmost column when dragging. When using the latter solution a user would simply drag the issue to the rightmost column and if implemented correctly a resolution screen would request the user to specify the resolution value. Personally, and almost always, I prefer the latter solution. However, there are instances where I do you use multiple done statuses in a project.

I hope the above helps. If not I might recommend that you open up a new question for others to chime in on.