Very happy to announce that I will be a speaker at Agile Manchester Conference, May 8th!
Here is a link to my talk:
It’s going to be very interesting to present our Ways of Working (a.k.a. Project Magellan) to the external world🙂 Looking forward to get a lot of questions from the audience🙂
… See you there!
In Scrum, we define velocity as the average of the story points finished by the team in the last “x” sprints.
How much is “x”? It’s up to you to decide. I use the average of the last 5 sprints as the definition of velocity for my teams.
There are several different ways that a Scrum team can use the knowledge of their velocity.
The first one that comes to mind is that velocity can be used a measure of productivity. If we have a look at Wikipedia’s article about it (http://en.wikipedia.org/wiki/Velocity_(software_development)), we can confirm that this is the only use that is described there.
By itself, this definition is simplistic, and, in a certain way, dangerous🙂.
Consider this hypothetical scenario: let’s treat velocity as the sole measure of productivity. We are measuring the productivity of a Scrum team which is actually quite motivated.
This team knows that the sole measurement of their performance is velocity, they are motivated, they want to succeed.
What they’re gonna do? They are going to try to get as many story points done during their sprints, obviously.
Sounds too go to be true, no? That’s because it actually is.
The ugly truth is that, after a certain plateau, if a Scrum team tries to artificially inflate their velocity (we all want to be winners, right?), they will deliver more product, together with an ever increasing technical debt (bugs, brittle code, you name it).
A sprint, is by definition, a time box. Delivering within a time box builds pressure onto the team – up to a certain level, that is healthy.
But if that pressure increases (even when that increase is self-inflicted), the team will start cutting corners.
One might argue, that a proper Definition of Done, in conjunction with proper demos (at the Sprint Review), will keep the technical debt under control. That is true, but only to a certain extent; even then, the technical debt will increase, on a silent way.
We must remember that we want that our team achieves the best productivity possible at a sustainable pace 🙂.
That’s the key: sustainable in terms of effort, and in terms of the quality of the finished product.
Then a question remains: what’s a good use of velocity?
In my opinion, velocity is more useful as a tool that will help the team do realistic commitments.
Realistic commitments will help the team to perform great, and delivery consistently their commitment at the end of their sprints.
And consistent deliveries will increase the team predictability.
Which will allow that the Product Owner can start thinking in terms on milestones in a roadmap, with more confidence!
And we are talking about creating software here, not making bricks… so that type of predictability is highly desirable.