Exploring Velocity: What Is it? How Do We Measure It? How Can We Leverage It?

Agile Coaches' Corner

This week, Dan and Sam are discussing an important metric to Agile teams: velocity. If used correctly, velocity can be an incredibly helpful tool for teams to leverage to forecast future sprints and understand what it is that they can accomplish in a given amount of time. If used incorrectly, however, it can wreak havoc on a team’s ability to work together and deliver value incrementally.

In this Scrum-centric discussion, Sam and Dan take a look at what velocity is; how to measure it, why it is important to teams, leadership, and the organization; how we can effectively leverage it to improve a team’s output (rather than damage it); and key takeaways to keep in mind.

Key Takeaways

What is velocity? Why is it important?

Velocity is an output-based metric that measures what the team typically does/how much they do over a certain period

In Scrum, velocity is usually measured within sprints

Velocity is history; not what you hope for (i.e it is a past measure)

Velocity is a great tool for teams to understand what they typically do in a given sprint and use it as a measure to know what they could do in a future sprint

Scrum teams who are truly self-managing can use velocity as a way to think about what they might do in their upcoming sprint given what they’ve done in the past

Velocity is similar to the term “velocity” used in physics (i.e. in physics, velocity is not just speed; it’s speed and direction) — If your teams don’t have direction, the speed at which they do things is meaningless

How is velocity measured?

There are a number of ways you can measure velocity (from story points to a “number of items completed” approach, etc.)Though velocity is often expressed in “points,” it isn’t needed to measure it in points (velocity is simply how much stuff you have done in whichever way you want to measure it)

Points are not a forecast or the capacity that the team is expected to hit

The pressure to measure in points can actually be more effort than it’s worth (if you’re already measuring in days, why use a conversion chart of days=points? Use what the team already knows and is working by)

Measure in as small of pieces as possible (the tinier something is the more accurately you can assess how long it is going to take)

Velocity anti-patterns:

Velocity can be one of the most abused metrics in all of software development if the wrong person in power gets a hold of it

Sometimes when leadership gets a hold of velocity metrics, they punish or put pressure on teams when they don’t meet the same markers that they did in the previous week/month/sprint

Some organizations see the Scrum Master’s role as making sure that the team is constantly increasing its velocity

Assigning “points” to people on the team (velocity is a team measure; not a measure of individuals)

Just getting stuff done that isn’t moving the product forward may make your velocity look great, but really you’re spinning your wheels and not going anywhere

You shouldn’t be managing velocity; velocity should be helping you manage other things (such as what teams can do to forecast)

Why can measuring velocity improve your teams?

As a Product Owner, you can use velocity to forecast beyond the next sprint

You can use it as a measure to revise and adapt each sprint

Key takeaways to keep in mind:

When you change the team composition, the velocity will be affected and most likely drop (even if you are adding someone because they need time to get used to working together)

Velocity is not about precision (through craving certainty, we want to apply a number measure to velocity) but teams begin to beat themselves up and spend too much time in refinement activities to have a stable velocity (rather than actually doing the work)

Mentioned in this Episode:

The Mythical Man-Month: Essays on Software Engineering, by Frederick Brooks Jr.

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [e-mail] or Tweet @AgileThought using #AgileThoughtPodcast!