A Path Less Taken
Published in

A Path Less Taken

Velocity is a House Built of Straw

Photo by Alex Kozlov from Pexels
Photo by Leah Kelley from Pexels
  • One builds a house of straw
  • One builds a house of sticks
  • One builds a house of bricks

Differing Interpretations of Velocity as a Metric

A Historical Note about Velocity

A Personal Note about Velocity

What Velocity Is

  • Velocity as a vector
  • Velocity as a lagging indicator
  • Velocity as a measure of a complex system

Velocity as a Vector

Velocity as a Lagging Indicator

Velocity as a Measure of a Complex System

Velocity Anti-Patterns

  • Using velocity to compare teams. Not only is this use of velocity arguably one of its most harmful applications, it’s also sadly all too common. Any leader who does this not only fails to understand velocity in a fundamental way, but also, in so doing, is likely damaging the morale of team members in the process.
  • Using velocity to shame teams. Unfortunately, in some organizations, leaders use what they might refer to as a “low velocity” as a means of exerting leverage on teams to “go faster.” Few things a leader can do are more toxic to a team than this.
  • Failing to meet the “Sprint Commitment.” A common variation on velocity shaming is where there is this notion that has persisted in the Agile community for quite some time, the “Sprint Commitment.” What this means is that the sum total of the estimates for the work items that are included in the Sprint — which we’ll call “planning velocity” — represents a “commitment” on the part of the team to finish at least that much work. In its worst form, the Sprint Commitment means that for any team that might fall short of that number, leaders and other stakeholders use that as an excuse to question how that that team is working, with the implication that heads will roll if they don’t hit the expected velocity next Sprint. For more about this, see my blog post The Difference Between a Forecast and a Commitment.
  • Measuring individual velocity. There are a number of problems with trying to measure velocity on an individual, vs. a team basis. To name one, it works contrary to the notion of a team being a team, not a collection of individuals. It also signals to team members that leaders are at least as interested in utilization at the individual level as they are in value delivery at the team level.
  • Comparing estimates to actuals. This particular anti-pattern sometimes manifests among people who have a history with traditional project management. Regardless of the reason, spending time calculating actuals, not to mention comparing them with estimates, is a form of waste, and this too signals to team members that leaders feel a need to monitor their utilization rates.
  • Inflating estimates. When faced with pressure to increase velocity, some teams feel they have no choice but to change how they estimate. There is nothing wrong with being conservative with estimates. However, this particular anti-pattern, when manifested as consistently increasing estimates across the board, has a number of negative consequences. For instance, when this occurs, it’s natural to assume that team velocity will increase, but under these circumstances, even if velocity does increase, there is probably little change in throughput (how much work actually gets done).
  • Taking partial credit. What this can look like is where a team finishes some but not all of the work for a story, and at the end of the Sprint, they split the story into two parts, “taking credit” for one portion of the work, and deferring the rest of the work to the next Sprint, even though no change was made during the Sprint to cause the nature of the work itself to change. If taking partial credit is a rare occurrence, it does little harm, but if it becomes a common anti-pattern, it’s important for team members to recognize it and take steps to stop it.
  • Splitting. There is nothing wrong with story splitting per se — in fact, it’s desirable to split work into reasonably small pieces, to help with flow. What we’re talking about here is spitting a story into multiple pieces, where the sizes for the resulting pieces, when added together, are MUCH greater than was the case for the original parent story, even though the parameters of the work remain unchanged. If this is due to a lack of clarity when the story was first sized, and new information has emerged that changes the nature of the work considerably, what we’re talking about here could be a natural consequence. However, when teams are pressured to increase velocity, they may also feel pressure to use story-splitting as an opportunity to get more “credit” for more or less the same amount of work.

Velocity and Probabilistic Forecasting

What is the Difference Between a Deterministic and a Probabilistic Forecast?

  • A range
  • A probability

What is the Purpose of a Forecast?

  • The goal is not to make estimates “more correct”
  • The goal is to make estimates (and therefore forecasts) “more useful”




This collection is for anyone who is looking for Lean-Agile content on a range of topics, with a particular focus on techniques that help with coaching and facilitation.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Philip Rogers

I’m an Agile practitioner at TextNow — I love to work with Agile teams to help them collaborate and deliver, and have fun while doing it.