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!
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.
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!
@Jack Graves [AC] first caught our eye with his incredible breakdown of what, in his opinion, can make or break a Jira software implementation. (Read his thoughts on this thread)! In this follow...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG