A flood-alert SMS service was planned with a phase-based WBS (requirements, build, test, launch). The team now wants adaptive delivery. What is an appropriate next step?
Select an answer to reveal the explanation.
Short Explanation
Phases stacked end-to-end are a waterfall cake; MVP slices let people taste frosting sooner. Pull usable alert value forward instead of waiting for the whole launch phase. That is WBS thinking remixed for adaptive delivery.
Full Explanation
When a flood-alert SMS service planned with a phase-based WBS (requirements, build, test, launch) shifts toward adaptive delivery, an appropriate next step is to reslice the phase WBS into MVP increments that deliver usable alert capability early and often. Converting phase-based decomposition into vertical, value-bearing increments lets citizens get early usable capability and helps the team learn faster, rather than completing entire sequential phases before any release.
Keeping all four phases sealed and forbidding any citizen-facing increment until final launch fails conceptually because that preserves the predictive phase barrier adaptive delivery is trying to remove. Replacing every work package with a single predictive cost baseline and stopping scope decomposition fails because a cost baseline alone does not create incremental alert value paths. Treating WBS phases as Scrum roles so "requirements" becomes the Product Owner fails because phases are not accountabilities; that confuses decomposition structure with Scrum roles.
Exam caveat: Adaptive shift means slicing value increments/MVP paths—not renaming phases as roles or forbidding releases until the end. Operational check: define a thin flood-alert MVP (for example, one hazard type to a pilot audience), deliver it, review with emergency managers and residents, then expand increments.