7. Break down hypotheses
You may have a mix of hypotheses at this point: Some call for building or prototyping software, and some may call for other actions that are not software-related. It’s important to break all of your hypotheses down into more specific, actionable sub-hypotheses that can be tracked in your project, but you may decide to separate your non software-related hypotheses out and track them separately.
For example, this broad hypothesis:
“We believe that building a website will result in better citizen engagement with our program. We’ll know we’re right when we receive more contacts from citizens.”
Might break down to:
“We believe that creating a way for citizens to easily contact our bureau from the homepage of our website will result in better citizen engagement. We’ll know we’re right when our daily contact volume goes up at least 10 percent.”
Broad hypotheses should be broken down enough so that individual team members have a good starting point for generating their own specific solution ideas, but general enough that it isn’t too prescriptive. For example:
Good: “A way for constituents to easily contact their senators.”
Not good (too prescriptive): “A text input field with a button people can click that sends their message to their senator.”
Your turn: Break your hypotheses down into more specific sub-hypotheses. We recommend bringing your newly-created sub-hypotheses into a new Trello or other story-tracking board as cards in a “story candidates” list (see example below). Keep your broad hypotheses somewhere else where the team can refer back to them (for example in this document or another project management tool).
Example of Trello board backlog labeling
|Abbreviated story description on card front||Full hypothesis on the card back|