Velocity chart

Velocity chart2018-06-15T11:32:29+00:00

What is velocity?

Basic Velocity ChartVelocity is one of Agile’s simplest concepts.

What does velocity tell us?

The purpose of velocity is to answer questions such as:

  • Can we realistically deliver all these stories in the next iteration?
  • When are we likely to deliver story #20 in the current backlog?
  • How many iterations would it take to deliver this epic of 350 story points?

To answer questions like this, Agile needs a measure of how much value the team delivers per unit of time, where:

  • ‘Value’ is measured by the amount of functionality delivered.
    • E.g., the total number of story points of all the backlog items actually delivered.
  • ‘Unit of time’ can be any period.
    • E.g., week, iteration or release.
    • The most widely used unit is the iteration.

This measure – in practice a measure of team performance and capacity – is the team’s velocity.

Misunderstandings of velocity

Velocity is only an estimate

It is important to bear in mind that velocity is only an estimate.

  • It does not in fact measure value delivered directly.
    • But it is a reasonable proxy.
  • All iterations and releases are different.
    • So make sure you also understand the range of your velocity too.
  • You should always expect to have to adjust the backlog sometimes.

Team velocity cannot be ‘set’

It is tempting to try to increase team velocity by ‘setting’ it higher. Product Owners and other stakeholders are often tempted by this idea, but it suggests a basic misunderstanding about what velocity means.

Velocity is not a standard or a commitment or a budget. It is simply an empirical observation of what the team has previously achieved. It is a speedometer, not an accelerator, and forcing it up will not make the team perform any better.

Having a reliable measurement of how much the team can deliver in a given period makes it sensible to commit to a certain amount of work in future. But you cannot ‘turn up’ the team’s velocity. You can increase team velocity by other means, of course.

How is velocity calculated?

The basic steps

Velocity is easy to calculate.

  • Decide the period for which you want to calculate your velocity.
    • Per week, per iteration, per release, etc.
  • Now add up all the story points (or other work units) you estimated for all the backlog items you actually delivered in the last period.
    • Velocity is calculated in the same units as the backlog as a whole.
  • Your velocity is the total number of work units delivered in the most recent period.

Because Agile uses small teams, short timescales & small scopes, this is all that is needed to measure delivery & estimate work.

If you have the data available, you can include any number of previous periods. this will allow you to see the trend in your velocity, and to identify any anomalies and exceptions.

Choosing your timescale

Choosing a timescale over which to measure your velocity is not difficult.

This sort of data obeys the ‘law of large numbers’. That is, having a large volume of data will smooth out any anomalies and exceptions. So the longer the period (e.g., story points per release rather than per iteration):

  • The more reliable the calculation.
  • The better you will understand the data.
    • E.g., ambiguities, concealed complexities, etc.
  • The better your ability to predict the team’s capacity in the next period.
  • The more likely you will be to succeed.

But the shorter the period, the more periods you will have to compare, which will make it easier to identify trends & other useful information.

So most organisations use the iteration as their basic time period for calculating velocity.

How established is your team?

Velocity is very sensitive to changes in teams, including how experienced they are in working together. So when calculating your velocity bear in mind:

  • If you’re an established team…
    • With a regular work rhythm and practices.
    • And iterations & releases that are all more or less the same duration & size.
    • … then basic calculations are probably enough: story points delivered per iteration.
  • But if you’re quite a new team…
    • The available data will be limited.
    • And probably rapidly changing as you gain more experience.
    • …it may not make much sense to look back far.

Getting started

As with much of Agile, the hard part about velocity is getting started.

  • There’s no shortage of obstacles:
    • Early on there is no data available for calculating velocity.
    • Unfamiliarity with Agile & with each other will impact your velocity.
      • So do not rely too much on past performance in other circumstances.
  • So it is good practice to adjust your first estimate at your likely velocity by quite a large factor.
    • Adding 50% to your estimate is not too much.
  • However, you will quickly be able to remove this factor as you gain experience.
    • Even during your first iteration you can take on more work if this is too pessimistic.
  • Quite soon velocity should stabilise on a reliable number of work units per period.
    • Usually over 4-6 iterations.
  • Then it should be much easier to estimate velocity for the next few periods.

