Burn Down chart calculation

Last post 10:32 pm September 17, 2021
by Ruth Russell
7 replies
Author
Messages
09:02 am September 4, 2017

In a Sprint if User Stories are estimated in Story points how is the burn down chart calculated.

Does the burn down chart is updated when Story points gets completed during the sprint or in a day by how many Story points are consumed or it is done through  task updation in hours or days or some other way.

 

Thanks,

Pradeep

09:33 am September 4, 2017

Scrum does not describe how you should visualize your sprint progress, so I would say it's whatever you think provides the best information for the team.

I'm not sure how you would divide story points properly for partially done work. If you estimate the tasks in hours/days and the tasks are up to date and reflect the current best estimate of remaining work, this could provide an accurate visual i.m.o.

You could also use other charts, like a burn up part for incoming work that wasn't planned upfront.

03:23 pm September 4, 2017

User Stories on a Product Backlog are commonly estimated in story points. The stories chosen in Sprint Planning are then commonly broken down into tasks estimated in hours. When a team follows this convention it can expect two measures of work remaining: story points and task hours. Either one or both of these might be modeled using a burn-down chart.

05:52 pm September 4, 2017

I agree with Ian. However, I am favor of using points when I can. Since you will have your story estimation and prioritization signed off by the customer/owner and your sprint is fixed, you don't need to worry as much about expectation disappointments based on some measurable unit like time. My teams have enjoyed this freedom and it fosters confidence in the team that will benefit everyone in future Sprint Planning meetings moving forward.

03:13 pm September 7, 2017

I agree with Ian. However, I am favor of using points when I can. Since you will have your story estimation and prioritization signed off by the customer/owner and your sprint is fixed, you don't need to worry as much about expectation disappointments based on some measurable unit like time. My teams have enjoyed this freedom and it fosters confidence in the team that will benefit everyone in future Sprint Planning meetings moving forward.

I'm not exactly sure what you mean by signing off estimation and prioritization, but a sprint is not fixed.

Just to be clear, the visualization of sprint progress is for the development team to manage their work. If using time as estimation and progress measure affects freedom and/or confidence in the team, there is something else wrong i.m.o.

08:22 pm September 11, 2017

Hi Norbert,

You are correct. (I apologize, I was responding to the thread and not your question). I like to update my charts daily to see where any ups and downs occur so I can rationalize that days situation in the Retrospective if necessary. Then you are all caught up at the end of your Sprint. If you use some of the software available, this is handled for you but you still need to be keeping it up to date.

 

03:20 am September 16, 2021

Hi All, Jumping into this conversation, I my scrum board, we use 'Story Point' field for estimation. However, there are few more additional fields in JIRA like 'Original Estimate' , 'Remaining Estimate' which isn't used much. Any idea if 'Original Estimate' field is to have respective estimated hrs of original story? Can confirm if Burn down chart uses 'Remaining Estimate' field to plot the trend line? 

10:32 pm September 17, 2021

View and understand the burndown chart | Jira Software Cloud | Atlassian Support

Configure estimation and tracking | Jira Software Cloud | Atlassian Support

Jira let's you do things like just use story points or use a combination of story points and tasks, so it depends on what works best for the team and you can configure Jira accordingly. 

The notes on Atlassian basically say if you want to then you can get it to work so that values only burn down when users enter time spent or set the remaining estimate to a new value. Whilst the documentation does explain everything, I had to have play with Jira on a fake board to see what Logging fields were actually affecting the burndown chart and what time tracking mechanism choices worked.

Maybe you could try some scenarios on Jira so you get to see first hand how it all works?