Final Performance Summary
Deliverable Acceptance
| Deliverable | Acceptance |
|---|---|
| Release 1 (MVP) — patient mobile app, provider console core | Accepted, Mar 27, 2026 (M. Delacroix) |
| Release 2 — messaging, refills, full migration, cutover | Accepted, May 8, 2026 (M. Delacroix) |
| Full historical patient data migration | Validated & accepted (T. Brannigan) |
| CareLink Classic decommission | Complete, verified May 12, 2026 |
Outstanding Items
- MCM-145 (read-only archival export, 5 pts) formally carried to a post-program maintenance task — owned by IT Operations, not tracked as a program shortfall
- MCM-155 (intake-to-notes pre-population, provider-requested) remains in the candidate backlog for a future enhancement cycle, unscoped
Lessons Learned
1. Linked ≠ Watched — Cross-Team Dependencies Need an Owner
Tracking a dependency in the tool isn't the same as someone actively watching it. The Sprint 2 near-miss on MCM-111 led to adding an explicit dependency-owner practice, which held for the rest of the program.
2. Splitting Oversized Stories Early Pays Off
MCM-133's split into a data-mapping story and a UI story (Sprint 3 refinement) avoided what likely would have been a Sprint 6 delivery risk — the pattern held up well enough that both teams applied it proactively on later large stories without prompting.
3. Staged Compliance Checkpoints Beat a Single End-of-Program Gate
Splitting the compliance review into a Release 1 checkpoint and a Release 2 checkpoint (decided at Kickoff) meant migration validation issues, had any occurred, would have surfaced with runway to fix them — rather than all validation risk landing in the final sprint.
4. Phased Rollout After MVP Reduced Support Risk
Holding Release 1 to the pilot cohort rather than immediate full rollout (Sponsor decision at Sprint 5 Review) kept early support ticket volume manageable and gave the team a smaller blast radius for any post-launch issues — none of which materialized, but the decision was sound regardless of that outcome.
5. A Two-Team Scrum-of-Scrums Model Scaled Well at This Size
Two teams of five was small enough that a lightweight, twice-weekly Scrum-of-Scrums was sufficient coordination overhead — a heavier SAFe-style Agile Release Train structure would likely have been more process than this program's size warranted.
Recommendation for Future Programs
This delivery model (two coordinating Scrum teams, lightweight Scrum-of-Scrums, staged compliance checkpoints) is recommended as a repeatable pattern for future ACME Health digital programs of similar size — before reaching for a heavier scaled-Agile framework.