The solution to be tested contains implicit assumptions about users that must be accounted for before testing commences.
👥 whole team | ⏰ between 45 and 60 minutes
In this activity, the team lists the assumptions inherent in the solution(s) that are going to be tested. After this, the team will quantify success and failure of the solution against those assumptions in the Operational Definition.
The key idea and belief that we are trying to prove is our hypothesis. Typically, it represents a solution to a problem for our users (or other customers) that we believe will provide value. It should be clear and specific enough to be something that we can break down into component assumptions, to answer the question of why we think customers will find our product or feature valuable.
The artifact from this step is simply a list of statements that must be true about the solution or about users in order for the solution to be effective.
If, for example, a solution involves a button on a page to drive email newsletter signups, some assumptions might be “Readers can see the button”, and “Readers understand what the button does”, and “Readers want to sign up for newsletters”.