How can I fix my burndown cliff?

Scott Elam

So we have a workflow that has a To Do type step for Selected for Development followed by several In Progress steps for In Development, In Internal Testing, In BETA Testing. The last step is Ready for Release after we get word back from our BETA testers and this last step is of the Done type.

So while we can see stories and tasks progressing nicely across the Kanban board, the burndown report is a flat line until the very end and the drops off in straight vertical line at then end of each sprint.

What am I doing wrong?

We size things using story points that encompass all of the steps in the process which I believe is correct. I really don't want to hours and remaining effort, but I know that will work. 

So I 'm not sure this report is really valid when using Story Points unless some intermediate step is classified as Done or Complete. My initial thought was to make In Internal Testing a Done stage, but that kind of defeats the whole point of encompassing testing and rework into the size estimate.

Tarun Sapra

Hello Scott,

This is a common problem across lot of teams.. The reason this happens because the right most column of the scrum board is considered the "done" column. Such that your story points get burned when the issues move to the right most column. 

Now, in scenario shared by you it seems that the team is moving the issue to the right most column right before the sprint ends thus resulting in a vertical drop in the burndown chart. 

Now, my suggestion is to have a status (lets say "Dev Done") before "Ready for release" which can be used for "done" i.e. for proper burning of points so that there is a nice graph in burndown chart instead of vertical drop. And proper progress of teams can be monitored.

And once the issue reaches the Dev Done then Beta testers start testing it and if it fails then it moves back other-wise on further on an kanban board it can move to "ready for release" and stay at the right most column in scrum board.

Now, the above approach works for mostly teams wherein beta testers or integration testing takes time and continuous delivery cycle is not very fast thus deploying on a certain environment ( before prod) is considered done to maintain the "sanctity" of the burndown charts but at the same time accepting that everything is *NOT* deployment ready at the end of the sprint. And thus requires further working on a "release" team kanban board.