Learn how I can make a difference #thatsIntelligence


read more @ www.agileatwork.co.uk

Agile Velocity

I was in a meeting recently explaining some ideas on how we could track velocity within a team I was leading. When the ops manager I was talking with finally came clean and admitted he had no idea what velocity was! And why was everybody talking about it and could I just explain in simple terms what it was all about!

Well that's one of the problems with IT and especially agile people... we do love our buzz words.

Planning Poker being played

So what is velocity?

Well - There's probably lots of subtly different definitions.. but put simply - It's a measure of how quickly the team deliver's 'done' items of functionality over a sprint.

I've just read that back and to be honest there is nothing simple about that explanation! So no wonder he still looked confused afterward!

So perhaps if I explain how velocity is calculated it will help!

So how do you calculate the team's velocity?

With every sprint a number of user-stories should be selected and committed too..  Each of these stories should be estimated with a number of story points, typically these are based more or less on a Fibonacci number sequence scale (1/2, 1,2,3,5,8,13,20,40,100) - Fibonacci number sequences are fascinating being found in nature and used in computer science (Fibonacci search technique and Fibonacci heap to name just two uses)   - The numbers we use in planning poker don't exactly stick to this sequence.... 1/2 has no place whatsoever in a Fibonacci sequence and 40 should be 33!

There are various methods of estimating work - planning poker is just one and I've blogged about several techniques in the past - but for now suffice to say that every story (and perhaps task) of work should be estimated with a relative amount of effort to complete.

At the end of the sprint you sum up all the story points which are 'done' (remember it's important to enforce that definition of done) and that's the team's velocity!

So - If you have 10 stories and via planning poker or some other estimation technique you decide that each task is worth 8 units of effort and you complete all 10 stories the velocity for the team in that sprint is 80.

You can now start to use this figure in planning - Both for helping to establish how much work the team should commit to within a sprint - The best logical order to do work and for producing burn-down or burn-up charts (my favourite is a burn down chart)

I tend to use an average velocity figure for planning - You should expect that the velocity figure will probably change over sprints (hopefully upwards)

In the past I used to calculate the average from the 2nd sprint onwards (I always assume the 1st Sprint might be a little different as the team beds in) and than use standard deviation to exclude the unusual sprints! more recently I've been calculating the average on just the last 3 or 4 sprints - I don't have definitive proof! but this does seem to give a more realistic velocity figure and tends to allows for improvements to filter through quicker to the average and be reflected in the burn-down charts

Hopefully that's explained Velocity!

Thanks for reading

As always... Feel free to connect with me on LinkedIn