Insights >Blog

Addition of an Hours burn down chart increases visibility into SDLC

José Gramaglia

September 6th, 2012

One of our clients recently asked whether the “Hours” burn down chart was adding value to our team.  It is important to note that this particular client was accustomed to using the Point burn down chart but wasn’t clear on how this other chart would benefit the software development lifecycle (SDLC).  In answering his question,  I thought it might also be useful for others.

In my opinion, an Hours burn down chart adds a lot of value.  In fact, sharing this chart with a committed team is essential to achieving sprint goals.  Allow me to explain a bit more.

The two images I’m sharing belong to the same Sprint from the same team.


The image to the right represents a Point burn down chart.   Despite the fact that the green line is quite far away from the baseline (blue), this chart is perfect.  It is almost impossible to get closer to the baseline, unless there is a really small User Story where the SDLC can be completed in a single day.

There are though at least two other explanations for what might be happening (see chart #2 from August 16th  post):

  • Managers may ask the team to explain certain deviations (consuming time on meeting the team, and consuming time on team members reviewing the data) only to arrive at the conclusion that indeed the team was on track after all.
  • Or, in some cases,  after some repetitions of option 1, everyone simply assumes the chart looks as expected, no one is alerted, despite the fact that someone on  the team may be struggling with a particular task.  In this case, by the time you realize that’s happening, it’s already too late and the sprint goal is missed.

The great thing about the Hours burn down chart is that you “force” team members to review and share their real progress each day.   This takes no more than five minutes per day.   If there is a deviation between the Remaining hours and the Baseline, it indicates that the sprint goal may be at risk.  You then have time to review the tactics and apply adjustments as necessary. This doesn’t mean that there is always a solution to fix it to achieve the sprint commitment.  However, you have a better chance to think about it and use that in your decision making.


Related posts

See also


Software development

Software testing

Consultancy & innovation

User experience



Media & entertainment


All industries






Why Belatrix?

International presence

Nearshore advantages

Project governance

Agile expertise

Flexible engagement models

Our talent development