We assume that delivering that feature will change players' behaviour. Once the feature is delivered, we can track if the assumption was true or not.

define actors in this order: specific individual, user persona, role or job title, group or department.

The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations. If a deliverable does not support an impact, even if it works correctly from a technical perspective, it is a failure and should be treated as a problem, enhanced or removed.

Ideally show a change in actor behaviour, not just the behaviour. Show how the activity is different from what is currently possible. So instead of just ‘selling tickets’, say ‘selling tickets five times faster’.

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people.

They provide an explicit context for making decisions and exposing uncertainty, which can then be addressed by doing experiments.

Primary actors, whose goals are fulfilled, for example players of a gaming system

The visual nature of this method also facilitates effective meetings and supports big-picture thinking, which provides organisational alignment.

Treat deliverables as options, don't take it for granted that everything listed here will actually be delivered.