Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to change the trigger for the burndown chart


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. 




1 answer

1 accepted

0 votes
Answer accepted

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.

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 Community Leader Nov 04, 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?

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 Community Leader Nov 04, 2020 • edited

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.

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.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you