This post is the first one in a 'How To' series of posts by Peter Measey. The posts in this series will explain different concepts, terms and practices within Agile, as well as how to run these practices.
Agile teams need the capability to monitor and track progress, and also the ability to be open and transparent about that progress. Many Agile teams use ‘Burn-Up’ and ‘Burn-Down’ charts to achieve this, especially within Scrum. This blog provides some practical advice on how to use these charts effectively, and what they can provide for your team.
Burn-down charts show the amount of effort/work left in a time period, these are mainly used at the Sprint level (i.e. a few weeks).
Burn-up charts show the amount of work completed and the total amount of work to be completed to hit a target, these are mainly used at the Release (Stage) or Project level.
1. Burn-Down Charts
A simple Sprint burn-down chart will show the amount of effort left on a day by day basis (Figure 1) which gives an indication of progress from the team.
Figure 1 – A simple burn-down chart
A more mature burn-down chart will add some further, very useful, information (Figure 2).
Figure 2 – A more mature burn-down chart
In Figure 2 the actual effort remaining line is still tracked, however, a planned effort line is also added. This gives the team the ability to track the amount of actual effort remaining against the amount of planned effort remaining.
To look at this in a bit more detail, let’s say Figure 2 assumes a ten day Sprint, a team of six people and a productive time of 6 hours/day.
Therefore the amount of available hours the burn-down chart starts with is 360 hours (10 days * 6 people * 6 hours productive time/day).
The planned effort line assumes that if everything is progressing smoothly then after one day there will be 324 hours of effort left (360 hours total – 36 hours ‘burnt’ in one day), after two days 288 hours left etc.
The actual effort line shows the actual amount of hours left at the end of a day. This figure is ascertained by asking each member of the team to give the latest forecast of the effort left on their task(s) each evening, and adding those figures into the burn-down chart. These figures are then added up to create the total forecast effort left on that day.
By tracking the planned and actual effort lines, the team can assess whether they are on track.
A Sprint Goal line can also be added to the burn-down chart. This line equates to the number of hours associated with the tasks that deliver the Sprint Goal. If a trend line is also added to the chart then the team can assess whether the trend of the actual effort left line is likely to cross the Sprint Goal before the end of the Sprint.
In Figure 2 the trend of delivery shows that the team is likely to achieve the Sprint Goal by the end of the Sprint but not deliver everything they had planned to do. This assumes that the Sprint Goal relates to a subset of the planned delivery, which is common within Agile teams because they recognise that no plan or estimate is ever 100% correct.
Burn-down charts can also be measured in other units, not just hours. Many Agile teams use Story Points to measure progress. This works well at the Project or Release/Stage level of detail; however at the Sprint levels, Story Points are typically not granular enough and it is difficult to track daily progress (Figure 3).
Figure 3 – Story based burn-down chart
So, in essence, burn-down charts give the team a good indication of whether they are making progress and whether they are on time to deliver the Sprint Goal.
However, the team also needs to be able to answer questions from Stakeholders such as ‘what scope can I have by what date’. This is where burn-up charts come into play.
2. Burn-Up Charts
A simple burn-up chart typically allows the team to monitor what has been completed and how they are performing against what is targeted to be completed.
Because burn-up charts are monitoring what has been completed, they are normally measured in units of completed stories or ‘story points’. They can be used very effectively at the Sprint level, however, they are more normally used at the Release (Stage) or Project level.
Figure 4 – Simple burn-up chart
Figure 4 shows how many story points have actually been completed by the end of what Sprint. The team can make a forecast to predict within which Sprint a certain number of story points/stories can be completed and therefore when a certain amount of features or scope can be delivered.
A simple burn-up chart can also be used to highlight changes in scope and what the implication of those changes in scope will be. However burn-up charts can also be used to give more flexible predictions than just scope on date.
Figure 5 – What features can be delivered by a fixed date
Figure 5 shows the actual delivery of Story Points from Sprint 1 and 2, the likely trend of delivery, and an optimistic and pessimistic view (a ‘three point estimate’). This allows the team to answer the stakeholders’ question ‘what features can I have on a certain date?’.
Figure 6 – When can a set of features be delivered
The Stakeholders may ask ‘when can we have a fixed set of features?’. Figure 6 shows how to use the burn-up chart to answer this question within a date range.
Figure 7 – Can we have this set of features on this date
Alternatively the stakeholders may state ‘I want this set of features on this date’. The burn-up chart allows the team to communicate the feasibility of doing this based on the predicted delivery velocity of the team. If it appears that the request is not deliverable then the team can initiate a conversation about whether the stakeholders would prefer delivery of less on the date or delivery of the full feature set on a later date.
Typically in an Agile delivery the date is fixed, and, if the factual data shows that the full required feature set cannot be delivered, then a subset of the feature set, or ‘minimum viable product’, is delivered. This is generally better than fixing the features and extending the time.
In essence the conversation between the team and the stakeholders goes ‘we can deliver something that will give you benefit on your required date and the remainder later, or we can deliver nothing on the date you require and all of it later; which would you prefer?’.
If we fix the date and flex the features, we can always flex the features and deliver something of value on the required date. If we fix the features and something goes wrong then we cannot move back time.
To summarise, let me share with you my view on the full picture: in order to maximise your outcomes, use burn-up and burn-down charts in tandem.
Over to you now - how are you tracking your team’s progress?
Read about burn-up and burn-down charts and lots of other topics in the book Agile Foundations - principles, practices and frameworks, written by Peter Measey and Radtac, and published by the Chartered Institute for IT.
The images with the charts used in this blog post were created by Radtac and are Radtac’s property.