How can I close tickets with sprint's end when tickets are not in the right-hand column?

[Marcel Sarvaš]

Hi,

We are using a standard ticket flow but we added a new status "Marked for release". In ticket flow, this status is placed before "Done" and during sprint completion, just right-handed column tickets are closed (in our case from status "Done"). We are using the ticket's resolution for "Marked for Release" - Done and for "Done" - Released. 

In general, the work for the developers ends in Marked for Release status, and when the tickets are released, they are moved to Done. So we do not want to move finished tickets to the next sprint...

Is there a way how to close also tickets from different statuses during sprint completion? Can I somehow use automation, workflow rules, field configuration, or anything else to close also issues from the "Marked for release" status? (If you will or will not, care about the sprint reports)

Or do you have any other idea how to handle this process...

[Trudy Claspill · Accepted solution]

Hello @Marcel Sarvaš 

Welcome to the Atlassian community.

If the purpose of the sprint is to represent the work of the developers, and you want the issues to be considered "completed" in the sprint when they are in the Marked for Release status, then the Marked for Release status has to be in the right-most column. Otherwise the sprint completion process will consider them incomplete and move them to the backlog or the next sprint.

The sprint completion process does not allow you to designate multiple columns to represent "complete" issues. Only the right-most column's statuses will be considered complete.

One solution is to put both the Marked for Release and Done statuses in the right-most column.

Another solution is to remove the Done status/column from your board (make it an unmapped status) so that Marked for Release becomes the right-most column. You would then need to use an alternate method to review the Marked for Release issues and transition them to Done as needed.

[Marcel Sarvaš]

Correct I thought about this (to merge the two columns or unmap the Done) but that does not work for us, because we need to consider two views: developers and PM/CS/Customers. Developers should see that their work is done, and the second group should see if the ticket was "just" fixed or also delivered. So I can not merge columns, we need to keep two columns.

Maybe an alternative could be to hide tickets in "Marked for Release" when they have two sprints filled out (because during sprint completion it will automatically add the next sprint), or when they were moved into Marked for Release during the previous sprint....But it needs to be automated, a board filter will be not enough...

I can not see a suitable automation action for it, maybe someone else has some experience. I can set an automation for sprint completion and status for "Marked for Release", but which action I can use to hide these tickets...

Or I could adjust a filter for the board not to show these kinds of tickets, but I am not sure about the SQL not showing issues that are in "Marked for release" status and have more than two fix versions...

Of course, the whole process is messing with charts, during sprint completion. 

[Trudy Claspill]

What is the definition of done for your sprint - Marked for Release, or Done (released)?

Is releasing the issue considered part of the current sprint, a future sprint, or is that outside the scope of sprints entirely?

If releasing the issue is outside the scope of sprints entirely, then I suggest setting up a Kanban board for your PM/CS/Customers to view. In that board you can have separate columns for Marked for Release and Done so they can see the issues in different statuses. Then in the Scrum board remove the Done status so that issues that are Marked for Release will be considered Complete at the end of the sprint. The completion of the sprint and removal of the issue from the backlog in the sprint will not impact the view of issues on the Kanban board.

[Marcel Sarvaš]

Most of these people are part of the teams that are checking the same board, I do not want to create other boards for some people, so they would need to switch between different boards. So the definition of done for sprint depends on the people in the team. 

We need to use one board, this process was created to simplify our situation and a second board would complicate it. Based on what we learned, we can close just right-handed columns with sprint completion, so the only solution would be to somehow automatically hide tickets or somehow close also the Marked for Release tickets...

For now, the alternative solution, or the only viable solution is to merge both statuses into one column and adjust a little bit the ticket flow... (If possible I would like to avoid this)

[Trudy Claspill]

somehow close also the Marked for Release tickets

If by "close" you mean so that at the end of the Sprint they will be considered "complete", the only way to do that is to have the status mapped to the right-most column. Without that mapping the issues will never be considered "complete" and the sprint burndown and velocity reports will not count the work as "completed".

