It was little before midnight, when my son was born on a Saturday. It was proud moment for me to become a dad and at the same time it was a happy moment too to see my wife and baby doing good. Now my son bigger and I was debating with my wife if he was growing good or not, was there anything we were missing. In short, as parent, we were more interested in knowing if he is growing mentally and physically or not. Hence we ended up turning towards the expert, my son’s pediatrician. When we had discussion with Mr. Pediatrician, he mentioned that he is keeping track of few things which he measures at each visit. Which are Weight,Height,Head Size
There are the three essential data sets which tells him if kids growth is up to the mark or if intervention needed to dig deep to find out what is actually happening. Apart from that, his behavior at each visit also tells him if he is growing.
Anyways, let’s roll towards why I was telling you all this. The above episode made me think what if we as Coach could come up with something where team could actually see the value and realize that they are growing on sprint by sprint basis. I wanted to come up with few things, not many, which would trigger the thought process in my team to start thinking about why did that happen.
As Mike Cohn pointed out in his article, Metrics can be a very useful tool on a project. Choose yours wisely—and remember that it is possible to manage some aspects of a project without metrics
In devising or considering metrics for your project, keep in mind these guidelines:
- Measure only what can be measured. I’ve come across a number of metrics lately that attempt to measure the business value delivered by each small feature added to a project. If the features are too small, measuring the value contributed by each doesn’t work. For example, what is the value of adding delete key support to a word processor?
- Measure at the correct level and in the correct units. Measuring the number of defects discovered per hour can be misleading because vastly different amounts of testing occur during different time periods. A better metric would be the number of defects discovered per hour of actual testing time.
- Measure something only if you plan to act on the results. There is a cost to collecting metrics. Don’t incur these costs unless you plan to act on the data.
There are so many agile metrics available to track the progress. There are few which are fairly common, like Velocity, Burn Down Chart, etc.
In my personal view, I believe these metrics are good but they lack the level of details team will require to trigger.
In my view, there are 3 metrics by which team should be able to measure their progress. And again, I am not saying these are the only ones, there could be more depending on what you want to measure.
- Tracking the change in the velocity
I am not sure what to name it, perhaps the agile community can help me in naming this. This is more measuring the velocity sprint by sprint and help team realize that they are actually making progress.
Its fairly easy, just track the velocity of your previous sprint and current sprint, calculate the percentage change in the velocity. This will tell team whether they are improving in delivering more story points per sprint or not. I understand, there comes the question of observer effect and because of that team will tends to hype the story points. Well to that question, I have two answers. One, if at all that happens it will be proportionate for all sprint, not just for one sprint. And two, this metric is a complementary to next metric. Have a look at the below metric and see if this helps us more.
How is this calculated?
To understand the calculation behind it, if team’s Sprint 1 velocity was 30 and sprint 2 velocity was 40, then change is velocity would be (40-30)/30*100 = 33.3333
Some organization might want to put cap on the this metric, let’s say 10%, may be defined as control limit, to ensure the change is velocity is sustainable and is because of teams effort.
- Tracking the commitment delivery
This is the best metric in my view which one can trigger the thought process in teams head and help them thinking what happened, if at all there was a miss in delivery. Some people also call it committed v/s delivered. I prefer it to be calculated based on the percentage of number of stories committed v/s number of stories delivered. This is good indication for anyone to understand if teams commitment to delivery is in good health or not. If not, then the reason behind it can be explored more in detail and fine ways to improve it.
How is this calculated?
At sprint planning, let’s assume team committed 6 user stories and they delivered 6 of them, that means their commitment delivery is 100%. On the other hand, if they committed 6 and delivered 5, then their commitment delivery is 100-(6-5)/6*100 = 83.3333
- Backlog Health
As we all know that agility is also measured on bases of the work team has in their backlog. How much work they have in their backlog and also what is the health. Scrum process relies heavily on constant grooming of user stories and making them ready (based on definition of ready) to be picked in the upcoming sprints. Hence, it is good to calculate the Backlog Health. To calculate this, first we will have to find the average velocity of the team. Second, considering team is constantly grooming and they are putting estimates as a result of their grooming, Backlog Health is the rational number generated by summing of all the estimates of the user stories sitting in teams backlog and average velocity.
How is this calculated?
Team’s average velocity is 33 and the summation of all the user stories estimation in team’s backlog is 100 (not including the user stories in active sprint), then Backlog Health is 100/33 = 3.0303