datenwerks Lieblingsmethoden: So habe ich das nicht gemeint!

Widersprüchliche Wünsche an ein Produkt, missverständliche Messages zwischen Auftrag und Umsetzung, Chaos. Wir stellen euch heute User Stories vor – eine Methode, um gemeinsame Bilder von Produkten zu entwickeln, lange vor dem Chaos.

Verstehen wir das gleiche?

Wenn ein Produkt fertig ist, passieren oft mehrere Dinge gleichzeitig: Ich als Kundin kann mir vorstellen, wie alles tatsächlich aussieht UND ich erkenne auf einen Blick, ob ich es will (oder doch eigentlich nicht?). Für all diese Erkenntnisse ist es dann aber schon reichlich spät. Wenn dann auch noch Dialoge wie der folgende entstehen, hat irgendwer irgendwo zwar zugehört aber vielleicht doch etwas anderes verstanden:

„Ich habe das aber ganz anders gemeint!“
„Sie sagten doch, dass es genau so sein sollte!“
„Das Produkt passt aber überhaupt nicht zu dem, was ich wollte!“.

Ein großartiges Beispiel dafür, was passieren kann, wenn alle vom gleichen reden aber ganz andere Bilder im Kopf haben sind Cakewrecks  – misslungene Torten.

Foto Kuchen mit Aufschrift

Ich wollte eine einfache Torte mit „alles Gute“ in lila.

Das ist nicht gut gelaufen. Das geht besser!

User Stories: Es geht um das „Warum?“

Schon im Entstehungs- und Produktionsprozess müssen alle Beteiligten ein gemeinsames Verständnis erreichen und das heißt: das gleiche Bild haben. Von Anfang an! Daher arbeiten wir im datenwerk mit der agilen Methode Scrum, zu der User Stories gehören: Kurze, knappe Geschichten mit fixem Aufbau. Wie zum Beispiel:

Ich als Organisatorin des Geburtstagsfests (wer?)
will eine für das Fest passende Torte bestellen (was?)
weil ich dem Geburtstagskind eine Freude machen will (warum?)
(ein fiktives Beispiel)

Klingt banal? Gut so. Je einfacher die Stories sind, desto leichter ist es, ein gemeinsames Bild zu entwickeln.

Das fixe Format von „Wer? Was? Warum?“ hilft dabei, konkret und ergebnisorientiert zu sein. Vor allem die Frage nach dem „Warum?“ ist dabei der Schlüssel zum Erfolg. Warum? Weil man durch das Beantworten herausfindet, was man wirklich will. Das „Wie?“ ist eine wichtige Ergänzung zur User Story, die technische Ableitung.

KundInnen wachsen durch die agile Umsetzung, zu der User Stories gehören, mit ihrem Produkt mit, sie bleiben nahe am Geschehen. Sie lernen ihr Produkt viel besser kennen und lieben <3 !

Der Weg zu User Stories

Input

Input für User Stories sind Zielgruppen, Werteversprechen und erste Wünsche. Wir beginnen, eine grobe Vorstellung von dem zu entwickeln, was und wer der Kunde/die Kundin in Wirklichkeit ist, was sie/er will und für wen. Das erarbeiten wir gemeinsam in Workshops – mit unseren Lieblingsmethoden, die wir euch größtenteils schon vorgestellt haben: Personas, Business Model Generation, Value Proposition Canvas.
Das gießen wir in User Stories. Wir schreiben zum Beispiel auf Post-its die wichtigsten Rollen, die sich aus den Zielgruppen herauskristallisieren (wer?). Zugeordnet zu den Rollen kommen die Wünsche (was?) und die Begründungen (warum?).

Foto Barbara erstellt User Stories und schreibt auf Post Its

User Stories schreiben heißt auch: viele Post-Its füllen und sortieren.

Dialog

Wenn wir die User Stories geschrieben haben, gleichen wir sie mit unseren KundInnen ab und ergänzen sie. Haben wir alles so verstanden wie unsere KundInnen? Haben wir ein gemeinsames Bild? User Stories – im Idealfall in Kombination mit Scribbles – sind großartig, um in Dialog zu treten.

Technische Ableitung

In dieser Phase kümmern wir uns auch um das „Wie?“, das heißt, wir besprechen die User Stories mit dem technischen Team. Nur mit einer technischen Ableitung der User Stories kann es eine zielführende Umsetzung geben. Ohne technische Ableitung steht man vor unsteuerbaren Ergebnissen.

Das können User Stories

  • Sie erzählen ein Ziel aus verschiedenen Blickwinkeln,
  • mit verschiedenen Bedürfnissen und
  • mit messbaren Veränderungen.

Was ist so schön an User Stories?

User Stories helfen, Missverständnisse frühzeitig zu erkennen und Lösungen zu finden. Die Antworten auf das „Warum?“ und die daraus resultierenden Ableitungen verhindern, dass zum Beispiel unnötige Features umgesetzt werden, die in Wirklichkeit niemand mehr will oder braucht. Das spart Zeit und Geld.

Was passiert mit den User Stories?

Was wir weiter mit den User Stories machen, erzählen wir euch den nächsten Methoden-Blogposts. Zusammengefasst sind die nächsten Schritte: Wir bewerten jede User Story, bündeln sie, erstellen eine Story Map und teilen Sprints ein.

Buchempfehlung: User Story Mapping

Ein großartiges Buch in diesem Zusammenhang, das hilft in die Welt der User Stories und Story Maps einzutauchen ist „User Story Mapping“ von Jeff Patton und Peter Economy.

4 Antworten

  1. 16. September 2016

    […] der Kuchen gebacken ist und wir wissen, warum – dann fangen wir an zu spielen. Heute stellen wir euch […]

  2. 6. Oktober 2016

    […] einen Cross-Browser Test durch? Was erwartet der Kunde von uns und wie erstelle ich dementsprechend User Stories? Wie wird der Aufwand dieser User Stories geschätzt? Wie verfasse ich einen Bericht für einen […]

  3. 7. Oktober 2016

    […] dabei, den Nutzen von Zielen sowie (Nicht-)Ziele zu definieren. Denken wir z.B. daran, wie User Stories aufgebaut sind: Sie enthalten die Antworten auf folgende Fragen: wer, was und warum. Viele Wünsche […]

  4. 18. Oktober 2017

    […] der agilen Software-Entwicklung, die wir bereits vorgestellt haben: Neben der Definition von User Stories, um ein gemeinsames Verständnis des Ziels zu haben, geht es darum, die Komplexität jeder […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Webseite verwendet Cookies. Mit der Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Mehr Informationen zu Cookies.
Ich habe den Hinweis gelesen.
x