Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

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

Can an issue be done but not closed?

We have a workflow setup for our project where things that are ready are set to "Ready for acceptance". I.e. ready for our customers to verify/sprint accept everything delivered in the sprint.

The problem is that this setup affects the reports in JIRA (for example sprint report). In some instances we had to postpone the sprint acceptanc tests (issues remain in "ready for acceptance) and we can't close the stories. Resulting in a non completed sprint (but in reality the sprint is completed since the development is done).

Is it possible to set an issue to "done" without setting it to "closed"? I want it to be done from a sprint perspective but not closed from a customer perspective. Should I split our current workflow into two separate workflows to achieve desired result ? One for the team and one for the customer? (see included picture). Any tip appreciated!



2 answers

1 vote

If you want a way to approach this without looking at the process, then you were close, but there is an easier way to work.

Boards are for teams and select issues from anywhere, so instead of setting up projects as containers (and having the pain of having to move issues), create two boards.

Board 1:  For the developers, probably with one column per status until you reach "ready for acceptance".  That status and the three green ones go in the last column on the board.

Board 2:  For the customer, having just the four that are "done" according to the developer board

Ok, that would be good from a visual perspective (to make it more easy to overview). But I don't think it would address the main issue of me wanting to be able to close the sprints and tracking the result using JIRAs reports (that in turn often relies on completed sprints). 

I think it could - as your developer sprints would close on "waiting for acceptance", (and fails/re-opens could go back into the backlog), and your tester/user sprints would be separated out.  The sprint reports work off the "done" column, and this scheme works for quite a few places I've seen.  As long as you can get your users to accept that "your done is not the same as mine", and you're clear on who is active where, it can work well.

Ok, but would that also mean that we need to apply a "close" status when we put them in done on our dev board? (or the sprint status will continue to look like in the attached example? I also guess that JIRA would treat the stories as "not done/complete" if we don't set them to status "closed"? And JIRA would move them back to the backlog as "not completed" when the sprint is closed? A lot of questions but I just want to be sure that we do this right  :-). 


Nope, you can leave them in "ready for acceptance" or the three green ones.  That's what boards are for - representing the workflow in a way that suits each particular team.

When your developers do a sprint report, they'll see those issues as done.  When the sprint is closed, the done issues don't change. 

When the testers look, they see stuff that still needs checking and closing off.

The only thing that might be a bit confusing is that your teams need to be doing different sprints on different boards.  In this case, it's a good idea to keep the cadence lock-stepped, so both teams are doing the same length sprints.

Thanks a lot for your support @Nic Brough _Adaptavist_! Much appreciated!

This seems like more of a philosophical discussion, and one I've dealt with before.  What's your Definition of Done?  In my case end customers don't attend sprint reviews so "Done" is when a Product Owner reviews the completed story in a QA environment and validates that it matches expectations.  At that point it goes to Awaiting Deployment which has a Jira status category of Done so it allows the sprint to close.  Because we don't deploy to prod every sprint for contractual reasons, this lets us track things that still need to get pushed out later.  We have a user acceptance testing (UAT) environment but we don't have an explicit Jira status to reflect that.  Problems found at that point (after the team says it's Done) are considered bugs or enhancements.


Not sure if that is helpful - there's a wide range of correct answers.  I would start with a conversation about what you really mean by Done.

Hmm...good point! Address the "What" before the "how" :). Just the input I needed before we start making any changes. 

I am facing same issue, unable to fetch sprint report as nature of project is , complete all Development, give demo and incorporate feedback but formal UAT and.closure will happen later post content Authorization. What is best way to manage workflow in this case what is best status to close the stories.

Your process is broken, you're not doing Scrum.  Change it so that you are, and you have a useful definition of done, and the sprint report will start working.

Suggest an answer

Log in or Sign up to answer

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