You have to drive this road, it's full of impediments:
this is your truck, it's loaded with technical debt, you have no choice other than bring it with you:
would you swap your truck with this car ?
obviously not. You don't need more horsepower, you need to clean up and "tune" your road (process) and get rid of technical debt first.
In Agile, Velocity is supposed to help teams in being more predictable.
Velocity measures how many units of estimation are completed in a given interval of time.
Units of estimation can be ideal time, story points, whatever.
Story points are the typical choice so it is pretty common that velocity is expressed as story points per iteration.
Units of estimation can be ideal time, story points, whatever.
Story points are the typical choice so it is pretty common that velocity is expressed as story points per iteration.
The idea is that looking at past average velocity it’s easy to “predict” the number of story points that the team will complete in each iteration.
Unfortunately things are not that simple.
Here are some thoughts and remarks about velocity and why you should not rely too much on it.
First ask yourself these questions:
“are we going in the right direction? how much value are we really delivering?”
This implies knowing the product vision (we all do, don’t we?) and constantly verifying that our results are aligned with that vision and valued by customers (let’s assume that we know how to measure value, unfortunately this is yet another tricky issue).
Being fast but producing functionality that is not valuable to the user is waste.
“are we going in the right direction? how much value are we really delivering?”
This implies knowing the product vision (we all do, don’t we?) and constantly verifying that our results are aligned with that vision and valued by customers (let’s assume that we know how to measure value, unfortunately this is yet another tricky issue).
Being fast but producing functionality that is not valuable to the user is waste.
Velocity can never be constant due to inevitable fluctuations:
- Incomplete/Rejected stories (a sprint could also fail completely leading to a zero velocity)
- Wrong task/user story estimations. Over or underestimating means that sprint velocity can be significantly different than expected. (estimation is yet another tricky issue, more about this in another post)
- Dependencies (i.e. having to wait for other tasks to complete). Dependencies should in general be avoided, but this is not always feasible.
- Impediments. i.e. server failures, missing/malfunctioning tools, …
- Changes to the process that could cause temporary rundowns
- Unplanned bug fixing activities (i.e. to address blocking/urgent defects)
- People added to or removed from the team
- People being sick, on vacation, etc.
Average velocity is supposed to balance these variations. However events like a failed sprint can impact it very badly.
- Incomplete/Rejected stories (a sprint could also fail completely leading to a zero velocity)
- Wrong task/user story estimations. Over or underestimating means that sprint velocity can be significantly different than expected. (estimation is yet another tricky issue, more about this in another post)
- Dependencies (i.e. having to wait for other tasks to complete). Dependencies should in general be avoided, but this is not always feasible.
- Impediments. i.e. server failures, missing/malfunctioning tools, …
- Changes to the process that could cause temporary rundowns
- Unplanned bug fixing activities (i.e. to address blocking/urgent defects)
- People added to or removed from the team
- People being sick, on vacation, etc.
Average velocity is supposed to balance these variations. However events like a failed sprint can impact it very badly.
Velocity figures can be biased in many ways:
- people working overtime
- taking short-cuts, i.e. adding technical debt
- people working overtime
- taking short-cuts, i.e. adding technical debt
- stories not really “done”
People cannot work overtime forever, technical debt will eventually slow down development etc.
People cannot work overtime forever, technical debt will eventually slow down development etc.
A quick note about acceleration: it has been suggested (i.e. metric acceleration) that teams should constantly improve/increase their velocity. I don't buy this. If you keep accelerating the end result is invariably a painful crash. BTW sustainable pace is one of the 12 original Agile principles. I would forget about acceleration.
However, velocity can increase in discrete steps. This happens as a result of process improvement initiatives and actions usually agreed upon during Retrospectives. The following figure shows what happens in these cases:
In general you should look beyond velocity and focus on the tuning and optimizing your process (BTW "see the whole" is one of the key Lean Principles).
Velocity should never be a target, people change their behavior when they know they are measured. That’s a recipe for gaming. i.e. you assign more story points to each story et voilà you are instantaneously faster It’s even worse if you try to measure individual velocity (a definite no-no).
Setting velocity targets can generate additional bad behaviors like increasing effort spent on estimating. People wants to be extra-sure that estimates are correct so that velocity is calculated correctly. This is a stupid waste of time and money.
*there is a simple way to avoid all these troubles with velocity: if you can, just avoid estimating stories ...
Final thoughts
Velocity does not imply effectiveness: being very fast but not doing the right things and/or not adding business value is worthless.
Remove impediments, tune-up your process, get rid of technical debt. Focus on these goals and ignore velocity. After you have done that, than you could try to look at velocity figures (but check *).
And remember once again: sustainable pace is one of the key agile principles.
