Wednesday, April 3, 2013

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 of questions that I get asked whenever teaching velocity that indicate to me that the concept is not particularly simple and there is a smell (to use a developer phrase).

  • How do I account for capacity changes from sprint to sprint?
  • What do I 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 I have them aligned around the same sizing and if so how?
  • Do I measure personal velocity (i.e. by team member)
  • Do UI points differ to Testing points which differ to Tech Writing points etc.?
  • Do I track actual velocity and estimated?
  • How do I track/account for stories that spill over with regards to velocity and what size the story ends up being?
  • Do I get credit for part of the story that was complete (when I don’t hit commitment)?
  • Do you burn up points and then stop work on the story when you have delivered that many points of value?
  • Do I put points on spikes and/or research tasks?
  • Do I put points on bugs?
  • Do I put points on non-dev activities that are in the sprint but required to get to completion?
  • Are points just complexity or what if there is little complexity and a lot of repetition or time?
  • If we change team members do we need to re-calibrate 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 I use?
  • Do I need to reset the velocity when the team changes?
  • Can we have an exchange rate on our points to another teams points?
  • Points aren't real so why should I 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 (i.e. XP teams).


Switching to kanban will resolve many of the issues but only if it 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, then 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.



OnTime Agile

No comments:

Post a Comment