Sprint reports are useless to us since they change over time

Question

I had already opened a bug for this, but apparently this is Not a Bug because there is no easy way to fix it (if our developers would reason like that we would be out of business by now):

https://jira.atlassian.com/browse/GHS-7266

Our rapidboard filters are based on sprint teams and if e.g. Team Rocket cannot complete an issue, or removes it from the sprint, and another team takes over, this issue "magically" disappears from the reports for the completed sprint of Team Rocket. Is that acceptable?

Fabian Meier1 · Answer

There is yet another example some of our users ran into:

https://answers.atlassian.com/questions/157963/greenhopper-scope-changes-are-inconsistent-is-this-expected

Fabian Meier1 · Answer

Sorry @Tom, but that is just an excuse. It should be absolutely clear that the Report mode cannot function like the Plan or Work mode and it does not because already today, the reports show the status the issue once had when it was in the sprint!

This shows that you are already storing historical information for the reports because a report looks at what happened in the past, not at the present situation!

I am sorry, but a "master board" is not an option for us as it is an impratical workaround. You are already logging estimate changes, scope changes, historical information about statuses...

And I tell you what, the solution is actually quite easy: The information you need to display the correct issues in the Reports mode is already in the database: The sprint custom field contains all the completed sprints. All you have to do is take that subset instead of filtering it further with the board filter query!

Tom Kotecki · Answer

Fabian,

I see where you're coming from, but this is a direct consequence of the way the boards are meant to work. Since the board filters allow you to have multiple views into the sprint (e.g. split by teams, like in your case), any issue that is not part of the filter will not show anywhere on the board - and that includes all the reports.

If you work with multiple teams who share a single backlog, the best solution would be to have a "master board" which contains both team's work. Any reports you'll see from this board will be unaffected by assignment of issues between teams.

Hope this helps

Tom Kotecki

Product Manager, GreenHopper