Phase 2: Development Sprints
Phase 2: The Implementation Iterations (Weeks 6-17) 🚀
This phase transforms planning artifacts into working, evolving software. Consistency beats intensity—aim for sustainable, repeatable delivery.
The Iteration Lifecycle (10 Steps)
| Step | Purpose | Output / Evidence | Common Pitfall |
|---|---|---|---|
| 1. Planning | Align on 3–5 outcome goals | Goals doc/issue | Overcommitting / vague goals |
| 2. Spike (optional) | Retire uncertainty before building | Spike issue closed with notes | Endless exploration |
| 3. Development | Implement vertical slices | Branch commits referencing issue | Long-lived branches |
| 4. Commit Hygiene | Maintain understandable history | Small, atomic commits | "WIP" jumbo commits |
| 5. Pull Request | Request structured review | PR with description + linked issue | Drafting too late |
| 6. Review | Improve design & correctness | Comments resolved, approval | Nitpicking style over substance |
| 7. Test & QA | Enforce DoD & acceptance criteria | Passing CI, added tests | Testing only at end |
| 8. Merge | Integrate increment safely | Main branch updated | Merge without review |
| 9. Demo | Validate value + foster shared understanding | Live walkthrough / short video | Demoing untested code |
| 10. Status Report | Reflect, surface risks, adjust plan | Report published | Vanity metrics only |
Iteration Planning Cadence
Time-box: 30–45 minutes. Agenda: 1. Review previous goals (met? spillovers? why?) 2. Revisit roadmap—still valid? any scope adjustment needed? 3. Select goals (outcomes, not tasks) 4. Break into issues (ensure DoR standards) 5. Assign initial ownership (ownership can change with pairing)
Goal Crafting Examples
Weak: “Work on authentication” → Strong: “Users can register & log in (JWT issued, persisted sessions).” Weak: “Add tests” → Strong: “Cover user model validation paths (≥ 5 core cases).”
Roles in Action (Per Iteration)
| Role | Iteration Focus |
|---|---|
| Iteration Lead | Goal clarity, flow of issues, report assembly |
| Backend Lead | API stability, data integrity, performance hotspots |
| Frontend/UX Lead | Accessibility, user flow coherence, design consistency |
| QA / Testing Lead | Test coverage growth, flaky test triage, DoD enforcement |
| DevOps / Release Lead | CI speed/reliability, tagging, environment parity |
Spikes: Definition & Exit
Acceptable outputs for a spike: - Decision summary (short markdown) - Prototype branch (closed without merge) + notes Define a time limit (e.g., 2–4 hours). Convert learning into actionable issue(s) or ADR. Avoid “spike loops.”
Demo Discipline
Golden rule: Demo behavior not code. Use a user narrative. If a feature is partially done, either (a) show the slice that meets DoD or (b) explain why it was deferred (avoid hand-wavy tours).
Status Report Data Sources
| Section | Data Input |
|---|---|
| Goals vs Achieved | Goals doc + closed issues |
| Work Summary | GitHub PR merge list |
| Risks | Retro discussion + blockers column |
| Adjustments | New roadmap deltas |
Spillover Handling
Ask: Why did it spill? Estimation gap, hidden dependency, priority change, quality gate failure? Capture root cause once—patterns drive improvements.
Tracking Technical Debt
Create a “tech debt” label + lightweight issues. Debt is a managed queue, not a shame pile. Re-evaluate each planning meeting.
Healthy Iteration Indicators
| Indicator | Healthy Range | Intervention Trigger |
|---|---|---|
| PR Review Time | < 24h first review | > 48h backlog |
| Spillover Rate | ≤ 25% goals | > 40% 2 iterations straight |
| CI Failure Recovery | < 1h | Failing main for multiple hours |
| Issue Size | 0.5–2 days typical | Many 4–5 day “epics” |
When to Re-Roadmap
Mid-course (after Iteration 3) evaluate: user value delivered vs plan. If ≥ 2 major goals persistently deferred, renegotiate final iteration focus to protect quality & polish.
Final Iteration Focus (Iteration 5)
Allocate explicit capacity for: - Hardening (tests, error handling) - Docs & ADR synchronization - Performance / accessibility pass - Release candidate validation
Avoid starting net-new large feature threads unless truly critical.
Retrospective Prompt Set (Extended)
- What nearly went wrong but didn’t (latent risk)?
- Which decision this iteration should become an ADR?
- What recurring friction point should we automate?
- What surprised us technically?
- What experiment (process tweak) will we try next iteration?
Close with 1–2 actionable improvements; assign owners.
How the Contribution Flow Works
┌─────────────────────────────────────────────────────────┐
│ 1. Contributor identifies a bug or has a feature idea │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2. Creates an issue using appropriate template │
│ - Describes the problem/feature │
│ - Checks "I am a developer..." if willing to work │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. Team reviews issue (within 48 hours) │
│ - Assesses alignment with design principles │
│ - Labels appropriately │
│ - Asks for clarification if needed │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 4. If approved: Contributor proposes solution approach │
│ - Discusses implementation strategy │
│ - Team provides feedback │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 5. Issue is assigned to contributor │
│ - Creates feature branch from main │
│ - Update Project Board (Issue Status) │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 6. Contributor develops solution │
│ - Reads DESIGN_PRINCIPLES.md │
│ - Reads docs/development/architecture.md │
│ - Writes code, tests, documentation │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 7. Creates Pull Request │
│ - Uses PR template │
│ - References issue number │
│ - Fills out all checklist items │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 8. Team reviews PR │
│ - Checks code quality │
│ - Verifies tests pass │
│ - Ensures alignment with architecture │
│ - Provides feedback or approves │
└────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 9. If approved: PR is merged! 🎉 │
│ - Contributor is thanked │
│ - Issue is closed │
│ - Changes included in next release │
└─────────────────────────────────────────────────────────┘