User Stories sind Hypothesen, keine Fakten!

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Sie nutzen doch sicherlich auch User Stories, um Anforderungen in Ihrer agilen Entwicklung festzuhalten. Halten Sie sich auch brav an die Satzschablone „Als [Rollenname] möchte ich [etwas mit dem Produkt tun], um [einen Mehrwert zu erhalten]“ oder gehören Sie eher zu den Leuten, die den Mehrwert schon mal weglassen, da er für alle Beteiligten ja selbstverständlich ist?

Keine Sorge, dies wird kein (direkter) Apell für den disziplinierten Umgang mit agilen Werkzeugen, auch wenn das Thema einen eigenen Blogartikel verdient hätte. Schreiben Sie Ihre Stories von uns aus doch wie Sie wollen, oder noch besser: schreiben Sie sie so, dass sie zu einer erfolgreichen Produktentwicklung beitragen. Und genau da liegt der Punkt, den so viele Anwender der Methode im Alltag vergessen.

Aber dazu kommen wir gleich. Zuerst eine kurze Auffrischung:
Vor dem „Als Käufer möchte ich eine Lieferadresse angeben, damit meine Einkäufe auch bei mir zu Hause ankommen“ und vor dem „User“ war die Story. Die Idee dahinter: Geschichten zu erzählen, um zu teilen, was ein Nutzer mit dem Produkt anstellen möchte und wozu eigentlich. Der „User“ kam erst später, als Zusatz zur „Story“, weil schlicht zu viele diesen aus den Augen verloren, in der Hektik der Arbeitswelt. Aus den Augen war er oder sie dann auch schnell aus dem Sinn und das Produkt schoss am Zielpublikum vorbei. Die Satzschablone folgte kurz danach, weil vor allem die Zielformulierung Einigen Schwierigkeiten bereitete. Dabei hat die Formulierung den immensen Vorteil, dass sie als einfache Checkliste dient. Die Fragen nach dem Wer, Was und Warum müssen beschrieben werden, so dass insbesondere der Verwendungszweck deutlicher herausgestellt wird. (unser Kollege Dr. Marcus Winteroll hat das vor einer Weile mal so treffend auf den Punkt gebracht: https://www.oose.de/blogpost/sind-funktionale-anforderungen-zwecklos/).

Wenn wir also die Geschichte vom Käufer erzählen, der eine Lieferadresse angeben möchte, dann ist das unsere persönliche Sicht der Dinge, nicht zwangsweise die Wahrheit und vor allem kein Fakt, sondern eine Hypothese. Wir meinen, er wäre glücklich/sein Problem wäre gelöst, wenn er das mit unserem Produkt könnte. Es ist unsere Experteninterpretation zur vorherrschenden Sachlage, nicht mehr, nicht weniger.
Wenn wir diese Geschichte dann dem Entwicklungsteam erzählen, wollen wir sogar, dass die Entwickler unsere Geschichte zu ihrer eigenen machen, sie auseinander nehmen, umschreiben und zu unserer Hypothese ein passendes Experiment aufsetzen, das Inkrement, welches wir am Ende der Iteration dann gemeinsam (mit dem Kunden) auswerten.

Probieren Sie es doch selbst einmal aus. Machen Sie Ihre Anforderungen diskutabel, formulieren Sie Ihre Stories als Hypothesen. In unserem Beispiel könnte das etwa wie folgt lauten: „Ich bin davon überzeugt, dass der Kunde seine Einkäufe zu sich nach Hause geliefert bekommen möchte und das können wir ihm am besten durch die freie Wahl der Lieferadresse ermöglichen.“ Sie werden überrascht sein, wie viel leichter es Ihren Kollegen auf einmal fällt Anforderungen nachzuvollziehen, mit Ihnen zusammen kritisch zu hinterfragen und zu gestalten, innovative Lösungsansätze zu erarbeiten und passende Testfälle zu finde.

Natürlich macht auch hier Übung den Meister und die nächste Gelegenheit dazu erhalten Sie in unserem Scrum Praxis Workshop am 28.08. in Hamburg. Alternativ schreiben Sie uns einfach eine E-Mail mit dem Stichwort „Hypothesen statt Fakten“ an info@oose.de oder Sie rufen uns an unter der +49 (40) 414250-0 und wir finden gemeinsam den passenden Weg diese und andere agile Praktiken gewinnbringen in Ihr Unternehmen zu integrieren.