More myth-busting awaits, and in this post, I’m going to close off the thread that I opened in part 5 that focused on some of the non-mandatory Scrum accessories that are often confused as being core fixtures. So if you recall, User Stories, Planning Poker and Task Boards are actually completely optional as far as Scrum is concerned!
Now there is one last contentious artifact that many believe is core to Scrum, and this is the Sprint Burndown. Now in the past this artifact that is used to track the daily progress or burnrate of the tasks in a Sprint, did in fact form a part of the core Scrum definition, but it has subsequently been deprecated. This is because in certain types of organisations, this tool ended up becoming an unfortunate aide for micromanagement…
Just quickly, let’s run through how it works. Teams would tally up the duration of their collective Sprint tasks and track this on the y-axis. Then for every day of the Sprint they would track how many collective hours remained for the tasks either still in progress or not started.
Following Sprint Planning, many teams would typically draw a straight, diagonal (theoretical) line, from the top of the y-axis values to end of the x-axis values, and use it as a benchmark for the actual burndown line.
The problem with this line is that Sprint progress rarely mirrors the theoretical line on a day-to-day basis.
Many Sprint Burndown lines actually burn up for the first few days because of new discoveries, before beginning its downward descent as the team gathers momentum. By including the theoretical line, a curious stakeholder may get the misleading impression that the team has fallen behind after only a day or two. Then you start hearing comments such as: “You guys suck, you’re already behind and you’ve barely started!” This in turn leads to beautiful looking charts that appear like this.
Whenever I see something like this I immediately know that the culture of this team is unhealthy, and people are either too scared to report reality, or estimates have been padded considerably.
It’s not all bad
That being said, I do find that the Sprint Burndown can be helpful to help galvanise the team (believe it or not). For example, if the team sees that it is tracking behind schedule it can be a useful reminder to focus on how the team can better swarm so that come the end of the Sprint, at least some of the Product Backlog Items stand a chance of making it to ‘Done’, rather than having them all left as works in progress. Further it can be useful to give an early gauge of whether the team is tracking ahead of schedule to trigger the Product Owner into getting a move along with any outstanding Product Backlog Refinement activities.
The bottom line is that while the Sprint Burndown is no longer a core Scrum element, it does have its benefits but it should be used very cautiously to avoid abuse.
Onto the next one!
Once again, I thank you my fellow mythbusters for joining me on the sixth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!
If you liked this article, you can:
Subscribe to this RSS feed!