Hypothesis-driven-development - es gibt nicht nur User Stories.

Ich glaube an die Vorteile von User Stories und würde dieses Format und das dazugehörige Mindset als „good practice“ für effektives Product Backlog Management nie entfallen lassen. Jedoch glaube ich auch an die Macht der Sprache und wie Formulierungen das Verhalten eines Teams beeinflussen können. Deshalb ist es mir wichtig die folgenden Erkenntnisse aus meinen Teams mit euch zu teilen.

Es wurde schon genug zum Thema „Gute User Stories“ geschrieben. Dieser Blogpost soll ein Anstoß dazu geben, das vorhandene Backlog zu überdenken und eine Ergänzung oder gar Alternative zu User Stories vorstellen: Hypothesis statements

Warum?

Eine User Story wird meistens wie eine beschlossene Sache, ein Fakt, eine Aussage behandelt – auch wenn das nicht unbedingt die Intention war. Der <Mensch> weiß, dass er etwas möchte um eines oder mehrere seiner Bedürfnisse zu befriedigen. Ich beobachte in der Praxis, dass wenn ein Team sein Backlog mit diesen Aussagen befüllt, es auf direktem Weg in die „Build Trap“ befördert wird:

„When companies measure their success on the amount of features  released rather than the customer needs those features fulfill, they are stuck in The Build Trap.“

– Melissa Perri („Escaping the Build Trap“)

Wir könnten nun meinen, dass durch den <Bedürfnis/Mehrwert> Teil einer User Story genau das verhindert werden soll. Doch zu 95 % in meinem Alltag ist diese Definition nur eine Annahme darüber, dass der Wunsch mit einer verbundenen Lösung einen gewissen Mehrwert in der Zukunft liefern wird. Dazu kommt, dass ich kaum ein Team getroffen habe, welches den <Bedürfnis/Mehrwert> Teil überhaupt verwendet hat und wenn doch eher aus „Zwang“ als aus Sinnhaftigkeit.

Anschließend müssen wir die Lösung (welche meist leider schon im Wunsch formuliert ist) erst vollumfänglich umsetzen, um zu validieren, dass der Mehrwert auch tatsächlich erzeugt worden ist. Auch das aktive Messen, ob der Mehrwert tatsächlich generiert worden ist, konnte ich bei kaum einem Kunden vorfinden.

Desweiteren würde ich gerne folgendes agile Prinzip hervorheben:

Simplicity – the art of maximizing the amount of work not done – is essential.

– Principles behind the Agile Manifesto

Wer sich mit dem Thema „Lean“ beschäftigt hat, für den wird dies nichts Neues sein. Insbesondere für jemanden, der sich auch in das Thema „Lean UX“ eingearbeitet hat. Es geht darum, den größten Mehrwert, mit dem geringsten Aufwand zu erzeugen (in Anlehnung an Pareto’s 80/20 Regel).

Die Implementierung des finalen Produktes ist die meist teuerste als auch aufwendigste Variante um eine Annahme zu validieren. Wir müssen erst durch einen kompletten Entwicklungszyklus laufen, um validieren zu können, ob eine Lösung den angestrebten Mehrwert erzeugt (und eventuell ob der angestrebte Mehrwert überhaupt richtig gewählt wurde – denn auch der Kunde weiß nicht immer gleich was für ein Bedürfnis er hat).

Meiner Erfahrung nach sind die meisten Unternehmen immer noch zu langsam darin, Annahmen zu validieren, Feedback einzuholen und somit das „richtige“ Produkt inkrementell zu entwicklen (Build, Measure, Learn). Dabei gibt es zig Wege, eine Annahme für einen Mehrwert zu validieren, welche leider aus Effizienzgründen meist hinten angestellt werden. Diese Alternativen zu fahren mag zu Anfang eventuell zeitintensiv sein – wobei es in Summe meist zeitintensiver ist, ein Feature vollumfänglich zu entwickeln und dann wieder auszubauen, weil es doch nicht verwendet wird bzw. den angestrebten Mehrwert nicht erzeugt hat.

Hier sind einige Alternativen hinzu vollumfänglichen Entwicklung eines Features:

– The Truth Curve (Giff Constable)

Nur: Wie fange ich an? Was gibt es für eine Alternative, die uns ermöglicht mehr in diesen reduzierten Aufwänden der Validierung zu denken? Wie kommen wir schnell zum „richtigen“ Produkt ohne unnötige Aufwände zu produzieren? Ich biete „Hypothesis statements“ als mögliche Antwort – eigentlich nichts Neues aus der Wissenschaft (aka. Experimente) und auch in der Praxis als „Hypothesis-driven-development“ bekannt – aber in meiner Erfahrung zu 90% nicht in Product Backlogs zu finden!

Hypothesis statements

Ein Hypothesis statement kann wie folgt formuliert werden:

