Scrum and Kanban: How to become more Hypothesis-Driven

The Starting Point

Starting to implement a more hypothesis-driven approach often starts from a Scrum or Kanban situation. Scrum, Kanban, and everything in between have been the industry norm for maybe the last 10 years. If you're running one of these processes, and you're curious to iterate towards a more hypothesis-based approach, this is the guide for you.

Meetings

Practicing Scrum or Kanban comes with a certain set of meetings and ceremonies. These are generally aimed at having the task planning match actual task execution. Only the most important tasks are included in this process.

These meetings build the formal guideline. Within these, we can take small steps to move from focusing on output to appreciating outcome. For a full 93-day quarter (60 working days), your meeting cadence might look like this:

Transitioning Culture

In practice, processes using Scrum or Kanban often still focus on the "what?" - the output rather than the outcome. In the following sections we're going to lay out how to ask questions and how to set values, which will help move meeting culture from applauding activity to celebrating insights.

A key challenge here is to first identify the underlying assumptions. The what? often takes most of the focus, while the why? remains vague and hidden. In order to identify learnings, it's first important to identify the underlying assumptions behind what's being attempted.

Daily Standup

Shift the focus from task updates to signals:

• Surface roadblocks or customer feedback that contradict the plan.
• Share prototyping learnings that challenge assumptions.
• Highlight metric shifts.

The daily becomes less of a status report and more of a signal scan. A conversation with a customer that contradicts an underlying assumption, a prototype result that surprised the team, or a KPI that ticked the right way — these are the inputs that feed into hypothesis iterations in Theso. When the team values evidence-driven decisions and acts on signals early, turnarounds happen faster and course corrections carry more weight. Recognizing and amplifying these signals is the engine that shifts a team toward hypothesis-driven work.

Sprint Planning

As bigger items (Epics or big Stories) are about to be started, what is the expected impact of the given piece of work, once completed? Often, this remains unsaid — implied at best, or simply wished for. Here it helps to be explicit, and to write down these assumptions. Is it more customers? Longer or more frequent visits? More revenue? And in which ballpark?

Besides being more clear about the assumed outcome, most teams will run into another issue: lack of metrics. But this can be improved. Often simple low-hanging fruits in terms of monitoring exist, which can easily get management buy-in. Having tools to gain more insights about the customer is crucial to see whether bets are actually paying off.

Quarterly Review

When looking back at a quarter, as the achieved tasks / projects are celebrated and tied into further plans, have the bets paid off?

• Did the achieved output lead to the desired outcome? Does the revamped website show increased performance metrics?
• Did something pan out just as expected? Has enriching the docs lead to less customer support calls?
• Did we learn something we didn't expect? Are customers using the new API key management feature, or does the actual workflow still lead back to support?

Quarterly Planning

When sharing information about bigger upcoming roadmap items, we can shift focus on learnings, assumptions and the competitive edge:

• What unique business insight can we gain about out customers?
• What will we learn?
• What do we need to learn as a company to avoid unsolicited effort?
• What is our big question that needs answering to ensure our survival?
• What are our sure bets which still have underlying assumptions which can be verified?