This guide explains how Agile/Scrum program delivery actually works, using MedConnect Mobile's real sprint history as a running example. It's written for anyone who knows predictive/PMBOK delivery well but wants to understand why a mobile rebuild ran on sprints instead of a phase-gated schedule.
Why adaptive delivery, for this program specifically: a native mobile rebuild competing against an unknown pace of user adoption and platform-store review cycles benefits from shipping incrementally and adjusting scope based on what real usage shows — the opposite bet from a program where the end state is already fully known. See the PMBOK suite's methodology guide for the predictive alternative.
Contents
1. Methodology at a Glance
Scrum is adaptive: instead of baselining scope up front, the team commits to a fixed-length iteration (the sprint) and re-prioritizes the Product Backlog before every one. What's fixed is the timebox and the process; what flexes is exactly which backlog items get built next, based on what was learned in the last sprint.
This only works because of two disciplines PMBOK delivery doesn't need in the same way: a reliable sprint cadence the whole organization can plan around, and a velocity number the team trusts enough to forecast with — both earned through repetition, not declared on day one.
2. The Sprint Cadence
Kickoff / Foundation Sprint
No feature work ships in Sprint 0 — it's for environment setup, backlog seeding, and team formation.
Why it matters: skipping Sprint 0 is a common mistake — teams that try to ship features in their very first sprint often discover mid-sprint that the environment isn't ready, which blows the sprint commitment before the team has even had a chance to build trust in its own velocity.
Toward Release 1 (MVP)
Each sprint delivers a working increment; velocity is tracked from Sprint 1 onward but treated as unreliable until the team has a few sprints of history to average.
Why it matters: an MVP release date set this early only works because it's a target the team is forecasting toward with real velocity data, not a date fixed at Planning the way a PMBOK baseline would be. If velocity had come in consistently lower than committed, Release 1 scope — not the date — would have been the thing that flexed.
Toward Release 2 (Full Cutover)
By this point velocity has stabilized enough to forecast the remaining scope with real confidence — this is where adaptive planning pays off, because the team isn't guessing at a schedule set six months earlier.
Why it matters: by Sprint 6, the team had 5 sprints of real delivered-points history (34, 41, 40, 44, 46) to average — a far more trustworthy forecast basis than the single planning-day estimate a predictive program would have locked in at Kickoff. That's the whole case for adaptive delivery in one number: the plan gets more accurate over time instead of being most accurate on day one and eroding from there.
3. The Four Ceremonies (Plus Refinement)
| Ceremony | Cadence | Purpose |
|---|---|---|
| Sprint Planning | Start of every sprint | Team commits to a set of backlog items for the sprint, based on velocity and Definition of Ready |
| Daily Standup | Daily | 15-minute sync on progress and blockers — not a status report to management |
| Sprint Review | End of every sprint | Demo completed work to stakeholders; gather real feedback before the next sprint is planned |
| Sprint Retrospective | End of every sprint | Team-only reflection on what to keep, stop, and start — Agile's continuous version of Lessons Learned |
| Backlog Refinement | Ongoing, between sprints | Keeps upcoming backlog items sized, clarified, and meeting Definition of Ready before they're ever pulled into a sprint |
The Retrospective is worth calling out specifically, since it's the ceremony a PMBOK-trained reader is most likely to underestimate: it happens every single sprint, not once at program closeout, which means lessons get applied within weeks instead of being filed away for the next program.
4. Key Disciplines vs. PMBOK Delivery
| Discipline | Agile / Scrum | PMBOK / Predictive |
|---|---|---|
| Scope | Reprioritized every sprint via the Product Backlog | Fixed at Planning baseline; changes go through formal Change Control |
| Schedule | Fixed-length sprints (2 weeks); scope flexes, not the timebox | Single baseline schedule tracked to completion |
| Progress measurement | Velocity and burndown against sprint commitment | % complete against baseline schedule/budget |
| Retrospective mechanism | Every sprint — continuous | Captured at Closeout, or as issues arise |
| Change authority | Product Owner reorders the backlog for free | Sponsor/Steering Committee approves formal Change Requests |
5. Change Handling in Agile
A common misconception is that Agile has no change control at all. MedConnect Mobile's own Change Handling in Agile page draws the actual line: ordinary reprioritization is free — the Product Owner just reorders the backlog, no approval needed. A formal Change Request is only raised when something affects a baselined commitment — the approved budget or a fixed release date — not routine scope adjustment.
Three formal CRs were raised on this program, all because they touched budget or schedule commitments, not ordinary backlog work:
- CR-01 — Additional Staging/Load-Test Environment. Raised Sprint 4, +$18,000 cost impact, no schedule impact, approved by M. Delacroix (Sponsor). A. Singh flagged that load-testing the video visit infrastructure against realistic patient volume needed a dedicated environment the original budget hadn't scoped.
Notice the shape: this needed formal approval specifically because it touched the approved budget, exactly the same reason a PMBOK program would route it through formal Change Control. The lesson isn't that Agile lacks discipline around cost and schedule — it's that Agile reserves that formal weight for baselined commitments, and doesn't spend it on ordinary scope decisions the Product Owner is already trusted to make sprint to sprint.
6. MedConnect Mobile by the Numbers
| Figure | Value | Source |
|---|---|---|
| Approved Program Budget | $1,850,000 | Program Budget |
| Actual Program Cost (at Closeout) | $1,810,000 | Program Budget |
| Total Reconciled Delivery Labor | $1,362,000 | Resource Plan |
| Program Duration | Sprint 0 (Jan 5, 2026) to Closeout (May 15, 2026) — 8 delivery sprints | Program Charter |
| Release 1 (MVP) | End of Sprint 5, Mar 27, 2026 | Program Charter |
| Release 2 (Full Cutover) | End of Sprint 8, May 8, 2026 | Program Charter |
| Average Velocity (Sprints 2–8) | 43 points/sprint | Velocity Chart |
| Formal Change Requests | 3 (all approved) | Change Control Log |
7. Roles at a Glance
Scrum defines fewer formal roles than PMBOK, on purpose — the framework relies on the team, not a role hierarchy, to make most day-to-day decisions.
| Role | Owns |
|---|---|
| C. Tyrrell — Product Owner & Agile Delivery Lead | Backlog prioritization, release scope decisions, and the single point of accountability across both teams |
| J. Marsh — Scrum Master, Team Falcon | Removes blockers, facilitates ceremonies, protects the team's sprint focus |
| R. Okafor — Scrum Master, Team Anchor | Same, for Team Anchor |
| M. Delacroix — Executive Sponsor, VP Digital Health | Program-level funding authority; approves Change Requests touching budget/schedule |
| Dr. L. Nguyen — CMIO (advisory, ~10%) | Clinical input, matrixed in from her home department rather than dedicated full-time |
| T. Brannigan — Compliance & Security Director (advisory, ~10%) | Compliance/security input, similarly matrixed |
Notice there's no dedicated PMO or governance layer sitting between the Product Owner and the Sponsor — that compression is deliberate. A PMBOK program's RACI often spans several accountable roles across different deliverables; here, C. Tyrrell is accountable for nearly everything delivery-related, with the Scrum Masters handling team-level facilitation rather than program-level decisions.
8. Questions & Answers
Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective, every sprint, plus ongoing Backlog Refinement between sprints.
No — it has a narrower one. Ordinary reprioritization is free; formal Change Requests are reserved for changes touching a baselined budget or schedule commitment. See Section 5 above.
Because it reflects real team capacity — availability, story complexity, and interruptions all vary sprint to sprint. MedConnect Mobile's velocity ranged from 34 to 46 delivered points across 8 sprints, which is why the team used a multi-sprint average (43) to forecast Release 2, not any single sprint's number.
Ready gates entry into a sprint (clear acceptance criteria, sized, dependencies known); Done gates exit (tested, reviewed, deployed). See Definition of Ready/Done for the program's exact criteria.
9. Related Reading
Agile Glossary — glossary.html — plain-English definitions of Scrum terms used across this suite.
Sprint Retrospective — sprint-retro.html — the Agile equivalent of a Lessons Learned register, refreshed every sprint.
Compare methodologies — see how this differs from PMBOK/predictive delivery and federal civilian contracting in the other two suites.