This blog is a continuation of the blog that I wrote about the importance of difficulty based estimations in the sprint process. In that blog, we covered how I feel it is important to distance the team from thinking in terms of time and to think of difficulty instead. Naturally, the next question to answer is: “How do I use those metrics to measure the burndown, and to a greater extent, the velocity of the team?“
Testing the Waters of Difficulty-Based Estimations
As I described in my previous blog, development is never a linear engagement. There are many twists and turns before you finally reach completion of any task. When you first start using difficulty as your main measure of estimating stories, you will notice that the numbers fluctuate greatly. What this signifies, is that the development team needs to be analyzing their previous estimates during the retrospective meeting to see what was accomplished. It is very likely that they may have over-, or under-, estimated stories by mistake. So the more a team practices this estimation process, the better they will become. A traditional project management approach would see the numbers side of this argument. If they did “50” last sprint, and they are only doing “35” this sprint, they are not working as hard. This is simply crazy.
Therefore, early in the adoption of this practice, it is imperative to not try to drive the sprint planning by the velocity. In the early stage, harping on variations in estimations will only drive the team to make worse and worse estimations. As your team becomes more accustomed to estimating, the opportunity to compare one burndown to the next will present itself. It’s a little bit like leading the witness. If you try to convey the answer you want from the team, they are more likely to tell you what you want to hear, and not what is true.
Manipulating the Burndown
When I was first in my Scrum Master training, my instructor told us a story about how he went in to do a consultation for scrum implementation and they had burndown charts all over the walls. They all showed great trends. When he saw this, he asked them, “Why do you need my help?” It was not until he probed that he found out that the development team had been manipulating the numbers on the burndown to make it appear that they were successful. What’s more astonishing, is that this had been happening for months. Not only was the burndown a lie, but the velocity was a lie too.
How to Become Effective at Burndown and Velocity
I have said this before, these are just numbers. They are tools to be wielded for good or ill. If you want to make an answer show up, you will. Your best bet is to refine your practice so consistent results appear naturally. Only then will you understand what your team is actually capable of.
Trust the people you hired to do the best job they can. Have them estimate how hard stuff is. If they fail at that, then you can start to figure out what is not working. How do you effectively monitor burndown and velocity?
Start by not.
When the team’s estimations have normalized through practice and reflection, and the sprint workload starts to be fairly congruent, you have your velocity. Don’t force it.
Have you experienced a similar burndown and velocity manipulation in your workplace? Share your wisdom with us in the comments section below on how you resolved your Agile practices. And while you’re here, make yourself at home and check out our blog home page to explore other fixes we’ve solved in our day to day work and best practices we follow using our favorite technologies. To make your life even easier, subscribe to our blog to get instant updates sent straight to your inbox:
