Velocity And Overtime In Scrum

Velocity is the most abused Scrum metric out there. When it’s abused, many things fall apart. That lack of sustainable pace and permanent overtime in Scrum are the usual symptoms. So should we even measure the Velocity?

 

What Is Velocity?

Let’s start with a basic definition of the velocity. It is a vector quantity, which means the direction is as important as the speed. If you don’t care about where you’re going, you’d be fine with just the latter.

“Velocity – the speed of something in a given direction.” – Oxford Dictionaries

When it comes to agile metrics, the Velocity is used to describe the amount of work done in one iteration. If you use Scrum and Story Points then you measure how many Story Points are completed every Sprint. If you don’t estimate your backlog items then you’d probably track the number of items done per Sprint. That is, assuming they are of a similar size.

Every single metric that says how quickly you burn through your backlog is a flavor of Velocity.

 

Measuring Overtime With Velocity

Velocity isn’t constant for any team. It changes with each iteration. Most people use average Velocity from all Sprints for any given project and team. That smoothes out the seasonal and random fluctuations. That can be a good or a bad thing, depending on who you ask.

Some try to capture the increase in performance of a team by taking the average from last few Sprints. In contrast to using the entire recorded history, this approach will take into account any recent changes in the team, technology and project itself.

There are also those, who try to capture the “true velocity”. They subtract days off, holidays, vacations and add any overtime that was reported by the teams. They treat it as “perfect velocity” and try to use to it predict the future pace based on the vacation plans and seasonal changes.

Experience shows that it doesn’t really matter how long your teams are staying overtime or how carefully you calculate any given metric. There will be unexpected events, black swans if you prefer, that will destroy any long-term planning.

The other thing that will obliterate your long-term plans is overtime.

 

Overtime And Sustainability

The agile approach is about making our customers more happy. The true goal is not to work more efficiently and faster. This is very often a side effect but it shouldn’t be the reason for anyone to “go agile” or adopt Scrum.

“Our highest priority is to satisfy the customer (…)” – Agile Manifesto

If you want to satisfy the customer, you might want to do it at any cost, even at the expense of your employees. That’s wrong as nothing makes your customers more happy than a happy Development Team. It’s not a fairy tale. When people are happy doing something, they do it well.

To make sure your products are of the highest quality possible, you need dedicated, happy teams who know both the product and the customers. Only then, they will be able to quickly and accurately adapt to inevitable changes. When they know everything inside out, they won’t make that many mistakes and they’ll have better ideas. Therefore, you need your team members to stick around.

 

Overtime Makes Velocity Drop (In The Long-Term)

Every change to the team structure will results in a sudden drop of efficiency as everyone adapts to the new circumstances. We all know that constant overtime causes higher rotation. People quit and you have to hire someone new in their place.

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

You’re supposed to be working at a constant pace indefinitely. That pace should be sustainable by all the parties involved – sponsors, clients, developers, and users. This means it’s better to work at 80% of theoretical efficiency for 5 years than with 120% for six months. Because after that time everyone will be burned out and you’ll have to start again.

Sadly, just by measuring Velocity you can make people work overtime.

 

Bad Metrics

You don’t have to measure Velocity. No one really makes more money with higher Velocity. It’s not the reason for doing this project or running that company.

“Working software is the primary measure of progress.” – Agile Manifesto

Every company is created to make money. As such, the primary metrics are profit, income and expenses. Metric of the second order would be e.g. number of orders. But there is a trap in optimizing metrics of higher orders.

If your company, on average, loses money with every order then increasing the number of orders will increase losses. If you’re dead set on optimizing Velocity or the amount of Work In Progress then you risk losing sight of the big picture.

Every time you introduce a publicly available metric and start to compare people, that metric will be twisted. It motivates people, sometimes in a wrong way, to do everything they can to satisfy the expectations. If everyone is trying to satisfy the customer – it’s fine. But if everyone is trying to max out the amount of completed backlog items or reduce the number of complains, bad things can happen.

We care about working, deployed software that our customers can use. That’s the primary measure of progress. Not the Velocity itself.

 

Usefulness of Velocity

Velocity can be useful, too. It measures the rate at which a team completes backlog items. That can tell us a few things if only we’re going to be very careful with what we read.

If a team completes between 3 and 5 requirements per Sprint that means 10th backlog item is going to be picked up for development, in the best case scenario, in two Sprints. If we’re going to be pessimistic about it, then we can say it should be under development no later than in four Sprints.

But we should also remember about worst case scenario. If we’re going to add more backlog items to the top of our list we can never even consider that item for a Sprint. It’ll remain 10th or lower forever. And that can be a good thing.

We started to talk about Velocity by saying it’s a vector quantity. It means that the direction is important. If you do a lot of low-value backlog items then your speed might be high but your Velocity can be zero. You can be running in circles and not really getting anywhere.

In reality, it doesn’t matter how fast you go, if you’re going in the wrong direction. Optimize for value first and then for speed. That way you’ll avoid the horror of Scrum overtime that is very often the consequence of forcing everyone to maximize their Velocity.

Use the measures, don’t let them use you.