A transit app release has most committed items Done, and the product owner explicitly authorizes deferring two low-priority enhancements. How can readiness be described?
Select an answer to reveal the explanation.
Short Explanation
You can ship the bus you finished if the product owner knowingly leaves two shiny extras at the depot. Authorized deferral is conditional readiness—not a secret eraser or an infinite backlog jail.
Full Explanation
A transit app release with most committed items Done, where the product owner explicitly authorizes deferring two low-priority enhancements, can be described as conditionally ready for the agreed scope when deferred items are explicitly authorized. Explicit deferral is a governed readiness pattern: the release ships Done scope with transparent exclusions. Civic adaptive releases often use this pattern to protect dates without pretending unfinished work is Done.
Claiming never ready unless every idea ever suggested is Done fails conceptually because infinite wish lists would prevent any release and ignore product-owner authority to defer. Claiming ready only if deferred items are secretly removed from all records fails because secrecy destroys auditability and stakeholder trust. Claiming blocked forever because partial Done always forbids release fails because authorized deferral of low-priority items is a legitimate readiness decision.
Exam caveat: Conditional readiness depends on explicit authorization of deferred scope, not secrecy or perfectionism. Operational check: document the two deferred transit enhancements with product-owner authorization, confirm remaining committed items meet Done, communicate the agreed scope to stakeholders and ops, and release only that authorized scope.