Reading the Burndown chart using time

[Juan Du Toit]

Hi,

We are using time to estimate our work as we bill by the hour and  run weekly sprints

I am looking at a burndown chart where we track time spent using remaining time estimate as I want to understand it better as to give feedback to the team 

My understanding is:

• The green line burns hours up which was logged during sprint
• The red line burns down as time is being logged during sprint 
• The red line burns down if the remaining estimate has been reduced
• The red line shows the initial commitment
• The red line burns up if the remaining estimate has been changed to a higher value
• The red line burns up when issues with time estimates get added to the sprint
• Commitment values should be the same when looking at the burndown chart and the velocity chart

Questions:

• Why does the green line burn down if an issue was removed from the sprint with some time still left on the remaining
• Is there another scenario's where the green line will burn down? 
• Does the green line represent hours logged during the sprint and the red line hours remaining? In other words, in extreme sprint scope change conditions, the green line would burn up, but the red line burns down very slowly creating a gap between the committed hours vs remaining? The wider the gap, the bigger the scope change in adding work?
• Why do the commitment and completed values differ between the burndown chart and the velocity report?
• Is there any additional information one can deduce from the burndown I attached?

Screenshot: Burndown

1. Commitment: 257h
2. Client-1: Scope Change - Issue Removed from sprint
3. Time logged: 242 (Completed value)
4. Time remaining: 58.83h
5. Difference between point 1 and 4 against point 1 = the scope change?

Screenshot of Velocity Report

1. Commitment:343.48h
2. Completed: 204.43

Thanks for all your help - I know it's a month full

[Warren · Accepted solution]

Hi @Juan Du Toit 

The green line is the amount of effort in the sprint i.e. the amount of time that has been logged by the team. If an item is taken out of the sprint, the time that was logged on that item doesn't relate to the sprint anymore, hence it will go down slightly.

The red line is the remaining time, which will change when :

• Someone explicitly changes the remaining time on any ticket
• Someone logs time against a ticket (Jira automatically updates the remaining)
• A ticket is added to the sprint after sprint start
• A ticket is removed after sprint start

I don't see any attachment here, but from your Burndown description, the difference between commitment and remaining ISN'T necessarily the scope change - it would only be that if it was a perfect situation where each team member logged exactly 1 day's hours every day and never updated a remaining estimate.

Under the Burndown chart is the list of all sprint changes and that is the only accurate log of scope changes.

[Juan Du Toit]

Hi Warren

Thanks for the feedback. I will attach the screenshots again as a reference

(Which was suppose to be attached)

I am still a bit unclear as to why the green line burns down if an issue was removed.  My take on the green line is time logged during the sprint, so why would it burn down? To me, that drop shows time not logged (Losing an hour's logged work) 

There is also a discrepancy between the Velocity Chart and the burndown as per the screens shots.  Any idea why this is?

Commitment:

Velocity Report: 343.48h

Burndown: 257h

Completed:

Velocity Report: 204.43h

Burndown: 242h 

 

[Warren]

Hi @Juan Du Toit 

The green line is time logged "in the sprint", so if you take something out the sprint, it then doesn't count as part of that sprint (or at least that's my reasoning). 

Honestly, I'm not a fan of Jira's Velocity report. I wonder if the velocity is based on Original Estimate, as opposed to Remaining Time, that could explain the discrepancy

[Juan Du Toit]

Hi Warren

Think I will do some investigations and see what the discrepancy is between the 2.

I agree that the time is logged "in sprint", but I don't see the reasoning behind the greenline burning down if it's removed from sprint.  Almost seems like the team is being penalised with the remaining estimate if it's removed for whatever reason. I will do some testing here also to see what the behaviour would be for a task that gets removed with no remaining estimate.

Thanks for all your help

[Ridham Sharma]

Hi @Juan Du Toit Do you mind sharing the configurations on your jira board to create velocity chart /table you have shared above.