Velocity measuring on individuals

In scrum the ideal world would be a world where a team is homogeneous, fully commited and every team member is multi-disciplinary such that the behaviour of the team becomes more predictable. However in real life, and especially in a setting where waterfall is the fundament you have to work on, this is usually not the case, facing members working part-time, having holidays and getting sick sometimes but most of all having different backgrounds.

Your goal as scrummaster is to optimize the productivity of the team. This means you have to suggest and steer the team in the process where needed in order for them to work as optimal as possible. This suggesting and steering is probably based on intuition, best practices and so on. As scrum is just a set of guidelines and rules there is a lot of open space on how to cope and handle situations like these. One could jump into detail and/or work on a higher level, inspect and adjust, try new methods etc. etc..

The problem is that sooner or later some manager or CEO would like to know what is happening and in which direction the project is going or what can be done to improve the project.
Usually the velocity of the previous sprint will give a good insight on what can be accomplished on product backlog (remember in the ideal scrum world it would be). The uncertainty is that the balance between all disciplines of each story is different. Some are real tech stories and whereas some are design/user interaction stories. This makes it hard to predict the outcome thus increasing the risks involved.

Now what can be done to reduce this risk? The most obvious is knowing what is happening: who is doing what at which velocity such that team velocity becomes more predictable. This implies gathering data, analysing, reporting and so on.

As we start walking down this road i get the creepy feeling something is wrong since we like to keep things simple and cut waste (reports). Focus on being productive is what we want right?
Using this method also reduces the agility in which one assumes it is ok not to know everything right now.

On the other hand:
Knowing the velocity of each team member provides better individual feedback and enables adjustment on the velocity on each member as each team member should/could work on roughly the same velocity, making the team more homogeneous.

Probably the best option would be to apply the statistics when:
– You got the impression the balance between the different fields/disciplines is off
– There is a need to give a more accurate estimate on the product backlog and identify risks.
– More accurate estimates on a single story
– Times off fluctuation in availability (holidays)

If the outcome on the individuals shows big gabs, then perhaps it is time to discuss what the meaning of a storypoint is and what causes these differences.
-are too many disturbances?
-are some members working harder?
-is the concept of a storypoint still clear?
-are the estimates during the sprint planning correct?
-…..

Too be continued…

3 responses to “Velocity measuring on individuals”

  1. Marianna says:

    You have good ideas on how to make a team work efficiently and at the same time productive. However, a team can never be homogeneous. Every member is first of all independent, meaning that works under his/her own rules and have their own points of reference or as you said yourself, different backgrounds.

    I think that making a team efficiently you should just try to inspire them and continuously motivate them. I don’t know much about scrum and agile but I believe that if you on the one hand motivate them and on the other hand reward your team members on what they achieve then you could expect good results.

    Oh and something else…be gently when you try to inspire them….do not be too harsh on them 🙂

  2. Nicotine says:

    This is my first visit here, but I will be back soon, because I really like the way you are writing, it is so simple and honest

  3. Gooner says:

    One of my friends already told me about this place and I do not regret that I found this article.

Leave a Reply

Your email address will not be published. Required fields are marked *