Your Sprint Burndown is telling you something. Are you listening?

Assumptions:
  • Product Backlog Items are represented as User Stories
  • User Stories are estimated in Story Points
  • Spring Backlog Items (aka tasks) are estimated in ideal hours
  • You draw a capacity line (aka "ideal line") on your burndown graph.

If any of the above assumptions is not valid, you might still be able to learn something from the graphs below -- you just may have to translate things to your particular situation.




Burndown 1: Work remaining is far below capacity at beginning of Sprint, OR work remaining remains far below capacity well into the Sprint.


bd2.JPG


Possible Causes

  • Way too little work is well defined on the Product Backlog
    • Possible Solution: Beef up the Product Backlog by kicking your PO into high gear and holding backlog grooming sessions.
    • Possible Solution: Have a developer and tester from the Dev Team help the PO groom stories, but still wait to estimate until the entire team is present.
    • Possible Solution: Look for more work
  • Assuming the team has selected a "full load" of stories for the sprint, then apparently the tasks for those stories have been wildly underestimated.
    • Possible solution: Have the team increase their task estimates to something more reasonably close to the capacity line
      • Work remaining at the beginning of the Sprint compared to the capacity line should be within an acceptable range
        • Acceptable Range
          • Sprints 1-4 for a new Scrum Team - 40%
          • Sprints 5+ for a Scrum Team - 20%
    • Possible solution: If the team is sticking to their task estimates, have them re-evaluate whether the Stories are estimated correctly or not.
  • The team does a lot of work "off the board".
    • This one is especially bad because it kills transparency. When you kill transparency, you kill your team's ability to inspect and adapt, which is the main reason for doing Scrum in the first place.
    • Possible solution: Make sure everyone has a task "in progress" every day on the board.
    • Possible solution: Strongly encourage the team to always have a task on the board for any non trivial(say, more than 1 hour per day) thing they're working on.
  • Some other cause? Email me with your ideas

Other Thoughts

  • This kind of burndown is pretty much a red flag that there are one or more very important impediments that need removal.



Burndown 2: Work remaining remains far below capacity throughout most of the timebox