Testing Assumptions

Assumptions vs Questions

Questions are normally items that we have identified which we don’t know the answer to and usually arise from curiosity and an enquiring mindset. There is an objectivity about the question, in that, we know we don’t know the answer and need to get more information through data or asking others.

Assumptions by contrast tend to be a projection of our understanding of what the solution should be and are usually based upon intuition rather than on qualified data to solve the problem.

Assumptions tend to be unaware or unconscious and can be a reaction to solve a problem quickly based upon our existing understanding, experience or intuition. However, consciously and purposefully raising an assumption that can then be tested is a useful technique to gather data to prove or disprove the assumption and can be used to set the hypothesis and framing of experiments.

Deriving questions and assumptions to set Sprint Goals to be tested then provides an intent behind the work done in Sprints to position them to enrich the current understanding of the product or service with evidential data, feedback and new findings.

Sprints as Experiments

The easiest way to test questions or assumptions is to conduct an experiment, build something quickly and evaluate it to provide more concrete data or evidence to prove or disprove the question or assumption.

An approach to do this in a Scrum context is to craft a Sprint Goal to provide the reason, intent and the “why” behind the work for the Sprint, which in this case would be to answer a question for example. The Sprint Goal then becomes the hypothesis of the experiment to be tested, allowing for specific evidence to be collected and conclusions drawn.

Using Sprints in this way to conduct experiments can help to arrive at appropriate solutions in complex problem spaces, which may have not otherwise have been possible to comprehend through traditional requirements gathering or spec writing activities alone.

During Sprint Planning the Sprint Goal can be referenced to indicate what work is selected by the team to test the hypothesis during Topic 1, and then the Development Team can break this down in Topic 2 into how they are going to deliver the work in the Sprint and conduct the experiment.

This then sets up the Sprint to evaluate the assumption or question, with the Sprint Review used to inspect the resulting data and determine if the hypothesis holds true, and what are the next steps. This could be the next Sprint Goal for example that moves on to the next question or assumption, or a refined assumption based upon what was found during the Sprint Review.

Lean Startup with Sprints

The Lean Startup movement[1] was initiated by Eric Ries and his book of the same name. The approach is much like using experiments, however, this approach conducts longer running experiments that may encompass a number of Sprints to build attributes to be tested and evaluated when used within a Scrum context.

The approach begins with a hypothesis or a question to be answered that are normally quite high level and challenging. The experiment then runs and may well include several Sprints as mini experiments to contribute to the overall hypothesis. Each Sprint will have their own Sprint Goals to position the Sprints, which may be sub parts of the overall hypothesis. Towards the end of the experiment validated learning is collected, which may be through the results of customer testing, surveys and other data that helps to prove or disprove the hypothesis.

Finally, the cycle ends with a decision to pivot and try a different hypothesis for the next experiment or persevere and continue to refine the hypothesis based upon the findings and observations. The cycle starts again with a new or refined hypothesis.

Applying this approach with a Scrum context allows for high level experiments to be conducted and leverages the Sprints as a means to conduct the experiment or to provide something that can be evaluated such a s prototype to be submitted for customer tested for example.

Simulations, Prototypes, Games

Working in complex problem spaces can be a little overwhelming if trying to visualise or put down possible solutions on paper. A much better way to engage much more of the brain power is to build prototypes, run simulations or devise games to model the search space. Seeing things in 3D, interacting with them in a physical sense and playing each other in a game setting can really help to bring the possibilities to light and enable context sensitive solutions to emerge from the model.

Building quick prototypes, such as paper prototypes for example, can help to illustrate new ideas and approaches. But have to be able to be constructed quickly and only show the concepts as opposed to final features. (The previous section on Customer Research provides more examples and approaches to prototyping.)

See Also

• Empirical vs Predictive Control Processes