A municipal licensing app is delivered in two-week sprints. How should the BA typically support acceptance criteria in this adaptive setting?
Select an answer to reveal the explanation.
Short Explanation
In sprint land, acceptance criteria are living checklists—you sharpen them with the team each cycle, not once in a dusty binder. Licensing stories get clearer as clerks try the flow.
Full Explanation
When a municipal licensing app is delivered in two-week sprints, the BA typically supports acceptance criteria by collaborating each sprint with the team and product owner to refine story acceptance criteria. Adaptive settings keep criteria thin, current, and testable as stories approach development rather than freezing one eternal checklist at kickoff. Civic licensing outcomes stay accurate when criteria evolve with ordinance clarifications and learning.
Writing one unchanging acceptance checklist at project kickoff and never revisiting it fails conceptually because adaptive discovery will invalidate early assumptions; frozen checklists become wrong. Handing acceptance criteria solely to procurement after the last release fails because procurement closeout is too late for sprint-level acceptance of licensing behavior. Forbidding acceptance criteria until the entire license module is coded fails because criteria should guide coding and testing, not arrive after the fact.
Exam caveat: In adaptive civic delivery, BA support for acceptance criteria is ongoing per sprint, not a one-time kickoff artifact. Operational check: in each licensing sprint refinement, co-write or update acceptance criteria with the product owner and team, ensure testers can execute them, and keep criteria aligned with current ordinance rules before development starts.