After 9 months acting as Scrum Master in his team, my client tells me: “I don’t see any improvement in my team. Our average velocity has not changed for several months. What are you going to do?”
My answer: “Nothing!”
His remark allowed us to have a conversation about velocity. What is it used for? To whom is it useful?
In Scrum, **velocity** is the number of story points “done” during a sprint (and “done” depends on the definition formulated by the team).
It is an indicator used to help development teams during their sprint planning sessions. In fact, it allows to assess the quantity of work they can select for an iteration. This indicator can be used by the Product Owner to plan releases provided that the associated cone of uncertainty is taken into account.
**Velocity is not a performance, an improvement, nor a productivity measure. It is not an indicator intended for top management.**
A first item to consider: the estimation is relative, and so is the velocity.
Human brain is absolutely unable to estimate time, distance, or speed. On the other hand, we are quite good in making comparisons. It is therefore the fundamental reason why we relatively assess Product Backlog Items (or PBI). During the assessment, the size (effort) of a PBI is compared to that of existing ones. To facilitate the use of these evaluations, the team allocates to PBIs a number of relative points on a non-linear scale (e.g. the Fibonacci sequence).
What’s important here is that these points are relative and without units. You’ll understand that when one rushes a team to increase their velocity, they simply have to allocate a greater number of points to a given size. However, from the point of view of the user, nothing has changed.
A second item to consider: delivering value sooner is the most important thing.
Your team’s velocity may be phenomenal, if they are working on the wrong functions, your users will end not using them. Besides, it is important to keep in mind that the value assessed by the Product Owner, and entered in the Product Backlog, is only a speculation. The only way to measure if you deliver value is to measure it once users are actually using the software application. They are the ones who can set a value on the functions released. Yet, one has to measure it, and it’s not easy.
As regards the conversation held with my client . . . I’ve questioned him about the different improvements he noticed.
Rapidly, it became obvious that: clients’ satisfaction is better; the team’s forecast is now more reliable during the sprint planning sessions; a PBI’s minimum cycle time went from 7 weeks to 3 weeks; the number of support requests decreased, thus giving more time for developing new improvements; the number of corrections after releasing has noticeably dropped; 3 teams are now synchronizing in order to release a potentially deliverable increment every 2 weeks (1 team at the beginning, then 2, then 3); the definition of “done” has been polished up; the team’s self-organization and self-sufficiency improved, etc.
Finally, whereas the team’s velocity remained stable, we worked on fundamental topics in order to improve the quality, delivery speed (sooner), and value of the items delivered. Another important factor, with the appropriation of the Product Backlog by the team, the PO’s workload decreased. He is still the owner of the Product Backlog. That is, he ensures its integrity and he orders it in order to maximize the value delivered. However, once the need is shared with the team, they collectively take full charge of the PBIs’ refinement. Therefore, the PO can now focus on the other tasks under his responsibility.
**The team improved themselves; still the right indicator must be looked at to notice it.**
During our conversation, my client also understood the importance of planning when velocity is stable and the team committed to refining the Product Backlog. This way, he can have a realistic projection of the PBIs release date. Thus, he can make the appropriate choices to order his Product Backlog.
Finally, when the team understands that they will be evaluated according to the value delivered not according to their velocity, the dynamics change. They no longer race for story points, but focus on increasing delivered value. The team stops having conversations on re-evaluating or not a PBI that is not “done”; it simply goes back in the Product Backlog at the end of the sprint. It becomes usual; there is no longer any sense of “loosing points” (gap between the initial estimation and the estimation of what’s left to be done on a PBI that is not “done”). The same thing occurs when you stop comparing teams according to their respective velocity.
Note: It’s not because velocity is an easily measurable figure that it is relevant.
In your organization, how is the notion of velocity being used?
1 Comment
Good & short article that explains it well.
Got the same discussion a year ago! Velocity is an outcome from a sprint execution (it results from a certain number of conditions and events), a measure that helps you plan your future sprints.
Thanks.