Tasks Done on Sprint Completion

We are wanting to track issues in a Sprint, the trouble is they don’t get closed in JIRA terms within the sprint. The workflow is as follows:-

  •  Scoping
  • Approval
  • Approved
  • Assigned
  • In Work
  • QA
  • UAT
  • Closed

In Sprint terms the Scrum Board is mapped as follows:-

  • Approved (Left Most Column, also defines backlog)
  • Assigned
  • In Work
  • QA
  • UAT (Right Most Column)

I’d like the Sprint, when closed, to recognise the items in the right most column (they essentially have the UAT status) as DONE. Is this possible?

The reason for this is the UAT is done by a different team to the development team, often involving third-parties and other complexities so the dev teams definition of done is matched against requirements, etc, so they can move forward onto other work (if UAT fails it will result in different tasks in future Sprints).

At the moment, the Sprint seems to be only recognising tasks as Done if they are actually closed. I can't be the only one who wants valid statuses on his issue pre and post those relevant for the Sprint?

4 answers

JIRA considers an issue to be ultimately CLOSED not by the issue status, but by the system field called "Resolution" if it has a value or not. The same can be said with the JIRA Agile and the "resolution" field can be automatically set in the scrum board so the issue can be considered closed.

To do this, go and "Configure" your board then open the "Columns" tab. Drag statuses between columns and you will be prompted with a checkbox named "Set Resolution", tick this if you want the resolution to be set whenever the issue is moved to this column.

The other way of doing this is to update the "workflow transition" to the UAT status and put a post-function to "update the resolution" field.

FYI, it doesn't look like the current version of JIRA supports the resolution change based on column changes.   I'll try changing the workflow transition setting (need to ask the admins to do this).

It absolutely does support it. All versions of Jira can set a resolution on a transition, since version 1.

You might be on an old version that doesn't have the flag to do it for you in the simplified workflows, but you can still add it manually.

Hi Gabrielle

Possibly I'm confusing two issues.

I totally agree with you closed and the resolution field. We went through that pain and we do now have a closed status which changes the resolution, etc.

Possibly, this is something different and I'm confusing the two end points. 

Basically, when we complete a Sprint we want anything in the right most column of the scrum board to be recognised as 'Done' (you're right, it's possibly not closed) so they don't fall into the next Sprint!

We'll test it with the next Sprint closure, but I'm not sure it was working last time.

Hi Gabrielle If we have to set the resolution field in order for a task to be considered done in a sprint how do we handle the fact the ticket is still live post-sprint with a few additional statuses? I am assuming here if we set the resolution field it's no longer an open issue.

A shorter way of putting it is it possible to have the right most column recognise issues as done for the purposes of the Sprint, but still have then open for further as the statuses go on past those on the scrum board, etc.


Please can someone provide an answer to the above thread?


I'm using JIRA Agile to manage dev but a story's lifecycle doesn't finish at the end of the sprint. It goes onto 'UAT passed' and 'Released to prod' stages (both of which are completed outside of sprint. 

So how can I close the sprint in JIRA, even though the stories within aren't technically complete (i.e. resolution field value exists)

Is there a better approach for this?


These counters:

XX issues were done
YY issues were incomplete

when pressing on the "Complete sprint" button also seem to be incorrect.

They do not depend on "Resolution" for sure, as I've tried setting this field before/after inserting them into the sprint - the "issues were done" counter is still 0. (Note: I've used this https://confluence.atlassian.com/jirakb/howto-bulk-edit-resolution-321857142.html to change the Resolution)

They do not depend on "Status" field for sure, as we have tickets in all possible statuses and "issues were done" is still 0.

They may have been dependent on the end time of the sprint, since ones I've seen a non-0 "issues were done" counter, I thought it was related to the Resolution and then I've changed the end time of the sprint and this counter stopped increasing. Now, though, I can't reproduce this any more.

I need to know the answer to work efficiently with Jira. It already is quite hard to manage since we have 4 different things representing the "status of an issue":

  • Status,
  • Resolution,
  • Category (which affects the color on workflow editor)
  • and Columns on the board view.

If there's some other, 5th, field or condition which is involved into determining the "Done" state of the issue to move tickets across sprints, then it'd be nice to know about it.



This is an old thread, with outdated answers.

However, the answer is now very simple.  An issue on a Scrum board is "done" when it is in the far right-hand column of the board.

Resolution, status category, any other column - no effect.  Status only has an effect in that you put one or more status into the last column.

This is sad. The "Set Resolution" tickbox is still there, but if you check it and go back to the board, it is forgotten the next time you come back. Surely there's a use case for having columns past the "definition of done"? We do a QA cycle at the end of each sprint and want to do a final test to verify each issue; at the moment we can't put this into a separate column otherwise it changes when we've marked issues as complete

y I'm New Here Dec 05, 2018

We have the exact same problem.  Using a Scrum board for developers our right-most column marks tickets ready for our QA team.  The QA team has a Kanban board where the left-most column picks up from there but as they mark tickets done they now appear re-opened on our Scrum burndown charts etc.!  We don't want to put these additional status into the right-most column of our Scrum board as that will create confusion for our developers.

Does anyone have ideas on how to fix this?

David Fraser I'm New Here Wednesday

Our process is slightly different - we shift to a QA phase at the end of each sprint. We ended up creating two separate boards in the same project. We're using Scrum boards for both, with different sets of columns in the right-hand side. Then depending on which Scrum board we choose it will show different progress in the burndown chart. I think there was some further complexity but don't remember the details so not sure why it isn't working for you.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Monday in Confluence

Organizing your space just got easier - Page Tree Drag & Drop is here

Hi Community! I’m Elaine, Confluence Product Manager. You may have read my earlier post about page tree in space navigation sidebar. I'm excited to share another improvement that helps you organize ...

101 views 3 4
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you