Sprint Team Training Guide (Tinggit Platform)¶

Audience: Developers, Engineers, Designers
Purpose: Explain how to execute sprint work correctly in Redmine

• Table of contents
• Sprint Team Training Guide (Tinggit Platform)
  • 1. Your Role in the Sprint
  • 2. Picking Work Into a Sprint
  • 3. Daily Execution Rules
  • 4. Handling Changes During Sprint
  • 5. Quality Expectations
  • 6. Sprint Close Responsibilities
  • 7. Understanding Sprint Metrics
  • 8. Common Sprint Team Mistakes
  • 9. Final Reminder

---

1. Your Role in the Sprint¶

Sprint Team owns:

• HOW work is done
• Task breakdown
• Daily execution
• Technical quality

You do NOT own:

• Sprint goal definition
• Product priority
• Release decisions

---

2. Picking Work Into a Sprint¶

When work is selected into a sprint:

• Break stories into tasks
• Estimate effort honestly
• Confirm understanding of Acceptance Criteria

Sprint Version represents:

• Active execution only
• Temporary container

Authoritative reference: Sprint Open Process

---

3. Daily Execution Rules¶

Every day you must:

• Update issue status
• Log progress transparently
• Raise blockers immediately

Blocked work must:

• Be marked Blocked
• Include a clear reason

---

4. Handling Changes During Sprint¶

If new work appears:

• Do NOT silently add it
• Escalate to Product Owner
• Respect Sprint Goal

Emergency work follows exception rules.

Authoritative reference: Edge Case & Exception Handling

---

5. Quality Expectations¶

A story is NOT done unless:

• Code is complete
• Dev tests are executed
• QA checks pass
• Acceptance Criteria are met

Partial completion does not count.

---

6. Sprint Close Responsibilities¶

Before sprint close, you must ensure:

• Completed stories are truly DONE
• Spillover work has clear reasons
• No hidden work remains

Never:

• Edit sprint history after closure
• Clear sprint fields casually

Authoritative reference: Sprint Close Process

---

7. Understanding Sprint Metrics¶

Sprint metrics are derived from:

• Completed In Sprint
• Story Points
• Status history

These metrics affect:

• Velocity
• Forecasting
• Trust in planning

Authoritative reference: Sprint History, Metrics & Audit

---

8. Common Sprint Team Mistakes¶

• Leaving issues outdated
• Marking Done without QA
• Hiding spillover
• Treating sprint as personal workload

---

9. Final Reminder¶

bq. Transparency beats heroics.

Your goal is not to look busy — it is to deliver reliably.