Burn Down chart calculation

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.

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.

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 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.

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.

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? 

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? 

Hello , Sometimes I’m facing the same issue.

User stories are estimated not with hours , but points. These points are related to a whole user story , not split into items . We can estimate Items ( PBI ) in hours. So how the burndown chart can remain accurate if we have to update them daily , knowing that we cannot have completed informations about daily completed story points ? 

Moreover how can it make sense when we put in the y axis the velocity of the team, and in the chart things related either to daily points ( how to estimate their daily achievement ) or hours ( which are quite different from points ) ?

Velocity is the rate at which work is Done, not partially Done. I'd suggest that trying to update a burndown to reflect the partial completion of user stories actually makes little sense at all.

A user story burndown could be used to monitor how well focus is being applied, so Product Backlog items are evidently being completed early and often.

If the Developers wish to monitor the progress of the technical work they have underway in the Sprint Backlog, they may find a task burndown to be more illuminating.