100% Velocity Is A Bad Idea

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”

This quote is one of the core principles of agile. But there’s a stigma that teams should be reaching for maximum velocity every sprint, or we’re wasting time, money and should be working longer. Velocity is often used as a tool to measure how well the team are performing when “working software is the primary measure of progress” is a better way to measure how successful a team is.

Velocity

Let’s take a step back and understand what the velocity of an agile team is. Velocity is a measure in story points or time, of the amount of work a team can tackle during a single sprint. Velocity is calculated at the end of a sprint and our velocity and accuracy should improve over time, based on experience of the technology and finding ways to improve ways of working.

Let’s say we achieved 80 of 100 available hours in a sprint, that makes our velocity 80%. If we complete 50 story points in a sprint, we have a velocity of 50. Over time we are able to refine what our velocity is and the team can understand if it’s too little or not enough.

If the team are always finishing too early, they should consider increasing their velocity. If the team are always in panic mode and missing goals, they should consider decreasing it.

Panic Mode

It’s right that we should be striving to be as efficient and work as well as we can and that most sprints should finish with a small sense of urgency, but aiming for 100% velocity is not a good idea.

When working on a new project, external stakeholders who are potentially paying for the project, or Project Managers can sometimes believe that the 20% of uncommitted time is a waste of their money and the team just aren’t good enough.

So why do we actually need to have a sustainable pace?

Take reading a book for example. You can read it as quickly as your eyes can move, but if you do that you’re likely to not understand the true meaning of the story.

If our laptop CPU is constantly working at 100%, the functional performance is actually severely reduced.

If we drive our car at maximum possible speed over a long period of time, we’ll run out of fuel quickly and eventually blow a gasket.

It’s actually about science too – our brains don’t work 100% efficiently, we take time to read, absorb and process things. We also need space to innovate and think of better ways to do things.

Most sprints focus purely on the delivery of a new feature but realistically every sprint will also contain:

• Corporate overhead – things we need to do outside of the project including any unaccounted for conversations
• Time to self-organise and help each other
• Context switching from one task to another
• Technical debt from previous sprints
• Space to innovate and think of ways to build better products in better ways in the medium-long term
• Unknown unknowns at the point of sprint planning

Constant Pace

In almost all case’s it’s better to maintain a steady, constant pace to get to where we want to be in good time. We often use the analogy – do we rush to get the lifeboat out or do we stop to work out how to get the lifeboat out even quicker?

Maximum velocity isn’t sustainable in the long term. It can cause stress and anxiety between the team or individually, a sense of micro-management or cause the team to always overestimate stories just to buy them time. Importantly it can also result in mistakes being made, the wrong thing being built or what we’re building not to be the best it possibly can be.

So now it’s clear why 100% velocity is a bad idea, here’s some ways we can help reach the right velocity in our teams:

1. Set reasonable goals. Bring an amount of work into the sprint that the ones delivering the work are comfortable with. Never compromise on quality. As long as the team achieve their goals most of the time, that’s ok as over the project it will balance out.
2. Establish a culture where we can be honest and transparent, commit together, win together and lose together. Don’t punish the team for falling behind, but find ways to improve.
3. Review velocity regularly at least every other sprint, and adapt accordingly to the environment and agree on velocity with the entire team
4. Introduce clean up stories to deal with technical debt and improve quality
5. Reduce meetings that aren’t going to be productive for what you need to achieve
6. Learn to say ‘no’ to small, regular scope creep, or we risk taking on too much quietly

Positive Outcome

If we work at a pace that the team are comfortable with, it means we can maintain that pace for longer, encourages a transparent culture and what we’re building isn’t always rushed and is always of high quality. It brings the team together to help improve, learn from each other and ultimately that positive culture will be relayed back into what they are building.

Yes teams should be busy, feel challenged and strive to produce amazing products as long as it’s done in a sustainable way where there is a positive, hard working culture, motivated teams and happy customers.

I’d love to hear more about how you manage velocity in your teams over the course of a project, drop me a comment below!