Tingg

h1. Product Process Guidelines (Redmine – Tinggit Platform)

*This document is the single source of truth for how product delivery is executed on the Tinggit Platform using Redmine.*

All teams (Product, Engineering, QA, DevOps, Compliance) **must follow these guidelines** to ensure:

* Predictable delivery

* Clean sprint and release history

* Reliable metrics

* Audit-ready traceability

* Zero process ambiguity

{{toc}}

---

h2. 1. Purpose & Scope

This document defines:

* How work moves from idea → backlog → sprint → release

* How Sprint and Release concepts are separated

* Which Redmine features are used for which purpose

* How history and traceability are preserved permanently

* How exceptions (hotfixes, rollbacks) are handled safely

This guideline applies to:

* All Tinggit products and websites

* All teams using Redmine under the *Tinggit Platform* project

* All Scrum / Sprint-based delivery

---

h2. 2. System of Record (Non-Negotiable)

Each system has **one and only one responsibility**.

|_. Area |_. System of Record |

| Product Backlog & Priority | Redmine |

| Sprint Execution | Redmine |

| Product Releases | Redmine |

| Code & Versions | Git |

| Deployment State | CI/CD |

| Runtime Health | Monitoring |

| Compliance Evidence | Wiki / Documents |

*bq.* Never duplicate data across systems.

---

h2. 3. Ownership Model

Clear ownership prevents process conflict.

|_. Area |_. Owner |

| Product Backlog | Product Owner |

| Sprint Backlog | Sprint Team |

| Task Breakdown | Sprint Team |

| Bug Fixing | Sprint Team |

| Bug Priority | Product Owner |

| Sprint Process | Scrum Master |

| Releases | Product Owner |

| Deployments | DevOps |

| Compliance Scope | Product / Compliance |

---

h2. 4. Core Delivery Flow (End-to-End)

The Tinggit delivery flow is strictly linear:

<pre>

Idea

 → Product Backlog

 → Sprint Planning

 → Sprint Execution

 → Sprint Close

 → Release Planning

 → Release Deployment

 → Audit & Metrics

</pre>

Each stage has:

* A clear owner

* A defined artifact

* A validation gate

---

h2. 5. Sprint vs Release – Fundamental Separation

Sprint and Release represent **different concerns** and must never be mixed.

|_. Concept |_. Meaning |

| Sprint | Execution container |

| Release | Business contract |

Rules:

1. Sprint is temporary

2. Release is permanent

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

4. Sprint history is preserved via custom fields

5. Releases define *what customers received*, not how it was built

---

h2. 6. Sprint Model (High Level)

Sprint management uses **Redmine Versions** and **Custom Fields**.

|_. Element |_. Purpose |

| Sprint Version | Temporary execution container |

| Completed In Sprint | Permanent sprint history |

| Spillover Reason | Accountability for unfinished work |

| Sprint Wiki | Human context (goal, learnings) |

Sprint lifecycle:

<pre>

Backlog

 → Version = Sprint YYYY-NN

 → Completed In Sprint = Sprint YYYY-NN

 → Version cleared

 → Sprint closed

</pre>

Detailed steps are defined in:

* [[Sprint Open Process]]

* [[Sprint Close Process]]

* [[Sprint History, Metrics & Audit]]

---

h2. 7. Release Model (High Level)

Releases represent **customer-visible value**.

|_. Element |_. Purpose |

| Release Version | Product release scope |

| Release Notes | Customer communication |

| Deployment Reference | Traceability to CI/CD |

Rules:

* Release versions are permanent

* Only completed & deployed work belongs to a release

* Release versions are never reused

* Rollbacks create new release versions

Detailed steps are defined in:

* [[Release Management Process]]

* [[Edge Case & Exception Handling]]

---

h2. 8. Naming Standards (Mandatory)

All naming must follow strict conventions.

Sprint naming:

<pre>

Sprint YYYY-NN

</pre>

Release naming:

<pre>

Release X.Y – Short Theme

Release X.Y.Z – Hotfix

</pre>

Forbidden examples:

<pre>

Sprint Alpha

Release Final

v2-final-final

</pre>

*bq.* Naming violations break reporting and audits.

---

h2. 9. Issue Classification Principles

Every issue must clearly communicate **intent**.

|_. Attribute |_. Purpose |

| Tracker | Nature of work (Story, Bug, Task) |

| Work Type | Business intent (Feature, Bug Fix, Tech Debt, Compliance) |

| Status | Execution state |

| Custom Fields | History, accountability, analytics |

Tasks and sub-tasks:

* Exist only under a parent story

* Never exist independently

* Are owned by the sprint team

---

h2. 10. Metrics & Auditability

Metrics are derived only from **immutable data**.

Tracked metrics include:

* Velocity

* Throughput

* Spillover rate

* Sprint completion trend

Metrics are calculated using:

* *Completed In Sprint*

* Status history

* Saved queries

Sprint history must be reproducible **months later**.

---

h2. 11. Exception & Emergency Handling

Non-standard scenarios are handled explicitly:

* Production hotfixes

* Rollback releases

* Partial releases

* Emergency fixes

These scenarios **must not corrupt sprint or release data**.

Refer to:

* [[Edge Case & Exception Handling]]

---

h2. 12. Compliance Alignment

For regulated products (e.g., Tingg Insight – HIPAA):

* Compliance scope is defined separately

* Compliance requirements are translated into Epics and Stories

* Sprint and Release processes remain unchanged

* Evidence and traceability are mandatory

Refer to:

* [[Tingg Insight Business Requirements Document]]

* [[Tingg Insight HIPAA Compliance Scope and Applicability]]

---

h2. 13. Governance Rules (Enforcement)

The following are mandatory:

* No sprint close without required fields

* No release without deployment reference

* No history rewriting

* No dual ownership of concepts

* No undocumented exceptions

Violations must be escalated to Product Leadership.

---

h2. 14. Final Statement

These Product Process Guidelines define **how Tinggit delivers software at scale**.

They exist to:

* Protect teams from chaos

* Protect metrics from manipulation

* Protect the company during audits

* Enable confident decision-making

*Deviation from this process is not allowed without explicit approval.*