Developers merged code for a restaurant-inspection lookup story but cannot demonstrate working software to health-department stakeholders. How should success be judged?
Select an answer to reveal the explanation.
Short Explanation
A merge without a showable product is like a rehearsal with the curtain still down. Adaptive success wants a demoable Increment—something stakeholders can poke. Transparency beats ‘trust us, it’s in git.’
Full Explanation
When developers merged code for a restaurant-inspection lookup story but cannot demonstrate working software to health-department stakeholders, success should be judged by whether there is a demoable Increment stakeholders can inspect—not merely code merged to a branch. Adaptive success emphasizes reviewed working software. Merge status without a usable increment leaves civic stakeholders unable to inspect outcomes or confirm public-health lookup value.
Claiming merged code alone proves success even without a usable Increment fails conceptually because a merge flag is not inspected working software. Measuring success only by story-point burn regardless of stakeholder visibility fails because burn metrics without demoable outcomes can hide non-delivery. Hiding unfinished work and reporting green status until the next fiscal year fails because it violates transparency and delays correction of real gaps.
Exam caveat: Increment demonstrability to stakeholders is central to adaptive success—not merge flags, points alone, or hidden greenwashing. Operational check: integrate the lookup story to a demoable state, run acceptance and Definition of Done checks, then review with health-department stakeholders before claiming Sprint success.