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.

• Table of contents
• How We Work at Tingg (Operating Manual)
  • 1. Purpose of This Manual
  • 2. How This Wiki Is Organized
  • 3. Authoritative Process Pages (MANDATORY)
  • 4. Sprint Lifecycle at Tingg (At a Glance)
  • 5. Role-Based Training Guides (HOW to use the system)
  • 6. Releases at Tingg
  • 7. Handling Exceptions
  • 8. Metrics, Audits & Trust in Data
  • 9. Compliance & Business Reference
  • 10. Governance Rules (Important)
  • 11. Final Statement

---

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

---

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.

---

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.

---

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

Every sprint follows this lifecycle:

1. Sprint Open → scope is committed
2. Sprint Execution → work is performed
3. Sprint Close → history is preserved
4. Sprint History & Metrics → outcomes are measured

Each step has a dedicated, mandatory process page.

---

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.

---

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

---

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.

---

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

---

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

---

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.

---

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