The Problem with Velocity

There is a smell in Agile around velocity (and estimation) that has not been resolved yet. So what is wrong with velocity? Below are the myriad questions that I get asked whenever teaching velocity that indicate to me that the concept is not particularly simple and that there is a smell (to use a developer phrase).

observer effect agile

  • How do we account for capacity changes from sprint to sprint?
  • What do we do with capacity when the team is particularly cross-functional in nature and has developers and non-developers on it (e.g. testers, business analysts, UI, tech writers)?
  • When the backlog is being supported by multiple teams, do we have them aligned around the same sizing, and if so, how?
  • Do we measure personal velocity (i.e. by team member)?
  • Do UI points differ from testing points, tech writing points, etc.?
  • Do we track actual and estimated velocity?
  • How do we track/account for stories that spill over with regards to velocity, and what size the stories end up being?
  • Do we get credit for part of the story that was complete (when we don’t hit commitment)?
  • Do we burn up points and then stop work on the story when we have delivered that many points of value?
  • Do we put points on spikes and/or research tasks?
  • Do we put points on bugs?
  • Do we put points on non-dev activities that are in the sprint but required to get to completion?
  • Are points just complexity, or is there little complexity and a lot of repetition or time?
  • If we change team members do we need to recalibrate the points?
  • If we take velocity as an average of the sprints, how do we account for different capacities in the sprints?
  • Is velocity a rolling average or the average from day one forward?
  • If rolling, how many sprints should we use?
  • Do we need to reset the velocity when the team changes?
  • Can we have an exchange rate on our points to another team’s points?
  • Points aren’t real, so why should we use them?
  • If we do extra work in the sprint that wasn’t planned for, do we get credit for it?
  • Should the goal be to increase velocity each sprint?
  • If multiple teams are working off the same backlog, do they have to be using the same point values?

I have answers for all these questions and I am not going to go into them here. My point is that the concept of velocity is not as simple as it seems on the surface, and in fact has some serious flaws.

So what is the solution?

If velocity is not a problem for your team because you have found something that works, then yay! Stay with it. I have seen it work well and not so well. It seemed to work best in teams that were comprised solely of developers that were pair programming (e.g. XP teams).

Switching to Kanban will resolve many of the issues, but only if Kanban fits your release process. Unless you are making use of inspect and adapt at the end of an iteration (which is what iterative development gives you) then you may as well ditch iterative development and go with a flow system like Kanban. Or, if you release to a heartbeat cycle and whatever is done by the next release point gets in, Kanban might be a better fit also. Kanban has a different approach to throughput than velocity, that does not raise all the questions above – hence the recommendation, but only if the process fits.

Otherwise, watch this space, or please let me know if you have any ideas or have seen something that works to resolve this aspect of iterative development.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.