Is it possible to get sprint burn-down chart to decrease on another status other than Done?

[Jonathan Muncaster]

We have a status called 'QA Done' and another called 'Done'. Both have their status to be 'resolved' but only 'Done' seems to count towards the burn-down chart.

I have noticed one thing. The columns in the board settings are slightly different. Do you see how the bar is blue for the 'QA Done' column but not for the 'Done' column? When I moved the 'QA Done' status into the 'Done' column, it registered in the burn-down chart! So I guess if I can get the 'QA Done' column to also have that green line? Not sure if that's possible - I can't see that as an option.

[KAGITHALA BABU ANVESH · Accepted solution]

Hello @Jonathan Muncaster ,

The right side Last column issues are considered as "Done".

Go to Board --> Board settings --> Columns -> 

Please drag and drop the "QA DONE" (4 issues) under the highlighted "Done"

 It will be helpful in burndown chart.

Thanks,

Anvesh Kagithala

[Bill Sheboy]

Hi @Jonathan Muncaster -- Welcome to the Atlassian Community!

I am curious: what problem are you trying to solve by burning down that chart on QA Done versus Done?

For example, is this a situation where your team's releases do not happen during sprints, and so work is not "done, done, done"...yet the team wants to see some form of progress measurement?

Thanks, and kind regards,
Bill

[Jonathan Muncaster]

Thanks @KAGITHALA BABU ANVESH , it wasn't exactly the answer I was hoping for. Ah well. I'll have to figure something out.

@Bill Sheboy 

"For example, is this a situation where your team's releases do not happen during sprints, and so work is not "done, done, done"...yet the team wants to see some form of progress measurement?"

You're pretty much right on the money there.

Basically, the difference for us between 'QA Done' and 'Done' is whether the story has been released to production or not. We release on Mondays but we have one week sprints which start on Wednesdays. 

If we only consider released stories as 'Done', then almost no stories can be done in a sprint (because the release is just two days after a sprint starts). So for all intents and purposes, once the story has been inspected, tested, OKd, etc. we consider it done. As all it needs is to be merged into the master branch. 

If we have five user stories in a sprint, but only one of them will be ready done before Monday, then only one will be considered 'Done done'. The other four, will be done before the end of the sprint, but won't count to our velocity, or show up in the burn-down chart.

If you have a better solution or idea, I'm all ears. I really want the team and stakeholders to see progress in a sprint.

[Bill Sheboy]

Thanks for explaining that, Jonathan!

Ideas to improve depend a bit on who does final release work and what the team means by "done".  (e.g. running-tested-features-in production, or "done with the scoped work for the story").  When people outside the team do release work, I have seen teams use release stories separate from implementation ones.  Others who recognize releases take longer than the current sprint duration may: make smaller stories, make longer sprints, or try a pull-based Kanban approach...while keeping all of the other Scrum practices in place to help with iteration planning.

[Bartosz Śledziński]

@Jonathan Muncaster 

Hi I have almost the same problem that you described in this thread.
In my case, setting the penultimate column as the one taken for the chart would be appropriate. But I didn't find any way to made such a change.

How did you solve your problem?