– Lean UX Hypothesis Statement Template

Einige Vorteile von Hypothesis Statements gegenüber User Stories zusammen gefasst:

• Kreativität im Team: Sie fördern die Kreativität und Ownership des Teams durch die explizite Formulierung und Durchführung von Experimenten
• Mindset „Effektivität & Wert“: Sie bringen das Team direkt in das Mindset das richtige tun zu wollen vs. stumpfsinnig User Stories abzuarbeiten
• Validierung von Erfolg: Sie „zwingen“ dazu, sich darüber Gedanken zu machen wie wir das Ergebnis validieren – im besten Fall auch quantifiziert damit wir im Sinne der Unternehmensstrategie Folgeaktivitäten besser priorisieren können
• Schnellere Feedbackschleifen und Risikoreduzierung: Jedes Hypothesis Statement erzeugt eine Art „Minimun Viable Product (MVP)“ anhand dessen wir Annahmen validieren können – schneller als die Implementierung der vollumfänglichen Lösung.

Wann greifen Hypothesis statements am besten?

Ein weiterer Indikator dafür, ob ich User Stories oder Hypothesis statements einsetzen sollte, liefert das Cynefin Framework (siehe auch The Cynefin Framework).

Befinden wir uns mit Anforderungen im chaotischen Bereich, greifen Hypothesis statements am besten. Wenn man sich den komplexen Bereich als Skala vorstellt, können Hypothesis statements den größten Mehrwert am oberen Ende liefern, wenn es Richtung chaotisch geht (es also viel mehr Unbekannte als Bekannte gibt). Im unteren Bereich können tendenziell User Stories besser dienen, da hier der Großteil der offenen Annahmen hoffentlich bereits validiert sind.

Wie baue ich Hypothesis statements in meinen Teamalltag ein?

Auch zu dieser Frage gibt es schon diverse Antworten (How to implement Hypothesis-Driven Development). Hier möchte ich alternativ einige praktische Punkte aufzeigen, die ich in meinem Alltag mit meinen Teams verfolgt habe.

1. Erkundige dich nach einem UX Experten, der deinem Team hilft, kreative und organisierte Experimente durchführen zu können.
2. Gehe durch dein Backlog und entscheide bewusst, ob du User Stories in Hypothesis statements umwandeln möchtest
3. Bespreche in Refinement oder Planning Aktivitäten welche Implementierung ihr für <doing this> anstrebt und welche Experimente ihr mit dem geringsten Aufwand fahren könnt, um die Erreichung des angestrebten Mehrwert zu valideren (welches Experiment könnten wir innerhalb einer Woche durchführen,  5 Tagen, 2 Tagen, morgen…).
4. Plant das Hypothesis statement aktiv im Sprint ein (analog zu User Stories & Co.).
   • Ziehe „Dual Track Agile“ in Betracht falls Hypothesis statements eure Refinement Aktivitäten leiten sollen (unabhängig vom Planungs-Zyklus)
5. Nach erfolgreicher Durchführung der Experimente, entscheidet euch, ob ihr daraus eine oder mehrere Backlog Items (evtl. User Stories) erstellen möchtet – denn jetzt könnt ihr euch sicher sein, dass ihr das Geld investieren solltet um die „finale“ Lösung zu implementieren.

Im Alltag, verwenden wir Hypothesen ähnliche Formulierungen auch für technische Spikes, z.B. bei der Anbindung von Drittsystemen um schnell das Risiko zu minimieren, dass eine Schnittstelle nicht das liefert, was erwartet wurde bzw. die technische Umsetzbarkeit noch nicht gegeben ist wie gedacht (wir nehmen an, dass Schnittstelle <X> <Y> liefert. Wir validieren diese Annahme durch einen Prototyp mit einer Timebox von 2 Tagen. Wir wissen, dass die Annahme erfolgreich validiert wurde, wenn wir <Z> auf unserer Staging Umgebung anzeigen können.

Fazit

Mit gut geschriebenen User Stories und dem richtigen Mindset, lässt sich natürlich auch alles erreichen was Hypothesen anbieten. Das explizite Ausformulieren fördert allerdings das experimentelle, Wert orientierte Mindset, gerade für neue Teams, exponentiell. Auch Mischformen sind eine Möglichkeit – egal wie – es gibt immer günstigere und schnellere Wege um eine Annahme zu validieren. Fallt nicht in die „Build Trap“ – wie es so viele andere weiterhin tun.

Diesen Blog Beitrag möchte ich mit einer Hypothese als Fragestellung für den Leser beenden:

Glaubst du, dass <ein alternativer hypothesengetriebener Ansatz>, für <deine Teams>, <einen größeren Mehrwert/Impact> erzeugen kann?

Mein Vorschlag wäre, ein oder zwei Experimente durchzuführen, um genau das herauszufinden.