Sprint Open Process (Mandatory)¶

Applies to all Scrum teams using Redmine
This process defines how a sprint is prepared, committed, and officially started

• Table of contents
• Sprint Open Process (Mandatory)
  • 1. Purpose
  • 2. Scope
  • 3. Ownership & Roles
  • 4. Preconditions (Entry Criteria)
    • 4.1 Sprint Version Created
    • 4.2 Sprint Wiki Page Created
    • 4.3 Backlog Readiness (Definition of Ready)
  • 5. Sprint Planning & Commitment
    • 5.1 Capacity Planning
    • 5.2 Sprint Goal Definition (Critical)
    • 5.3 Selecting Sprint Backlog Items
  • 6. Validation Gates (Before Sprint Start)
    • 6.1 Sprint Commitment Check
    • 6.2 Capacity Sanity Check
    • 6.3 Readiness Check
  • 7. Sprint Lock (Start of Sprint)
  • 8. Rules During the Sprint (High-Level)
  • 9. Artifacts Produced at Sprint Open
  • 10. Common Mistakes to Avoid
  • 11. Final Statement

---

1. Purpose¶

The Sprint Open Process ensures that:

• The sprint has a clear, shared goal
• Only ready and valuable work enters the sprint
• Team capacity is respected
• Sprint commitment is explicit and auditable
• Sprint metrics remain reliable

This process prevents:

• Over-commitment
• Mid-sprint chaos
• Unclear priorities
• Broken velocity trends

---

2. Scope¶

This process applies to:

• All Scrum / Sprint-based teams
• All sprints created under the Tinggit Platform project
• All backlog items selected for sprint execution

---

3. Ownership & Roles¶

*. Role	*. Responsibility
Product Owner	Defines priority and sprint goal
Scrum Master	Facilitates sprint planning and process compliance
Sprint Team	Estimates, commits, and executes work
QA	Reviews test readiness and risk

---

4. Preconditions (Entry Criteria)¶

A sprint must NOT start unless all conditions below are met.

---

4.1 Sprint Version Created¶

• A new Sprint Version exists in Redmine
• Naming follows standard:
  

  Sprint YYYY-NN
  

• Start and end dates are defined
• Version status = Open

---

4.2 Sprint Wiki Page Created¶

A Wiki page must exist:

Sprint YYYY-NN

At minimum, it contains:

• Sprint Goal (single sentence)
• Sprint duration
• Team participants
• Known risks or constraints

---

4.3 Backlog Readiness (Definition of Ready)¶

Only items meeting Definition of Ready (DoR) may enter the sprint.

Each proposed Story must have:

• Clear description
• Acceptance Criteria defined
• Story Points estimated
• Work Type selected
• No unresolved dependencies
• No open design ambiguity

Items missing any of the above are not allowed into the sprint.

---

5. Sprint Planning & Commitment¶

---

5.1 Capacity Planning¶

Before selecting work:

• Team availability is reviewed (leaves, holidays)
• Historical velocity is considered
• Capacity calculation is done outside Redmine (planning discussion)

bq. Capacity limits commitment, not desire.

---

5.2 Sprint Goal Definition (Critical)¶

The Product Owner defines one clear Sprint Goal.

Rules:

• One sentence
• Business or platform outcome-oriented
• Explains why the sprint exists

Examples:

• “Enable secure tenant onboarding for healthcare customers”
• “Stabilize survey reporting performance under high load”

The Sprint Goal is recorded in:

• Sprint Wiki page
• Sprint Planning notes

---

5.3 Selecting Sprint Backlog Items¶

During Sprint Planning:

• Stories are selected in priority order
• Team discusses scope and approach
• Tasks may be identified (optional at this stage)

Once agreed:

• Selected issues are assigned:
  

  Fixed version = Sprint YYYY-NN
  

This action represents official sprint commitment.

---

6. Validation Gates (Before Sprint Start)¶

The sprint cannot start unless all checks pass.

---

6.1 Sprint Commitment Check¶

Using saved query:

Sprint Open – Sprint Backlog (Sprint YYYY-NN)

Confirm:

• All committed items are visible
• No unrelated items are included

---

6.2 Capacity Sanity Check¶

Using saved query:

Sprint Open – Capacity Check (Sprint YYYY-NN)

Confirm:

• Total Story Points ≤ team’s sustainable capacity

If exceeded:

• Remove lower-priority items
• Adjust scope before sprint starts

---

6.3 Readiness Check¶

Confirm:

• No Story in sprint is missing Acceptance Criteria
• No Story is missing Story Points
• No unresolved dependencies exist

---

7. Sprint Lock (Start of Sprint)¶

Once all validations pass:

• Sprint Version assignment is locked
• Sprint officially starts
• No scope changes are allowed without explicit agreement

bq. After sprint start, priority changes are discouraged and tightly controlled.

---

8. Rules During the Sprint (High-Level)¶

Once the sprint is open:

• New work does not enter the sprint by default
• Bugs found in sprint scope belong to the sprint
• External interruptions are escalated to PO and Scrum Master
• Sprint Goal guides daily decisions

Detailed execution rules are defined in:

• Sprint Execution Rules

---

9. Artifacts Produced at Sprint Open¶

By the end of Sprint Open:

• Sprint Version exists and is populated
• Sprint Wiki page is complete
• Sprint Goal is visible
• Sprint Backlog is committed
• Capacity assumptions are understood

These artifacts enable:

• Daily Scrum
• Sprint tracking
• Clean Sprint Close

---

10. Common Mistakes to Avoid¶

• Starting sprint without a Sprint Goal
• Overloading sprint beyond capacity
• Pulling in “almost ready” work
• Treating sprint as a wish list
• Changing scope without transparency

---

11. Final Statement¶

A sprint that is poorly opened cannot be closed cleanly.

Following this Sprint Open Process ensures:

• Clear commitment
• Predictable delivery
• Stable metrics
• Calm sprint execution
• Reliable retrospectives

This process is mandatory for all teams.