-
Notifications
You must be signed in to change notification settings - Fork 0
Retrospective Phase 1
Date: 2026-06-07 (updated 2026-06-11) Phase: Phase 1 — Foundation Gaps (Core CRM Completion) Sprint: Sprint 1 Complete ✅
See also: Risk Register, Project Board
Phase 1 was planned as the first deliverable of Oscar, targeting core CRM feature completion. Of 10 planned issues, 7 were closed pre-PM and 3 were completed in Sprint 1.
| # | Issue | WSJF | Sprint 1 Outcome |
|---|---|---|---|
| #10 | Wire Redis for Caching | 1 (3.33) | PR #61 merged ✅ |
| #8 | API Key Management Backend | 2 (3.0) | PR #60 merged ✅ |
| #11 | File Attachments for Records | 3 (2.2) | PR #62 merged ✅ |
Result: Phase 1 is fully complete. All 10 issues closed on or before June 11 — well ahead of the Aug 2026 deadline.
- Good: The README roadmap provided a clear phased scope with linked issues
- Gap: No sprint-level decomposition existed — issues were in a phase milestone without prioritization or timeboxing
- Corrective Action: WSJF scores now provide sprint-level priority; Sprint 1 (2-week) milestone replaces flat phase bucket
- Good: 7 issues closed without a formal PM system — the developer worked autonomously
- Gap: No visibility into WIP limits, cycle time, or bottlenecks
- Corrective Action: Project V2 board with Status field enables WIP visualization; burndown tracks remaining effort
- Gap: No burndown chart, no variance analysis — phase completion could not be tracked
- Corrective Action: Project V2 insights provide burndown; weekly sprint reports via Discussions
| Waste | Manifestation | Corrective Action |
|---|---|---|
| Waiting | Redis was in go.mod and config.go since project inception but never wired — dependency was "available" but not acted upon. The project waited for a dependency that was already decided on. |
Treat Redis as a Sprint 1 spike (Risk R2 mitigation). Use JIT principle: when a dependency is decided, execute it immediately. |
| Partially Done Work | API Key Management has a complete frontend UI but no backend — the frontend was built before the API existed. This work delivers zero value until the backend is complete. | "Stop starting, start finishing" (Kanban principle). Complete the backend for one feature before starting the frontend for another. |
| Task Switching | 10 issues were started simultaneously under Phase 1. | WSJF prioritization in Sprint 1 enforces single-piece flow. Do Redis first, then API Keys, then File Attachments. |
| Defects | Not observed in Phase 1 | CI workflow already prevents merge with failing tests |
| Agile Principle | Score (1-5) | Notes |
|---|---|---|
| #1: Highest priority is customer satisfaction | 4 | CRM core features are being built; visual design is strong |
| #3: Deliver working software frequently | 3 | Delivered in batches (phase-level), not incremental sprints |
| #7: Working software is the measure of progress | 3 | Frontend stubs exist but don't count as working software |
| #9: Technical excellence and good design | 5 | Codebase is well-structured (repository pattern, layered architecture) |
| #10: Simplicity — maximize work not done | 2 | 10 items in Phase 1 includes items that could wait |
Average: 3.4 / 5 (Phase 1) → 4.2 / 5 (Sprint 1) — Delivery cadence and working software improved significantly with sprint structure.
All three recommendations were followed in order:
| Order | Issue | PR | Delivered |
|---|---|---|---|
| 1 | Redis (#10) — WSJF 3.33 | #61 | ✅ Eliminated "waiting" waste |
| 2 | API Keys (#8) — WSJF 3.0 | #60 | ✅ Eliminated "partially done work" waste |
| 3 | File Attachments (#11) — WSJF 2.2 | #62 | ✅ Completed within sprint |
Key discipline: Single-piece flow was maintained — one WSJF-ordered item at a time. No task switching occurred during Sprint 1.
| # | Title | PR |
|---|---|---|
| #64 | CI/CD Pipeline with provider-agnostic kubeconfig deployment | #65 |
| #66 | OKE cluster bootstrap, ingress, CI-CD readiness | #67 |
| Waste from Phase 1 | Sprint 1 Result |
|---|---|
| Waiting — Redis decided but not wired | Eliminated — Redis wired in first item (PR #61) |
| Partially Done Work — API Keys frontend without backend | Eliminated — backend completed (PR #60) |
| Task Switching — 10 items started simultaneously | Eliminated — single-piece flow, WSJF order |
The next sprint should focus on Phase 2 (Analytics & Insights):
| Priority | Issue | Notes |
|---|---|---|
| 1 | #13 Build Reports and Analytics Dashboard | Highest user-facing value after core CRM |
| 2 | #16 Build Global Full-Text Search | Critical for UX |
| 3 | #15 Sales Goal Tracking and Quotas | Complements reporting |
| 4 | #14 Sales Forecasting Engine | Analytics depth |
| Metric | Phase 1 (Pre-PM) | Sprint 1 Result |
|---|---|---|
| Cycle Time per issue | Unknown | ~2 days (3 PRs in 4 days after sprint start) |
| Throughput | ~7 issues / ~10 weeks (0.7/week) | 5 issues / 4 days (8.75/week) |
| WIP Limit | Unlimited | 1 (single-piece flow) ✅ |
| Scope Change | None tracked | WSJF review at sprint start |
This retrospective applies the Lean "see the whole" principle — understanding Phase 1's delays requires looking at the entire workflow, not individual tasks.