Product Process Guidelines » History » Revision 2
Revision 1 (Redmine Admin, 12/24/2025 04:23 PM) → Revision 2/4 (Redmine Admin, 12/24/2025 05:30 PM)
h1. Product Process Guidelines (Redmine) *This document is This space defines the single source of truth mandatory operating processes for how product delivery is executed on the Tinggit Platform using Redmine.* Redmine. All teams (Product, Engineering, QA, DevOps, Compliance) **must must follow these guidelines** guidelines to ensure: * Predictable delivery Reliable metrics * Clean sprint and release history * Reliable metrics * Audit-ready traceability data * Zero process ambiguity Predictable delivery {{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 Core Process | Scrum Master | | Releases | Product Owner | | Deployments | DevOps | | Compliance Scope | Product / Compliance | Pages --- 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 Close Process]] * [[Edge Case Handling – Hotfixes & Exception Handling]] --- h2. 8. Naming Standards (Mandatory) All naming must follow strict conventions. Sprint naming: Rollbacks]] <pre> * [[Naming Standards]] Sprint YYYY-NN </pre> Release naming: <pre> Release X.Y * [[Decision Rules – Short Theme Release X.Y.Z – Hotfix </pre> Forbidden examples: <pre> Sprint Alpha Release Final v2-final-final </pre> vs Release]] *bq.* Naming violations break reporting and audits. --- h2. 9. Issue Classification Governing 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: is an execution container * *Completed In Sprint* Release is a business contract * Status history * Saved queries Sprint history History must never be reproducible **months later**. --- h2. 11. Exception & Emergency Handling Non-standard scenarios are handled explicitly: * Production hotfixes rewritten * 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 Metrics must 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 **h** reproducible months later