I've worked in the world of Agile for around ten years now, as an 'Agile developer', Scrum Master and Agile coach/consultant for various clients. 

One of the questions I probably hear more than any other is 'We want to increase velocity, how do we do it?' I'll leave you to guess who asks that question! but I'll give you a clue.... it's not the developers! or actually should I say it's not the Agile team! (but that's a whole other blog for another day)

I have a stock answer for this question... and it's somewhat facetious... 'Simple, double your estimates' 

Some of my Twitter followers may have already seen this!

OK it's a silly answer - but actually it isn't any more silly than the question is!!!!

I don't want to delve too deeply into velocity in this article because it's a subject matter in it's own right... but velocity is simply the number of story units achieved over the duration of a Sprint, or iteration, simple enough... but what are those units? the units represent a measure of complexity allocated to each task/job/story - THEY ARE NOT A MEASUREMENT OF TIME! They are a way of identifying if a job is 2 * bigger or 4 * bigger... or perhaps so big they need breaking down further (an epic)

Now that last statement is not strictly true... in fact it's probably wrong! because although  the relative level of complexity is represented as a unit so IS NOT A MEASURE OF TIME! by summing up the number of story points and therefore units 'Done' (or that meet the story acceptance criteria) over a sprint  you get your team's velocity! or if you like speed of working!

However - as a Scrum Master I know not to measure my team by velocity alone.... as I half joked earlier, The team estimates the units for a job - so if they want to increase velocity they only have to increase the estimates! velocity increased overnight! - job done, thank-you very much!! and remember - as a scrum master it's not my job to change estimates or to overly challenge them - only to provide guidance!! and for that matter people outside of the team and I'm talking to managers now have no part in the estimation process.... not unless there a member of the team! and remember velocity relates to the team not an individual or subset! we all work together collaboratively as a team and deliver together! (or sometimes fail together)

Agile teams that work well... really well! the ones that make Agile so famous and brilliant! are Agile teams that are transparent - who are self organising and who trust each other and importantly trust the Scrum Master - once you start trying to measure velocity for the sake of increasing it -  your meddling with that trust! your applying pressure (passive or otherwise) and which in-turn decreases the honesty and I'd rather know the truth than hear the answer a team thinks I want! and besides.... Measuring speed is only part of it!! it doesn't matter how fast your travelling if your going in the wrong direction! 

In my experience it's much better to measure a team by results and 'done' items of work... who cares if a team velocity is 50 or 100 units per sprint??? the important measure.... the one that counts is the measure of completed shippable items of work!! Remember that important definition of done? if your not enforcing that all important definition of done your increasing your 'technical debt' and one day that needs to be repaid... with interest!

So the question really should be..... How can I help my team deliver more 'Done' items quickly... but I'll leave that for another day and another blog! :-)

Written by Christian Miles