In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.
What does velocity refer to?
The concept of velocity signifies:
The speed at which a Development Team converts Product Backlog Items into a Product Increment that is RELEASABLE.
Pay particular attention to the highlighted word. Feature velocity is applicable when a Development Team can deliver an Increment that is releasable at least once per Sprint. In this case, Done = DoD = releasable. Awesome!
But even in this case, velocity does not show:
-
Whether the client’s problem was resolved.
-
Whether team is working on the highest priority problems.
-
Amount of value delivered.
-
Level of client satisfaction.
Velocity only shows that the team was busy with something.
But is this an accurate measure of the success of the products and services? Do the clients value products based on how busy company’s staff are?
To put it another way, Velocity reflects the volume of a Development Team’s output. Unfortunately, this is not enough for the creation of successful products and services.
The feature velocity of component teams = 0
Component teams have the most stable feature velocity. Because it always equals zero. Component teams are by definition not able to convert Product Backlog Items into value for a client. At a minimum they need integration with other component teams.
When a team has Undone work
In my opinion, the most dangerous dynamic arises in cases where a Development Team is not capable of generating a Product Increment that is releasable each Sprint. This means that Done = DoD + Undone and team optimizes just the part of the whole flow.
Let us examine a system diagram that shows the link between the strength of DoD and organizational agility.
The stronger the DoD, the smaller Undone work in the Sprint. Undone work limits the team regarding the number of potential releases, and, as a result, also regarding the amount of feedback that can be received from the market. The more feedback, the more decisions can be made by the Product Owner on the re-ordering of a Product Backlog. That could be called organizational agility — being able to quickly change the direction of a Product’s development. This may prompt a Scrum Team to undertake additional improvements to create an even stronger and more exhaustive DoD.
By strengthening the DoD, velocity decreases and becomes real
How is the strengthening of a DoD reflected in velocity? The velocity will decrease at least in the short term. But this is not a problem if the goal is flow optimization (shortest Lead Time), learning and agility. Velocity decreases and becomes more real!
But how likely is it that a Development Team would strengthen the DoD, if they know that team effectiveness is evaluated according to the velocity?
My answer is unlikely. Focus on velocity keeps the team away from strengthening their DoD. As a result, that inhibits feedback from market, learning and agility.
Focusing on velocity inhibits organizational agility.
When I was a young and an inexperienced Scrum Master many years ago, I focused my teams on velocity excessively, which reduced their agility and increased the amount of Undone work. Nowadays, my advice to Scrum Masters who are just starting out goes something like this:
Forget about velocity, if your team cannot produce an increment that is releasable at least every Sprint. Focus on strengthening your DoD first.
What should we measure then?
I recommend focusing on metrics that show the ability to deliver actual value to the market and satisfy client’s needs. For example, Scrum.org has developed framework Evidence-Based Management, and is offering a range of metrics that shows:
-
A team’s ability to create value in the long term
-
The speed at which value is generated (Time 2 Market)
-
How much actual value is delivered to the market
In conclusion
I would like to repeat once more the fundamental idea that I want to convey with this article. The basic idea of Scrum is to create an increment that is releasable at least every Sprint. If your team is already at that stage, then the concept of velocity is useful and genuinely demonstrates the speed at which a team converts Product Backlog Item elements into an increment. If not, please focus on strengthening Definition of Done (DoD) and flow optimization.
The Article’s Main Ideas
-
Velocity denotes the speed at which a Development Team converts Product Backlog Items into a Product Increment that is releasable.
-
Velocity does not show whether clients’ problems are being resolved, nor whether value is being delivered, as reflects volume of output.
-
Velocity only shows that a team was busy with something.
-
The feature velocity of component teams is always zero.
-
When team focuses on velocity and has Undone, it is unlikely they would strengthen the DoD.
-
Focusing on velocity inhibits organizational agility.
-
Focus on the value that is actually delivered to the market.