Relay / fictional worked example
Outcome scorecard: learning, delivery and cost
The scorecard is an illustrative template, not actual measured outcomes. Replace “not measured” with evidence from the real product before publishing any success claims.
| Dimension | Question | Evidence for a real project | Status in fictional example |
|---|---|---|---|
| Product understanding | Have we learned which user problem matters most? | Interviews, observed task outcomes, usage, purchase signals | Illustrative hypothesis revision; not validated |
| Scope discipline | Did we remove or change low-value work? | Scope history with rationale, avoided maintenance obligation | Candidate urgency feature removed in scenario |
| Functional correctness | Do supported inputs produce contractual outcomes? | Automated contract tests and reproducible checks | Intake slice has runnable tests |
| Design integrity | Were boundaries maintained? | Dependency analysis, ADR review, consumer contracts | Architecture written; not all checks automated |
| Reliability | Can real infrastructure survive retries, failure and concurrency? | Integration, fault-injection and load tests | Not established |
| User value | Do people complete the job better than with alternatives? | Comparative tasks and pilot results | Not established |
| Delivery efficiency | What is the full cost of the validated outcome? | Agent spend, review time, rework, tool maintenance and ops cost | Not measured |
Avoid false precision
A success metric should connect to a product assumption and be measurable. “Agent wrote 4,000 lines” cannot tell whether the product improved. “Model spent fewer tokens” can be helpful for cost control, but cannot establish correctness or value.
A disciplined team can make progress by not shipping a feature. That decision should have visible reasoning and should free capacity for something more valuable.