The Backlog Projection chart
When using an Agile methodology it can be hard to convey what is going to be delivered. Agile is all about adapting to change, and if goals change in the lifecycle of a project, what will be delivered is bound to change.
So what is the best way to make sure all your stakeholders are aware of what the final delivery is going to be? First and foremost a good old conversation is usually the best way to make sure everybody is aligned and there are no surprises, you should never expect that an email, a document or a chart will do all the work.
However, you should use them to drive conversations and to define a clear picture in everyone’s mind. One that I have found very useful is what I call the Backlog Projection Chart.
I find this artefact useful because it combines the priorities in the backlog with the different velocities a team can achieve. It enables us to have a good idea of “when” and “what” will be delivered as well as what will not be delivered. All this in a very visual and easy to read way. Don’t take my word for it, check it out for yourself.
The bars in the graph represent the backlog. Each colour represents a different Epic. Priority is in reverse, so Epics in the lower end of the bar actually have a higher priority than the ones at the top end. The Projection lines represent different velocities. An optimistic one, a pessimistic one and the third one is an average between those two. In the X axis you can see the sprints (the chart above assumes you are about to start sprint number 6).
To find out when something is going to be ready, you just need to look for when the projection line goes over the Epic.
The great thing about this, is that you can change the priority order and find out how it pans out against the velocity. You can also use Themes instead of Epics, go down a level and use user stories, or even specific features or functionalities. You can even dumb it down to a single colour and just find out when you are done with the whole thing.
So how do you get here?
(The explanation below is for Google Sheets, but it should apply to any spreadsheet software)
You need to have at least 2 pieces of information. An estimated backlog, and team velocity. Let’s say we are building an app that gives you a suggestion of what you could cook for dinner based on the food you have at home. The backlog could look a bit like this:
And let’s say you are five sprints into your project, and you have achieved the following velocities:
Using the information above you can easily conclude the following:
(Additional sprints = total story points / velocity)
The next step is to create the following table:
The first column shows a sprint count. Then you have a column for each Epic and you fill it with the total point count for that specific Epic. Finally the last 3 columns are about velocity. The Velocity columns contain the cumulative burn points. If you have a velocity of 20, which is your starting point, then on the second sprint you would have burned 40 on the third sprint you would have 60 and so on.
Once you have the data in place, you can select all the columns and rows and go for “Insert a Chart”. You need to specify that the first row and columns are headers, tick the “stack” checkbox and Select the following type:
Define which series should be columns and which should be lines and coordinate the colours. The Epics should be set as columns and the velocity as lines.
Once you have all Epics as columns and all Velocities as lines you should have:
Now with a quick glance you can see that if everything goes extremely well, you will finish in Sprint 11, if things go really bad you will finish in Sprint 17. Most probably you will be finishing around Sprint 12 or 13. (Note: once you get more sprints you should take away the lowest and the highest velocity score you have to adjust against “blips” in the process).
Not only do we know when we will be done, we also know when a particular feature of the system will be done, in this case “storing the ingredients” and “suggesting recipes” will probably be done by sprint 9.
If you want to change priorities and have a look at how that will affect the release date, go ahead and create a new chart, show it to your stakeholders to start the conversation. Still using the same case we decided to move the most important features and stories up and redraw the chart. To find out that we could get a MVP in sprint 7.
Is this the best way to communicate release dates?
Is this the best way to talk about priorities in the back log?
It depends, it is just another tool in your agile toolbox and like any tool it needs to be used when it’s appropriate, sometimes on its own, and sometimes in conjunction with other tools.
Have you ever used the Backlog projection chart? How did it go?
Do you use a different chart? Don’t be shy leave us a comment on Twitter.