Measurement of Individual Velocity in Agile teams.

Adoption of Agile methodology is going through hard, painful process and many organization are paving their way with customized version of flavor. I get very curious to hear stories from different professionals from various organization about how they made it agile work as a work culture.

Of Course Agile or Scrum its just specification… an abstract specifications and team adopt it as their understanding, circumstance, client and nature of work. During the course, you may encounter various cases, where you might find team overrun couple of very core and important Agile aspects and follow the old age waterfall mindset.

Measurement of individual velocity is one of them.It may not be something new to many of us, but it's for decision of consideration of individual velocity in Agile burn down charts.

In one of the project, we had received more and more requests to add individual velocity measurement in Jira tracker. Senior Management wanted to see this information and use for iterations planning. And as suggested we started for a week, but then realization came is it really required to measure individual velocity? It was not clear initially, but there are some serious problems with individual velocity for sure which works anti Agile philosophy.What caveats such calculation has?

Individual velocity is a measure of how much effort a person may complete in a defined time frame. In Agile, each task gets tagged with a time frame iteration in hours or points.For e.g. If Tom burns more sprint points for several tasks within a week and Jerry burns less for the same week, we should say that Tom has better velocity in the last iteration. Does it mean that Tom is a better and faster developer? Judging to yes for this answer is not straight at all. There are hundreds of reasons why Jerry completed less. Being a part of collective ownership, He helped other developers with tasks and mentored them, one of his tasks was underestimated due to unexpected performance problem with third-party component or he was feeling low for a day or two and had almost no progress. We can bring many more reasons in the table. Performance in the last iteration says nothing and the worst thing to count. Then another idea came what about average velocity? Will average velocity help us to make correct iteration plan? If we sum up individual velocities all developers will it help us to create a better iteration plan? No, since we already have Iteration Velocity metric and it will be exactly the same. Why should we care about individual velocity, in this case? To make better assignments for each person? Is it helpful? Maybe, a bit.

Individual velocity measurement has the wrong focus on individual performance. Agile recommends focusing on team performance, individual performance is not important. If an individual resource knows that his velocity is measuring, he maybe will not help other team members a lot. He will focus on his performance as an individual developer. The worst thing company can do is to bind bonuses to individual performance. This nips teams in the bud a bad. Individual velocity measurement forces work assignment while in agile teams it is all about work commitments. In agile methodology, any velocity is a team velocity, by definition.The right solution is to measure team performance with the performance metric a very good, simple and helpful that enough for iteration planning. Individual velocity will only create unhealthy competition, backstabbing and introduce cat mouse race with direct impact on quality. Individual velocity would/can/may lead to individuals trying to ensure they look good at the expense of the teams overall goal - and that is to deliver to the customer. Team should do a commitment to complete as many user stories as they feel can be completed during next iteration. Through every iteration planning meeting, team starts to learn the strengths and weakness of the team as they working together sprint to sprint and will try to find a pace with more robust commitments in total. The team soon get to know who is pulling their weight and who is not through the daily meetings and then they can do something about it. If you measure individual velocity you tend to assign stories based on numbers you have in hands rather team commitments team will fight each other to point out who is smart and who isn’t. “Hey, are you kidding? You did only x points in the last sprint, how are you committing more?”. Individual velocity may de-motivate people, and many managers having it in hands will use it incorrectly. It is very common to revert back to muscle memory of waterfall days and make assignments instead of commitments.

Then “How about recognizing talent for rewards”? Management and even each employee expects a factor to measure his performance. If we only measure team velocity then how do the find the visibility and productivity of each engineer on the team? If team velocity is a basis for productivity then you are flying blind when it comes to understanding if each engineer is being productive and pulling their weight or not. This is very big question where I see most of us are confused. I don't know the right answer, but my experience says, This should be addressed or measured with contribution of the individual developer to the team’s productivity, automation, competence, speed. Each person will vary here and its measurement.

You must have to care for each team member to have a great team. If the team’s win is coming as the result of one great individual but 10 player that are just OK and when you lose that one great player? All of a sudden you have a losing team. So team should be pretty careful about that and complete transparency is the best practice in my experience.

In the end, I think individual velocity is anti-Agile and harm to the team commitment, collaboration and breaks the rule collective ownership. Rather than individual velocity, I would recommend leadership to measure the contribution of individual to the team’s productivity, automation, competence, speed to understand the contribution.