Show all posts
10 years ago

Should You Measure Individual Velocity?

We are receiving more and more requests to add individual velocity measurement in TargetProcess. People want to see this information and use for iterations planning. But is it required to measure individual velocity? What caveats such calculation has? It may be not clear initially, but there are some problems with individual velocity for sure.

What is an individual velocity? It is a measure of how much effort a person may complete in a defined time frame. In agile development time frame is an iteration. If Ted completed several tasks with 40 hrs of effort in total and Jerry completed tasks with 25 hrs effort only, we should say that Ted has better velocity in last iteration. Does it mean that Ted is a better/faster developer? Not at all. There are hundreds of reasons why Jerry completed less. He helped other developers with tasks and mentored them; he got serious headache during two days in a row and did almost zero progress; he had two birthday parties last week and his performance was no good next day after each party; one of his tasks was underestimated due to unexpected performance problem with third-party component. We can bring many more reasons on the table. Performance in last iteration says nothing.

OK, but what about average velocity? Surprisingly, Jerry’s average velocity is 54 hrs per iteration. Gosh! What happened with Jerry last two weeks? Will his 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? But we still don’t know how much effort Jerry will complete next iteration. The good guess is from 25 hrs to 60 hrs. Is it helpful? Maybe, a bit. Is it worth the darkside of the individual velocity measurement? And sure there are some problems with it.

Individual velocity measurement has wrong focus on individual performance. The focus should be on team performance, individual performance is not important. If Jerry 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. The right solution is to measure team performance, but in agile development we already have team performance metric, it is a well-known iteration velocity - very good, very simple and very helpful metric that enough for iteration planning. Individual velocity will not bring additional benefits there.

Individual velocity measurement forces work assignment, while in agile teams it is all about work commitments. Team should do a commitment to complete as many user stories as they feel can be completed during next iteration. On iteration planning meeting Jerry may feel bad about his poor performance in last iteration (yes, developers know their performance without measurements) and will commit to 70 hrs work items in total and complete them all with courage. If you measure individual velocity you tend to assign stories based on numbers you have in hands. “Hey, Jerry, are you kidding? You did only 25 hrs last iteration, how are you going to do 70 hrs?” It is good if Jerry has courage to answer something like “Just believe me, I will do that” and project manager/Scrum master agrees and allows Jerry to make such commitment. But Jerry might think “oh, he doesn’t believe me… Well, let it be, I will take 50 hrs, it is close to my average velocity”. Individual velocity may demotivate 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 (especially when your project is in troubles).

I don’t see much value in individual velocity, but I do see many problems it may cause (or hide, or support).

  • Wayne

    Great post! Seems like every team transitioning to agile goes through the stage of wanting to track individual velocity. This is a great way to reinforce the concept of team delivery of value rather than individual delivery of tasks.

  • Evan Leonard

    Thank you for taking a stand on this issue in the face of contrary customer requests. And thank you for presenting your points logically and clearly.

  • agile-tester

    What puzzles me is that there are actually clients that claim to do or be agile, and still request these kind of things…scary and dangerous!

    Agree with you!

  • Gerald Williams

    In a word – no. Team velocity is what counts. The team soon get to know who is pulling their weight and who is not through the daiy meetings and then you can do something about it. Besides – do you really want the hassle of measuring individual velocity, what use would you put it too. I think the team have more productive things to do than compiling individual metrics, 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.

  • Evan Leonard

    Thank you for taking a stand on this issue in the face of contrary customer requests. And thank you for presenting your points logically and clearly.

  • Kedar Potdar

    Team Velocity is very important no doubt about it. But I also think Individual Velocity or Developer Velocity is equally important. Although it has some side effects, it also gives a Product Manager the ability to form teams appropriately. mix and match for parallel cycles etc.

  • indigo777

    In agile methodology, any velocity is a team velocity, by definition. As for individual developers – it’s called productivity, competence, speed, the combination of several those factors that contribute to the team velocity.

  • Chuck Harvey

    Very interesting conversation. I have one question. If all you measure is team velocity then how do you get visibility into the productivity of each engineer on the team? If all you measure is team velocity as a basis for productivity then you are flying blind when it comes to understanding if each engineer is being productive and pulling their weight.

    Complete transparency is the best practice in my experience and understanding productivity at an individual level is critical. In professional sports you capture metrics for every person on the team. Great sports teams that win consistently care about metrics for every member of the team. It is the measure of the value you are getting for each team member. The metrics will tell you where you want to make changes based on who is delivering in each game.

    This argument would say that you should not care about each position on the team and only care about weather the team is winning or losing. But if the win’s are coming as the result of one great individual but 10 player that are just OK, what happens when you lose that one great player? All of a sudden you have a losing team. You have to care about each team member to have a great team.