It is against the Scrum Framework to measure the velocity of each individual team player.
Here is a case study, which I’ve created to help you understand why Scrum says measure the team & not the individual.
Back ground: Meet John & Mark
- We have 2 developers, John & Mark
- Both are highly skilled in their own area of the code base for the application which they develop
- The business know the overall team velocity but want to know how many points each individual developer can complete
- It has been established that on average:
- John completes 5 points a week
- Mark completes 10 points a week
Looks are deceiving
On the surface it looks as though Mark is ‘better’ at getting work done then John. But what if John completes a significant amount of work which helps the entire team’s overall velocity by story points?
John works in a part of the application, which has a far, more challenging code base. In other words when John develops ‘stuff’ he has to re-factor allot of the existing code around the new feature he is implementing to ensure that the application’s health is improved and maintained. This means it will be easier for others to create new code in this challenging code base in the future. But, the time John spends re-factoring the code is not recorded in points. John also needed Mark’s input into part of the code base he is less familiar. Mark (as the ‘highest point scorer’) is more focused on delivering what he needs to deliver and is thus less helpful and less enthusiastic in helping John. John will continue coding with less knowledge and essentially create software, which could compromise quality – the other side effect of course is that measuring individual velocity creates an unhealthy competitiveness between team players.
To summarise, focusing on individual velocity points is:
- Misleading since there are tasks completed by developers which are not accounted for by the story points
- There will be LESS QUALITY in the software created because developers will be less concerned with tasks such as re-factoring code & helping those with a knowledge gap because of their own focus to focus to deliver points individually
- It creates an “everyman” for himself mentality which is against the humanistic fundamentals of the Agile mindset
- Finally, SCRUM is a framework that is built on a team effort – measuring individual velocity begins to separate the team player mentality
In my humble experience, when the business are measuring each individual’s velocity it usually comes down to a lack of trust. When the business does not have trust in technology they begin to micromanage and want to know who does what on a day-to-day basis. In their mind, the points achieved by each individual developer are an indicator at how ‘good’ they are at their job. This mindset is oblivious to the non-measured tasks that developers carry out which are fundamental in creating high quality software (helping one another to look at parts of the application a developer is less familiar with, re-factoring etc) , spreading knowledge team players (taking time to engage and spread knowledge with a team player mentality), keeping the application in a healthy state (again taking time to refactor for example)
The irony is, this micro management technique reduces team morale, increases work pressure and ultimately reduces the quality of sofware.
All of the things that Agile & its Scrum framework are not.
If you are concerned that a team player is not pulling his/her weight, trust me a real Scrum team will pick up on this and they will not last very long. Be it the daily stand up, sprint planning meeting or the retrospective. There are many events within a Scrum team that highlight who is pulling their weight and who is not.
Individual velocity management isnt the way to do it.