After evaluating all assumptions, mapping them, planning experiments, and setting the evaluation criteria, we need to develop a work plan for the following experimentation phase. The Experimentation Plan looks at the required efforts and necessary duration for each experiment and the dependencies that might exist between some assumptions. Then, it chunks them into experimentation sprints the team can run sequentially.
Experimentation should be approached with an agile mindset. Running through all experiments in one go and then learning afterwards deprives the team of the chance to iterate, refine and reprioritise along the way. Instead, a sprint-based Experimentation Plan ensures that we can keep using resources in the best possible way to learn faster and better.
Prepare a workshop board with the Assumption Backlog template - one for each concept.
Run a session during which the team first cycles through all the experiments and assigns resource values to those - how much effort they will be to create and run -as well as ideal runtime durations.
Map out potential dependencies between assumptions and between experiments. E.g., a “Make or Break” feasibility assumption for a feature should be validated before a “Strategic” desirability assumption on that feature, as without the former in place, the latter needs not be checked in the first place.
Chunk the experiments into sprints by deciding on the following:
How long will your sprints be (typically 2 or 3 weeks in during)
Which experiments have priority over which
What is your resource level/velocity
Fill up a sprint with “Experiment Creation” and “Experiment Operation” tasks until the resource level is filled, and move to the next sprint.
Realistically evaluate required resources and your resource level - and if specific experiments are a terrible match for your resource level, feel free to iterate.
Be mindful of dependencies and sequence accordingly.
Be mindful of preparation/creation time and sequences accordingly.
Don't
Don’t cram sprints too full; leave some buffer for the ad-hoc workload that might be required or fluctuations in resource availability.