Data Retention Settings

Eugene_Rack

Currently we have ours set to 365 days for all work items. Does anyone else have it set to something different and if so what is the best practice for data retention duration?

Adam_Dzyacky

The following is no means a best practice, but just wanted to share some (personal) rationale on the topic:

Changes = 365 days, I couldn't tell you why but being able to look back at a year of changes in the CMDB without resorting to the DW feels right for some reason

Incidents = This depends almost entirely per environment in my opinion (high/low IR volume), I'm a fan of around 120/180 days here as I want to treat Incidents as those one-off, break/fix scenarios that analysts should seldom have to lookup or reference in the future (especially for an affected user). Obviously if they do, you'll have to turn to the DW to get them or...

Problems = Any criticism of Incident management in the aforementioned example may be best solved with better defined Problem management. It's with this said, I'd argue that Problem retention should be at least double the time from Incidents so as to create a more bird's eye view.

Service Requests = I tend to be of the opinion that this particular retention number decreases as your organization moves away from Incidents (tickets if you will) and into more Service Requests. My logic here is that because SRs are a "I need" and less of a "it's broken fix it!" that you should hopefully be churning through SRs faster than IRs. Along the same line of thinking, if you were ripping through SRs faster than IRs you'd probably want to trend that through reporting. Ultimately - SRs I believe provide more value when represented through reports and less value from a real-time historical lookup in the live SCSM CMDB/operational db.

Release Requests = I won't challenge anyone's TFS users on this topic.


Again - by no means a best practice. Just sharing. I'd be interested to hear other's choices as well.

Adam_Dzyacky

The following is no means a best practice, but just wanted to share some (personal) rationale on the topic:

Changes = 365 days, I couldn't tell you why but being able to look back at a year of changes in the CMDB without resorting to the DW feels right for some reason

Incidents = This depends almost entirely per environment in my opinion (high/low IR volume), I'm a fan of around 120/180 days here as I want to treat Incidents as those one-off, break/fix scenarios that analysts should seldom have to lookup or reference in the future (especially for an affected user). Obviously if they do, you'll have to turn to the DW to get them or...

Problems = Any criticism of Incident management in the aforementioned example may be best solved with better defined Problem management. It's with this said, I'd argue that Problem retention should be at least double the time from Incidents so as to create a more bird's eye view.

Service Requests = I tend to be of the opinion that this particular retention number decreases as your organization moves away from Incidents (tickets if you will) and into more Service Requests. My logic here is that because SRs are a "I need" and less of a "it's broken fix it!" that you should hopefully be churning through SRs faster than IRs. Along the same line of thinking, if you were ripping through SRs faster than IRs you'd probably want to trend that through reporting. Ultimately - SRs I believe provide more value when represented through reports and less value from a real-time historical lookup in the live SCSM CMDB/operational db.

Release Requests = I won't challenge anyone's TFS users on this topic.


Again - by no means a best practice. Just sharing. I'd be interested to hear other's choices as well.