The Product Owner of a city building-permits portal adds a “one-click plan markup” experiment to the Product Backlog. What must be explicit on that item for it to be an Evidence-Based Management experiment rather than just another feature request?
Select an answer to reveal the explanation.
Short Explanation
An experiment without a target is just a feature in a lab coat. Tie the backlog item to the Key Value Area and goal it is supposed to nudge, and say how you will know. Otherwise the team ships markup tools and still cannot tell if permits got any healthier.
Full Explanation
Under Evidence-Based Management, Product Backlog experiments exist to test a hypothesis about a goal and a Key Value Area—Current Value, Unrealized Value, Time-to-Market, or Ability to Innovate. For a building-permits 'one-click plan markup' item to be an experiment rather than another feature request, the Product Owner must make explicit which KVA and goal the experiment is intended to move and how that move will be measured so inspection is possible after the Increment.
Specifying the exact production architecture Developers must implement turns the item into a specification document, not a value hypothesis. Promising that Time-to-Market will improve regardless of which Key Value Area is named decouples the claim from measurable intent. A council resolution that freezes the experiment as a committed annual output converts learning work into a fixed project deliverable. Permitting experiments earn their backlog place by naming the civic outcome they intend to move.
Exam caveat: PSPO II experiments require hypothesized KVA movement and measures; architecture mandates and frozen outputs are feature-factory tells.
Operational check: on the markup backlog item, write the target KVA, the goal, the success metric, and the fail criteria before Sprint Planning selects it.