One lovely day a (or “the”) manager asks you to increase your velocity by any means, as this way we can achieve a higher productivity. Great. Fantastic. Marvellous. Now what?
Don’t be shy, everyone has experienced this at least once in the his/her agile lifetime. it’s a prefect example of how the notion of predictability is crashing against the wall of complexity and unpredictability (I assert that you already acknowledge the fact that our world, not just software development is complex and unpredictable. If you do not believe the latter, no hard feelings, you can stop reading now.) Can you accurately estimate complexity using velocity?
The short and direct answer is NO.
But what can you do instead? And how can you use velocity? Let us first define velocity.
Velocity is defined as a complementary practice that provides indication of the average amount of Product Backlog turned into a “Done” Increment during a Sprint by a Development Team.
Velocity is not a performance measurement or a comparison tool for the performance of Scrum Teams/individual team members. Velocity does not hold a promise of what will be delivered in the future nor should it be used for long term planning.
What velocity actually does is to provide the Scrum Team with empirical data in order to forecast the speed of turning Product Backlog Items into potentially releasable increments.
Now, I have had this experiences quite a few times in the past. A manager approaches and asks (or demands) to increase our velocity so that we can deliver more and faster. So what do you do if you are a developer? You just use your book of dirty tricks and you increase the estimation, in other words you create inflation and voila, velocity has increased. Management is happy, developers are left alone and the Scrum Master is seen as someone capable who can handle tough situations and push the team towards greatness. And then everything falls apart. Well, not directly but as soon as it is realised the king is naked. Yes, sometimes faster means that you will end up going slower.
If instead you really want to go faster and deliver more value to your customers, take a step back and ask: “What are your impediments, what can we do to remove this impediments and increase your ability to create releasable increments?”. What I have done in a past project, was to sit down with the delivery manager and create a value stream mapping. Guess what, it actually worked. Focus on eliminating waste and removing impediments if you want to go faster and deliver value more frequently.
Oh, and one last thing. Listen to your developers. And to your Scrum Master if you are courageous enough.
Bonus question; “We have estimated our whole Product Backlog, it’s a total sum of 300 points, the team’s velocity is 20 points per Sprint, the Sprint is 2 weeks long, therefore we will finish in 15 Sprints or in other words in 7,5 months. We are committing to that.” Now seriously, how many times in the history of mankind and business has this worked?
Bonus question 2: “The team has committed to deliver X number of points for this Sprint.” Look above.
NoAgile 