How to change the trigger for the burndown chart

Tim Lange November 4, 2020

Hello!

We would like to trigger the burndown not based on the last column, but on a column before that last one.

Goal: allow the dev team to monitor their progress before bringing all stories of a sprint to the review meeting where the PO sets the stories to DONE as the final stage. 

Thanks,

Tim

 

1 answer

1 accepted

1 vote
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 4, 2020

There is no way to do this.

The last column on a board is "done", and hence gives you a burndown.

Your goal here is perfectly valid, but botching status so that things are done but not done is not the right way to achieve it.

Tim Lange November 4, 2020

Thanks for the clear answer!

I'm just wondering how others do this in similar setups. Do the devs set stories to DONE before presenting them in the sprint meeting? Our goal is to set stories in the review meeting to done once they meet all criteria approved by the PO. 🤔

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 4, 2020

i have used a method of splitting my workflow across two boards, i.e. dev in scrum board w/ last column = 'ready for QA' and a kanban that starts with 'ready for QA'  and ends with 'Done'. Not a big fan but it did serve the purpose. Maybe a similar approach would work here?

Like Krisna Leo Parista likes this
Tim Lange November 4, 2020

Thanks Jack! 

This way the burndown chart goes down once the devs set the stories to the most right column? 

And the stories are DONE once QA sets it to DONE in the second board and thus the stories are entirely closed? 

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 4, 2020

precisely. The point is burndown is driven by the board not the workflow so splitting the workflow across boards can work. Also, in my case my QA team wasn't 'agile ready' so we had an agile development and kanban QA process.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 4, 2020

I agree with this - you've got a situation where "done" differs between two separate teams.  You can make your workflow match the actual process, and then set up boards for each team, having "their" done mean the right thing for them.

My over-simplified example is when you have Development and Test teams separately.  You create a workflow that is something like:  To do -> in development -> dev complete -> in test -> finished.

The developer's "done" is "dev complete", but the tester's "done" is "finished".  So you have developers board that maps to-do to to-do, in development to in-progress and dev-complete as done (you could also put in-test and finished into the done column if you want to retain visibility).  Then the testers get a board that starts with dev-complete, and their "done" is just the "finished" status.

Like Krisna Leo Parista likes this

Suggest an answer

Log in or Sign up to answer