A predictive WBS element labeled "Reporting module" for a tax portal must feed adaptive delivery. What is the most appropriate translation for successive iterations?
Select an answer to reveal the explanation.
Short Explanation
Treat the WBS "Reporting module" like a big moving box — adaptive teams unpack it into backlog items that fit each iteration's trunk space. Leaving it as one opaque block or deleting feedback does not enable iterative delivery. Decomposition is the bridge from plan-based structure to adaptive work.
Full Explanation
When a predictive WBS element labeled "Reporting module" for a tax portal must feed adaptive delivery, the most appropriate translation is to decompose that element into prioritized backlog items sized for successive iterations. Adaptive planning often unpacks predictive decomposition into product backlog items that can be ordered, refined, and completed within timeboxes, enabling successive citizen-visible value rather than one opaque module block.
Keeping the WBS element untouched and never creating backlog items fails conceptually because it leaves no iterative slices for adaptive delivery. Replacing the entire portal with a single undocumented task lasting one day fails because that erases decomposition and traceability rather than translating it. Deleting stakeholder feedback so the module stays one opaque block forever fails because feedback is required to prioritize and validate successive slices.
Exam caveat: CAPM expects recognition of WBS-to-backlog translation for hybrid or adaptive shifts, not discarding all decomposition or freezing modules as immovable monoliths. Operational check: split "Reporting module" into ordered backlog items with acceptance criteria, schedule them across iterations, and review each increment with tax-portal stakeholders.