If you don't have that mapping, but instead just "hide" the issues from view, then the work won't be considered "complete" in the sprint.

There is no alternative to force the sprint to see the work as completed.

The design of Jira is such that only the issues in the right most column are considered "done" for the sprint. Neither Jira nor the concept of Scrum support the idea of having multiple definitions of done for a sprint. If you need multiple definitions of done then you need to have different scrum boards/sprints for that.

[Marcel Sarvaš]

OK, thank you for confirmation of my hypothesis.

[Alex Kamenskyi]

If you have a sprint process during which your tickets are ready to be released, but are not yet released and then after you finish a sprint you have another process to actually release your work while your next sprint is already in progress then I have a solution.

What I have done (only possible in company managed project where you can create multiple boards within a project)

1. Created a scrum board for the sprint - last column is "Done(ready for release process to start)" 

2. Created a kanban board in the same project from a filter (I have done it from a filter as I want to see tickets from 3 different projects from 3 different teams that will participate in the single release process after all team's sprints are completed). Filter is just all tickets from current sprint from all teams.

Kanban board needs to have the first column matching the last column in your sprint scrum board - "Done(ready for release process to start)" . 

When tickets in sprint end up in this column "Done(ready for release process to start)"  - they also appear on your Release Kanban board in the first column.

Close your sprints normally - all reporting works as expected.

Only after closing sprints (it is important to not do it before) start working with your release kanban board - you can have all your QA, smoke test and deploy steps as column and your final column is DONE/Released.

Move tickets through to the last column as you go through your release process, meanwhile you can start the next sprint in your team's scrum board and do it in parallel - no issues.

When all tickets are in DONE/Released - click the release button on Kanban board, put release name and date - tickets will disappear from your release board and will be recorded in the release which you can view later at any time.

The final thing to do - is when you finish the next sprint and want to run the release process again is to go to your Release board settings and change the filter to point to the current sprint (if you have one team) or multiple sprints in multiple projects if you have several teams releasing at the same time.

Feel free to ask questions.

Cheers,

Alex

[Nic Brough -Adaptavist-]

No, this makes no sense.

An issue that is not done cannot be seen as done.  How are you going to explain "done, but not" to your people?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

An issue is only "done" when it is in the last column of the board. 

If your issues are truly "done" when "marked for release" (as far as the current team using the board is concerned), then map that status into the last column on the board.  The last column means "this team has no more work to do on this"

[Alex Kamenskyi]

All comes down to the definition of done for a workflow.

If done in the context of sprint is for example - code complete, reviewed, QA done and ready to be deployed, just that the actual deploy happens a week after you close the sprint. Then the model works.

You make the last column of your board "Ready to be deployed" and that is matching Done in the sprint workflow.

Then there is a release workflow which takes it into prod - if you want to track it separately in another workflow.

Of course - if you do it all in one go and you deploy all done issues straight into prod, then no need for this complexity. This is only required when your release process is done some time after you close the sprint.

[Nic Brough -Adaptavist-]

Yes, but as I said before, an issue that is not done cannot be seen as done.  How are you going to explain "done, but not" to your people?

[Alex Kamenskyi]

Done in sprint - which is ready to be released and nothing else needs to happen in any future sprints form engineering, product or QA perspective.

But not released, because release is happening next week.

When release happens the issue status changes from Done to Released.

This is only for teams who want to release some time after they complete sprints.

Or who do not release after each sprint.

Also who want to track tickets status all the way to released (not just to done, which is ready for release).

If the team prefers to release within the sprint, or doesn't need to track tickets all the way to released, then all of the above is not necessary.

[Nic Brough -Adaptavist-]

Right, so when you need to mark an issue done for the team using the board, you need to put the issue into the last column on the board.

Your released status is not needed by the current team, but they should see it as done, so you need that status in the last column.