Product Process Guidelines¶

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

• Table of contents
• Product Process Guidelines
  • 1. Purpose & Scope
  • 2. System of Record (Non-Negotiable)
  • 3. Ownership Model
  • 4. Core Delivery Flow (End-to-End)
  • 5. Sprint vs Release – Fundamental Separation
  • 6. Sprint Model (High Level)
  • 7. Release Model (High Level)
  • 8. Naming Standards (Mandatory)
  • 9. Issue Classification Principles
  • 10. Metrics & Auditability
  • 11. Exception & Emergency Handling
  • 12. Compliance Alignment
  • 13. Governance Rules (Enforcement)
  • 14. Final Statement

---

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

---

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.

---

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

---

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

The Tinggit delivery flow is strictly linear:

Idea
 → Product Backlog
 → Sprint Planning
 → Sprint Execution
 → Sprint Close
 → Release Planning
 → Release Deployment
 → Audit & Metrics

Each stage has:

• A clear owner
• A defined artifact
• A validation gate

---

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

---

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:

Backlog
 → Version = Sprint YYYY-NN
 → Completed In Sprint = Sprint YYYY-NN
 → Version cleared
 → Sprint closed

Detailed steps are defined in:

• Sprint Open Process
• Sprint Close Process
• Sprint History, Metrics & Audit

---

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

---

8. Naming Standards (Mandatory)¶

All naming must follow strict conventions.

Sprint naming:

Sprint YYYY-NN

Release naming:

Release X.Y – Short Theme
Release X.Y.Z – Hotfix

Forbidden examples:

Sprint Alpha
Release Final
v2-final-final

bq. Naming violations break reporting and audits.

---

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

---

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.

---

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

---

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

---

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.

---

14. Final Statement¶

These Product Process Guidelines define h