Tingg

h1. Sprint Execution Rules (Mandatory)

*Applies to all active sprints on the Tinggit Platform*  

*Defines how work is executed, tracked, and protected during an active sprint*

{{toc}}

---

h2. 1. Purpose

The Sprint Execution Rules define **how teams behave once a sprint has started**.

These rules ensure that:

* Sprint commitment is respected

* Progress toward Sprint Goal is visible daily

* Blockers are surfaced early

* Scope remains controlled

* Quality is built in, not added later

* Sprint metrics remain trustworthy

Without clear execution rules, even a well-opened sprint will fail.

---

h2. 2. Scope

These rules apply to:

* All active sprints

* All issues assigned to a Sprint Version

* All team members participating in the sprint

* All work executed between Sprint Open and Sprint Close

---

h2. 3. Core Execution Principles

During an active sprint:

1. Sprint Goal takes precedence over individual tasks

2. Commitment is protected over opportunistic changes

3. Transparency is required every day

4. Problems are escalated early, not hidden

5. Quality is non-negotiable

---

h2. 4. Daily Work Tracking Rules

---

h3. 4.1 Issue Status Updates

Every issue in the sprint must reflect its **true current state**.

Status changes must be:

* Honest

* Timely

* Based on actual progress, not intent

Allowed behaviors:

* Move issue to *In Progress* when work actually starts

* Move issue to *In Review* when ready for peer/QA review

* Move issue to *Blocked* immediately when stuck

Forbidden behaviors:

* Keeping issues in *In Progress* with no activity

* Marking issues *Done* prematurely

* Skipping *Blocked* status to avoid visibility

---

h3. 4.2 Task and Sub-task Usage

Tasks and sub-tasks:

* Are owned by the Sprint Team

* Represent execution-level breakdown

* May be created, updated, or deleted during the sprint

Rules:

* Tasks must belong to a parent Story

* Tasks do not define sprint success — Stories do

* Completion of all tasks does not equal Story Done unless Acceptance Criteria are met

---

h2. 5. Daily Scrum Expectations

The Daily Scrum exists to **inspect progress toward the Sprint Goal**.

During each Daily Scrum, the team answers:

* What progress was made toward the Sprint Goal?

* What is planned next?

* What blockers or risks exist?

Tracking expectations:

* Blockers must be reflected in Redmine

* Ownership of blockers must be clear

* Actions decided must be visible in issue updates

---

h2. 6. Blocker & Impediment Management

---

h3. 6.1 When to Mark an Issue as Blocked

An issue must be marked *Blocked* if:

* External dependency is unresolved

* Required clarification is missing

* Environment or tooling prevents progress

* A critical defect blocks forward movement

Blocking must be reflected immediately in Redmine.

---

h3. 6.2 Blocker Escalation Rules

Once an issue is marked Blocked:

* Scrum Master is responsible for escalation

* Product Owner is informed if Sprint Goal is at risk

* Resolution path must be documented in issue comments

Blocked items are reviewed daily until resolved.

---

h2. 7. Scope Change Rules (During Sprint)

Sprint scope is **protected by default**.

---

h3. 7.1 Adding Work During Sprint

New work may enter a sprint only if:

* It directly supports the Sprint Goal

* Product Owner explicitly agrees

* An equivalent amount of work is removed (swap, not add)

* Change is visible and documented

Unplanned work must never silently enter a sprint.

---

h3. 7.2 Removing Work During Sprint

Work may be removed if:

* It no longer supports the Sprint Goal

* A dependency makes it impossible

* Product Owner agrees

Removed items must:

* Have Sprint Version cleared

* Be returned to the Product Backlog

---

h2. 8. Bug Handling During Sprint

---

h3. 8.1 Bugs Found in Sprint Scope

If a bug is found in work that belongs to the sprint:

* Bug is part of the sprint

* Bug must be fixed within the sprint

* Story cannot be marked Done while bug exists

---

h3. 8.2 Bugs Outside Sprint Scope

If a bug is unrelated to sprint work:

* Logged as a separate Bug issue

* Prioritized by Product Owner

* Does NOT automatically enter the sprint

---

h2. 9. Quality & Definition of Done Enforcement

---

h3. 9.1 Definition of Done (DoD)

An issue may be marked *Done* only if:

* Acceptance Criteria are fully met

* Code is complete and reviewed

* Required tests are executed

* No open sprint bugs remain

Marking *Done* without meeting DoD is a process violation.

---

h3. 9.2 QA During Sprint

QA activities:

* Validate Acceptance Criteria

* Focus on sprint scope only

* Log defects transparently

QA must not:

* Expand scope mid-sprint

* Introduce new requirements

---

h2. 10. Progress Visibility & Metrics Integrity

During the sprint:

* Redmine is the single source of progress truth

* Issue status reflects reality

* Story Points are never changed mid-sprint

* Sprint metrics must remain stable

Manipulating data to “look good” is not acceptable.

---

h2. 11. Handling Emergencies During Sprint

If an emergency occurs:

* Sprint Goal is re-evaluated

* Product Owner decides priority

* Emergency work follows:

  * Hotfix process

  * Edge case handling rules

Refer to:

* [[Edge Case & Exception Handling]]

---

h2. 12. Common Execution Anti-Patterns

The following are not allowed:

* Treating sprint as a todo list

* Hiding blockers

* Constant reprioritization

* Mid-sprint re-estimation

* Marking Done at the last minute without review

---

h2. 13. Relationship to Sprint Close

Proper Sprint Execution enables clean Sprint Close.

Failures during execution will surface as:

* Spillover

* Unreliable velocity

* Poor retrospectives

Refer to:

* [[Sprint Close Process]]

---

h2. 14. Final Statement

Sprint Execution is where **process discipline becomes delivery success**.

Following these rules ensures:

* Predictable outcomes

* Calm execution

* Honest metrics

* Continuous improvement

* Trust across Product, Engineering, and QA

*These rules are mandatory for all active sprints.*