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?
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.
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).
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!
The solution is as follows:
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 :-)
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.
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!
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.
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.
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.
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.
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.
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"?
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.
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.
Hello Atlassian Community! Feedback from customers like you has helped us shape and improve Jira Software. As Head of Product, Jira Software, I wanted to take this opportunity to share an update on...