Archiving strategies - best practice

[Dave Cobb]

I currently have a number of projects that are accumulating a number of "DONE" issues.
One strategy I have adopted is to filter the board to only show done issues within a set range, e.g. 30 days.

Which is fine from a visual perspective, e.g. hiding the issues. However, when running bulk operations it still has to run through all of the issues, which adds an increasing overhead.

I was considering moving aged DONE issues to a separate project and updating a custom field to give indication of the team that completed the issue (we have multiple teams & projects). The issues would sit there for auditing & review purposes.

What strategies does everyone else follow in these circumstances?

[Nic Brough -Adaptavist-]

I don't bother filtering boards for this.  With a Kanban, a release clears the issues out of done, and with a scrum, done things drop out when the sprint ends.  Filters for a whole project, I want to include the done ones.

So a question is where are these a problem in boards?  (I know growing projects is an issue for searches and gadgets etc, but your approach of using "and status != done" or "resolution is not empty" is already the way to go with this)

[Dave Cobb]

Glad I'm on the right track with hiding issues.

I don't see it as being an immediate problem, as the done tasks are in the low thousands. But can see it being a problem when you need to perform bulk operations across the whole project as I believe it still iterates over all issues regardless of status(?) 

[John Funk]

Just remember to clearly define your filter when doing the bulk operations and it shouldn't have to touch all of the Done ones. 

[John Funk]

Hi Dave,

We do a weekly release for each project that will move the Done tickets off of the board. That way each team is aware of what got done that week (how many tickets were moved to Done) and how many they should roughly replenish this week to work on. 

The release is simply a date stamp, and not a traditional "version release". So our release name would look something like October 9, 2019 Release. That's it!

Not sure that's a "best practice" but works for us.  :-)

[Dave Cobb]

Thanks for confirming your approach, that really helps.