A municipal open-data team debates one-week versus longer iterations for tiny catalog fixes. Which statement best captures a trade-off of very short iterations?
Select an answer to reveal the explanation.
Short Explanation
One-week cycles are like tasting the soup constantly — feedback arrives fast, but if the tasting ritual takes longer than cooking a tiny fix, overhead wins. That is the trade-off. Short iterations do not ban demos or erase all planning by magic.
Full Explanation
Very short iterations for tiny municipal open-data catalog fixes speed feedback but can add overhead when ceremonies outweigh the tiny work. That trade-off is the heart of the question: shorter cycles increase inspection frequency, which helps adaptive teams correct course quickly, yet planning, review, and retrospective time can dominate when each item is trivial. Associates should recognize both the benefit and the overhead risk.
Claiming short iterations always remove all ceremony and never produce feedback fails conceptually because short iterations still include planning and review and are chosen specifically to increase feedback, not eliminate it. Claiming they forbid any demonstration of working catalog pages fails because demonstrations of increments remain part of adaptive inspection. Claiming they guarantee zero planning forever fails because iterations still plan capacity and goals within the timebox.
Exam caveat: Iteration-length questions test trade-off thinking—feedback speed versus ceremony cost—not absolute rules that short equals no process. Operational check: if one-week catalog iterations spend more time in ceremony than in fixes, lengthen slightly or batch tiny items, while preserving enough feedback frequency for citizen-data quality.