Velocity Is Not A Number

2 figure velocities aren’t bad, but I’m just used to working with 3 figure velocity teams

I was working with Not On The High Street and heard this from a contractor Scrum Master, he played more of a supervisor role but let’s be honest – you can get paid more calling yourself a Scrum Master. I was playing the role of Scrum Master for a subset of a team amounting to about 30 people and rightly playing the role of protecting the team and its performance from such misinformed statements.

My first response was, “well we can stick a zero on the end of each estimate and instead of being a 34 point team, we can be a 340 point team. It wont change what gets done but it will keep the big wigs happy knowing it is a bigger number – despite not understanding what a velocity of 340 actually means.”, it was a somewhat sharp response but the situation warranted the tone.

The key underlying point to remember is that velocity not a number. This goes beyond the argument that some teams estimate tasks by t-shirt sizes and so could not be a number, but imagine the conversation above playing out with comments such as, “I’m used to working with XL velocity teams”. Estimates are relative and the amount means nothing in terms of output and everything to do with projection.

The correct use of velocity is to help the person responsible for delivery identify if the work being done is on track or not. If the velocity suggests that the work remaining is not going to be delivered on time, it is the responsibility of the Delivery Lead to have the hard conversations with stakeholders and find a resolution. I’m not afraid to tell someone I expect a project to go over schedule because I know there is still time to do something about it, I am however afraid to give someone the same bad news when there is no time left to respond to the situation. Remember: people can deal with bad news now, but they hate bad news too late.

Pop Quiz Hot Shot

A good test to ensure a person understands that velocity is not a value to be held against the team is to pose the following scenario:

There are 2 teams; Team A and Team B.
You require each team to estimate and complete 10 tasks.
Team A estimates each of the 10 tasks as 3 points
Team B estimates each of the 10 tasks as 5 points
Both teams complete the 10 tasks in the same period of time.
Which team was more productive?

I’ve heard the answer, “the team with 50 points” more than once would you believe. The real answer is of course that both teams are equally productive. I appreciate this is a trivial and convenient example but it is useful for illustrating the point. If someone asks you to increase your teams velocity be sure to ask for more resource or just bump up each estimate, both approaches will see an increase in velocity but only one will actually increase productivity.

No F*cks Given To Velocity Number

I honestly don’t give a f*ck about the number when it comes to velocity, I don’t give a f*ck about the number when estimating, what I give a f*ck about is what is most important and that is that the sizings are relative to other sizings and reviewed regularly. I often start by letting estimates be assigned and don’t question anything until we have a control batch, at which point I ask questions like “is this story still X points considering this other story is Y?”, and “are these stories both X points, or is one more or less than the other?”. Again, estimates are relative and the key to accurate estimates is to compare and adjust appropriately as more information becomes available.

Once upon a time I was introduced to the concept of estimations and velocity, along with other “sexy” sounding terms – I mean come on, Velocity, it sounds so fast and efficient – give me a break. My point is when I first encountered these topics I took them at face value and believed everything I was taught, for better or worse, until I eventually took a step back to consider what the point of all this was. All these methodologies are great and add value to cohesive teams but if I didn’t dig deep and work to understand why we were doing these exercises I’d just be continuing on as an agreeable employee, keeping my head down and pretending I understand as much as the next team member – which could only last so long.

And one last thing…

3 points is 1 day, so I would say this is probably a 3

Seriously, if you are going to take this approach you might as well ditch story points and estimate based on time. Then your superiors will ask why the commitment didn’t get completed in the sprint period and you can spend your time explaining why you cannot accurately predict the future.