Select Page

All of us would have used sprint burn down charts on our projects. Each one of us will have our opinion on the effectiveness of it. We might also have our own favorite flavors and versions. 

I’m going to talk about one implementation of Sprint Burn Down Chat that could be useful for the teams who are relatively new to agile and are very comfortable with effort estimates.

When we use story points for sprint burndown, the chart may not have significant information as the story closure during a sprint is infrequent and predominantly loaded over the final phase of the sprint.

The following chart is an actual case from one of the teams that had started embracing agile recently. 

This chart shows the list of items in testing backlog. We could see the completed stories line up for testing at the end of the sprint. 

One of the approaches I tried with reasonable success is to task/sub-task the stories. The sub-tasks are granular:

Tasking: Guidelines

  • Granular: could be done in 1 day or 2
  • Technical / Horizontal …
  • Clear Estimates in Effort Hours
  • Always look ahead: how much more time necessary (NOT how much time spent)

Usually, I’d encouraged teams to create tasks during Sprint Planning Meeting. This helps every team member to share their ideas. The testing becomes better as the story is broken down. The possibility of some one else picking up a story/task, in any eventuality, is easier. 

Tasking: Benefits

  • Increases transparency
  • Improves our ability to respond (as we get quicker feedback)
  • Possible to distribute Test Effort

Test Early (at task level): Fail Fast

Once we start tracking the tasks, the Burn Down chart becomes more usable. A few samples are attached. 

Tasking: Challenges

  • There may be an argument that the effort estimate in hours is not the agile way
  • Tasking is micro-managing

My recommendation is that the teams moving from conventional development to agile, would find the tasking and effort estimate easy to follow. Once they become comfortable with agile practices, they could still do tasking without effort estimates and the burndown could track the number of tasks instead of time remaining. 

Reference:

SK