Adding Value
Domain 5, Adding Value, tests whether you maximize outcomes rather than output. Questions ask how value is defined, measured, prioritized, and protected across the product life cycle.
Core rules
- Value is the benefit a product delivers to customers and the organization. It can be financial, such as revenue or cost reduction, or nonfinancial, such as satisfaction, compliance, or risk reduction. It should be explicit and measurable.
- The Product Owner maximizes value by ordering the backlog, setting outcome-focused Sprint Goals, validating assumptions, measuring results, and adapting. Delivering features is output; realized customer or business change is the outcome.
- Useful measures include customer satisfaction, adoption, retention, revenue, lead time, and quality. Avoid vanity metrics that look good but do not guide decisions. Velocity measures team output, not product value.
- Cost of delay, return on investment, and total cost of ownership help ordering. Technical debt and poor quality reduce future value, so they belong in value discussions.
- A minimum viable product is the smallest version that delivers value and enables learning. It is not an excuse for poor quality or an incomplete user experience.
- Value should be inspected with stakeholders. Feedback from users and the market informs backlog ordering and may change the roadmap.
Worked example
A team raises velocity from 40 to 60 story points by splitting stories, but adoption and revenue are flat. A weak answer declares success because output rose. A better answer checks whether the increase reflects real scope or smaller slicing, then examines adoption, retention, customer satisfaction, and revenue against the intended outcome. Reasoning: velocity is an internal forecast input, not evidence of value; the Product Owner must measure outcomes and adapt the backlog.
Traps
Do not equate high velocity with high value. Do not prioritize the easiest or cheapest item by default. Do not ignore technical debt and quality. Do not measure only delivered features. Do not treat value as purely financial. Do not use an MVP as a label for low quality. Do not let the team define value without stakeholder input.