BROADCASTS.com

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\u2019s ability to work together and deliver value incrementally.

\xa0

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\u2019s output (rather than damage it); and key takeaways to keep in mind.

\xa0

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\u2019ve done in the past

Velocity is similar to the term \u201cvelocity\u201d used in physics (i.e. in physics, velocity is not just speed; it\u2019s speed and direction) \u2014 If your teams don\u2019t 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 \u201cnumber of items completed\u201d approach, etc.)
Though velocity is often expressed in \u201cpoints,\u201d it isn\u2019t 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\u2019s worth (if you\u2019re 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\u2019t meet the same markers that they did in the previous week/month/sprint

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

Assigning \u201cpoints\u201d to people on the team (velocity is a team measure; not a measure of individuals)

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

You shouldn\u2019t 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)

\xa0

Mentioned in this Episode:

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

\xa0

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!