Tingg

h1. Edge Case Handling – Hotfixes, Rollbacks, Emergency Releases

This page defines how to handle non-standard scenarios without corrupting sprint or release data.

{{toc}}

h2. Case A – Production Hotfix (Outside Sprint)

h3. Scenario

* Critical production bug

* Cannot wait for next sprint

h3. Correct Handling (DO THIS)

*Issue Creation*

|_. Field |_. Value |

| Tracker | Bug |

| Work Type | Bug Fix |

| Status | In Progress |

| Sprint Version | *Not set* |

| Release Version | Release 2.5.1 – Hotfix |

h3. After Fix

* Status → Done

* Deployment Reference URL added

* Status → Closed

* Release Version marked Closed

h3. Why This Works

* Sprint metrics remain clean

* Full production traceability

* Clear audit trail

*bq.* Do NOT backfill into sprint  

*bq.* Do NOT create fake sprints for hotfixes

---

h2. Case B – Hotfix with Sprint Follow-up

h3. Scenario

* Immediate patch required

* Proper fix planned later

h3. Correct Handling

1. Hotfix issue:

   * Release Version only

2. Follow-up work:

   * New Story

   * Work Type = Tech Debt

   * Planned through normal backlog and sprint

This separates urgency from correctness.

---

h2. Case C – Rollback Release

h3. Scenario

* Release deployed

* Rolled back due to issues

h3. Correct Handling

* Do NOT reopen completed issues

* Create new Bug(s)

* Work Type = Bug Fix or Platform

* Assign Release Version:

<pre>

Release 2.5.1 – Rollback Fix

</pre>

h3. Why

* History remains immutable

* Rollback is recorded as an event, not a rewrite

---

h2. Case D – Partial Release

h3. Scenario

* Some stories ready

* Others delayed

h3. Correct Handling

* Release Version contains only:

  * Accepted

  * Deployed stories

* Delayed stories:

  * Have no Release Version

  * Planned into next release

Results:

* Clean release notes

* No ambiguity