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 Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

683 views 4 16
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot