Tingg

h1. How We Work at Tingg (Operating Manual)

*This page is the single entry point to understand how Tingg plans, builds, ships, and audits software using Redmine.*

{{toc}}

---

h2. 1. Purpose of This Manual

Tingg operates a multi-product, multi-team SaaS platform.  

To ensure:

* Predictable delivery

* Clean sprint and release history

* Reliable metrics

* Audit and compliance readiness

we follow a **defined operating model** documented in this wiki.

This page helps you:

* Understand how the system is structured

* Find the correct document quickly

* Avoid process confusion or duplication

---

h2. 2. How This Wiki Is Organized

This wiki is structured into **three layers**:

1. *Authoritative Process* (rules)

2. *Role-Based Training* (how to follow the rules)

3. *Reference & Compliance* (business and regulatory context)

*bq.* If two pages ever appear to conflict, the *Authoritative Process* pages always win.

---

h2. 3. Authoritative Process Pages (MANDATORY)

These pages define *how work must be done*.  

They are **rules**, not suggestions.

* [[Product Process Guidelines]]

* [[Sprint Open Process]]

* [[Sprint Execution Rules]]

* [[Sprint Close Process]]

* [[Sprint History, Metrics & Audit]]

* [[Release Management Process]]

* [[Edge Case & Exception Handling]]

No alternative processes are allowed outside these pages.

---

h2. 4. Sprint Lifecycle at Tingg (At a Glance)

Every sprint follows this lifecycle:

# Sprint Open → scope is committed

# Sprint Execution → work is performed

# Sprint Close → history is preserved

# Sprint History & Metrics → outcomes are measured

Each step has a dedicated, mandatory process page.

---

h2. 5. Role-Based Training Guides (HOW to use the system)

These guides explain **what you do day-to-day in Redmine**, based on your role.

They do *not* redefine rules.

* [[Product Owner Training Guide]]

* [[Sprint Team Training Guide]]

* [[QA & Compliance Training Guide]]

All team members are expected to read the guide relevant to their role.

---

h2. 6. Releases at Tingg

At Tingg:

* A *Sprint* is an execution container

* A *Release* is a business contract

* Deployments are handled by CI/CD, not Jira/Redmine

Release rules are defined here:

* [[Release Management Process]]

---

h2. 7. Handling Exceptions

Urgent situations (hotfixes, rollbacks, emergencies) are inevitable.

They must always follow controlled paths defined here:

* [[Edge Case & Exception Handling]]

Improvisation is not allowed in exception scenarios.

---

h2. 8. Metrics, Audits & Trust in Data

Velocity, throughput, and spillover are only meaningful if history is preserved.

Sprint metrics and audits are governed by:

* [[Sprint History, Metrics & Audit]]

These metrics are used for:

* Planning

* Forecasting

* Retrospectives

* Audits

---

h2. 9. Compliance & Business Reference

The following documents define *business and regulatory context*.  

They are **reference documents**, not delivery processes.

* [[Tingg Insight Business Requirements Document]]

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

---

h2. 10. Governance Rules (Important)

To keep this system clean and reliable:

* No new process pages may be created without review

* Canonical process pages must not be duplicated

* Role-based guides must only explain *usage*, not redefine rules

* Sprint and release history must never be rewritten

Violations must be escalated.

---

h2. 11. Final Statement

*bq.* This operating manual exists to protect trust —  

trust in delivery, trust in metrics, and trust in history.

If you are unsure what to do:

1. Start here

2. Follow the links

3. Do not invent new processes