HKSM

Secure copies of code, configuration, data, and documentation created at planned intervals to enable recovery, rollback, or audit. In Scrum, they are maintained throughout sprints and used as inputs when restoring environments, supporting releases, or validating increments.

Key Points

• Copies of working assets created to recover from loss, corruption, or failed releases.
• Typically produced during Create Deliverables and used during Deploy Product Increment and Demonstrate and Validate Sprint.
• Scope includes source code, infrastructure as code, environment snapshots, databases, and key documents.
• Frequency and retention align with risk tolerance, compliance needs, and sprint cadence.
• Quality is proven by regular restore tests, not only by logs stating success.
• Access is controlled; encryption and integrity checks prevent tampering and silent failures.
• Links to Definition of Done and release back-out plans for reliable rollback.

Purpose

Back-ups protect the team from data loss and enable quick recovery so the sprint can continue with minimal disruption. They also support safe releases by allowing rollback when a deployment or increment fails validation.

In SBOK-aligned Scrum, they act as inputs to activities that verify or ship increments, ensuring continuity of development, testing, and demonstration environments.

Key Terms & Clauses

• RPO (Recovery Point Objective) - Maximum acceptable data loss, guiding how often to back up.
• RTO (Recovery Time Objective) - Target time to restore, shaping tooling and process choices.
• 3-2-1 Rule - Maintain 3 copies, on 2 media types, with 1 offsite or immutably stored.
• Full/Incremental/Differential - Strategies that balance speed, storage, and restore complexity.
• Snapshot/Point-in-Time - Fast captures of environments or databases for quick recovery.
• Immutability and Encryption - Protect against ransomware and unauthorized access.
• Integrity Checks (hashes/checksums) - Verify that back-ups are complete and uncorrupted.

How to Develop/Evaluate

Define the assets to protect (code, DBs, pipelines, configs, docs) and set RPO/RTO with stakeholders. Choose the approach (e.g., nightly full plus hourly incremental, or snapshot before merges and releases) and automate scheduling.

Store offsite or in immutable storage; enforce least-privilege access. Document restore runbooks and test restores on a cadence (e.g., per sprint). Evaluate by measuring restore success rate, mean restore time, and coverage against critical assets.

How to Use

During daily work, restore files or data after accidental changes, reseed test environments, and support hotfix rollbacks. Before Sprint Review, restore representative datasets for reliable demos.

During Deploy Product Increment, use verified back-ups in a back-out plan if validation fails. In Retrospect Sprint, inspect backup incidents, adjust RPO/RTO, and update the Definition of Done or working agreements as needed.

Example Snippet

Sample sprint-level backup policy:

• Code: Branch-protected VCS plus nightly repository snapshots; integrity hash verified.
• Database: Hourly incremental and daily full; 7-day hot retention, 30-day cold storage.
• Environments: Pre-release infrastructure and app snapshots taken before deployment.
• Testing: Weekly restore drill to staging; target RTO 30 minutes, RPO 1 hour.
• Runbook: Steps stored in team wiki; on-call rotation trained quarterly.

Risks & Tips

• Risk: Untested back-ups that fail during an incident. Tip: Perform scheduled restore drills and record results.
• Risk: Single-location storage vulnerable to outages or ransomware. Tip: Apply the 3-2-1 rule and immutability.
• Risk: Back-ups missing critical secrets or configs. Tip: Include IaC, secrets management backups, and document scope.
• Risk: Excessive recovery time. Tip: Use snapshots, parallel restores, and prioritize critical services first.
• Risk: Access misuse. Tip: Enforce role-based access, encryption, and audit trails.

PMP/SCRUM Example Question

During a release, the increment fails validation in production due to a corrupted configuration. What should the Scrum Team do to minimize downtime while preserving the last known good state?

1. Create a new user story to fix the configuration and schedule it for the next sprint.
2. Escalate to the Product Owner to re-prioritize the product backlog immediately.
3. Execute the back-out plan using verified back-ups to restore the previous stable version.
4. Hold an emergency Retrospect Sprint to discuss improvement actions before proceeding.

Correct Answer: C — Execute the back-out plan using verified back-ups to restore the previous stable version.

Explanation: The appropriate action during a failed deployment is to roll back using pre-validated back-ups to meet RTO/RPO and minimize impact. Prioritization and retrospectives happen after service is restored.