A homeless-services intake form rebuild uses eight-week iterations, and frontline caseworkers only see working software at the end of each cycle. What is the main drawback of that long cadence?
Select an answer to reveal the explanation.
Short Explanation
If you only taste the soup every two months, you burn a lot of ingredients before you know it needs salt. Long iterations push learning way out, so bad assumptions hang around. Shorter inspect-and-adapt loops catch that sooner.
Full Explanation
Using eight-week iterations on a homeless-services intake form rebuild so frontline caseworkers only see working software at the end of each cycle mainly delays feedback and learning, allowing wrong assumptions to persist longer before correction. Iteration length trades overhead against feedback speed; overly long cycles slow inspect-and-adapt, which is especially costly when civic caseworkers need timely usability corrections.
Claiming longer iterations automatically eliminate the need for a Definition of Done fails conceptually because quality agreements remain necessary regardless of cycle length. Claiming stakeholders must attend daily standups for eight continuous weeks with no exceptions fails because daily Scrum attendance rules are not the defining drawback of long iterations; delayed increment review is. Claiming velocity becomes meaningless because story points can only be used in one-day sprints fails because story points are not restricted to one-day sprints.
Exam caveat: The major con of overly long iterations at CAPM depth is slower learning—not disappearance of Done, mandatory eight-week daily attendance myths, or story-point invalidity. Operational check: shorten the intake-form cadence enough that caseworkers review working software sooner, keep DoD intact, and measure whether defect/assumption corrections arrive earlier.