Burndown charts and scope changes

I am confused as to how Greenhopper handles scope changes during the sprint. When we postpone an issue to a later sprint (change the fix version), Greenhopper removes this issue from the burndown chart, also for dates in the past.

In a comment on this page (http://confluence.atlassian.com/display/GH/How+Hour+Burndown+Charts+Relate+to+Time+Tracking+in+JIRA), Atlassian explains that Greehopper's philisophy is that, once the sprint planning is done, the chart will reflect what the team has committed on at the start of the sprint. However, it appears to me that Greenhopper only does right when you add a new issue after the sprint has started, or when you change the estimate of an issue during the sprint. When you add an issue to the scope that was created before the sprint started, or when you remove an issue from the scope, this does change the past datapoints in the burndown chart.

How do you handle this? Is this desired behaviour, and if so, why?

Thanks you for your comments!

2 answers

I never thought of it this way, but we use this to our advantage since we set the list of issues for one sprint as first action in the sprint. So, at the first day of a two-week sprint, we set the fix version of those issues we want to fix during the sprint - with the side effect that the discussions are fresh in mind when we start with our issues. If it indeed was a bug we'd have to change our behaviour...

I guess this doesn't necessarily help you but it might give you another perspective.

Hi Nica,

We are probably not living up to the rules of a good agile development process yet, moving issues in and out of the scope of the sprint after the sprint has started, but that is what we currently do. I see that your sprints are only two weeks, while ours are one month. The shorter the sprint cycle, the less chances that scope changes will be needed of course, maybe that is the solution.

But still, I feel that what Greenhopper does with the burndown chart is not correct. Manipulating data points in the past is wrong.

Thanks for sharing your experience!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 29, 2019 in Jira Software

Transforming Jira Software projects for general project management purposes

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....

478 views 5 8
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you