A recruitment consultant will contact you soon.

Agile coach: recipes for success #4

Infotel_Agile coaching_Burn Down

The Burn Down

The Burn Down Chart tracks a team’s progress towards its sprint goal by measuring the work done and the work remaining within the time available.

However, beyond being a monitoring tool, the Burn Down can also detect malfunctions within a team or even within an organisation.

This article will demonstrate how the Burn Down Chart can identify different types of problems:

  • Systemic (queue beyond a team’s sphere of influence for example)
  • Organisational
  • Team (mastering SCRUM)

Burn Down chart_Ideal

The sketch above shows the ideal Burn Down everyone is familiar with. In the rest of this article, we will see four different Burn Down patterns revealing team or organisational dysfunctions. For now, we are only going to be interested in the first Scrum bad pattern: late or non-dependent User Story validation.

1. Late or off-team validation

Before reading the remainder of this article, it should be noted that the Burn Down Chart is built upon and reflects the team’s progress in line with the definition of completion (definition of done) determined by it.

This bad pattern can be expressed as follows: the validation of the User Stories is either too late due to the product owner (PO) accepting or rejecting them at the last moment in the sprint or, even worse, validation of the US does not depend on the team, but on an external entity.

Burn Down chart_Late acceptance

As we have seen, this burn down highlights various problems, the causes of which we will now identify:

Lack of the product owner’s availability: The product owner is not available for the team. He is not there to clarify, make sense of and validate the changes that have been made.

This lack of availability creates a bottleneck in the testing procedure, indirectly reducing the team’s velocity and, in consequence, undermining the value given to the product.

Fluid communication: we often encounter this problem with a proxy product owner who, by definition, operates remotely from the team. In this type of case, we have to consider redefining what we mean by “completed”.

The results

As seen above, these problems can have significant consequences. These include a decrease in velocity, the undermining of the increment produced and a declining notion of commitment, since this is not the team’s direct responsibility. As a result, the overflows and remaining stages must be addressed (or not, depending on the product owner’s updated reprioritisation), although this will inevitably add a further degree of complexity to the next sprint.

Thus, if this is not an epiphenomenon, i.e. identifying and treating the causes of the problem, how do we cope with this kind of scenario?

What should you do in this case?

Several tracks are possible and should be considered as a means of rectifying these team issues:

  • Enriching the burn-down: For example, creating two curves:
    • Follow current procedure “Done = developed + tested”
    • Only follow what is “developed”
    • This will highlight the bottleneck and maintain the notion of team commitment
  • Rethink the testing strategy if the PO is not available

2. Slow progress or over-commitment

Burn Down chart_slow progress

Several behaviour patterns can be at the origin of this type of Burn Down:

The team is over ambitious:The sprint’s goal is too ambitious and it is only during the sprint itself that the team realises it will not be able to reach its target. While it is acceptable to aim high and fail, it should not become a regular pattern or habit, as this negativity influences the organisation’s confidence in the team.

The submissive team:The team is not sufficiently self-assured and lacks the courage to confront the product owner with a realistic vision, afraid this might be seen as painful and call into question the team’s production capacity in a sprint. However, delivering a false promise can also lead to the organisation losing its faith in the team.

Variations in the team: Team members fall ill, leave or go on holiday without this being specified at the start of the sprint.

Last minute priority: The team may need to solve a critical problem – often a bug – leaving less room for manoeuvre to reach the sprint goal. Depending on how often such disruptions occur, the team may need additional flexibility in its commitments.

Commitment and dependencies: The team has to cope with dependencies outside its unplanned sphere of influence when planning the sprint.

3. Increasing the scope

Burn Down chart_Scope increases

In most cases, we observe this Burn Down when the sprint has not been properly prepared.

Imperfect story identification: The team was unable to isolate the stories correctly and did not therefore identify the fact that efforts to create a product increment (sprint) would turn out to be more challenging than expected. If this occurs regularly, it means that the team has accepted user stories that are not understood or have too much uncertainty about them, which shows serious dysfunctions.

Significant variations in the scope: A lack of prioritisation or a lack of slack may make it impossible to manage emergencies.

What should we do in such cases?

A few ideas
Set up a back-to-finish in mid-sprint session to get into a sprint launch environment with mature user stories.

Allow a little slack on the sprint (do not commit to the limits of its production capacity), leaving room to add improvement initiatives as needed and have sufficient bandwidth to cope with emergencies.


Burn Down chart_Early finish

However, be warned, this Burn Down is a SCRUM anti-pattern only if it occurs regularly. We will not criticise the team that sometimes works better than expected!

However, if this Burn Down has become a habit in your teams:

The team is too cautious: The team probably overestimated the effort when this was being assessed. This imprecise estimate can come about from using an unverified user story, or from anxiety among team members when the context is too strict or “failure” is not an option.

No visibility of technical moves: The team retains its production capacity for handling technical tasks (technical debt management) without making these moves visible.

In conclusion

  1. It’s a good idea to analyse the Burn Down sometimes, so why not after a stand-up or during a retrospective aimed at identifying systemic issues?
  2. Greater transparency and visibility can be provided by coupling the Burn Down Chart with other indicators, such as cycle time, lead time and so on.
  3. It is beneficial to update the Burn Down during daily scrums without the Scrum Master having to be responsible for doing it every time. Do not hesitate to make this a rotating task among team members!