Tuesday, August 09, 2016

Agile Burn Down Chart

I am guiding a project team on some architecture changes. Its a new product. However, I was not getting any clear picture on the progress. I checked Burn down chart. Even that did not give me clear picture. I checked with project team as well Process team on the burn down chart. AND they successfully confused me. :-)

Process team told me that they track the burn down chart based on the 'remaining effort'. Every day each team member update how much time he/she worked any story. The 'remaining time' is the used to plot the 'burn down chart'. 

Now consider the scenario below
  1. Original estimate of Story A is 40 hours.
  2. Team member X, worked on Story A on first day for 8 hours. So he logged 8 hours and 'worked' and 32 hours as remaining.
  3. 2nd day he worked for 8 hours and updated 24 hours as remaining
  4. 3rd day he worked for 8 hours and updated 16 hours as remaining
  5. 4th day he worked for 8 hours and realized that many more things are still do be done to actually complete the story. So he updated 36 hours as remaining.

The chart will show that till day 3 you are on track. However, on day 4 you are suddenly 'delayed'. At this point, the graph will shoot upwards (Q: Do I still call it burn 'down' chart ??). In my opinion, this type of burn down chart gives a misleading picture to project team. On top of this,  consider that sprint duration is 1 month and stories are estimated at 40 to 60 hours duration. Now you have completely inaccurate picture of project progress. Many cases, by the time PM or Scrum master realizes something is wrong, team is very near to end of Sprint and has very little time to take any corrective action. Exactly the scenario that you are trying to avoid by implementing Scrum. !!!!

So what a Scrum team should do to get better picture in "burn down chart" ??

This is what I will do
  1. I will not use remaining time (or remaining story points) to update the burn down chart.
  2. If the story is not done, then entire estimated time is 'shown' as 'remaining' in burn down chart.
  3. When the Sprint starts, I will ensure that stories are broken down to level where they can be completed in 2-3 days (irrespective of I am using story points or hours for 'story sizing').
  4. I will ask which stories may get delayed during the Daily Huddle, but will not use 'remaining hours' estimate by developer to update the burn down. I will use this info only to decide who may need help and how to give that help.
Now my burn down chart will look like a ladder. 
For the above scenario,  till first 3 days, story will remain open and at 40 hours remaining time. On 4th day, when story is complete, remaining time will go to 0. The burn down chart will now look like this.

What do you think ? How do you calculate the burn down chart in your project ?


Manoj Phatak said...

Makes perfect sense!
I find it equivalent to Dr. Goldratt's approach of measuring THROUGHPUT, INVENTORY & OPERATING EXPENSE.

THROUGHPUT is a measure of value delivered. In this case it is expressed in terms of # of stories & may be weight representing how important that story is.

It has to be binary. i.e. Story is either DONE or NOT DONE.

Its still useful to report how many efforts we actually spend on the story that is yet incomplete. That's INVENTORY. Its the time we invested, but value not yet realized. A high inventory means we either have too much fragmentation or there are some unimitigated risks.

Krishna Oza said...

The problem seems to be here with the estimation, I have also faced a similar situation that the estimation go for a toss and we end up carry forwarding the work in the next sprint.