Defining Velocity for relative estimating teams (Agile)

Defining Velocity

Let’s define “velocity” in “Agile” (or should I say more accurately relative estimating teams?) terms before we get started so that we have a shared understanding of what the community and thought leaders have to say.

Regular unleaded from dictionary.com

velocity

[vuh–los-i-tee]

noun, plural velocities.

1. rapidity of motion or operation; swiftness; speed:

a high wind velocity.

2. Mechanics. the time rate of change of position of a body in a specified direction.

3. the rate of speed with which something happens; rapidity of action or reaction.

The various glorious inconceivable Agile definitions:

The team’s velocity for an iteration is equal to the sum of the size of all the stories completed in an iteration – Dean Leffingwell’s, Scaled Agile, Inc., the SAFe. (excellent and relative!)

---

Velocity is a capacity planning tool sometimes used in agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project.^[1] -wikipedia.com

---

Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. – VersionOne

---

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. – Agile Alliance

1) Velocity measures how much functionality a team delivers in a sprint.
2) Velocity measures a team’s ability to turns ideas into new functionality in a sprint.
– Mike Cohn, Mountain Goat Software

---

“Velocity is the ratio between an ideal-time estimate and the actual time that it takes to do something.”

Velocity is really just output

There’s no connection between velocity and output. A very high-velocity team might be generate very little output this iteration if it’s working on a particularly difficult story.

Velocity is the ratio between an ideal-time estimate and the actual time that it takes to do something. It is a measure of estimation accuracy, not of output or work. In fact, treating velocity as an output indicator is actively destructive. It leads to initiatives to “improve the team velocity,” which typically lead to dysfunctions like overtime.

Velocity indicates how much the team can do at the current moment in time on the current class of problems. You use it to help size stories to make sure that they’ll fit into a fixed-length iteration. – Dr. Dobbs (I like this one with a few exceptions. I don’t see velocity as the ratio between an ideal time estimate and the actual time it takes to do something. Velocity is only part of that equation. And it sadly only accounts for volume and not the other three critical elements of what a story point is)

---

 

The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It’s just that simple. You also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning. – Extreme Programming.org – Don Wells / Kent Beck

 

---

Now, you won’t find a definition of velocity in the Scrum Guide at scrumguides.org. Because velocity is not defined as part of the Scrum framework. Neither is “Agile.” You will find dozens of definitions at the Scrum Alliance community forum. Ditto for scrum.org (even some craziness).

People seem to get wrapped around the axle about what velocity is supposed to be for teams using a relative estimating technique. I’m not saying I have a perfect answer. Not even a better answer. Maybe not even the right answer. But, hopefully one that helps people understand it better.

---

Define the “Agile” team first

a cross-functional appropriately sized (see Dunbar’s number) group of like-minded people, self-organized around a (domain) purpose, and aligned with the value system and principles described in the “Manifesto for Agile Software Development.” Usually associated with product or service delivery organizations, especially software development, but not necessarily always the case.

I have actually grown fond of “High-performance” teams as a more thoroughly descriptive name for what we strive for in learning/relentlessly improving, innovation organizations. Thanks to a guy named Brian.

Blogagility definition of velocity for a relative estimating team (or “Agile” or High-performance team)

For long-lived “teams”, “velocity” of the team is simply the average of the team’s delivery of working product/service (valuable) in the last few iterations in the form of normalized story points.

The velocity of an iteration (or sprint) is the amount of the team’s delivery of working product/service (valuable) in that iteration in the form of normalized story points.

Normalized story points come into being by a team using a consistent relative estimating technique and additive system.

Story points have four parts:

1. volume
2. complexity
3. knowledge
4. uncertainty (dependency/risk)

I encourage teams to use additive systems for estimating. No one knows what “that team of teams produced the equivalent of 450 extra large t-shirts. Or was it 1000 small t-shirts?” —means, what?

Starting with planning poker and a modified fibonacci sequence that will remain consistent across the portfolio is a good idea.

Why isn’t velocity the average of all the teams production of value in all iterations?

Because business context changes. The older velocity would make the current estimates less relevant and cause inconsistencies in the team’s estimating.

search: calculating normalized velocity safe