The problem with ‘Commitment’ and using velocity as a measure of success (pt1)

(Note, this post was originally written in October 2010, and than I got distracted by actual work and never got to post it)

Extensions team had a new BA/Product Owner starting soon. Agile is (now, relatively) new to her, but already I see her asking some really great questions as she attends our Stand Ups and Retro’s. These have actually starting me thinking about the answers beyond the usual parroting from what I was once taught. Below are some of them:

Q: I understand that “Velocity” is a way of measuring productivity, but how do we measure it? What units do we use (stories? Story points?) and over what timeframe – is this what we are doing with the start dates we now assigning to stories?

My A:Velocity is a measure as you say. We use the term to denote how many points a team did over a given time period, typically a sprint. We can than average out how many points a team does over a number of sprints to get the average velocity of that team. This allows us to do some planning based on past trends for that team. Some teams use Velocity as a way of judging how much to ‘commit’ to in the next sprint.

However (disclaimer approaching) Velocity changes quite drastically over sprints for a number of reasons, team absence, type of story being tackled, familiarity with the code base etc. Over a long release with many sprints, you should, and generally do, see velocity increase as the sprints go on, especially if the same area of code is being worked on. Velocity will drop back once the team moves into new areas of code or even hit some legacy code with lots of technical debt.

This also got me asking a question of myself:

Q: What is commitment, and how can you make sure a team hits its commitment every time?

A: This is actually a question asked of me previously, but I never published my reply.

Commitment is a target a team sets at the beginning of a sprint as a goal. There are a lot of different ways teams will set a commitment, either;

- By using 'yesterdays weather', that is, the number of 'points' a team completed in the previous sprint, or as mentioned earlier, an average of a number of sprints.

- The team might take all the proposed stories for the sprint, and after planning, make a judgment call on how many of those they believe they can make it through knowing what they do about hte proceeding time period (taking into account Leave, Pub. holidays etc)

Commitment is an often misunderstood concept by people within and without agile teams. In some more rigid applications of Scrum, if a team doesn’t meet its commitment target, the sprint is regarded a ‘failure’. In more extreme cases, the team, upon realizing it won’t meet its commitment may choose to ‘abandon’ the sprint and start again.

In my experience, denoting a teams inability to meet a commitment as ‘failure’ has some behavourial consequences. Teams may choose to under commit to ensure they ‘never’ fail. I have even witnessed teams over-estimate, so they can achieve a ‘higher’ score for the sprint. Essentially ‘gaming’ the system we have put in place.

Other negative consequences of using ‘velocity’ as a form of planning are just that, we focus on a number of points for a set time period, rather than focusing on features. This doesn’t always happen, but can be a consequence of this approach. I prefer to focus on ‘how long will it take to deliver this ‘feature’ to the customer, rather than how many ‘points’ can we complete. I’ll return to this topic in future posts, but I am going to publish this in, admittedly, a half baked manner now, just to get it out there. Comments, disagreements etc welcome.