Burndown charts and scope changes

Jan De Geeter August 28, 2011

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

0 votes
Jan De Geeter June 26, 2012

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!

0 votes
Nica Huestegge June 26, 2012

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.

Suggest an answer

Log in or Sign up to answer