Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Reading the Burndown chart using time

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

1 answer

1 accepted

0 votes
Answer accepted
Warren Community Leader Dec 17, 2019

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.

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 

 

 

 

 

 

 Velocity.jpgBurndown.jpg

Warren Community Leader Dec 17, 2019

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

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

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Software

How to create Jira issus from Excel file?

When to use CSV importer When managing your processes in Jira, there are many occasions where you need to create a lot of tasks. Creating them one by one will cost you a lot of time and effort and i...

4,528 views 22 32
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you