Actions

History

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

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.

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

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

4. Daily Work Tracking Rules¶

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

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

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

6. Blocker & Impediment Management¶

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.

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.

7. Scope Change Rules (During Sprint)¶

Sprint scope is protected by default.

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.

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

8. Bug Handling During Sprint¶

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

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

9. Quality & Definition of Done Enforcement¶

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.

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

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.

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

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

13. Relationship to Sprint Close¶

Proper Sprint Execution enables clean Sprint Close.

Failures during execution will surface as:

Spillover
Unreliable velocity
Poor retrospectives