Issues marked as Done still appears in a New Sprint

[Marco_Santiago]

We configured our workflow so that we have have a status of Deployed (for code that has been successfully tested and deployed). This status is mapped to a category of Done in the status definition screen. We also have status of a Closed in the workflow, for issues that are resolved for other than deployed status. This status is also mapped to a category of Done.

The problem that we're having is that when we set the status for an issue to Deployed, we're expecting these issues to drop off when we create a new sprint since these issues were resolved from the previews sprint. 

How do we get this to work?

[Nic Brough -Adaptavist-]

A board and sprint's definition of done is "in the far right hand column on the board".  The status and category do not matter beyond the status being in that column.

Make sure "closed in the workflow" and "deployed" are included in the last column.

[Paul Klapperich]

Make sure "closed in the workflow" and "deployed" are included in the last column.

It seems there's more to this than that. Our rightmost column is just called "Done" and issues marked as "Done" are moving to the next sprint. (We have it set so that there are different resolution options when moving an issue to the right most column, but that only affects the "Resolution" field which you said doesn't matter).

[Nic Brough -Adaptavist-]

Do the issues that move have sub-tasks that are not also in the done column?

[Paul Klapperich]

When issues have incomplete sub-tasks we get an error and can't even attempt to close the sprint. ("Sprint cannot be completed as there are incomplete subtasks on the following issues...")

But you pointed me in the right direction. It was the opposite; there were a couple of large parent tasks in the verify column who had all of their subtasks in done. Thanks!

[Nic Brough -Adaptavist-]

Ahh, nicely spotted.  Sub-tasks are not the obvious one to think of, but I'm glad I helped you find the missing issues by mentioning them!

[Paul Carroll]

So, I too have been struggling with this problem. It would seem to me that if I marked an issue as Done in a previous sprint, when I close that sprint and start a new one, these Done issues should not show in the new sprint at all. I recognize that they are in the far-right Done column, but I don't want to see them. As the Project manager, I am interested in seeing what has been moved to Done in this sprint. Stuff that happened in a previous one is not very interesting to me.

It seems to me there ought to be a way to set it up to work this way. This is a three year long software development and deployment effort and I have high level Epics that cover the main efforts involved, and then stories for major components, and Issues below those. Some Issues have sub-tasks as well. Just because the highest level is not completed should not mean that these Done Issues should still be hanging around in the Done column of each sprint.

Maybe I have things set up incorrectly, but if someone can tell me how to do this better I am willing to learn!

[Carl Screwvala]

The solution is as follows:

• Ensure your "Deployed" status is mapped to the far right column of your board
• If you actually don't want to see those completed/done issues any more on the board during an active sprint, edit your board's Filter query to exclude issues in the status Deployed ( " AND Status != Deployed ").

Once you move them to this status, they will disappear from the board, but as they are technically mapped to the far right column, they won't be carried forward to the next sprint :-)

[Gavin Howden]

Thank you.   

[Sam Leinbach]

Create two (or more) Boards: First board is your current board with columns for all steps of the workflow showing. This is for the team's day to day issue management. Create a second board with all 'Resolved' issue statuses (i.e. Deployed and Closed) in the last column. Use the Second board specifically for closing sprints. This will ensure story points for all resolved issues are accounted for in velocity and sprint reports, while having the other board to show all statuses clearly.

[Ashish Jain]

I still have issues that tasks with 'Done'Status are still moving to the next new sprint. And I have also confirmed that the 'Done' column is at the far right end of the Board. 

[Sierra Larsen]

I have a ton of tickets where you can see the history of it being resolved and in the final done column.  It still continues to add more sprints.  If I'm missing something, PLEASE let me know as this is complicating records.  

[Gert Stalmans]

Hi,

we have a "sprint board" and a "roll out board" that cover the whole workflow.

Sprint board = A story is developed and released in the acceptance environment. The last column of that board maps on a status of DONE category and the storypoints are nicely counted as done. BUT ...

Roll out board = the first column is the done status of the previous (sprint) board. When we get the green light from our endusers to roll out we move them to the column "go-live planned" and then to "Live". Alle statuses in this board have a DONE category. But when moving to the "go-live planned" column the storypoints are added again to our current sprint counts.

Anyone an idea where this comes from?

[Nic Brough -Adaptavist-]

A board represents a team's pile of issues that need attention.  I say that because it explains why "done" is relative.

