Burn down or burn up – which is best?

Well it kinda depends on what you want to show to your stakeholders:

Burn down charts are great for showing progress in a sprint.  you can show Work in Progress (WIP), the actual burn and the ideal burn.  These three will give stakeholders and team members a snapshot of where you are in your build.  You can use it to give focus to certain areas to close the gap between ‘actual’ and ‘ideal’.  Burn up charts show the amount of work remaining on a project and a projection of work completed based on the current velocity of the team.

Burn-down charts have the advantage that they’re simpler — they only show one line.  However if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for release management and stakeholder management.

Burn Down Charts

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.   The Scrum Master updates the values for WIP and actual burn after the daily standup.

Burndown

Burn Up Charts

A burn-up chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.

burnup

 

You can make burn up charts more sophisticated, showing  several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.

complexBurnUp

Advertisements

Need a basic ‘Definition of Done’ – Here’s one ;)

Definition of Done

  1. All acceptance criteria has been met.
  2. All tests are passing.
  3. Code has been peer reviewed and refactored where necessary.
  4. Any technical debt has been recorded in a new story.
  5. New functionality is documented in the Wiki.
  6. Changes to the interface are documented in the IDL and REST documentation.
  7. Key decisions are documented in the Decision log.
  8. The build is ready to be deployed.