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

Scrum board burndown needs to include statuses other than 'closed'

Ian Mackay

Hi, I have a workflow of the form:

open->in progress->in test ->complete

As far as my development team is concerned, the work is done when items enter the 'in test' status, since the UAT and merge to production happens outside the sprint.

Ideally I'd like:

The burndown chart to show issues in test as counting towards sprint progress (set to resolved, not closed)

I need to keep the 'closed' status for items that have completed UAT.

I can't seem to get Greenhopper reports to identify these tickets as counting towards completion, so the burndown always looks hardly worked on, and in order to make it correct, when the sprint finishes I need to temporarily drag the status of 'in test' into the final Done column in the board configuration settings.

Any ideas?

Thanks

Accepted answers

OmarA

Hi Kulu,

Actually the way how burndown chart works is to burn the values base on the last column in the columns mapping in your board configurations.

So my suggestion is to set 'In Test' in the last column then you can set 'Closed' before 'In Test' or you can merge those together. I know that might not make some logical sense but that's how GH works indeed.

Cheers,

Omar

All comments

OmarA

Hi Kulu,

Actually the way how burndown chart works is to burn the values base on the last column in the columns mapping in your board configurations.

Cheers,

Omar

Ian Mackay

Ah, ok, makes sense, but quite annoying from a useability point of view, since we have some ticket types that need to go through UAT, and others that can bypass this and go straight from 'in progress' into complete.. Getting my developers to understand and use a back-to-front column set-up would be tricky.

Thanks for your explanation for how it's being implemented though.. it would be nice to have this as a config setting, so Greenhopper boards can be configured to show resolved or closed tickets in the burndown (rather than always having it as tickets in the final column).

Ian Mackay

I ended up making a second board with a simplified workflow - we now use the burndown from this whilst using the main one for issue transitions. Horrible workaround really, but I don't see any other way to do it.

Christen Lorensen

Is it still like this. We have the same problem, but don't want to do this horrible workaround, as sometimes we need the devs. to test technical tasks them self. And getting them to do that we need to remind them with the collums.

Frank Orozco

Please fix this in a future release, such that teams can choose the column on which to burn down!

Nur Duygun

We have the same issue, our scrum teams are "done" once code is pushed to production queue, but we cannot close the tickets until the code is actually live in production. Having a burndown chart based on "closed" status have been messing up all of our team's sprint reports.

Devin Edwards

In the column section under Project Administration you could just add the In Testing status and the Done/Closed/Resolved Status to the same column; the last one. Ether status would show as done in the burndown and you don't require a different workflow.

Peter Černuta

Is there an update on this?

Nic Brough -Adaptavist-

Update on what? The system burns down on the done column, as it intended to.

Peter Černuta

Update on requests to make the system burn down based on a custom column.

Andreas Heini

As far as I can see, there is still no appropriate answer to the initial question. Now, 5 years later: Is there a way to display more than just the one "Done" graph on the board?
My User Story: As a Scrum Master I would like to see a graphs for "in progress" and "in test", so I can challange the team to have less work in progress.

Chris Green_253rbq

Is there an update on this?

Chris Green_253rbq

This is very similar to what our team need, though we would like to track "merged" and "tested". 'Done' is not useful for this

Keith Harris

Yes, this is exactly how my boss and I both would like to be able to track this. I don't understand how this is something that couldn't be easily configurable. If I can add custom columns then let me track our work progress the way that makes sense for us.

Tom Claessens

Not sure if this is what you want but I think our team had the same issue.

We have a single project with two scrum boards: development / testing. The last two columns on the development board are "development done" and "completed". Completed has mapped all "done" statuses. The statuses grouped in "development done" match all possible statuses on the testing board.

The issue we had is that sprints are one week. Development + testing. Acceptance (part of testing) happens the second week. So tickets never really finish during their actual development sprint. Velocity and sprint burndown was never accurate, since it only reflected the tickets that the testing and acceptance team completed in the second week, because that's when the started development tickets during the first week reached their "done" status.

This was solved by keeping the first scrum board (development) but exchanging the second board (testing) with a kanban board. Now the last column on the development board is still development done. I mapped all statuses further down the workflow onto columns in the testing board, and by using a filter + sub filter on the kanban board I filter on all issues with unreleased fix version or with released fix version but not in "done" status or fix version empty and in current sprint.

This way, when I close the sprint after one week, tickets that were not tested remain on the kanban board because of the queries and since development tickets now reach the last column during the one week sprint (development done), all tickets are used in the burndown charts and reports. Which allowed me to finally use velocity numbers right from within JIRA instead of doing some odd excel calculations to get an average sprint velocity.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

workflow