← Back to principles

QA

Focus on Value

Statement

Quality work must verify both that we are building the product right and that we are building the right product.

What this means in practice

Teams assess functional correctness and delivery quality (“built right”), and also validate outcomes and value (“right product”), adjusting effort to focus on what matters most.

  • Testing prioritises scenarios that protect user experience and business value alongside functional testing.

  • Teams can switch focus quickly when evidence shows the product direction or scope needs to change.

  • Business value is assessed early (“shift left”) during discovery and refinement, not after build.

  • Quality is measured in terms of outcomes, not vanity metrics.

Why this matters

Value-focused quality avoids wasted effort and increases the chance of delivering the right thing.

  • Building the wrong product is expensive.

  • Missing the opportunity to realise value reduces impact and trust.

  • Clear prioritisation improves decision-making and helps teams spend time where it reduces the most risk.

Practices that meet this principle

  • Team exploratory testing that uses product domain knowledge to identify important scenarios not yet considered.

  • Use feedback from user acceptance testing to confirm value delivered to users.

  • Active involvement in providing an opinion on feature value during refinement.

  • More active demos during development, not only at the end of a sprint.

  • Sprint demos that explicitly call out value delivered and remaining risks.

  • Feedback in production of users interacting

Validation

A project meets this principle when:

  • Test effort is demonstrably prioritised toward user and business-critical scenarios.

  • There is a clear, shared understanding of the intended value of each feature before build.

  • UAT and demo feedback results in changes to scope, design, or priorities when needed.

  • Quality reporting includes outcome metrics (for example, user impact, incident/support trends), not only test counts.

  • The team are encouraged, and challenged to be critical and engaged during refinement.

Potential blockers

  • Lack of clarity on expected outcomes or success measures.

  • Limited access to users, stakeholders, or UAT feedback.

  • Incentives that reward output (tickets closed, tests written) over outcomes.

  • Insufficient product domain knowledge within the delivery team.