# Sprint Guidelines

## DSDM (Dynamic Systems Development Method) Core Tenets

- Time and budget fixed; requirements flex
- Continuous stakeholder engagement
- Incremental progress over monolithic releases
- Quality standards never compromised
- Projects address genuine business needs above all else
- Each sprint must produce at least one demonstrable artifact

---

## Sprint Structure

- Duration: exactly 2 weeks (no extensions without ELB approval)
- Start dates: 1st and 15th of every month
- If end date on weekend/holiday: sprint closes next working day
- All teams start and end on same dates (company-wide synchronization)
- Sprint goals visible to all stakeholders in task management system at start

---

## Sprint Ceremonies

### Sprint Planning (start of each sprint)

Three phases:

1. **Triage**: review unverified tickets, verify or reject
2. **Point estimation**: poker-style for all newly verified tickets
3. **Sprint commitment**: select capacity-matched tickets

Rules:

- All participants arrive prepared having reviewed relevant tickets
- Tickets enter sprint only if: Verified + MoSCoW label + point value (unless Epic/Legendary)
- Total points must not exceed projected capacity (no over-commitment)
- Mid-sprint changes: unanimous team + scrum master agreement required
- All sprint tickets added to sprint project in Forgejo

### Daily Standup (every working day)

- Maximum: 15 minutes (strictly enforced)
- Each member shares: done yesterday, doing today, any blockers
- Blockers: logged as ticket update + add Blocked label + State/Paused
- All contributors must attend OR provide async update
- Blockers without existing tickets: create ticket immediately and link

### Sprint Review / Retrospective (end of sprint)

- Must occur before next sprint's planning
- Live demonstration of key deliverables (working code, not speculation)
- Demos led by contributor most responsible for feature
- Must Have items and critical path items must be demonstrated
- Feedback from stakeholders → capture as new tickets → triage next sprint
- Document lessons learned, blockers, improvements

### Owner Review (every other sprint)

- Held after all sprint work done + committed + passed peer review
- Provides project owner with updated prototype or feature demo
- Gathers direct feedback
- Adjusts future sprint priorities based on feedback
- Cannot exceed one day's worth of work
- Occurs in buffer period between sprint end (28th) and next sprint start (1st)

---

## Triaging Process (6 stages, performed at sprint planning)

### Stage 1: Unverified Ticket Review

- For each State/Unverified: decide Verified / Wont Do / Duplicate
- All decisions logged in task management system
- Unverified items either refined to actionable tasks or rejected

### Stage 2: Epic and Legendary Preparation

- Project owner creates/updates Epics and Legendaries
- Tech lead and scrum master review for completeness
- Epics/Legendaries: NEVER given a point value
- Verification: tech lead + scrum master review; owner has final authority

### Stage 3: Assign Epics/Legendaries to Sprint

- Only verified Epics/Legendaries eligible
- Scrum master proposes; team collectively agrees
- Priority/deadline drives ordering
- Carried-over items re-reviewed for validity

### Stage 4: Break Into Actionable Tickets

- Tech lead decomposes verified Epics into issues
- All new child tickets: State/Unverified, Priority/Backlog
- Each lists parent Epic as dependency
- Remain unassigned initially
- Must be completable within ONE sprint (absolute maximum)
- Minimum task size: 15 minutes

### Stage 5: Point Estimation (poker-style)

- Ticket must be State/Verified
- Ticket text must be self-sufficient (no oral clarification)
- Silent individual reflection → simultaneous reveal → discussion if needed
- Repeat until consensus
- Values represent proficient expert's effort (no learning curve factor)
- Never hint at value before first reveal (resets entire round)
- Scrum master records agreed value

### Stage 6: Owner Approval and Sprint Population

- Project owner reviews all child tickets for Epic
- On approval: Epic → State/In progress
- Team collectively determines capacity (not any single person)
- Sprint added: Priority/Backlog → Priority/Critical|High|Medium|Low
- New sprint tickets: remain unassigned until work begins
- At capacity: no additions without removing something

---

## MoSCoW Prioritization Rules

- Project owner sets ALL MoSCoW labels (NOBODY ELSE)
- Each ticket: exactly one MoSCoW label before entering sprint
- No "Won't Have" label — use State/Wont Do
- Must Have tickets: review with project owner by day 2 of sprint
- Should Have/Could Have enter sprint only if no Must Have behind schedule
- Mid-sprint reclassification: needs project owner approval + documentation
- MoSCoW labels not static: re-evaluate every sprint planning
- Epics and Legendaries: NOT assigned overall MoSCoW (individual child tickets get the labels)
