2013-07-06

Five questions on Velocity

What is Velocity, really, in software jargon?
  • "Velocity" is a measure on how fast something moves. In, say, Scrum, it translates to how many Story Points we can expect to produce during a fixed time-period. A Story Point is a relative estimate of the effort required to realise a well described User Story, or a user episode, if you like. I have used the term "Gummy Bears" instead of StoryPoints though. The name doesn't really matter.
Why do we want to measure Velocity, in this sense ?
  • In order to allow us to optimise our development speed, as our Velocity should be tightly correlated to our ability to construct software. Getting better at what we do should translate to a higher Velocity, and higher Velocity should reflect overall higher production speed.
Why do you think Velocity is correlated to development speed?
  • We estimate the size of a UserStory in Story Points. We believe we are able to estimate user-stories good enough to establish such a correlation. Sure enough, some times we are overly optimistic, and at times we are to pessimistic. But we believe we are equally wrong all the time, on average.
You only talk about User Stories in relation to Velocity. But I do other tasks as well, such as fixing bugs or upgrading my OS. Shouldn't they count positively against the Velocity as well - it is necessary work that needs to be done, right?
  • Ideally, no - fixing a bug doesn't count positively on the Velocity. You see, spending time fixing a bug, is time not spent building a new valuable User Story. So if you spend much time on fixing bugs, your Velocity should really be expected to go down.
But that's madness - I need to fix my bugs! Why do you say not to fix the bugs?
  • Please fix the bugs! But Velocity is feedback on how fast we are creating new valuable stuff. If you have to spend time fixing bugs, you've done something in the past that prevents you from creating new valuable stuff now. Velocity going down because you need to spend your time fixing bugs, is just an indication that you'r team need to get better at, say, quality assurance, in order to squash those bugs at an early state when they are easy to fix!