nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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!

Accepted answers

Scott Theus

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

All comments

Scott Theus

Hi @Ben Blomerley ,

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud