Are you self-deluding when measuring sprint velocity?
I‘ve seen the outcomes of making high velocity an objective in young agile teams you people wouldn't believe. Attack ships on fire off the shoulder of Orion… Um.., maybe I am not going to talk about Tannhäuser Gate. But certainly, I am convinced that if one understands velocity the impact will be the improvement of the velocity. Even without c-beams glittering. Let’s slow down a bit.
As a matter of fact, focus on going fast could mislead me. So, do I want to run fast or do I want to run well?
Let me ask you a question. What are you going to do to have a high velocity? In fact, why do you track velocity?
Since we decided to measure our velocity when developing in agile at the beginning of the sprint we agree to
- Assign the negotiated value points to some user stories (US) and
- Pick enough US to keep us busy
Then we develop them and at the end of the sprint, we add the story points in order to calculate our velocity. Easy, isn’t it?
As I realized by working with new agile teams and this concept of velocity is not so obvious. The most common reflexes I have observed is to relate story points with productivity.
Once, a developer had carried out some designer tasks. The whole team counted the time the developer had spent as story points and added those points to the sprint velocity. They were dissatisfied when I announced that this work didn’t account for the team velocity. “But, she was working!” they argued “Her work must be taken into account.” “No,” I told them. “This work is not comprehended in our team velocity. We have had a developer working as a designer this sprint, this has an impact for sure as we have not yet delivered value. It is important to know that this issue has effectively slowed down our velocity. What could we do the next time in order to maintain it? Or do we choose not to maintain our velocity? Because the designer tasks were really necessary and it prevents us from rework developed US with the PO”
My interpretation is that the team was self-deluding to keep a high velocity, seeing their velocity as a justification of their daily work.
Another common mistake I have seen is the measurement of the velocity as the amount of US’s points that have been developed, even if the PO didn’t test and accept them. In that case the velocity was restricted to the developers’ team, therefore eluding the responsibility of continuous testing by the PO and giving a wrong velocity as the done-done US had not been respected. This behaviour puts delivered quality at risk and shifts the burn-down on the developers’ shoulders. Are you really going to demo US to your stakeholders without knowing if they have been correctly implemented? If you are lucky, the US will be correctly implemented. If some bugs are present you are creating technical debt that will be slower to fix and will increase cost of development.
Since the time needed to fix the US will be included in the next sprint you are in fact deteriorating your lead time, i.e., the time between the creation of the US and its delivery in production.
Once I told to a PO that I didn’t agree with her measured velocity as the real velocity was zero. None of the US had been accepted for the sprint. She answered “yes, but a zero velocity is sad”. What to do about it?
Is my car running fast enough?
We are in a car and we want to know when we will arrive to destination. We measure our average velocity every 50 Km.
This is the velocity that the team reported:
This is what we understand with this measure:
This is the real velocity (done-done US):
And this is the reason of the real velocity:
What I mean is that if you are not strict when calculating your velocity, you reinforce the chances of not detecting the issues that sway your work. When your team is facing obstacle, it is normal that velocity goes down. When the team removes obstacles, then the velocity goes up again.
Do I want to run fast or do I want to run well?
Let’s assume that my purpose is to run faster and I am self-deluding (in the same way I observed when working with the teams) to measure a high velocity. I can forsake some weight, eliminate seats and other stuff, I can strip down the air conditioning system, put narrower pneumatics to reduce friction, change my windows for the lighter Plexiglas windows… Ok, ok, at the end my car will look like something you people wouldn't believe.
After such extreme car tuning the velocity will rise. Nevertheless, if there is a cow on the road in a known area with domestic bovines free, my previous measures won’t be very helpful. I didn’t objectively observe and measure my previous sprint. As a consequence I am scorning how to predict obstacles. Even more, I am refusing the knowledge obtained from testing related solutions to that hitch, thus neglecting any possible improvement (other way of self-deluding to have a high velocity could be to overestimate the assigned points to the US in the planning game. Fortunately, I never saw such a practice with my teams).
In the other side if I consider that my purpose is to run well I will possibly consider other priorities, as the comfortability of the cabin, the isolation… and I will be likely more receptive to collateral impacts of my decisions. I will analyze which elements contributed to my velocity. If the event the produced the slowdown of velocity cause to occur again, I will take advantage of my previous experience.
This is why I am not afraid to measure a zero velocity for a sprint, even if it is sad. And the reason that makes a high velocity is not my aim. Velocity is a tool that I use to work continuous amelioration by analysis (for example in the retrospective) and, so doing, I will improve my velocity. Time to live.