How to read a Burn-down chart

How to read a Burn-down chart

Why Burn-down Chart?

Burn-down chart is a simple and yet a very powerful tool to view/monitor/make visible your team’s progress. I’ve never see any other report that can show me the teams progress in 5 seconds.

How do you read a Burn-down Chart?

             1)   The Y axis shows the remaining effort (in hours) required to complete the Release (400 to 0).

             2)   The X axis shows the number of days until the Sprint ends (e.g. Jan 13 in the image)

             3)   The Blue line is the ideal scenario. the team has 400 hours available to Burn-down @ 40 hrs each    day. This Blue line will drop 40 hrs every day e.g. 400, 360, 320, 280 …. 40, 0.
       4) The Red line is your actual Burn-down. This should reflect the hours remaining and Not the hours spent. A common mistake teams do is that they update hours spent and not hours remaining and this makes the Burn-down useless.
      E.g. I have 400 hours available for this release & on day 1 the team spent 40 hrs..now does that mean I have 360 remaining on Day 2? Well..NO
      The team may spend 40 hrs on these tasks but may require another 20 hrs to complete it. This means your Burn down for Day 2 should read 380 and not 360.

How to read this chart in 5 seconds?

   1)      If your red line (actual Burn-down) is overlapping the blue line (planned Burn-down) then your project is on schedule.

    2)      If your red line (actual Burn-down) is below the blue line (planned Burn-down) then your project is ahead of schedule.

    3) If your red line (actual Burn-down) is above the blue line (planned Burn-down) then your project is not going to meet its release date

Isn’t this simple!

 

Sizing Stories with Planning Poker

Sizing Stories with Planning Poker

As a Scrum Master / Coach i hear a lot of non-agile enthusiasts complain about Story Sizing.

" Why size stories and waste time?"

"I want hours and not some vague story points"

"We spent so much time playing poker but i really see no value in it"

Well Story Sizing exercise is definitely a waste of time if you don't know the real reason behind it.

"The value in sizing is in the cross-functional discussion"

This is the probably the first time a group of individuals of various skill sets are coming together and having a discussion. Developers, Testers, Business Analysts & UI folks look at user story from various angles and this is what you want to capture during the sizing exercises.

If you are convinced about the usefulness of sizing then read on..

“Olive garden serves me twice the amount of Chicken Alfredo Pasta than what I would get at the Cafeteria”

Our Limitations:

We humans are better at relative sizing than absolute sizing..Why spend days coming up with upfront effort estimation in hours when most of the time your numbers rarely match up with actual's.


Story Points:

• Story Points are only used to size stories on the Product Backlog and Not Within the Sprint
• Story points are NOT effort estimation in hours
• Story points are relative estimates

 i.e. You get the numbers by comparing one Story to another

 There is always a reference story (A )and all other stories (B, C &D) are compared to this reference story.

Usually…

The Higher the uncertainty and risks for a given story the higher is the story point.

 Why not estimate these Stories in Hours?
   A While ago Yale University had reported that
“The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours “

This means that Hours completed tell us nothing about how many features we can ship and when we can ship them.

The most important metric that defines our progress is ..
The number of story points the team has committed and can deliver per Sprint.
Rather than the number of hours being spent by the team per Sprint.

How is Planning Poker Done

• Each person (estimator) participating in the estimation process is given a deck of cards, each card has valid estimate written on it
• Customer/Product owners reads a user story and it’s briefly discussed
• Each estimator selects a card that represents their estimate
• Cards are turned over so all can see them
• Differences between estimates are discussed
• Re-estimate until estimates converge

Varied Estimates!!
Varied estimates mean that it’s a good time to get the unknowns out. Testers might have some specific scenarios in mind which developers have not even thought about.
Same goes with developers too!!

Repeat Till estimates converge

Let’s Play Poker!