Product Process Guidelines » History » Version 4
Redmine Admin, 12/24/2025 05:32 PM
| 1 | 4 | Redmine Admin | h1. Product Process Guidelines |
|---|---|---|---|
| 2 | 1 | Redmine Admin | |
| 3 | 2 | Redmine Admin | *This document is the single source of truth for how product delivery is executed on the Tinggit Platform using Redmine.* |
| 4 | 1 | Redmine Admin | |
| 5 | 2 | Redmine Admin | All teams (Product, Engineering, QA, DevOps, Compliance) **must follow these guidelines** to ensure: |
| 6 | |||
| 7 | 1 | Redmine Admin | * Predictable delivery |
| 8 | 2 | Redmine Admin | * Clean sprint and release history |
| 9 | * Reliable metrics |
||
| 10 | * Audit-ready traceability |
||
| 11 | * Zero process ambiguity |
||
| 12 | 1 | Redmine Admin | |
| 13 | {{toc}} |
||
| 14 | |||
| 15 | 2 | Redmine Admin | --- |
| 16 | 1 | Redmine Admin | |
| 17 | 2 | Redmine Admin | h2. 1. Purpose & Scope |
| 18 | |||
| 19 | This document defines: |
||
| 20 | |||
| 21 | * How work moves from idea → backlog → sprint → release |
||
| 22 | * How Sprint and Release concepts are separated |
||
| 23 | * Which Redmine features are used for which purpose |
||
| 24 | * How history and traceability are preserved permanently |
||
| 25 | * How exceptions (hotfixes, rollbacks) are handled safely |
||
| 26 | |||
| 27 | This guideline applies to: |
||
| 28 | |||
| 29 | * All Tinggit products and websites |
||
| 30 | * All teams using Redmine under the *Tinggit Platform* project |
||
| 31 | * All Scrum / Sprint-based delivery |
||
| 32 | |||
| 33 | --- |
||
| 34 | |||
| 35 | h2. 2. System of Record (Non-Negotiable) |
||
| 36 | |||
| 37 | Each system has **one and only one responsibility**. |
||
| 38 | |||
| 39 | |_. Area |_. System of Record | |
||
| 40 | | Product Backlog & Priority | Redmine | |
||
| 41 | | Sprint Execution | Redmine | |
||
| 42 | | Product Releases | Redmine | |
||
| 43 | | Code & Versions | Git | |
||
| 44 | | Deployment State | CI/CD | |
||
| 45 | | Runtime Health | Monitoring | |
||
| 46 | | Compliance Evidence | Wiki / Documents | |
||
| 47 | |||
| 48 | *bq.* Never duplicate data across systems. |
||
| 49 | |||
| 50 | --- |
||
| 51 | |||
| 52 | h2. 3. Ownership Model |
||
| 53 | |||
| 54 | Clear ownership prevents process conflict. |
||
| 55 | |||
| 56 | |_. Area |_. Owner | |
||
| 57 | | Product Backlog | Product Owner | |
||
| 58 | | Sprint Backlog | Sprint Team | |
||
| 59 | | Task Breakdown | Sprint Team | |
||
| 60 | | Bug Fixing | Sprint Team | |
||
| 61 | | Bug Priority | Product Owner | |
||
| 62 | | Sprint Process | Scrum Master | |
||
| 63 | | Releases | Product Owner | |
||
| 64 | | Deployments | DevOps | |
||
| 65 | | Compliance Scope | Product / Compliance | |
||
| 66 | |||
| 67 | --- |
||
| 68 | |||
| 69 | h2. 4. Core Delivery Flow (End-to-End) |
||
| 70 | |||
| 71 | The Tinggit delivery flow is strictly linear: |
||
| 72 | |||
| 73 | <pre> |
||
| 74 | Idea |
||
| 75 | → Product Backlog |
||
| 76 | → Sprint Planning |
||
| 77 | → Sprint Execution |
||
| 78 | → Sprint Close |
||
| 79 | → Release Planning |
||
| 80 | → Release Deployment |
||
| 81 | → Audit & Metrics |
||
| 82 | </pre> |
||
| 83 | |||
| 84 | Each stage has: |
||
| 85 | * A clear owner |
||
| 86 | * A defined artifact |
||
| 87 | * A validation gate |
||
| 88 | |||
| 89 | --- |
||
| 90 | |||
| 91 | h2. 5. Sprint vs Release – Fundamental Separation |
||
| 92 | |||
| 93 | Sprint and Release represent **different concerns** and must never be mixed. |
||
| 94 | |||
| 95 | |_. Concept |_. Meaning | |
||
| 96 | | Sprint | Execution container | |
||
| 97 | | Release | Business contract | |
||
| 98 | |||
| 99 | Rules: |
||
| 100 | |||
| 101 | 1. Sprint is temporary |
||
| 102 | 2. Release is permanent |
||
| 103 | 3. Sprint and Release must never coexist on the same issue |
||
| 104 | 4. Sprint history is preserved via custom fields |
||
| 105 | 5. Releases define *what customers received*, not how it was built |
||
| 106 | |||
| 107 | --- |
||
| 108 | |||
| 109 | h2. 6. Sprint Model (High Level) |
||
| 110 | |||
| 111 | Sprint management uses **Redmine Versions** and **Custom Fields**. |
||
| 112 | |||
| 113 | |_. Element |_. Purpose | |
||
| 114 | | Sprint Version | Temporary execution container | |
||
| 115 | | Completed In Sprint | Permanent sprint history | |
||
| 116 | | Spillover Reason | Accountability for unfinished work | |
||
| 117 | | Sprint Wiki | Human context (goal, learnings) | |
||
| 118 | |||
| 119 | Sprint lifecycle: |
||
| 120 | |||
| 121 | <pre> |
||
| 122 | Backlog |
||
| 123 | → Version = Sprint YYYY-NN |
||
| 124 | → Completed In Sprint = Sprint YYYY-NN |
||
| 125 | → Version cleared |
||
| 126 | → Sprint closed |
||
| 127 | </pre> |
||
| 128 | |||
| 129 | Detailed steps are defined in: |
||
| 130 | 1 | Redmine Admin | * [[Sprint Open Process]] |
| 131 | * [[Sprint Close Process]] |
||
| 132 | 2 | Redmine Admin | * [[Sprint History, Metrics & Audit]] |
| 133 | 1 | Redmine Admin | |
| 134 | 2 | Redmine Admin | --- |
| 135 | 1 | Redmine Admin | |
| 136 | 2 | Redmine Admin | h2. 7. Release Model (High Level) |
| 137 | |||
| 138 | Releases represent **customer-visible value**. |
||
| 139 | |||
| 140 | |_. Element |_. Purpose | |
||
| 141 | | Release Version | Product release scope | |
||
| 142 | | Release Notes | Customer communication | |
||
| 143 | | Deployment Reference | Traceability to CI/CD | |
||
| 144 | |||
| 145 | Rules: |
||
| 146 | |||
| 147 | * Release versions are permanent |
||
| 148 | * Only completed & deployed work belongs to a release |
||
| 149 | * Release versions are never reused |
||
| 150 | * Rollbacks create new release versions |
||
| 151 | |||
| 152 | Detailed steps are defined in: |
||
| 153 | * [[Release Management Process]] |
||
| 154 | * [[Edge Case & Exception Handling]] |
||
| 155 | |||
| 156 | --- |
||
| 157 | |||
| 158 | h2. 8. Naming Standards (Mandatory) |
||
| 159 | |||
| 160 | All naming must follow strict conventions. |
||
| 161 | |||
| 162 | Sprint naming: |
||
| 163 | <pre> |
||
| 164 | Sprint YYYY-NN |
||
| 165 | </pre> |
||
| 166 | |||
| 167 | Release naming: |
||
| 168 | <pre> |
||
| 169 | Release X.Y – Short Theme |
||
| 170 | Release X.Y.Z – Hotfix |
||
| 171 | </pre> |
||
| 172 | |||
| 173 | Forbidden examples: |
||
| 174 | <pre> |
||
| 175 | Sprint Alpha |
||
| 176 | Release Final |
||
| 177 | v2-final-final |
||
| 178 | </pre> |
||
| 179 | |||
| 180 | *bq.* Naming violations break reporting and audits. |
||
| 181 | |||
| 182 | --- |
||
| 183 | |||
| 184 | h2. 9. Issue Classification Principles |
||
| 185 | |||
| 186 | Every issue must clearly communicate **intent**. |
||
| 187 | |||
| 188 | |_. Attribute |_. Purpose | |
||
| 189 | | Tracker | Nature of work (Story, Bug, Task) | |
||
| 190 | | Work Type | Business intent (Feature, Bug Fix, Tech Debt, Compliance) | |
||
| 191 | | Status | Execution state | |
||
| 192 | | Custom Fields | History, accountability, analytics | |
||
| 193 | |||
| 194 | Tasks and sub-tasks: |
||
| 195 | * Exist only under a parent story |
||
| 196 | * Never exist independently |
||
| 197 | * Are owned by the sprint team |
||
| 198 | |||
| 199 | --- |
||
| 200 | |||
| 201 | h2. 10. Metrics & Auditability |
||
| 202 | |||
| 203 | Metrics are derived only from **immutable data**. |
||
| 204 | |||
| 205 | Tracked metrics include: |
||
| 206 | * Velocity |
||
| 207 | * Throughput |
||
| 208 | * Spillover rate |
||
| 209 | * Sprint completion trend |
||
| 210 | |||
| 211 | Metrics are calculated using: |
||
| 212 | * *Completed In Sprint* |
||
| 213 | * Status history |
||
| 214 | * Saved queries |
||
| 215 | |||
| 216 | Sprint history must be reproducible **months later**. |
||
| 217 | |||
| 218 | --- |
||
| 219 | |||
| 220 | h2. 11. Exception & Emergency Handling |
||
| 221 | |||
| 222 | Non-standard scenarios are handled explicitly: |
||
| 223 | |||
| 224 | * Production hotfixes |
||
| 225 | * Rollback releases |
||
| 226 | * Partial releases |
||
| 227 | * Emergency fixes |
||
| 228 | |||
| 229 | These scenarios **must not corrupt sprint or release data**. |
||
| 230 | |||
| 231 | Refer to: |
||
| 232 | * [[Edge Case & Exception Handling]] |
||
| 233 | |||
| 234 | --- |
||
| 235 | |||
| 236 | h2. 12. Compliance Alignment |
||
| 237 | |||
| 238 | For regulated products (e.g., Tingg Insight – HIPAA): |
||
| 239 | |||
| 240 | * Compliance scope is defined separately |
||
| 241 | * Compliance requirements are translated into Epics and Stories |
||
| 242 | * Sprint and Release processes remain unchanged |
||
| 243 | * Evidence and traceability are mandatory |
||
| 244 | |||
| 245 | Refer to: |
||
| 246 | * [[Tingg Insight Business Requirements Document]] |
||
| 247 | * [[Tingg Insight HIPAA Compliance Scope and Applicability]] |
||
| 248 | |||
| 249 | --- |
||
| 250 | |||
| 251 | h2. 13. Governance Rules (Enforcement) |
||
| 252 | |||
| 253 | The following are mandatory: |
||
| 254 | |||
| 255 | * No sprint close without required fields |
||
| 256 | * No release without deployment reference |
||
| 257 | * No history rewriting |
||
| 258 | * No dual ownership of concepts |
||
| 259 | * No undocumented exceptions |
||
| 260 | |||
| 261 | Violations must be escalated to Product Leadership. |
||
| 262 | |||
| 263 | --- |
||
| 264 | |||
| 265 | h2. 14. Final Statement |
||
| 266 | 1 | Redmine Admin | |
| 267 | 3 | Redmine Admin | These Product Process Guidelines define **how Tinggit delivers software at scale**. |
| 268 | |||
| 269 | They exist to: |
||
| 270 | * Protect teams from chaos |
||
| 271 | * Protect metrics from manipulation |
||
| 272 | * Protect the company during audits |
||
| 273 | * Enable confident decision-making |
||
| 274 | |||
| 275 | *Deviation from this process is not allowed without explicit approval.* |