Sprint Burndown Stops Before End of Sprint

JD January 24, 2020

We have a sprint burndown chart for a recent and closed sprint which does not burn all the way to the end of the period - it stops/has a gap with a day to go and the graph doesn't touch the rightmost side.

 

We had a lot of issues marked as done and some scope changes. We also had some incomplete issues which were moved to the next (current) sprint. Finally, some issues were removed from the sprint, all of which have now been marked as done except one (an epic, which stretches across multiple sprints and should not have been included in this sprint).

 

Do you know why the chart stops, how to fix it and why it happened/how to prevent it from happening in the future

Image link (trimmed) here: https://img42.com/EyXrP

1 answer

0 votes
Jack Nolddor _Sweet Bananas_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
January 27, 2020

JD,

It seems the Sprint was scheduled to run until 21/jan but was closed a day before that's the reason the red line stops/has a gap with a day to go and the graph doesn't touch the rightmost side.

 

Regards

JD January 27, 2020

Hi Jack.

This seems to be the issue! Thank you. And to convey my thanks, I have a quick follow up question, related to the burndown chart...  :l

We add in estimates before the sprint begins e.g. estimates are added at 2pm on 27/01/2020. Then the sprint is started (retrospectively) as of 9am on 27/01/2020.

This leaves the burndown chart starting at zero for a few hours, then quickly spiking to the total of the estimates before burning down as the team add time. No stories are added after the sprint is started.

Is there a way of getting the burndown chart to start at the total of the estimates rather than at zero?

We normally plan our sprint on sprint day 1, so we don't have estimates ready at 9am on sprint day 1; only after the planning has been done

JD January 27, 2020

Broken Burndown 2.png

Jack Nolddor _Sweet Bananas_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
January 27, 2020

Estimation needs to be done before the Sprint starts, if not i will be consider as Scope Change.

JD January 27, 2020

Even though we are estimating before we start the sprint (at 2pm) and then retrospectively starting the sprint at 9am?

 

Are you saying we'd need to estimate the day before?

JD January 27, 2020

It is my understanding that a new sprint starts at say 9am. The first item on day one of the new sprint is sprint planning, where planning and estimation of tasks are done.

 

How can the estimation be done prior to the new sprint starting?

 

Or would you do sprint planning and after that is complete with all estimation finalised, mark the new sprint as started e.g. at 2pm?

Jack Nolddor _Sweet Bananas_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
January 27, 2020

As far as I know, that's the correct way.

Task should be included on the top of the backlog once their are correctly Estimated and Documented (DoD and DoR) and them be selected for be included in one of the active or future Sprints.

JD January 27, 2020

I was editing my post just as you replied...could you confirm

"Would you do sprint planning at 9am-2pm and after that is complete with all estimation finalised, mark the new sprint as started e.g. at 2pm?"

Suggest an answer

Log in or Sign up to answer