A grants portal needs basic identity verification before applicants can submit, while advanced analytics can wait. How should those components be assigned across releases?
Select an answer to reveal the explanation.
Short Explanation
You don’t open the grants door without checking IDs, but fancy charts can wait for a later wing of the building. MVP security first; analytics later—that’s release slicing by value and dependency.
Full Explanation
A grants portal that needs basic identity verification before applicants can submit, while advanced analytics can wait, should place MVP identity verification in release 1 and schedule advanced analytics for a later release such as release 3. Release planning sequences enabling and mandatory capabilities ahead of discretionary analytics so civic applicants can submit safely before fancy reporting arrives. That ordering protects integrity of grant applications and public trust.
Putting advanced analytics in release 1 and postponing identity verification indefinitely fails conceptually because analytics without identity controls exposes the portal to unsafe or noncompliant submissions. Shipping every analytics dashboard in release 1 and omitting identity checks as cosmetics fails for the same reason—identity is not optional decoration on a grants portal. Bundling both only into a single final release fails because big-bang packing delays all value and keeps the portal dark until everything finishes.
Exam caveat: MVP release planning prioritizes enabling and risk-reducing capabilities before later enhancements. Operational check: update the grants roadmap so identity verification is in release 1 and advanced analytics is deferred to a later release, confirm dependencies and acceptance criteria for identity, and resist packing analytics into release 1 under stakeholder pressure.