In Scrum, the principle is simple - every item is something that needs attention, and "done" means "this team does not need to pay any more attention to it".  (Kanban is a little more complex, with the releases, but it's still "the last column, and...")

Boards do this by having a final column - the team can ignore anything in it, it's done.  Categories, the meaning of the status, the resolution field - all irrelevant - it's done if it's in the last column.

The last column on your two boards is relative to the team - your dev's done = roll-out to-do.

But actually, the developers also consider roll-out's in-progress and done, as done, because the developers still don't need to pay any attention to them.

The "fix" here is simple - map all the roll-out status into the developer's team last column.

[Moses Thomas]

@Marco_Santiago

in-addition to  previous  comments,

make sure that  active sprint is completed.

if not  go  to   active sprints  >  complete sprint   they should disappear and you can view them in reports.

Best!

[Sam Leinbach]

We have the same set up and problem. Last two columns of the board are for issues that are 'Done'. When moving issues into 2nd to last workflow step, the resolution screen comes up and tickets are marked with a resolution (i.e. Done, Won't Do, Cannot Reproduce, etc.). There is no change in Resolution status when moving into the last workflow step.

When I click Complete sprint on the Active Sprint page, I would expect all issues with a Resolution (i.e. Done) would drop from the sprint, but they roll over to the next sprint. This causes Done issues to be in the new sprint and not credit these Done tickets to the velocity.

We don't want to put two states in the last column because we lose visibility of this status and cannot drag between columns.

[Nic Brough -Adaptavist-]

As before,

A board and sprint's definition of done is "in the far right hand column on the board".  The status and category do not matter beyond the status being in that column.

The resolution is also irrelevant.  Look at the "done" column.

[Sam Leinbach]

@Nic Brough -Adaptavist-Thanks for that clarification.

[Rajkumar_Porwal]

Does any one found the solution for this yet. I am also facing the similar issue.

Regards

Raj.

[Carl Screwvala]

There is no solution beyond moving your 'done' column to be the far most right column

Sadly, a board and sprint's definition of done is "in the far right hand column on the board".  A strangely arbitrary and fixed definition for JIRA, given its flexibility is its real power. 

So issues will be carried forward (even if in a 'done' status and Resolution=Done etc) unless they are in the far right column.

[Rajkumar_Porwal]

Thanks @Carl Screwvala  for response- At present to move forward, i have also used the work around to move 'Done' column rightmost. 

Regards

Raj.

[Alex Murillo]

I ran into this issue recently when I decided to introduce several new Done Status Category types.  When is this going to get fixed, because this is poor design?

Especially when you consider that everywhere else in Jira the new Done status types are properly recognized natively and by plugins.

This includes Jira showing the custom Done status types with a green checkmark and the new types recognized properly when queried in filters.

I'm stunned this design issue has been around this long.

[Nic Brough -Adaptavist-]

There is no issue or bug here. 

Jira has always defined at the last column on a board as "done".  That's how boards work.

[paulczajka]

Agree there is no bug, but the lack of flexibility creates unnecessary friction for us.

We have the "Done" column, but also a "Won't Do" column for tickets that were ultimately not pursued, for whatever reason.  We don't want these tickets to carry over to the next sprint, nor is it correct to put them under the last "Done" column (for concerns like reporting, auditing, planning, correctness, etc, etc).

Allowing multiple columns to behave as "done, don't carry-over" would resolve the friction.

[Nic Brough -Adaptavist-]

That's clumsy, and won't work.  "Done" effectively means "the team does not need to do anything more with this".  They don't care whether it's won't-do or really done.  If they did, then you have a broken process because you've got done issues that are not done.

Stick them both in the same "don't care about these any more (done)" column and it'll work fine.

[paulczajka]

That's... interestingly worded.  I might disagree and say ~we~ probably have the best sense of what we care about.  In any case, thank you for the response.  It was enlightening.

[Nic Brough -Adaptavist-]

You're right, it is "interestingly worded".  Probably quite clumsy when I re-read it.

The problem here is not so much about what you have the sense of what you care about, but how you are using a Scrum tool to represent it.

In Scrum, "done" really does mean "we, the team, have no further interest in this", at least in terms of the stuff the team needs to actually do with it. 

Some teams, or people within them, will continue to take an active interest in the issues, following them as they progress further.  You may well have some interest in reporting stuff too.  Some teams or people simply don't care, once it's done (for them) it's of no further interest.

But the point of "done" for this team is that it's done.  Whether that is because it is "done" or "won't do", the team has no more to do on it.

It's not a lack of flexibility - Jira copes with multiple end-status for issues by letting you map them into the "done" column, rather than clutter a board with many columns that have the same meaning in the context of the team's workload.

Another way to ask the question (which I was asked a while ago and helped form this answer) - how does it help a team plan and execute its current workload by having 2+ columns that all mean "not relevant to us at the moment"?

[Caleb Abbruzzese]

I think the majority of the problem is not being considered here. The solution is not addressing the actual problem. It's solving an unrelated problem.

If the actual answer is that sprint boards are incompatible with needing another workflow, or set of statuses that follow after a sprint, then that is the answer.

But the problem then is that the feature fails to explain its behavior in any reasonable way. A giant warning of "sprint boards are incompatible with complex workflows by design, please stop now, do not use this feature" is the only way to solve future use cases.

Before that's viewed as sarcastic or over the top, team-managed projects have a similar warning. I would argue it's still missing full context that team-managed projects do everything differently and are incompatible with apps. But that inflexibility caused the warning to be created, and any information is better than none.

This answer is that the sprint boards will always be inflexible, and that a large collection of needs of the customer cannot be met with it. So be open about that, or provide a solution.

Being legalistic and non-transparent is not a real answer.


As for solutions for those who care about the workflow after the sprint, need the history of the ticket, and are not willing to manage the same issue types across different project types, and build complex automation to copy stories across projects, if there is a way to build an automation step that removes the latest sprint from "done" stories with no activity more recent than 2 weeks (or your sprint length) that may fix it. If I get any success I'll update.

[Nic Brough -Adaptavist-]

The "solution" here is to use the tool as intended, it's not fixing the tool - there's nothing wrong with it.

>If the actual answer is that sprint boards are incompatible with needing another workflow,

They are not.

> or set of statuses that follow after a sprint, then that is the answer.

They work fine with that too.

That only applies to company-managed projects.

Team-managed projects limit you to keeping it simple and Scrum.  They are supposed to be used by a single team, that manages the entire story in the team.  They would never need a workflow that has status outside their team 

Company managed projects have more flexibility and can accommodate working with Scrum as covering only part of the lifecycle of your story.

The problem here is you are not using the right tool (team managed projects) for the way you want to work, not that the tool doesn't do what you want.

[Thanh Nam Tran]

We have few tickets that have Resolution as Done. 
The "Done" column is the far most right column.
However, the tickets are still being carried over when we complete the sprint. 
There is no subtask for the ticket.

[louisdj]

Do you add a resolution to the ticket when it is considered 'done'? Without a resolution, Jira keeps the ticket open...