Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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.

Like Kalos Bonasia likes this

@Nic Brough _Adaptavist_

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.

Keep in mind this is stated to happen while mapping statuses between columns, not issues.  This is what Matt is referring to from Gabrielle's answer. I am not seeing it either and I'm on Server 7.12.3.  Seem that either users have to set or it has to be set during transition.  It would be nice if I can set as originally described.  

We are using a custom workflow, not simplified.

Like Kalos Bonasia likes this

That is what i said.  i'm not sure what you're asking?

Like Kalos Bonasia likes this

Thanks, it was not entirely clear to me that the 'set resolution' option when editing boards is only available in the simplified workflow and not for custom workflows.

I had expected to see it in my custom workflow scheme, but it appears that it either isn't present at all for custom schemes or I don't know how to turn it on. (this would be my question now, how to get a custom workflow to show that option when editing a board)

And yes I could do it while modifying the workflow to set on transition, but that would affect all projects that use that workflow instead of just the project that has the board configured.  

Ultimately though, it seems this is now moot for my purpose as it seems JIRA no longer depends on "resolution" to consider an issue closed for a sprint.

Like Kalos Bonasia likes this

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.

Ok. Let us know :)

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 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

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?

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
Published in Jira

Announcing the waitlist for Jira Work Management

Hey there Cloud Community members! We’re excited to give you the first glimpse of the new home for business teams on Jira — Jira Work Management. Jira Work Management is the next generation of J...

874 views 14 20
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you