At a consumer home-robot company, the companion-app team has shipped a new feature every Sprint for the last five Sprints, yet daily active use of the robot's app has not moved. What should this pattern prompt the Scrum Team to inspect?
Select an answer to reveal the explanation.
Short Explanation
Shipping a feature every Sprint feels productive, but "done" and "valuable" aren't the same thing. Five features nobody touches is still five features nobody touches. The real signal here is whether customer behavior changed, not how many things got built.
Full Explanation
Empiricism only works if the team inspects the right signal, and a count of shipped items is an output metric, not an outcome metric. The mechanism is simple: at Sprint Review, the Scrum Team and stakeholders look at the actual Increment in use and ask whether it moved something that matters, like retention or task completion, not whether a checklist of features got built. A steady cadence of shipped work can mask the fact that none of it addressed a real customer problem. The distractor about Developers not completing enough items reframes the concern as a throughput problem, which misses the point entirely, since throughput was fine but impact was not. Shortening the Sprint attacks cycle time, not whether the work is valuable. Extra Definition of Done steps address quality of the build, not whether the right thing was built. The caveat: this isn't a call to stop delivering Increments; it's a call to change what gets inspected at Sprint Review. A concrete check: before planning the next Sprint, look at one real usage metric tied to the last five features and see whether any of them actually moved it.