Hypothesis backlog
This post is part of 101 ideas for agile teams.
Context
You gather problems, ideas, complaints at the start of your retrospectives. The same problems and ideas are named over and over again. You spend time explaining the same thoughts and selecting from more or less the same topics to choose the topic to work on during the rest of the retrospective.
Your team needs a lot of time to come up with ideas on how to solve the discussed problems or on how to improve your way of working.
Action
Introduce a hypothesis backlog. The hypothesis backlog consists of ideas for experiments:
- What should we try?
- How long should we try it?
- How can we measure whether the hypothesis was proven or disproved?
The team members can add hypothesis any time during the Sprint.
During the retrospective, prioritize the hypothesis backlog first. Then start at the top and refine the experiment. Finally, decide whether to execute the experiment or not. Continue with the next hypothesis until the time-box is used or there are already enough experiments running.
The refinement of the experiments gives the whole team the opportunity to discuss the idea behind the hypothesis and enrich it with the thoughts of all team members. Maybe you can split big experiments into smaller experiments or experiments of a different flavor (e.g. try different things for the same problem).
In the next retrospective, check whether you could prove or disprove any of your running experiments.
What you gain
A backlog or road-map of things to try in the future.
Fewer discussions on the same topics in several retrospectives.
How to strengthen
If you have already enough running experiments then use a different retrospective format.
Combine all run experiments with an achievement wall.
Risks
Yet another backlog to maintain. Keep it small, simple, accessible and visual.
Please help me improve this idea by providing feedback.
More ideas at 101 ideas for agile teams
Many thanks to bbv Software Services for making this blog post possible.
