One of the many qualities of Agile is the general propensity to visualise data rather than representing them as a series of numbers. The Agile board, with its cards, its columns, its swimlanes and colours, is perhaps the clearest expression of this tendency.
Agile is NOT about maximising utilisation of the project team, and when applied in its purest form it rejects the notion of effort altogether. Therefore, people unfamiliar with Agile might wonder how you could show the progress of a project to the board without an effort estimate, let’s not even talk about forecasting.
Scrum and time estimate
Let’s focus on Scrum: even if it usually disregards effort estimates, one cannot just forget how every project is bound to time by Sprints. We generally talk about “velocity” throwing numbers but what most people forget is the unit of measurement of those figures: points per sprint.
This is possibly the most misinterpreted of Scrum recommendations: working Agile does not mean disregarding time and the importance of the product time-to-market. What Scrum is ultimately trying to point out is that effort (and not time per se) is difficult to estimate, subjective, unreliable, and it forces us to consider the working day of each and every team member as the lowest common denominator. Conversely, once we abstract from the effort, the team’s ability to deliver stories with different size and complexity – as a group achievement – becomes the new lower common denominator.
A team, whose velocity is estimated to be 45 (points per sprint), has good chances to deliver a 360-point backlog in 8 Sprints. If the velocity has been determined against a 2-week sprint, we are hence confident that the backlog will be delivered in 16 weeks. Scrum does not have any problem with this thinking.
The Burndown Chart
Now we can focus on how we can represent these data, and the most common way is the burndown chart. The burndown is a chart that shows the relationship between time and the work left to deliver the backlog estimated in Story Points.
Let’s keep working with the example we made before. Our backlog has been estimated in 360 story points. Since the team that will be working on the project has a velocity of 45 points/sprint, we forecasted 8 sprints to complete the delivery of the backlog. Contrary to expectations, the team finished only 20 points worth stories during the first sprint and 40 during the second. So after two sprints, the team burned 60 points against the 90 expected. At this stage, the average velocity of the team is 30 and not 45 and thus, should it stay like that, we can expect the whole backlog to be delivered after 10 more sprints (300 ÷ 30 = 10), 12 total, rather than 8 (360 ÷ 45 = 8).
This is how you would represent the progress and the forecast of this project with a burndown chart.
In the following couple of Sprints, the team has become more and more familiar with the project and manage to burn 50 and 40 points, increasing the average velocity to 38 points. The burndown chart will immediately show this change.
The team’s velocity keeps growing from Sprint to Sprint and at the end of the sixth iteration we are left with 98 story points left and an average velocity of 44.
The burndown is telling us that we might not make it for handful points but the team should step up and make a call: will they be able to keep the very positive trend and increase even further they velocity? Alternatively, should we trust the average velocity of 44 points, considering that the team’s historical average is 45 points? However, this definitely sounds like a story for another time, does it not?