Is there any way to keep the sprint reports with old values after changing a board filter?

[Artur.Cybruch]

Hi Community,

My department decided to clean up the teams backlogs (which have between 200-400 items) so that the teams can focus on the future work rather than having all the items hoarded from X years ago. There's a usual attachment to the items that were created X years ago so my suggestion was to, firstly, categorise the old items vs. more forward looking ones and then start rejecting the ones that are no longer needed and will never be worked on.

We planned to do this by having 2 separate boards: Old Backlog (will include items created longer than 1 year ago and exclude tech debt items with a specific label) and Forward-looking Backlog (will include items created less than a year ago and tech debt items). However, this causes a problem in sprint reports due to the filters being used where the sprint reports are incorrect and under-report the numbers of story points etc.. Ideally, we'd want to still see the historical sprint reports with correct values that were used in the original sprints.

Has anyone ever come across this problem and is there any way to keep the sprint reports with the old values?

[Bill Sheboy]

Hi @Artur.Cybruch 

Yes, I have run into this challenge for several years using tools like Jira.  Unfortunately some tools do not account well for teams improving over time, and so history appears to be "altered" when a team makes a large change, such as workflow, status values, components, filters, etc.

When I help teams make a large change, such a backlog truncation, we create a new project and reset the clock completely.  Then move the items you want kept to the new project and leave the old project in place for historical reporting...and archive when it is no longer needed.  In the interim, consider making the information in the old project read-only through permission changes to avoid dual backlog use.

This approach will reset reporting history (e.g. velocity) but you can refer back to the old project for a while to check it.  Regardless, velocity is usually helpful for a few sprints, not months or years, so the impact should be smaller as the team moves forward.

Best regards,

Bill