Adapting to change

Even for the most stable team, not everything remains the same.

So adjustments need to be made to your velocity too. However, Agile teams, stories, iterations & releases are all quite small. So adapting your velocity to change is usually simply a matter of common sense.

  • If a team of 8 loses two members – reduce velocity by 25%.
    • If one of them if a key player, reduce it a little more.
  • New team members should be estimated to contribute perhaps 50% of what an established member contributes – adjust your velocity accordingly.
  • If the team needs to work in a new area, make sure you include the backlog items needed to get up to speed.
    • Iteration 0 preparations, additional planning, talking to users & SMEs, spikes, etc.
    • Their story points should be included in the iteration & release plans.
    • Plus an adjustment factor for unfamiliar areas of work.

And remember, you can always adapt the Release & Iteration Plans as implementation and delivery proceed.

Chart formats

Velocity Charts are very easy to construct.

All the charts below can be constructed using basic spreadsheet tools, and recording only the estimated story points for planned stories and for actually delivered stories. The histograms and trends lines can all be created automatically with basic chart functions.

Basic Velocity Chart formats

The most basic form of Velocity Chart is simply a graph of work delivered, iteration by iteration. That is, it shows the story points actually delivered by each previous iteration.

Basic Velocity Chart

A slightly more useful type of Velocity Chart compares the delivered story points with the number committed to at the start. It shows the story points (or other unit) planned & completed in each previous period.

Velocity Chart 2

This Velocity Chart makes it even clearer just how well the team is doing.

Velocity Chart 3The added line compared  (as a percentage) how many story points were committed to with how many were actually delivered – that is, the ratio of planned vs delivered story points.

  • In this case, the story points delivered remains high, but the fall of the line in the last period suggests that we have over-committed.
  • So absolute performance is good, but is it sustainable?

Finally, this Velocity Chart calculates the overall performance trend. What can you tell from this Velocity Chart?

Velocity Chart 4

Extended Velocity Charts

You can also use your Velocity Chart to see how much effort you are spending on each type of work.

Extended Velocity Chart 1

Issues & risks

Is it really that simple?

Yes it is – so long as you operate in a truly Agile way. That means following a few simple rules:

  1. True velocity is not always clear or measurable.
    • Velocity is most meaningful when the team:
      • has a stable membership.
      • has a well-established pattern of work.
      • is working on familiar functional areas.
      • with familiar technology & systems.
      • in a stable, self-sufficient environment.
      • So Velocity Charts are well-suited to, for example, a mature Product Team.
    • But velocity is much less reliable for:
      • a new team.
      • assembled for a single project.
      • in a new functional/business area.
      • using unfamiliar systems or technologies.
      • embedded in a complex environment (e.g., a large programme).
      • In these circumstances, a Velocity Chart can be very misleading.
  2. Velocity needs to be recalculated for every new period.
    • Never treat it as a fixed figure.
  3. Your calculations of velocity are very vulnerable to the problem of volatility.
    • The volatility of your velocity score is a measure of how stable it is.
    • A low level of volatility means that your current velocity is a good predictor of the velocity you are likely to achieve in your next iteration or release.
    • But a high volatility means the reverse – your current velocity tells you very little about what you will achieve in the next round of work.
  4. Work that is ‘almost complete’ should always be excluded.
    • Stories are 0% or 100% complete only.
    • It’s just Work In Progress – an investment with no current return.
  5. Changes in iteration & release duration affect velocity.
    • Unusually long or short iterations & releases may both reduce your velocity.
      • If very short, they have disproportionate overheads.
      • If very long, they can undermine the sustainability of the team’s pace.
  6. Involvement of external resources, SMEs, etc. can complicate velocity.
    • If you rely heavily on an Extended Team, changes there will affect your real velocity.
    • Including delays in availability & conflicting priorities.
  7. Only value delivered should be counted, not work done.
    • The only true measure of velocity is what has actually been delivered – the amount of work done is often a very different thing.
  8. Watch out when units change their meaning.
    • E.g., the implicit value of story points may change between iterations & releases.
  9. Changes in performance over time should also be allowed for.
    • Always consider the trend in velocity as well as its absolute value.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?