Tingg

h1. Sprint Close Process Guideline (Redmine)

*Applies to all Scrum teams using Redmine*

*This process is mandatory and must be followed for every sprint*

---

{{toc}}

---

h2. 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*.

---

h2. 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) |

---

h2. Core Principle (Golden Rule)

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

Breaking this rule permanently removes sprint history.

---

h2. Phase 1 – Freeze the Sprint

h3. 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*.

---

h2. Phase 2 – Issue-Level Verification (Critical)

h3. Step 2: Review Every Issue in the Sprint

Filter issues using:

<pre>

Version = Sprint 2025-03

</pre>

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

---

h3. 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.

---

h3. 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.

---

h2. Phase 3 – Preserve Sprint History (Non-Negotiable)

h3. 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.

---

h2. Phase 4 – Clear Sprint Version (Key Step)

h3. 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

---

h2. Phase 5 – Close the Sprint Version

h3. Step 5: Close Version in Redmine

Navigate to:

<pre>

Administration → Versions → Sprint 2025-03

</pre>

Set:

|*. Field |*. Value |

| Status | Closed |

The sprint is now officially closed in Redmine.

---

h2. Phase 6 – Capture Sprint Metrics

h3. Step 6: Record Sprint Metrics

Use saved queries to capture metrics.

*Completed Work*

<pre>

Completed In Sprint = Sprint 2025-03

Status = Done or Closed

</pre>

*Velocity*

* Sum of Story Points for completed issues

*Spillover*

<pre>

Spillover Reason is not empty

</pre>

Optional actions:

* Export results as CSV

* Save summaries for audit or reporting

---

h2. Phase 7 – Update Sprint Wiki

h3. Step 7: Maintain Sprint Documentation

Update the Wiki page:

<pre>

Sprint 2025-03

</pre>

Include:

* Total completed stories

* Final velocity

* Key learnings

* Spillover summary

* Retrospective action items (linked issues)

This creates a human-readable sprint record.

---

h2. Phase 8 – Prepare for Next Sprint

h3. Step 8: Carry Forward Spillover

For spillover issues:

* Move issues back to the backlog

* Re-estimate if required

* Decide inclusion in the next sprint

---

h2. 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.

---

h2. One-Page Summary

<pre>

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

</pre>

---

h2. 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.*