What does a velocity chart look like in an agile team?

In my last article I gave a brief description of “velocity” and how I might use it in a training course.  I ended up measuring progress in “coffee points.”

This allowed me to plan my training topics and to share our progress during the day with the students in the class so we could continuously plan during the day.

All great stuff – but you might not actually know what a velocity graph looks like.  So this article runs through how I might draw my velocity graph as a “burn-up chart”, “burn-down chart” or something else.

Can I finish the project on time?

In my last article everything went really well and we made good time nearly all day.

But let’s assume I am using the same approach with a new class and I don’t go quite as well.

I have a scope of 26 Coffee Points and 8 hours to get through them.  I also estimate that I can get through 4 coffee points for hour.

Do I expect to complete the course on time?

Yes – in 8 hours I can deliver 8 x 4 = 32 points.  I should be able to finish early, or sneak in extra war stories and videos to pass the time.

The Burn-up chart

So let’s put this in a burn-up chart.  I will show “points” on the left axis and “hours” on the bottom axis.  Now I can add the numbers so I can put in my scope of 26 points.  Finally I can add my projected speed of 4 points per hour.


Cool – I should finish my course in about six and a half hours.  We will all be going home early.

Or, more likely, I have a lot of time for additional questions and material and maybe some extra discussion in each unit I go through. I tell the team we can cruise today – go into as much detail as they want in everything, so they leave happy at the end of the day.

We start the course

We start the course and we record how many points we actually get through each hour.

We discuss things in more detail than planned and after 3 hours we review our progress.  The first hour we get through 3 points, which is OK. Its’s less than our target of 4, but it’s only the first hour so we have time to catch up.

Then we get through 2 points and 3 points in each of the next two hours. Now we are a bit behind – having completed a total of 8 points in 3 hours.


People add potential scope half way through

We do our lunch time retrospective to see how people think the course is going. People are happy but the discussions have triggered more thinking.

People now want to add 3 new (but relevant) topics to the days. I could simply reject them but at the beginning of the course I claimed we would “welcome changing requirements” and “adapt to change.” Maybe I should have saved those concepts up until the end of the course.

We could also break each new topic down in detail to see how much of it we can cover, but this would involve spending valuable time on the topic before we agree to cover it and we are already under pressure to finish the topics we have on the lesson plan.

But we can also do a very rough estimate before committing to anything.

One item is an additional bit of practice, which is therefore like my “story exercise” of 3 points.  Another is similar to story walls in humid climates so it is 2 points.  The last one is just one point as it is about jargon and we could cover it quite simply. So we have a total of 6 points in additional work.

Measuring velocity should help our planning

With our slower than hoped for pace and our increased scope, I am not so confident we will finish on time.  Let’s update the velocity chart and see what it looks like.


Even if I were moving at my planned velocity then it would be tight – but at this rate of progress there is no way.  Let’s project what will happen on my graph if we continue at this rate AND aim for the full 32 points of awesome learning:


Not good – it will take more than 10 hours to get there.

I could propose to my students that we stay late, but that is unlikely to be well received.  Maybe we can speed up if we do something different, or maybe we have to accept that some of the material will not be included today.  In this case we can either drop whole units or cull some of the finer points to get through the core elements of everything.

Let’s see … how many points am I likely to get through at the 5pm:


At the rate I am going – I can cover 21 points of material, including what I have already done in the morning. Not what I wanted to hear, but at least I can plan what to do from here with a better understanding of how it will all end up. And at least I can involve the class in the planning with some understanding of how much effort each topic will be.

We might agree to improve our process to get through the material quicker.  Maybe we can ask one question at a time or include questions on post-it notes.  Or maybe I could stop covering every slide and drop my boring war stories.

At the same time we can also decide how much detail we can cover less important topics in, or we can make sure we cover the most important things first.  Not everything can be compressed and shuffled but a lot can.

We try improving our process and see how we go.  Then in another hour we can check again and see how we are going then.

Like all agile courses and agile projects the course goes really well after that and everyone using agile.

Why use coffee points?

I used coffee points which represent “how much I could cover over a cup of coffee”.  Its a completely made up thing though – people don’t drink that much coffee when learning.

I expected that each coffee point would be the same as about 15 minutes of class time, so I could just as easily have estimated each item in minutes.  One topic is 15 minutes instead of 1 point and the next is 30 minutes instead of 2 points.

But if the first item takes, for example, 18 minutes instead of 15, then it is a painful to go and update the times on everything else on the board.

Instead I just leave the “coffee points” the same on each item and then change my estimate of how long a point takes to complete.

In other words I can just plan on the bases that the remaining topics will take 18 minutes for each coffee point.  This means that instead of getting through 4 points in an hour I will only get through 3 and a third.

It just seems quicker and easier to do this than continually refine my estimates.

The burn-down chart

What if I am “old-school” and I want to use a burn-down chart instead of a burn-up one?

Burn-down charts are virtually the same except they go down instead of up.

So instead of drawing a scope of 26 points and starting my actual progress at zero, I start my chart at 26 points and estimate how long it will take to get to zero topics left.

So this is the chart at the beginning:


After 3 hours I am going slower than hoped for … so my actual burn rate is above the line where I want to be:


And this is what it would look like if I added another 6 points of scope … both lines move further away from my destination of 0 points left:


I can see I have gone backwards, but having two lines could be confusing. So I could show it as one line.


Regardless of which chart I use the story is the same – there is no way I am going to finish all the desired material by 5pm.

Again though, if I want to slash scope to make sure I finish at 5 pm I can do so with the burn-down chart.


This might look a bit messy and chaotic – but that is just because my planning was in fact messy and chaotic over the lunch period.  I added heaps of scope and then removed heaps of scope.

Which is better – burn-down or burn-up?

Some people tell me that they prefer the simplicity of the burn-down chart or that it creates a greater sense of urgency than the burn-up one. Others tell me that the burn-up chart is better because it more clearly separates scope from changes in speed and better assists with planning.

I have also been told that psychologically the burn-down chart keeps us focused on the future while the burn-up chart gives more of a sense of accomplishment and progress. I am not sure about that though.

Some agile teams even use both. The burn-down chart is used during a sprint to track the hours left in the planned tasks in the sprint, while the burn-up chart is used to map progress across multiple sprints.

I just use whichever looks better on a particular wall.  So it is more of a decor decision for me than a data based one.

Cycle time

I am still using velocity in my projects but some people now use Cycle Time.  In fact many factories and customer service teams use cycle time instead of throughput (velocity) as a measure for both planning and improvement.

So how would I use cycle time in my course instead of velocity?

Cycle time is the time it takes to complete a unit of work (answer one call, build ship one car).  So rather than looking at points per hour I am now looking at hours per point.

At the beginning of the day I have a cycle time of 15 minutes per point, or in hours that is 0.25 hours per point.

When using cycle time, we should really break all of our work units down to about the same size.  So for example I should break everything down into 1 point units.  But let’s assume I don’t.

Since I have a total of 26 points to get through, that means I start with an estimated time to completion of (15 minutes per unit x 26 units  / 60 minutes) = 6.5 hours.  Pretty good.

But 3 hours into my course I am going slower than expected.  I got through only 8 units in 3 hours … meaning my cycle time is now 0.375 hours per coffee points of learning).

If I could magically reduce my cycle time back to the planned 0.25 hours, then I would have (26 units * 0.25 minutes per point) or 4.5 hours of work left to complete.  I could still finish at 4:30 pm

But in fact my cycle time is worse than that.  If I continue to complete one point of learning every 0.375 hours it will take me longer to finish.  And I added scope, so I need to complete (18 +6=24) points of work remaining.

I can now predict that if I want to complete everything and continue to travel at the same speed, we will be here for another 0.375 hours x 24 points = 9 more hours.  That means a 7 pm finish time, probably sitting in the room on my own since everyone else would leave.

On the other hand, if I want to know how much I will have done by 5 pm then the maths tells me it will be (5 hours / 0.375) = 13 or 14 more units of work, which would again give me a total of (13+8 = 21) points for the day.

As you might notice, cycle time keeps us focused on what we can do from here.  It can also look like more maths and less diagrams.  But in fact the maths is the same.

Cycle time is often used in teams that are delivering work continuously rather than in sprints (since there is no sprint to have a velocity).

It is also used more by teams who have work that can be broken down to units of the same size – so you don’t talk about cycle time per point but rather per story or deliverable. This sometimes makes sense for support teams whose incidents are not estimated or outsource teams who define clear deliverables between teams.

You might even use it because the business people you are working with use lean manufacturing approaches and like it.

But again it is not mathematically superior or inferior to burn-up and burn-down charts. It is the same mathematics presented in a form you find useful.

Parking lot reports

Some people like to compare projects against each other and others like to compare how much of each feature, stream or component of the project we have gotten through.  But comparing velocity (burn up, burn down or cycle time) is ugly.

We need to define the units of measure and this is hard if each team is using their own.  I might be using coffee points of about 15 minutes and you might be using coffee points of 18 minutes.  But someone else is using story points and someone else is working in tasks that come to person days of work.

So someone invented a way to compare progress in different teams of topics and all they did is copy they approach that was used years ago in Telethons and charity events here in Australia.

Rather than measuring absolute speed (work over time) they measured percentage of work completed over total work. If you are a waterfall project manager you might think this sounds like old school “percent completed” because it is.

The parking lot measure is not one that is supposed to help manage capacity per sprint or to highlight bottlenecks and constraints in the team.  It is meant to be a measure for the project office or wider team take a step back and see how different teams are going at a high level.

So it might look something like this:


I won’t explain these here because my focus is on the velocity measures often used by a team to plan their own work, rather than a way to compare where different teams are on the map between starting and the destination.

We measure speed to help us make better decisions

So there you have it.  We have many ways of measuring speed and all of them are designed to communicate a simple number or clear picture of the progress the team is making.

But remember that in physics, velocity consists of speed (distance over time) AND a vector (direction of movement).

All the graphs I have shown here are measures of speed.  This can be a great measure for a team … but it would not be the only measure. A race car driver is not making good progress if they are speeding in the wrong direction.

In fact a driver might be concerned if they are going really fast but the petrol is running out, or worse the brakes are failing.

He or she would also be disappointed to find out too late that the engine had overheated, the oil run dry and he had just entered a curve where he could not turn at this high speed and was about to go over a cliff.

In the same way, “velocity” is not a measure of value created or quality of work or even whether the work is done.

Velocity is simply a measure (or tool) to assist the team to identify their capacity, predict the time it will take to get their work done.

The team can potentially use a change in their speed as a starting point, to understand their constraints and issues so they can continuously improve their delivery.

But going fast at the expense of quality, safety and usefulness of what you produce is not the goal. The goal is to assess your speed to help you plan your work so you can build something safely that has good quality and is useful.

So next time, let’s discuss how velocity fits into the other measures an agile team can use make effective decisions.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s