Velocity: How to interpret it to improve your agile team productivity. 1 of 3: Flavours of Velocity

Velocity is a commonly used metric in agile teams. It is a great metric due to its apparent simplicity. However, I often see teams drawing the wrong conclusions for the metric, which results in decreased productivity. 
This post is the beginning of a three-part series to convey my understanding of how to make sense of the information that velocity, as a metric, can provide to an agile team. And use this information to improve the team’s productivity.

What do I understand by Velocity?

I do not know where Velocity, as a metric, was first referenced. I am aware it is intimately linked to Scrum teams who use user stories. However, the current Scrum Guides have no explicit reference to velocity.

Schwaber’s original paper in OOPSLA 95, casually mentions the concepts of “project velocity and acceleration”, but does not specifically refer to it as a metric. In Mick Cohn’s “Agile Estimation and Planning”, the use of Velocity is well developed, and this book has been the textbook I’ve used when teaching agile estimation at the University. 

In this series, I will convey my understanding and use of the metric velocity.

Measurement, measure and metric

Before we begin with Velocity, we need to disambiguate our language about software measurement. Measurement, measure and metric are three words that represent three different concepts, and yet I often see these words used as synonyms. And it is important to differentiate these concepts to make good use of the software measurement process.

Measurement: This is the act of comparing a distinguishable attribute of an entity against an agreed pattern. 

Measure: Is the result of the act of measurement and should be expressed by a number and a Unit.

The concepts of entity and attribute are key to the understanding of measurement:

Entity is the object that is being measured.

Attribute is the characteristics of the entity that is being measured.

A metric, brings all these concepts together, into a construct that is identified by a name, and defines the entity and attribute being measured, the measurement process and unit, and the indicator.

I will use the following format for defining a metric in this series:

Name	<Name of the Metric>
Entity	<Name of the Entity>
Attribute	<Name of the Attribute>
Measurement	<A description of the measurement process and formula>
Unit	<Name of the Unit>
Indicator	<A description of the criteria for use of the metric>

With this, we are ready to define Velocity.

The three flavours of Velocity

When following this understanding of Measurement, measure and metric, we can observe that Velocity is an overloaded term. Therefore we need to disambiguate the types of metrics that are related to velocity.

First, daily velocity:

Name	Daily Velocity
Entity	Team
Attribute	Productivity
Measurement	Daily during the Sprint: – Sum points of completed User Stories – Subtract from total user story points in the sprint – Add the point for the day in the burndown chart
Unit	Story points/day
Indicator	A comparison with ideal velocity for the sprint. Typically graphed in a burndown chart.

It is in the burndown chart where the concepts of velocity and acceleration (mentioned in the Scrum original paper) can be observed. Daily velocity is the distance between two consecutive points, and acceleration is the slope. 

The naive interpretation is that, on days when the daily velocity is above the ideal velocity of the spirit then the slope is bigger than the slope of the planned velocity for the sprint.

Acceleration is observed every time that slope changes angle. 

Typically, when looking at burndown charts, teams tend to focus on remaining work and the difference from it to the ideal trend, not in velocity. As a result, they place a lot more emphasis than needed on being close to the ideal trend line. Meeting the estimate is not the goal (more on this fallacy next week), particularly, because neither velocity nor remaining work, are measures of value.

Moving on to Sprint Velocity:

Name	Velocity in the Sprint
Entity	Sprint
Attribute	Work performed
Measurement	At the end of the sprint: Sum points of completed user stories
Unit	Story points / Sprint Name || number
Indicator	Comparison with the estimated story points in the sprint (*)

This flavour of velocity is useful for reviewing the recently finished sprint. Yet, this is not a metric that is particularly meaningful in isolation. Teams should avoid qualifying the success of their sprints on this metric only.

Finally, average velocity:

Name	Average Velocity
Entity	Team
Attribute	Productivity
Measurement	The Sum of story points of past sprints / Number of sprints considered (**)
Unit	Story Points per sprint
Indicator	N/A

This metric is used to inform planning, therefore, I have never worked with an indicator for this metric. 

Story points are the final bit of this puzzle. Story points are the unit of complexity of a story point. Most of all, I would stress that story points are not used as a proxy of effort, nor should they be grounded on effort. 

This is a common mistake, where N Story Points are equated to a day of work. Teams doing this, are effectively preventing themselves from observing one of the project management dimensions.

The scale most used with Story points is the Fibonacci Scale. However, the confounding factor is that in agile estimation we use this scale to encode two concepts (measure and appreciation) in the same number. As you move rightwards in the Fibonacci scale, the difference between two consecutive numbers increases. In agile we use this to communicate uncertainty about a complexity estimate.

So, If my Story point complexity is 3. Then my uncertainty is between 2 and 5. But If my story point is complexity 13, then my uncertainty is between 8 and 21.

Summary

This post has established the groundwork for the discussion on how to use Velocity in agile software development. Next week, I’ll post about how to interpret these metrics, followed by a short Q&A post the following week.