In Endless Pursuit of Improving ‘Velocity’
More Velocity brings more PBIs to completion and not necessarily more value out from those PBIs
Story points are tagged as an outcome of relative estimation to the Product Backlog Items (PBIs). What comes when we sum up this number at the end of the Sprint for the ones that are marked ‘Done’ and accepted qualifies to the Scrum Team’s Velocity.
No wonder you are yawning to read this definition for the nth time in recent times from blog posts and articles.
Even I too agree to that. But, have we got the real intent behind why we need to measure and show improvements in Team’s Velocity?
Velocity is one classic ‘Vanity Metric’ which can be easily measured, monitored and also manipulated. Measuring Velocity doesn't bear any direct or say even indirect correlation with numbers that speak about business value and success.
Given the false hope of success and an illusion of making progress, most organizations still believe measuring Velocity is key to their program.
What happens when a leader sets a target to improve the Scrum Team’s Velocity?
The following are some of the cascading effects from the Scrum Team for a leaders’ endless pursuit to improve the Team’s Velocity:
- Start looking out for ways to create Product Backlog Items and inflate the size to match the velocity expected.
- Slice the existing Product Backlog Items horizontally. This approach helps to show enough work pulled and completed in the Sprint.
- Try closing the Product Backlog Items as ‘Done’ and accept the same in the current Sprint immaterial of the work done. Next is to recreate the same set of items for the next Sprint with better Story points.
- Negotiate and skip all relevant work that is required by the Development Team which cannot get tagged with Story points. This approach helps to sustain and improve Velocity. For example, work to be done for refactoring the code and optimizing it. Now with the debate prevailing to tag Story points for such technical optimizations, the Development Team prefers to avoid/delay picking up such timely technical work.
- Start duplicating Product Backlog items one for each role showing more work and extrapolating additional Story points contributing to Velocity Improvement. Remember your Dev Stories and Testing Stories?
- Delay early and often collaboration with the Product Owner and business on the lookout for feedback around the progress made within the Sprint. This practice may threaten the Development Team’s attempt to match the Leaders’ Velocity expectations.
Instead, the Development Team can start piling up all the work done for the last day of the Sprint to get reviewed and accepted in one go. This approach might help to oversee a few challenges with the work done in a last-minute rush. And forcibly make the Product Owner accept the PBIs to done helping the Development Team sustain with the Velocity numbers.
Are we telling that measuring Velocity is totally wrong?
No, not at least till the point the Leader / Management also focus only on monitoring and improving the same.
Velocity is an output metric, a lagging indicator which can be used by the Scrum Team for making their own forecasts and pull work. PERIOD.
Nothing more or nothing less is what we can expect from Scrum Team’s Velocity.
The moment we leak these numbers for discussions within the management to sustain, standardize and improve, the essence behind measuring Velocity is lost. Sorry to say, it doesn't stop there.
The leader himself has built his own strategy to get fooled with these numbers. Get fooled with more and more useless code and Product Backlog Items in ‘Done’ & accepted state, but has no clue on how to infer real progress and value generated out from it.
