How exactly does the burndown chart work in terms of triggering 'done' for an issue (Classic Jira)

[Ben Blomerley]

We have a development flow where our customers are also in our Jira boards, and take a particular role (UAT). However, from a burndown point of view, we want issues to be 'done' when they get to UAT, but not resolved (in case they get kicked back). 

However, I'm struggling with the burndown chart, as it only seems to recognise issues as 'done' when they reach the final column. Is there a way to force the reporting to be triggered at a different stage, so that our workflow works, and we have issues being done as the sprint progresses, but the customer can also do UAT as part of our board's workflow?

Any thoughts or ideas, please say!  

[Scott Theus · Accepted solution]

Hi @Ben Blomerley ,

The burndown (and Jira in general) will only recognize the status(es) that are in the right-most column of the board as "Done." It may be as easy as adding the "UAT" status in the right-most column of the board (under Board Settings, Column.)

Let me know if that works, if not I'll dig a bit more.

-Scott

[Ben Blomerley]

Thanks Scott - but we don't want that to be the final 'done' state, because UAT may push back the ticket, and certainly we don't want it to be resolved. 

Maybe we can have two statuses in that right hand column? 

[Scott Theus]

Either that or have a separate Scrum board for the development team, especially if your project has stories that are done outside the boundaries of a sprint.

Personally, I set up my projects with three boards; one Kanban for non-development tasks, one Scrum for the stuff that is done by the Scrum team, and one Kanban that includes all the issues. In this case you could have UAT in the right hand column for the Scrum board and your final "Resolved" status in the right hand column for the other two.

That should allow you to run the Sprint Burndowns from the Scrum board to show progress within the sprint through UAT and (assuming the issues all have a Fix Version populated) Release Burndowns from the Kanban board that holds all the issues in the project. 

[Jack Brickey]

what I have done in a previous life is to split my workflow across two boards - Dev and QA. I had "Ready for QA" as the right-most column in the DEV board and "Done" in the right-most for QA.

While it worked, in the end I found it unnecessarily messy/complicated and I realized I needed to simplify my processes. Rather than trying to make scrum fit my complex process I simplified things. I moved to where development had development tasks and QA had verification tasks that were only linked. then each could develop or test their task independently.

[Ben Blomerley]

Thanks guys! 

[Ben Blomerley]

@Scott Theus in your example, I assume you use a filter for the Development Scrum board? In that case, how do you manage to exclude the non-Development issues from the Burndown? Or is there another way? 

[Scott Theus]

Yes, I use a filter on the Teams field, which is part of Portfolio. If you don't use Portfolio you can use a Label to identify the development and non-development work.