nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Burndown chart Scope change issue on Sprint start

Nuno_Duque

Hi,

I'm facing a problem with the Burndown chart.

I've planned my Sprint 3, and after adding ALL the Stories I start it on the 30/08.

The problem is that the burndown chart is showing the stories as if they were added after the sprint start, as Scope change. Even more akward is that it is marking this Scope changes as one per day for future dates always at 6:00.

Attached is the current Burndown chart on the 02/09.

Any idea what is the cause of this behaviour? And own can I solve it?

Accepted answers

All comments

Donny Cordova1

This is happening to me too.

Were you able to solve the problem?

Rahul Aich [Nagra]

Are you estimating the stories in your sprint before starting the sprint or after. If it is after that may explain why it is showing as scope change.

In ideal case stories must be estimated before the sprint gets started.

Rahul

Nuno_Duque

@Donny I still have the issue.

@Rahul The estimation was made before, and it work properly for the first 2 sprints. this start to happen at Sprint 3 and it's being occuring since.

Donny Cordova1

@Rahul - yes, the estimation was made before the sprint was started. After the sprint is started, all the stories appear in the burndown chart and report as scope change. My burndown chart and report are similar to Nuno's.

In case it is helpful, my board contains issues from two projects. Also, I have parallel sprints labs feature turned on. I am not using parallel sprints on this board, but they are being used in another project / board in my organization.

Donny Cordova1

Hi @Rahul and @Nuno,

I think my issue might have been caused by adjusting the sprint start date right before starting the sprint, from the default time it gives (current time) to an earlier day/time. We tend to start our sprints after planning meeting, which is usually Monday @ noon. However, in the last sprint, the planning meeting went late and we didn't start the sprint in JIRA until Tuesday morning. When I started the sprint in JIRA, I back-dated the sprint start date to the afternoon of the day before (to reflect when developers started working on issues). However, I think it treated all issues as scope change because of that.

Is that expected? @Nuno - did you adjust your start date?

I just started my next sprint, leaving the defaults, and at least initially, it seems fine. I did experience what @Nuno did with an issue appearing to change scope at the same time every day.

Thanks,
Donny

Nuno_Duque

Hi @Donny,

This happened for the first time in Sprint 3, and I did in fact adjust the dates (not sure if it was the start or end date, and for before or after). however it happens on the following sprint as well, even if the date weren't changed.

If the problem is with the dates being changes, it seems a bug to me. If the date change functionality is available it shouldn't cause this issue.

thanks,
Nuno

Mike Shkolnik

Sorry to attempt to revive such an old thread but it's 2016 and this still happens. Basically if you do sprint planning on the first day of the sprint and set the start time to any time before the moment you clicked "Start Sprint" (even an earlier time on the same day), any changes made between the start time set on the sprint and the moment you clicked "Start Sprint" are counted as scope change. This seems pretty crazy. Is there no way to work around this? I've worked with other tools that did not have this problem.

Steve Clark

For anyone experiencing this issue, you can simply edit the start time of the sprint to after you made the "scope changes."

You can do this by going to the backlog view and clicking "Edit Sprint" next to the active sprint.

sridhar Ramasubbu

Hi Steve,

What if the scope change date is 2 days after the sprint started, how to fix it?

Thanks,

Sridhar

James Cornthwaite

I was seeing this problem with issues added just prior to starting the sprint. being able to push the start time ahead a couple of minutes fixed it nicely. thanks!

Matt Stephens_uhtvx8

Well it's now 2018, and this issue still happens! Exactly as reported - happened to start the sprint in JIRA late, so backdated the sprint start date and it treats everything as scope change. Why hasn't this bug been fixed?!?

Chris_Dowing

The scope change thing happened to me today, luckily pushing the sprint start time ahead a few minutes did the trick.

Cheers!

PS. The problem does seem to have been there for quite some time now.

David Markowski (DO NOT USE)

Its 2019 and this is still happening...

FlorinB

it's 2020 and this is still happening.

FlorinB

Does anybody know who I can change the dates or how I can make the software to take given date and not the default entry dates?!

steve.vanarsdale

Hello. I met the same issue. And found no apparent solution. So I re-created the burndown report in Excel. A side benefit was the extension of the data over time into a comprehensive velocity report in Excel.

Velocity-information-radiator_Ex.2.jpg

Savvas Demetriou

Yup this is still a problem.

Atlassian seem to ignore these issues as they have been open for years.

I know I am going to have to add items that are only going to be ready to add after the sprint starts, and my burndown is going to go beserk.

I can't adjust my start date by a couple of days or even maybe a week, that's all wrong..

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud