A city's citizen chatbot needs change after nearly every town hall as residents request new intents and languages. Which delivery approach is most appropriate for that uncertainty?
Select an answer to reveal the explanation.
Short Explanation
When town halls keep rewriting what the chatbot must understand, locking a year of intents on day one is like printing a menu before you know who is coming to dinner. Adaptive delivery expects that learning and reshapes the backlog. Freezing early or ignoring feedback fights the uncertainty.
Full Explanation
A city's citizen chatbot that must change after nearly every town hall, as residents request new intents and languages, exhibits high uncertainty and frequent requirement change. An adaptive approach that embraces frequent feedback and evolving requirements is the most appropriate delivery stance: short learning cycles, prioritized backlog adjustments, and inspected increments let the product track shifting civic needs rather than pretending the first frozen intent list was complete.
A fully predictive approach that freezes every chatbot intent before the first sprint of learning fails conceptually because early lock-in fights the observed uncertainty and delays incorporation of town-hall feedback. Cancelling all user feedback so the backlog never changes fails because suppressing learning removes the primary signal adaptive (and good civic) products need. Building the chatbot only with a fixed concrete pour schedule and no increments fails by misapplying a low-learning physical-construction metaphor to a software product that benefits from iterative discovery.
Exam caveat: Suitability questions ask which approach fits uncertainty and change rate; adaptive is favored when requirements are expected to evolve through stakeholder feedback. Operational check: after each town hall, refine chatbot backlog intents and languages, deliver a small increment, review with citizen or service representatives, and reorder remaining work rather than defending an obsolete frozen scope.