I am continually astonished at the number of teams I meet who have not yet established a stable velocity! I was speaking at DDD North recently and I asked the audience out of interest how many of them did something Agilish. About 70% of the audience were doing something Agile (Scrum, XP, DSDM, Wagile, Scrumban etc). I asked the audience how many of them had a stable velocity in their team and about 2% of them raised their hands!
The Critical Question
It doesn’t really matter if you are doing Agile, Waterfall, Lean or whatever, sooner or later someone (probably your boss) is justifiably going to ask your team:
“What can you do by when?”
This seems to me to be a perfectly reasonable question, although it does sometimes get asked in a totally unreasonable manner:
- Can you work harder and faster?
- When will it be done?
- Is it done yet?
I’m sure you have heard some other alternative ways of asking the same question!
Why Is Achieving A Stable Velocity Important?
Achieving a stable velocity is critical to answering “The Critical Question” (above). Sometimes teams don’t understand just how important this question is! When you exist in a Sprint / Scrum bubble, it is easy to forget that there is a while swathe of people out there trying to sync their work up with the end of yours.
For example, a critical announcement to the stock market may depend on knowing when your next major release will happen. You may have a marketing team poised ready to tell the world how great your work is. You probably have customers desperate to use your latest cool feature!
If you have a stable velocity, you can plan. If you can plan, you can let all those people listed above know what to expect when and you’ll make their lives 100% easier as a result!
The second reason that having a stable velocity is important is that it allows your organisation to make “value” decisions. I’ve written about value before. My favourite definition is:
Value = Benefit – Cost
The benefits of a product can be defined by an organisation (usually the marketing department or similar will do this). The cost (for software) is primarily defined by how much effort it will take to create the product. To have a reasonable estimate how much effort is required we need (yes, you guessed it) a stable velocity! We also need a Product Backlog, but that’s a whole other blog post…
Why Do Teams Not Have A Stable Velocity?
My experience working with teams as an Agile trainer and coach reinforces my feeling that stable velocity is not being achieved by most software development teams.
So why is this?
The Team Is Not Stable
The number one reason I find in most teams is that the team is not stable. The productivity of a team is a unique result of the blend of people in that team. It is not sensible to say that since a team has 5 people in it and they work 35 hours per week that the team does 175 hours of work per week… A team is so much more than the sum of its parts!
As a thought experiment, let’s create a hypothetical team from the very best programmers in a large organisation. We would expect this to be the most productive team in the organisation. It turns out that this is not true! Our “best” team in this hypothetical case contains a lot of leader-style personalities. Lumping them all together will result in them spending most of their time arguing about the “proper” (whatever that means) way to do things. Similarly, another hypothetical team could be filled with worker-style personalities. They will also get very little done since they have no leader to point them in the right direction.
Consider what happens to productivity when a new member joins your team. Generally the team will take a hit to productivity for an undetermined amount of time.
Consider what happens to productivity when a member leaves your team. Generally the team will take a hit to productivity for an undetermined amount of time! So, if your team make-up is continually changing, your productivity will be permanently sub-optimal and permanently unstable!
Product Backlog Issues
Another common reason for unstable velocity is a product backlog that contains a small number of large user stories. I like to stick my neck out and say that a good user story should usually take half a day to a day and a half of a single person’s time to complete. There are exceptions (I’m working on one myself right now!), but as a general guideline this seems to be about right for most teams. Teams with large user stories will frequently have large hangovers between sprints so they will have a low velocity one sprint and (possibly) a high velocity the next sprint!
What Do Teams Need To Do To Achieve A Stable Velocity?
In general, the achievement of a stable velocity requires:
- A well-groomed product backlog with lots of small user stories
- A stable team composition
Once you have this, you are in a great position to answer the critical question:
“What can you do by when?”
Get in touch with our team to learn about range of Agile Services and Workshops to kick start your transformation.
