Managing burn charts

Managing burn charts2017-10-12T22:05:27+00:00

Burn Chart Workflow

Context

Summary

Provide a summary of this practice.

A burn chart is a simple, widely used work tracking tool that makes it easy to predict the outcome of an iteration or release and take corrective or preventive action where it’s needed. It shows in a simple format the team’s ‘earned value’.

Purpose

What is the overall goal or intention of this practice?
Burn charts summarise progress in a form that is:

  1. Easily created.
  2. Easily maintained.
  3. Easily understood.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

Status should be reported and the burn chart updated at least daily.

  • In Daily Stand-Up Meetings.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

Burn charts continue to be used for as long as the iteration (or release) continues.

Entry conditions

What pre-conditions must be met before this practice is used?

Burn charts cannot be useful until:

  • The iteration stories have been estimated.
  • The team’s velocity is known (or a good proxy is available).
  • Work has actually started.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Prepare burn chart
  1. Prepare chart & axes.
  2. Calculate Effort Available.
  3. Draw Effort Available line.
  4. If using a Burnup Chart, draw in the Total Deliverable Story Points line.
  5. Check Effort Available and Total Deliverable Story Points converge at the end-date.
  6. Display the burn chart prominently to the whole team.
2Maintain burn chart
  1. At least daily, review status of stories in progress with responsible user & developer.
  2. If 100% complete, update chart.
3Analyse burn chart
  1. At least daily, track progress towards end-date.
  2. If diverging from planned date, agree remedial action with user & developer.
  3. Report as required.

Detailed process

#StepByOutputInstructionsNotes
1Prepare burn chartIteration Lead.Initial burn chart.
  1. Prepare chart & axes.
  2. Calculate Effort Available.
  3. Draw Effort Available line.
  4. If using a Burnup Chart, draw in the Total Deliverable Story Points line.
  5. Check Effort Available and Total Deliverable Story Points converge at the end-date.
  6. Display the burn chart prominently to the whole team.
  • To create the basic chart:
    1. Decide what units to use.
      • Generally speaking, burn charts use:
        • story points or
        • tasks points
      • Do not use stories themselves!
        • They are different sizes, so make burn charts misleading.
    2. Set up the axes.
      • The horizontal axis defines elapsed time from start date to end date of the release/iteration.
        • Typically day-by-day.
      • The vertical axis shows the effort available to do the work.
  • When publishing the chart, make sure that it is visible in all locations – offshore teams, etc.
2Maintain burn chartIteration Lead.

Iteration Team.

Updated burn chart.
  1. At least daily, review status of stories in progress with responsible user & developer.
  2. If 100% complete, update chart.
  • The chart should always be updated after Daily Stand-Up Meetings.
  • The team may want to update it more frequently – e.g., to make clear the status of especially risky or difficult tasks and stories.
  • For an explanation of why only 100% complete stories are credited, click here.
3Analyse burn chartIteration Lead.

Iteration Team.

Progress & status reports
  1. At least daily, track progress towards end-date.
  2. If diverging from planned date, agree remedial action with the responsible user & developer.
  3. Report as required.
  • Click for methods of burn chart analysis.
  • Progress should be reviewed by the whole team. This will ensure that the real significance of small variations or invisible obstacles are properly understood.
  • If the Product Owner does not attend all Daily Stand-Up Meetings, the Iteration Lead should ensure that they are aware of progress, obstacles & how issues are being managed.

Issues & risks

What are the key concerns in making a success of this practice?

  1. For more about burn charts, click here.
  2. Burn charts can be used at both iteration & release level. Iteration-level charts can also be added together to project the probable outcome of a complete release.
  3. Burn charts are very powerful communications tools for the Product Owner, senior management and other stakeholders  but only if they are accurate and up to date.
    • Daily progress tracking requires discipline.
    • But it provides the extra visibility of real progress, risk, obstacles and dependencies on which Agile relies.
  4. It is valuable to record the specific impediments and opportunities that will affect how delivery progresses.
    • It makes it easier to identify recurring patterns & problems.
    • Alternatively, consider using a highly visible Improvement Board.
  5. Problems fixed informally can be neglected. If they are recorded directly on the burn chart, this will:
    • keep them in the team’s mind.
    • encourage synergistic solutions across multiple problems/stories/iterations.
    • provide usefully explicit input to your subsequent Retrospective.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?