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!