Traditional project management places a strong emphasis on comprehensive metrics. The general thought is if you can’t measure it, then you can’t control it. While comprehensive metrics has its place, it’s often overused and adds unnecessary weight and complexity to a project. Our experience is the larger the organization, the more layers of metrics there are, and they’ve been in place for so long that the organization has become addicted to them. Agile can be scary for an organization and a threat to the mental security that metrics provide.
In Agile we’re not crazy about metrics because they are often snapshots of a point in time and therefore obsolete almost instantly or they often don’t paint the complete picture. The other thing that can make metrics troublesome is people’s reactions to them. If there is no reaction, it’s a waste of time and money, then on the flip-side are the people who over react to them. This overreaction is also a waste of time and money because teams start to chase metrics to keep micro-management off their back rather than focusing on producing value. Producing metrics is not enough for us – we want to produce the right metrics that paints the right picture and prompts the right reaction from people. However, even though we’re not crazy about them, there are some metrics that feed us important information and one in particular we watch very closely.
By far the most important of all metrics in a Scrum environment is the “Burndown” chart. This is the heart monitor of the team. It is both powerful and beautiful in its simplicity. When we understand how to read the burndown chart, it becomes crystal clear if the team’s progress is healthy. Anti-patterns become equally clear, and we can either triage with additional metrics or at the very least know enough to start having a conversation. So, let’s take a look at some burndown charts and understand how to read them.
In the image above, working from left to right, the first bubble is the total story point value of all the stories at the launch of the sprint. Hopefully, it matches the team’s capacity. Immediately, we see a healthy downward trend as numerous small stories are completed, leading to the second bubble where the remaining point value and the grey predictor line meet. After this, the team continues to complete stories ahead of schedule. At this point, the third bubble shows that the team appears to be well ahead of schedule and may start to discuss the possibility of pulling in stretch stories. However, after this, the forth bubble points to progress stalling a bit. Then right at the end of the sprint, the fifth bubble, the team completes all of its planned stories ahead of time. At this point, if there are any stories that the team feels it can complete in the remaining time, the team can agree to pull the stories in as stretch stories.
This second image scares us. The first and second bubbles show that before the team has made any progress by completing stories, the team agrees to pull in additional work. This is an anti-pattern and a huge red flag. As the sprint progresses, there is a small amount of progress, but nowhere near enough. The third bubble shows that with only about a day left in the sprint there is no indication that the team will live up to the commitments it made at the beginning of the sprint. If the team does this multiple times, it’s difficult to imagine anyone having confidence in this team.
This third example is so full of anti-patterns that there is no real point in pointing them all out. But, it does have one very redeeming quality and that is that the team delivered all of the stories it committed to at the beginning of the sprint, as well as the stories it brought in after the start of the sprint. So, this is a team we would watch carefully and hope they would work to improve their process. If they consistently deliver, then as an enterprise coach, we will protect whatever their process is.
Burndown charts are the heart monitor of the team, and Product Owners and Scrum Masters need to constantly look at them to monitor the teams progress. When anti-patterns are detected, it doesn’t indicate that there’s a problem, just that further investigation is needed. There may be no problem at all and therefore no action required. If there is a problem, a solution can be implemented before the team’s sprint commitments become at risk.