A city finance WBS includes a work package labeled "Payment gateway." The adaptive team breaks it into stories such as tokenize card, send receipt email, and support a refund path across upcoming iterations. What practice does that illustrate?
Select an answer to reveal the explanation.
Short Explanation
A WBS chunk is like a whole pizza; stories are the slices you can serve one at a time. Tokenize, receipt, refund—each can land in an iteration without waiting for the entire gateway. That is how plan-based decomposition feeds adaptive delivery.
Full Explanation
When a city finance WBS work package labeled "Payment gateway" is broken into stories such as tokenize card, send receipt email, and support a refund path across upcoming iterations, the practice illustrated is slicing a predictive deliverable into iterative backlog items that can be delivered incrementally. Teams often start from traditional decomposition and then translate work packages into backlog stories sized for iterative civic value, creating incremental payment capability rather than one monolithic release.
Deleting the WBS permanently so no scope decomposition remains anywhere fails conceptually because translation does not require erasing all hierarchical understanding of scope. Converting every story into a fixed baseline milestone that cannot change mid-release fails because adaptive stories remain refinable; freezing them as immovable predictive milestones undoes the iterative intent. Replacing acceptance criteria with a single annual phase-gate document fails because story-level acceptance supports incremental delivery; an annual gate alone does not.
Exam caveat: CAPM expects recognition of WBS-to-adaptive translation, not discarding decomposition entirely or re-freezing every story as an immovable baseline milestone. Operational check: maintain traceability from the payment-gateway package to backlog stories, deliver vertical slices across iterations, and refine acceptance with finance stakeholders as increments ship.