Sprint Close Process Guideline (Redmine)¶

Applies to all Scrum teams using Redmine
This process is mandatory and must be followed for every sprint

---

• Table of contents
• Sprint Close Process Guideline (Redmine)
  • Purpose
  • Ownership and Timing
  • Core Principle (Golden Rule)
  • Phase 1 – Freeze the Sprint
    • Step 1: Stop Scope Changes
  • Phase 2 – Issue-Level Verification (Critical)
    • Step 2: Review Every Issue in the Sprint
    • A. Completed Issues
    • B. Not Completed (Spillover)
  • Phase 3 – Preserve Sprint History (Non-Negotiable)
    • Step 3: Validate All Sprint Data
  • Phase 4 – Clear Sprint Version (Key Step)
    • Step 4: Clear Sprint Version from All Issues
  • Phase 5 – Close the Sprint Version
    • Step 5: Close Version in Redmine
  • Phase 6 – Capture Sprint Metrics
    • Step 6: Record Sprint Metrics
  • Phase 7 – Update Sprint Wiki
    • Step 7: Maintain Sprint Documentation
  • Phase 8 – Prepare for Next Sprint
    • Step 8: Carry Forward Spillover
  • Final Validation Checklist
  • One-Page Summary
  • Final Statement

---

Purpose¶

This guideline defines the mandatory Sprint Close process in Redmine to ensure:

• Accurate sprint history
• Reliable velocity calculation
• Clear spillover tracking
• Clean and performant Redmine data
• Easy audits and reporting

Failure to follow this process results in loss of sprint history and unreliable metrics.

---

Ownership and Timing¶

*. Item	*. Details
Owner	Scrum Master
Required Participants	Product Owner
When	After Sprint Review and before next Sprint Planning
Mandatory	Yes (no steps may be skipped)

---

Core Principle (Golden Rule)¶

bq. Never clear the Sprint Version before setting the “Completed In Sprint” field.

Breaking this rule permanently removes sprint history.

---

Phase 1 – Freeze the Sprint¶

Step 1: Stop Scope Changes¶

Once the Sprint Review is completed:

• No new issues may be assigned to the Sprint Version
• No priority changes are allowed inside the sprint

When this is done, the sprint is considered frozen.

---

Phase 2 – Issue-Level Verification (Critical)¶

Step 2: Review Every Issue in the Sprint¶

Filter issues using:

Version = Sprint 2025-03

Each issue must be handled using one and only one of the paths below.

---

A. Completed Issues¶

For issues that are fully completed in the sprint, set all of the following:

*. Field	*. Required Value
Status	Done
Completed In Sprint	Sprint 2025-03

Verify before proceeding:

• Acceptance Criteria are met
• QA is completed
• No open sprint bugs remain

Important:
Do not clear the Sprint Version at this stage.

---

B. Not Completed (Spillover)¶

For issues not completed in the sprint:

*. Field	*. Required Value
Status	In Progress or Ready
Spillover Reason	Mandatory (must be filled)
Completed In Sprint	Do not set

This ensures incomplete work is properly explained and traceable.

---

Phase 3 – Preserve Sprint History (Non-Negotiable)¶

Step 3: Validate All Sprint Data¶

Before clearing the Sprint Version, confirm:

• Every completed issue has Completed In Sprint filled
• Every spillover issue has a Spillover Reason
• No issue is ambiguous

bq. If anything is incorrect, STOP and fix it before continuing.

---

Phase 4 – Clear Sprint Version (Key Step)¶

Step 4: Clear Sprint Version from All Issues¶

For every issue in the sprint:

*. Field	*. Action
Version	Clear (empty value)

After this step:

• The Sprint Version is no longer used by any issue
• Sprint data is preserved in custom fields

---

Phase 5 – Close the Sprint Version¶

Step 5: Close Version in Redmine¶

Navigate to:

Administration → Versions → Sprint 2025-03

Set:

*. Field	*. Value
Status	Closed

The sprint is now officially closed in Redmine.

---

Phase 6 – Capture Sprint Metrics¶

Step 6: Record Sprint Metrics¶

Use saved queries to capture metrics.

Completed Work

Completed In Sprint = Sprint 2025-03
Status = Done or Closed

Velocity

• Sum of Story Points for completed issues

Spillover

Spillover Reason is not empty

Optional actions:

• Export results as CSV
• Save summaries for audit or reporting

---

Phase 7 – Update Sprint Wiki¶

Step 7: Maintain Sprint Documentation¶

Update the Wiki page:

Sprint 2025-03

Include:

• Total completed stories
• Final velocity
• Key learnings
• Spillover summary
• Retrospective action items (linked issues)

This creates a human-readable sprint record.

---

Phase 8 – Prepare for Next Sprint¶

Step 8: Carry Forward Spillover¶

For spillover issues:

• Move issues back to the backlog
• Re-estimate if required
• Decide inclusion in the next sprint

---

Final Validation Checklist¶

Before declaring the sprint closed, confirm:

• Can we answer what was completed in this sprint?
• Can velocity be recalculated months later?
• Are spillover reasons clear?
• Can a new team member understand this sprint from records?

If all answers are Yes, the sprint is correctly closed.

---

One-Page Summary¶

1. Freeze sprint
2. Mark completed issues → Completed In Sprint
3. Mark spillover → Spillover Reason
4. Clear Sprint Version from all issues
5. Close Sprint Version
6. Capture metrics
7. Update Sprint Wiki
8. Prepare next sprint

---

Final Statement¶

Following this guideline ensures:

• Permanent sprint traceability
• Accurate velocity
• Clean releases
• Fast and maintainable Redmine usage

This process is mandatory for all teams.