Velocity or Speed?

The term 'Velocity' was chosen over speed because it is a vector, not a scalar value... that is, Speed is the time rate at which an object is moving along a path, while Velocity is the rate and direction of an object's movement.

Now, whilst the velocity used by agile teams is almost never shown as being negative (as a velocity can be), it also rarely accurately reflects direction either.  The original intention of this metric was to measure and forecast the remaining time or effort required to reach key milestones in the future.  These were typically releases, defined either by a date or by a set of required system features & capabilities.  This forecast would be revised (re-estimated) after every iteration / sprint when the velocity was calculated, the average velocity updated and new learnings from this past iteration applied to the remaining backlog items in the form of re-estimating.

So why might a team's velocity ever drop towards zero or even negative?  Well, depending on what type of 'goal' or 'destination' a team sets themselves, they could actually move further away from it.

Are you using Velocity effectively?

Be careful not to derive too much from this analogy.  For example, typically, a 'sat-nav' or similar system will select the fastest route as the default option.  When applied to the efforts and finite resources of a team, it's hard to see how knowingly heading away from your goal can be the fastest route.

However, this analogy may still be a useful thinking tool to consider whether you're using 'Velocity' as effectively as you can be.  Often the calculated and recommended fastest route (which would have a low, even negative velocity at points)...:

• Is a longer distance

• May put more wear and tear on the vehicle

• May consume more fuel.

• May provide fewer diversions and choices when faced with major roadblocks or congestion, such as being on a motorway with no nearby exits.

On the other hand, the recommended route may also offer advantages:

• It typically maximises flow, reducing roadblocks, uncertainties, and congestion estimates, while minimising wear and tear on other parts of the vehicle.

• It may provide a more comfortable journey.

• It may be better suited to the capabilities and type of your vehicle (luxury car versus an off-roader).

So consider:

• Are you trying to take the shortest route?  Or the fastest route?  They may not be the same.

• Is your planned route putting undue stress and wear on the team?  Is there a different route that is better suited to their skills and strengths?

Coming back to the analogy, consider the entire team in the vehicle, not individuals in different cars.  You may consider parallels with your team's experience and capabilities, the tooling, the tech debt you carry, even the level of certainty you have in your destination.  What do you want your vwelocity to help you understand?

High levels of confidence in the various volatile, uncertain, complex, and ambiguous  (VUCA) factors of your development may suggest that you can better plan the 'fastest' route, even if it means investing effort and time in things that allow you to better navigate the latter part of the journey (your roadmap and backlog).  See also Setting Up for Success.