Tingg

h1. Edge Case & Exception Handling (Authoritative)

*Applies to all Tinggit products managed in Redmine*  

*Defines how non-standard, urgent, or exceptional situations are handled without corrupting sprint or release data*

{{toc}}

---

h2. 1. Purpose

This document defines **how Tinggit handles exceptions** such as:

* Production hotfixes

* Emergency fixes

* Rollback releases

* Partial releases

* Mid-sprint interruptions

* Compliance-driven urgent work

The goal is to ensure that **exception handling never damages**:

* Sprint metrics

* Release traceability

* Audit history

* Product credibility

*bq.* Exceptions must be controlled — not improvised.

---

h2. 2. Scope

This process applies to:

* All products under the Tinggit Platform

* All teams (Product, Engineering, QA, DevOps)

* All work that cannot follow the normal Sprint → Release flow

---

h2. 3. Governing Principles (Non-Negotiable)

1. Sprint data must never be rewritten

2. Release history must remain immutable

3. Emergency does not justify process corruption

4. Every exception must leave an audit trail

5. Sprint and Release must never coexist on the same issue

---

h2. 4. Exception Categories

All exceptions fall into one of the following categories:

|_. Category |_. Description |

| Production Hotfix | Immediate fix required in production |

| Emergency Fix | Urgent work threatening stability or compliance |

| Rollback | Reverting a released change |

| Partial Release | Releasing subset of planned scope |

| Sprint Interruption | Emergency work during an active sprint |

| Compliance Exception | Regulatory or legal urgency |

Each category has **explicit handling rules** below.

---

h2. 5. Production Hotfix (Outside Sprint)

---

h3. 5.1 Scenario

* Critical production bug

* Customer impact is active

* Cannot wait for next sprint

---

h3. 5.2 Correct Handling (MANDATORY)

*Issue Creation*

|*. Field |*. Value |

| Tracker | Bug |

| Work Type | Bug Fix |

| Status | In Progress |

| Sprint Version | *Not set* |

| Release Version | Release X.Y.Z – Hotfix |

Rules:

* No Sprint Version is ever assigned

* A new patch Release Version is always created

---

h3. 5.3 After Fix

* Status → Done

* Deployment Reference URL added

* Status → Closed

* Release Version marked Closed

---

h3. 5.4 Why This Works

* Sprint metrics remain clean

* Release history remains truthful

* Audit trail is preserved

* Emergency response is fast but controlled

*bq.* Never backfill hotfixes into a sprint.

---

h2. 6. Emergency Fix During an Active Sprint

---

h3. 6.1 Scenario

* Critical issue discovered mid-sprint

* Work is unrelated to Sprint Goal

---

h3. 6.2 Correct Handling

* Create a new Bug issue

* Do NOT assign Sprint Version

* Handle as:

  * Production Hotfix, or

  * Emergency Fix release

Sprint work continues uninterrupted unless PO explicitly re-evaluates the Sprint Goal.

---

h3. 6.3 Sprint Protection Rule

Sprint scope must not silently expand.

If emergency work threatens the Sprint Goal:

* Product Owner decides

* Sprint Goal may be revised

* Decision must be documented in Sprint Wiki

---

h2. 7. Hotfix With Planned Sprint Follow-Up

---

h3. 7.1 Scenario

* Quick patch now

* Proper fix needed later

---

h3. 7.2 Correct Handling

1. Immediate Hotfix

   * Release Version only

   * Minimal scope

2. Follow-up Work

   * New Story

   * Work Type = Tech Debt or Platform Improvement

   * Planned through normal backlog and sprint

This separates **urgency from correctness**.

---

h2. 8. Rollback Release

---

h3. 8.1 Scenario

* Release deployed

* Issues require rollback

---

h3. 8.2 Correct Handling

* Do NOT reopen completed issues

* Do NOT edit past release scope

* Create new Bug issues

* Assign new Release Version:

<pre>

Release X.Y.Z – Rollback Fix

</pre>

---

h3. 8.3 Why This Is Mandatory

* History remains immutable

* Rollback is recorded as a new event

* Auditors can see cause and response clearly

---

h2. 9. Partial Release

---

h3. 9.1 Scenario

* Some items ready

* Others delayed or blocked

---

h3. 9.2 Correct Handling

* Release Version includes only:

  * Accepted

  * Deployed items

* Delayed items:

  * Do NOT receive Release Version

  * Return to backlog or next sprint

---

h3. 9.3 Outcome

* Honest release notes

* Clear customer communication

* No ambiguity about delivered value

---

h2. 10. Compliance-Driven Exceptions

---

h3. 10.1 Scenario

* Regulatory or legal requirement

* Time-bound obligation (e.g., HIPAA)

---

h3. 10.2 Correct Handling

* Product & Compliance jointly approve urgency

* Issue is created with:

  * Clear compliance reference

  * Explicit audit notes

* Handled via:

  * Emergency Release, or

  * Dedicated Sprint (if time allows)

Compliance urgency does not bypass traceability.

---

h2. 11. Documentation & Audit Trail (Mandatory)

Every exception must leave behind:

* A clearly classified issue

* A Release Version (if deployed)

* Deployment reference URL

* Comments explaining *why* exception occurred

* Links to affected sprint or release (if relevant)

---

h2. 12. Common Anti-Patterns (Strictly Forbidden)

The following are not allowed:

* Adding hotfixes into completed sprints

* Editing historical sprint data

* Reusing release versions

* Hiding emergency work inside sprint tasks

* Treating rollbacks as “non-events”

Violations must be escalated.

---

h2. 13. Relationship to Other Processes

This page complements:

* [[Product Process Guidelines]]

* [[Sprint Execution Rules]]

* [[Sprint Close Process]]

* [[Release Management Process]]

It overrides *none* of them — it protects them.

---

h2. 14. Final Statement

Exceptions are inevitable.

Chaos is optional.

By following this Edge Case & Exception Handling process, Tinggit ensures:

* Fast response to emergencies

* Clean sprint and release data

* Audit-ready history

* Trust across teams and stakeholders

*This page is the single authority for all exception handling.*