Project

General

Profile

Actions
History

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

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:

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:

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:

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:

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 how Tinggit delivers software at scale.

They exist to:
  • Protect teams from chaos
  • Protect metrics from manipulation
  • Protect the company during audits
  • Enable confident decision-making

Deviation from this process is not allowed without explicit approval.

Updated by Redmine Admin about 2 months ago · 4 revisions