I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.
I was listening to an episode of the DotNetRocks podcast about Agile Metrics. There was an interview with Michael ‘Doc’ Norton about his experiences figuring out the right metrics to measure for the productivity of a development team. The basic issue discussed was that Velocity is a dangerous metric to rely on as a goal or target.
Velocity is a measure of units over time, so in an agile iteration or sprint, that would be the number of story points completed in the iteration. This is a dangerous metric because it is misleading to management. One week, your team may complete 10 story points in the iteration. Management may then say,
“Well, that’s great, if you can better that to say 12, we might finish early.”
The team, then starts their next sprint, aiming to complete 12 points, but they end up only completing 5. This is like a red rag to a bull to management, but this could be a valid scenario. The velocity of 12 from the previous sprint may have been achieved because all the development tasks where contain within the development team. If as part of the next spring you need input from other teams or departments, then this could affect your ability to get work done as planned. This just one example of an external influence affecting velocity, you could have people go of sick, on holiday, or anything else that can happen that is out of the teams control.
It is because of these external influences that the velocity metric becomes a bad metric to rely on. There is just too much variability in the numbers from sprint to sprint. This doesn’t mean you should ignore velocity completely, but managers should not ask teams to hit targets based on velocity.