Myths with agile metric (Sprint Velocity)
DEFINITION of ‘Metrics‘ Parameters or measures of quantitative assessment used for measurement, comparison or to track performance or production. In general, metrics analysis is usually associated with establishing success/failure criteria, progress indicators, and benchmarks. Metrics analysis can essential lead to provide a fair assessment towards the journey to maturity of a system/process. As the same time the improper use of Agile numbers is very common and dangerous.
I would like to highlight some of the wrong interpretations of agile metrics by teams/management:
- Myth 1: It is OK to compare velocity of one team to that of another team.
- Myth 2: Sprint Velocity should increase over a period of time and if it does not, it indicates that a team has stopped improving.
- Myth 3: Resource rotation in a sprint team (add/remove/change members with different skills) does not impact sprint velocity (even # of members are kept same)
With my observation and experience to work in a agile ecosystem, I feel a profound need of education, training and open mindset by all (team as well as management and leadership) to analyse metric in true sense to lead team/organization to agile maturity.
- One should resist to compare velocity of a team with another as the team sizing benchmark vary from team to team. One team vary in every aspect from another team. And if remotely one want to compare then prior normalization of story point estimation across multiple teams must be evaluated & applied.
- I have seen sprint velocity going down with time with factors like estimation benchmark changing over a period of time (same time tend to give a small SP to similar story they might have done 6 months ago).
- Also any change of resource or team members brings it’s own challenges (ramp up time, skill set proficiency, getting to understand team culture etc.) and we should consider these aspects on merits.
I feel the fundamental agile concept of ‘individual and interaction’ is the best to deal with any situation in agile or business scenarios. And the team or organization must use this fundamental concept to sail through any situation of confusion/doubt/disagreement.