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!
/Johan
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 :-).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm...good point! Address the "What" before the "how" :). Just the input I needed before we start making any changes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.