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.
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.
This is what I've been considering... a "Done" step partway through the entire flow. I just wasn't sure that was a correct method. But if I have 10 bugs/tasks to fix in a given application, I would want wait on all 10 to be coded before sending to QA and possible rework. So the developer may have moved 8 items from In Development to In QA, but those 8 are still In Progress and as such, my burndown doesn't move.
So yeah... maybe after In QA, anything that passes can be considered "Done." We just wouldn't really have anything Ready to Release until after the BETA period.
The trick is to have many small pieces of work, so that as each small piece is being completed (through the duration of the sprint), the burndown of story points is happening and looks meaningful.
From what you're implying, ALL your stories are only being completed at the end of the sprint, which is obviously wrong.
Sort of... I hadn't been considering the story complete until we had "potentially shippable software"... so yeah, that doesn't happen until we hear back from BETA testers.
I read somewhere that another team just imagined what the burndown chart would look like. As long as things are moving forward on the board, it was assumed they were doing well... but that's not measurable.
With complex desktop application, I think waiting until the 5 bugs and 8 enhancements have been coded before we release it to QA and then out the door makes sense. Perhaps we could involve the testing earlier, but I think my real problem is the fact the the story is over until the end and using Story Points to track burndown makes it look like we're not progressing.
Strictly speaking in Scrum, what you're seeing with your burndown is correct :-) Until an item is ready to go to the customer, you can't claim the story points. But ... you're not getting any useful feedback on the team's progress as it is now, hence it would be useful to change
So I changed 2 of the last 3 states (In Internal Testing, In BETA Testing) to DONE types in hopes that when the an issue was moved to In Internal Testing, it would move the burndown chart down the number of story points completed. That didn't happen.
It appears as though the only way that happens is for issues to make it to the last column regardless of what type of column that is. That means I lose visibility of the issues after Internal Testing (on the board at least... i can still have other states in the workflow). I guess that's just something I have to live with unless someone knows how to make a column that isn't the last one complete.
AHA! I see now... I can move that one status mapped to a column... so instead of having my columns dedicated to a single status, I can group all of the final status into the last one. and simply rename the column to Development Complete or something.
I could then probably create some custom report using JQL to breakdown anything I want finer details on and still use the built-in burndown report as is.
I'll keep playing around... THANKS!
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs