A principle that is not easy to understand by starting Scrum is the calculation of velocity.

Firstly because it is abstract, intangible, virtual. If the velocity of a cyclist is represented by the number of pedal turns made per minute, the amount of work done by a developer – or team – is much more difficult to demonstrate, and it takes a lot of brain work to reach this level of abstraction.

Secondly, the velocity of a Scrum team is now measured in relative value (Story points) instead of the traditional number of days or hours. It is a paradigm shift; we must think differently and it can be difficult.

Do not compare the velocity of two teams

My ears were buzzing when I heard a discussion between two product managers who met in a forum:

– How much Story Point is your team completing every Sprint?
– About 42 and yours ?
– 65
– Oh God, that’s unfair! Your developers are so much better.

This discussion is unfounded, firstly because the value of a story point for team 1 and team 2 is not identical. If team 1 defines that the completion of a user story X is 5, team 2 may evaluate the same task maybe at 8 : so the same task will not have the same value. Worse, team 1 will perhaps have realized its User Story as evaluated at 5 SP in 4 days and team 2 its User Story evaluated at 8 SP in 3 days. To summarize, the relation of the task to the story point and to the time are not the same.
Secondly, how do you compare the work of two teams if they are working on different products, perhaps with different technologies and constraints? What about quality? Are both teams delivering the same quality? Even if you had two almost identical teams working on the same thing, are you sure you want to create a climate of competitiveness? But that is another discussion.
Velocity should be compared only between sprints into the same team in order to monitor progress.

;

Continuing to give a temporal value to the Story Point

One thing to avoid is to give a time base value (hours, days) to the story point within the development team that performs the evaluation. By beginning Scrum this is obviously convenient: one functionality X = Y hours = Z Story Points. However, it is a bad practice because you hide the progress (or regression) of the performance of your team.

Here is the example of what not to do:

If during year 1 your team estimates and realizes a task «X » in the following manner:

Task 1 = 16 hours = 8 SP

In Year 2, the team estimates and performs the same task (team is now more powerful and can perform the same task more easily).

If you calculate in hours the following will happen:

Task X = 10 hours = 5 SP

By the end of year 2 for the same work, the team will realize 5 story points instead of 8 and fill the 3 story points missing by taking some other tasks. Team will be hyper-effective compared to year 1 but through numbers will achieve the same number of SP.

Year 1, only the task “X” was performed for 8 SP.

Task X = 16 hours = 8 SP

Year 2 tasks X, Y, Z are performed, but still for 8SP.

Task X = 10 hours = 5 SP
Task Y = 4 hours = 2 SP
Task Z = 2 hours = 1 SP

Team velocity performance standing (even though it performs more tasks):

Now comes the real process:

Year 1, only the task “X” was performed for A 8 SP :

Task X = 8 SP

Year 2 tasks X, Y, Z are made but task “X” is kept at 8 SP:

Task X = 8 SP
Task Y = 2 SP
Task Z = 1 SP

(Task Y and Z could also have more story point by using the same rule, as well there should be more sprints composed of numerous U.S., but we will not over-complicate this example)
This makes a total of 11 SP for Year 2:

This time the improvement of the team is visible. In the first example the performance of the team was disappearing in the evaluation.

Thanks to Christian Lapointe from Pyxis Switzerland for his help on this post.