When you choose to work within Agile frameworks such as SCRUM you are doing so to receive certain benefits. Two of these are predictability and stability. In order to achieve this SCRUM defines fixed time boundaries called sprints and encourages the team to fix the amount of work to be achieved in this period. Effectively it is turning two of the aspects that are often variables in traditional software development, time and scope, into constants.

The rate at which work is completed in the fixed boundary of sprint is called the team’s velocity. Velocity is a characteristic of how the team works together. In depends how the work is sized, how well the team members collaborate, how good they are at actually completing the work vs managing work in process and many other aspects.  Therefore, is very personal to the team and this is just one of the reasons why the velocity for different teams should not be compared.

Velocity after 1 sprint

Velocity changes too. The team may get better at sizing work or they simply may get more effective. This can cause the velocity to go up. The team make up may change or the definition of what completed work is could be expanded. This might make the velocity go down.

It can tell you other things too. When looking at trends of sprint velocity over a number of sprints a sudden dip on an otherwise stable trend may tell me that that team had a particularly difficult sprint. Perhaps, a story was badly defined and the team ended up thrashing around on it, not getting it done.  Maybe something outside the team’s control such as technical issues meant that, for example, work could be tested properly.

Velocity after many sprints. Here the third sprint highlights a shared environmental problem

I said previously that you shouldn’t be tempted to compare the velocity for different teams. However sometimes the urge gets too much and we do so anyway.

Recently a few of us working on an Agile project did just that, looking for trends that might be enlightening. We were comparing two teams, with different people, skills sets and working on different things. The velocity was different but they showed the same general pattern. There was clear upwards trend and when one team had a difficult sprint so did the other one. So, question 1 was

Is the share pattern a coincidence or something else?

Next we wanted to see if there was anything interesting when comparing the velocity of the work done across a wider period, in this case several sprints. When we did this, we noticed something unexpected. Whilst it was the clear the velocity was always different on each sprint, the averaged velocity over the longer time period was almost exactly the same. So, the second question was

Why was the average velocity the same for different teams?

Going back to the first question I had these thoughts. Firstly, we were coaching both teams the same way at the same time and they were improving at a similar rate. So, both teams having a similar upward trend was to be expected. The teams were getting work from the same backlog and there was a set of circumstances that meant during one sprint the stories simply weren’t good enough meaning both team suffered the same set of consequences.

My feeling about the second result is purely speculation so read into it what you will.

I think this is an indication that the teams are capable of much more. By much more, I mean a higher velocity. If you looking at the bottom of two drain pipes, one wide and one thin and water was flowing through them at an identical rate you might start to think that something was restricting the flow rate upstream. After all, the pipes are obviously capable of a higher flow rate. Is there something the environment, something to do with the work coming into the teams that is limited how effective they can be?

In summary, velocity is very personal to a team because it is function of how that team works. Similar velocity trends across multiple teams and sprints may highlight environmental changes that are effecting all teams. And velocity shouldn’t be compared unless it is and it tells you something interesting.


One thought on “Musings about Velocity

  1. Nice post Nigel! I’ve so much to consider on this subject I really should get around to writing my own articles…couple of points to make:
    – Stability is the key, getting a predictable velocity is the goal to aid planning. Delivering beyond the sprint goal is as much a failure as not reaching it (though much more pallatable of course).
    – Velocity is often used as a measure of productivity. This leads to ‘gaming’ of the estimates and, worse still, compromises on definition of done.
    – Velocity will vary for all sorts of reasons, as you mention. One I often see is the team will do more and more in each story when they get comfortable with what ‘quality’ means for the product, but the team don’t include the extra effort in the estimates.
    – Factors outside the team’s control can have a huge effect. Dependencies, build, environment all lead to blockers or hidden work; resolve these ‘external’ factors before worrying about internal productivity (preferably by taking control into the team).


Leave a Reply


WordPress.com Logo


Twitter picture


Facebook photo


Google+ photo


Connecting to %s