Velocity and why it’s important
Velocity is an important tool in Agile. Let me explain a little about what it is and why we find it useful.
Speed = distance over time
One of the challenges when planning each two weeks’ sprint is working out how much work we can realistically commit to. That’s where estimates and velocity work together.
Since we estimate each task (using ideal hours), at the end of each sprint we can count up the values of all the tasks that we completed (only those that landed safely in the DONE column in Trello—that is tasks that have been both completed and successfully tested) to reveal our velocity for that sprint: how much value we were able to deliver to the project (or projects) during that two weeks’ timebox.
In theory that should then tell us how much we ought to expect to complete during the next sprint.
But it doesn’t always work like that.
It’s a bit like estimating how long it will take you to drive somewhere. If your average speed is 50 mph then you should be able to estimate that in two hours you’ll travel 100 miles. But any driver will tell you that it’s never quite that simple. There are many other things that can influence your speed; for example, road or weather conditions, driver tiredness, car performance, etc.
The same is true for teams: a developer’s experience can play a significant role, or you may uncover some unforeseen complexities in a task; a developer may be overtired because of a new baby, or that elusive software bug may send you on a wild goose chase for a couple of days.
There is an important lesson here that a team’s velocity, their speed of delivery, does not necessarily reflect its productivity. And also that one team’s velocity shouldn’t be compared with another’s.
Historical data is a very valuable tool, assuming that the team hasn’t changed—consistency is important.
Shore and Warden in The Art of Agile Development (O’Reilly, 2008) claim that velocity should stabilize within three or four sprints. I’ve read Mike Cohn in the past suggest that taking the average of eight sprints offers the most accurate velocity, and that velocity from sprint to sprint can increase or decrease by approximately 20%.
When we started our current project we had grown the team since our feasibility exercise so we had to start again from scratch—we couldn’t rely on our previous average velocity, it was essentially a new team: with a different lead developer and more content editors. So we had to… well, guess.
We started with our universe of work, which gave us a ballpark figure. Having added up our commitments to daily stand-ups, the sprint retrospective, business as usual meetings, portfolio meetings, etc. that gave us a number of hours remaining for project work.
Of course, that works really well if your estimates are rock solid, and if your team is well-established and familiar with Agile, with the business, and doesn’t have any ad hoc business as usual emergencies being thrown at them left-field.
Needless to say we were wildly out in our estimates. We stacked up far too much work for the first few sprints, but six sprints in things are beginning to stabilize a little now. As the team has begun to gel and mature I’ve noticed that we are picking up speed.
And this is where the real value of historical data comes in. In many ways it doesn’t matter if our estimates are absolutely correct; it doesn’t matter if something we estimate will take one hour actually takes two. What really matters is that our estimates are consistent. If our estimates are consistent then these simply become estimates of task size not duration.
As an aside, something that struck a few members of the team recently is that when we estimate task size we also ought to include time for testing.
Our aim as the team continues to learn how to work more effectively together is to arrive at a fairly stable velocity which will help us to plan ahead.
Shore and Warden offer the following tips to improve your velocity:
- Pay down technical debt—fix things incrementally; a stitch in time saves nine, and all that.
- Improve customer involvement—make sure business ambassadors or advisers are available when you need them, so you’re not left waiting for them.
- Support energized work—don’t burn out your developers.
- Offload programming duties—find ways to excuse programmers from unnecessary meetings and interruptions.
- Provide needed resources—if your developers are complaining that their PCs are slow then improve them: remove as much as you can that is slowing them down.
Are you using Agile? What lessons have you learned about your velocity?