A Product Owner tells the Scrum Team their success this quarter will be measured by the total number of firmware features shipped before the retail launch window. A Developer pushes back on this framing. What is the strongest empirical reason for the pushback?
Select an answer to reveal the explanation.
Short Explanation
Counting shipped features is easy, but easy isn't the same as meaningful. A pile of firmware toggles nobody notices doesn't help the robot sell, work, or delight anyone at unboxing. Value gets measured by what changes for the customer, not by how many boxes got checked in a backlog.
Full Explanation
The mechanism at stake is the whole point of Scrum's emphasis on empiricism and value: a Product Backlog exists to maximize the value of the product, and value is inspected through real outcomes, not tallied like inventory. A count-based success measure creates an incentive to slice work into more, smaller items regardless of whether any of them matter, which is the opposite of what a Product Owner is accountable for. The certification-timing distractor is a real operational fact about hardware, but it doesn't address why counting features is the wrong measure in the first place, it just complains the count is unfair, not that count is the wrong metric. The Sprint Backlog point confuses a planning artifact with a success metric; the Sprint Backlog tracks what the Developers plan to do, not why it matters. The overtime point is a working-agreement concern, unrelated to what success should mean. Caveat: this doesn't mean feature counts are useless as raw data, only that they should never stand in for value. Operational check: at the next Sprint Review, ask what customer-facing change resulted from what shipped, not how many items closed.