- Wednesday, 08.01.25, 11:00 - 12:00 Uhr
- Remote per zoom call,
- Lukas Stratmann
13 Learnings der digitalen Produktpositionierung über User Stories
16. September 2014, 14:00 :: Allgemein
Autor: Matthias Gräf
Wir alle wissen, wie schwierig es sein kann Softwareprojekte zu realisieren. Kommunikation zwischen Entwicklern und kreativen Denkern ist nicht immer einfach. Hier ein paar Tipps, die euch in Zukunft helfen können.
Am 31. Juli fand Andreas Pihans Workshop „User Story Training“ im STARTPLATZ statt. Hier sind die wichtigsten Learnings aus spannenden drei Stunden! Am 23. September geht der Workshop hier im STARTPLATZ in die zweite Runde, also vergesst nicht euch eins der beliebten Tickets zu sichern!Konventionen brechen, Produkte validieren und Risiken minimieren
13 spannende Learnings haben wir nach 3 Stunden User Story Workshop mitgenommen. Erfahrt in diesem Artikel welche Fallstricke wir wie gelöst haben und wie wir schon im Vorfeld problematische Punkte ausmachen konnten…
Mit 19 Anmeldungen war das Interesse an einem scheinbaren Nischenthema sehr beachtlich. Also machte ich mich an die Vorbereitung des User Story Workshop. Meine erste Überlegung war ein theoretisches Feuerwerk abzubrennen, doch davon bin ich schnell wieder abgerückt. Also baute ich einen sehr praxisorientierten Workshop auf, was an den erleichterten Gesichtern der Teilnehmer anzusehen, letztendlich eine gute Wahl war. Nach einer kurzen Vorstellung und Einführung ging es auch schon direkt los.
Die Idee war es für eine Smartphone App namens StickyDo User Stories zu schreiben und anschließend einen priorisierten Produktbacklog aufzubauen.
Gesagt getan und so sah die übergreifende User Story aus:
Als Produktmanager
Will ich eine Smartphone App für Überraschungsaufgaben entwickeln lassen
So dass wir die Nutzer der App täglich mit spannenden und unerwarteten Aufgaben begeistern sowie über die Inhalte und Funktionen monetarisieren können.
Die Profis unter Euch erkennen gleich die Stolperfallen. Eine App – ja welche? iOS oder Android? Spannende Aufgaben – was ist damit gemeint? Die Nutzer begeistern und über Inhalte und Funktionen monetarisieren – wie haben wir das zu verstehen?
Aufgabe 1: Identifiziere alle User Stories für die neue App
Um den Einstieg in das Produkt zu erleichtern hatte ich ein paar Designs der App im Gepäck. Die Designs zeigten den groben Workflow der App und welche Funktionen zur Verfügung stehen sollten. Schnell war die Idee von StickyDo verstanden und aufgeteilt in drei Teams ging direkt los. Die erste Aufgabe war es alle User Stories und zwar diesmal aus Sicht des Nutzers zu identifizieren sowie zu formulieren. Dafür hatte jedes Team 45 Minuten Zeit. Sehr sportlich also…Nach den 45 Minuten hatte jedes Team im Schnitt 25 User Stories ermittelt und jede User Story auf eine Karte geschrieben. In einer kurzen Session stellten die Teams einen Auszug Ihrer wichtigsten User Stories, ihre Hindernisse und ihre ersten Learnings vor.
Learning Nr. 1 – Erstelle eine übergreifende User Story
Wichtig war es, dass es eine übergreifende User Story aus Sicht des Produktmanagers gab. Diese User Story sollte dabei so einfach wie möglich geschrieben sein und Raum für Agilität bieten. Eine übergreifende User Story hilft das Produkt zu verstehen, die Emotion aufzugreifen und um sich in die Thematik reinzudenken.
Learning Nr. 2 – Nicht reden sondern einfach machen
Nicht zu viel diskutieren und denken, sondern einfach machen
(in diesem Fall schreiben). Am Anfang wurde viel zu stark über den späteren Ausbau der App gesprochen, neue Ideen entwickelt anstatt sich auf die Grundfunktionen des Produktes zu beschränken und diese erst einmal zu in den Grundzügen zu beschreiben.
Learning Nr. 3 – Unterteilung der User Stories in Kategorien
2 von 3 Teams haben Ihre User Story gleich zu Beginn in Kategorien (Bspw. FrontEnd, BackEnd, Vermarktung, Monetarisierung etc.) unterteilt. Teilweise haben sich die Teams auch in diese Kategorien aufgeteilt und dafür die User Stories geschrieben. Das ist eine gute Hilfe um ein erstes Cluster zu bilden, weniger zu diskutieren und es verschafft am Ende einen guten Überblick.
Learning Nr. 4 – Die Pair Writing Methode
Gemeinsam eine User Story zu schreiben macht viel mehr Spaß als alleine und ist am Ende und gerade bei neuen Produktideen deutlich effektiver. Die Pair Writing Methode ist also ein gutes Instrument, um User Stories zu schreiben.
Learning Nr. 5 – Ein klares Zeitfenster setzen
Timeboxing ist hart aber es hilft! Setzt Euch ein klares Zeitfenster pro User Story. Maximal 3-5 Minuten sollten in der Regel ausreichen. Dauert es länger, dann ist das meist ein Indikator dafür das die User Story noch zu groß formuliert ist, weil man versucht alles in eine User Story „reinzupacken“. Besser ist es, wenn man am Ende 20 kleinere User Stories hat als 5 aufgeblähte User Stories.
Extra Tip: Weitere sehr gute Tools, um auf die User Stories für ein Produkt zu kommen, sind Interviews mit der potentiellen Zielgruppe, Review & Retrospektiven (Produktmanagement & Scrum Teams) sowie digitale Umfragen. Dafür braucht man zwar etwas mehr Zeit aber wenn man diese im Vorfeld einplant wird es sich definitiv lohnen!
Aufgabe 2: Dekliniere pro User Story alle Akzeptanzkriterien
Die nächste Aufgabe der Teams war es für jeweils eine User Story alle Akzeptanzkriterien zu definieren. Also, welche Kriterien müssen erfüllt werden damit die User Story nach der Entwicklung vom Produktmanager abgenommen werden kann. Um den Wissenstransfer unter den drei Teams zu fördern, wechselten jeweils 2 Mitglieder eines Teams in das nächste Team.
Als Arbeitsmaterial standen diesmal Flipcharts, Marker, Karten und Metaplanwände bereit. Jedes Team hatte für diese Aufgabe 30 Minuten Zeit und am Ende würden in einer weiteren Session erneut die Ergebnisse vorgestellt.
Was waren die Learnings aus dieser Session?
Learning Nr. 6 – Denkt aus Sicht des Nutzers
Wie würde der Nutzer die App benutzen und was erwartet er?
Dieser „Rollentausch“ hilft dabei sich stärker in die User Experience reinzuversetzen und kitzelt schon eine Menge Akzeptanzkriterien zu tage.
Learning Nr. 7 – Welche Testfälle fallen Euch ein?
Wie würde ein QA/Test Manager an die Sache ran gehen? QA/Test Manager haben eine stringente Vorgehensweise, oft getrennt nach FrontEnd, BackEnd, Plausibilitäten und Fehlermeldungen. Welche Testfälle fallen Euch ein?
Learning Nr. 8 – Welche technischen Rahmenbedingungen müssen bedacht werden?
Performance, Codequalität, Framework etc.
Was ist dem Entwickler wichtig?
Learning Nr. 9 – User Stories sind keine Fachspezifikationen!
Schaut nicht zu tief in die Akzeptanzkriterien. User Stories sind keine Fachspezifikationen, die 10 Seiten lang sein müssen. Es geht mehr darum Denkanstöße zu generieren. Insbesondere bei eingespielten Teams sieht man sehr oft das neben der eigentlichen User Story die Akzeptanzkriterien maximal eine DIN A4 Seite lang sind, wenn überhaupt.
Learning Nr. 10 – Welche Punkte sind anderen Zielgruppen wichtig?
Der angesprochene „Rollentausch“ hilft dabei sich in andere Zielgruppen reinzuversetzen. Ein guter Tip ist es sich die wichtigsten Zielgruppen einmal aufzuschreiben. Was ist der Vermarktung wichtig? Welche Punkte sind für den Vertrieb relevant? Wie erfolgt die Monetarisierung?
Extra Tip: Legt Euch einen Pool an Akzeptanzkriterien an, die einen wiederkehrenden Charakter haben. Diese gelten dann übergreifend für alle User Stories. Also ähnlich wie bei der DOD (Definition of Done) für Scrum Teams. Der Vorteil dabei ist, dass man sich bei der Definition der Akzeptanzkriterien für neue User Stories auf die „Exoten“ konzentriert.
Aufgabe 3: Priorisiere die User Stories nach Wichtigkeit
Nachdem die Teams die ersten beiden Aufgaben erfolgreich erledigt und dabei einige überraschende Learnings herauskamen, sah die dritte Aufgabe so aus: Priorisiere die User Stories nach Wichtigkeit und erstelle einen ersten Produktbacklog!
Die Fragestellung ist also, wie sieht unser MVP (Minimum Viable Product) aus, mit welchen minimalsten Funktionsset wollen wir mit der App an den Start gehen?
Viele von Euch werden es schon vermuten, dass dies keine leichte Aufgabe ist und ebenso das meiste Diskussionspotential bietet. So war es auch bei dieser Aufgabe. Die Teams hatten wiederum 45 Minuten Zeit diese Aufgabe zu erfüllen und am Ende wurde die „Roadmap“ vorgestellt.
Als Learning konnten wir folgende Punkte herausstellen:
Learning Nr. 11 – Die Kategorisierung im Vorfeld war ein guter Grundstein
Es stellte sich heraus, dass die Kategorisierung der User Stories gleich zu Beginn ein guter Grundstein für den Aufbau des Produktbacklogs war. Schnell konnten aus den einzelnen Kategorien die wichtigsten User Stories entnommen und in den zentralen Produktbacklog überführt werden.
Learning Nr. 12 – Priorisierung in zwei Schritte unterteilen
Ergänzend zum vorangegangenen Learning half es die Priorisierung in zwei Schritte zu unterteilen. Als erstes würden die User Stories aus den jeweiligen Kategorien priorisiert und anschließend wurde der gesamte Produktbacklog priorisiert. Durch diese Herangehensweise entsteht schnell ein deutliches Bild wie der Produktbacklog aussehen könnte.
Extra Tip: In der Praxis bietet es sich an, wenn man sich bei der Priorisierung des Produktbacklogs nicht einig wird, ein „Voting“ durchzuführen. D.h., jedes Teammitglied vergibt für die 5-10 wichtigsten User Stories jeweils einen Punkt. So entsteht eine Art Heatmap und man erkennt sehr schnell wo der gemeinsame Nenner liegt.
Learning Nr. 13 – Identifiziere eine User Story an der man sich orientieren kann
Sind die User Stories klar genug formuliert und sind bei der Priorisierung/Planung Entwickler mit im Team, dann ist es oft sehr hilfreich eine grobe Bewertung der User Stories vorzunehmen. D.h., es wird eine User Story identifiziert an der man sich gut orientieren kann und alle anderen User Stories werden an dieser „Referenzstory“ gemessen.
Andreas Pihans Fazit
Alles in allem war es ein super Workshop mit hochmotivierten Teilnehmern und es hat eine Menge Spaß gemacht. User Stories für neue oder bestehende Produkte zu identifizieren, zu schreiben und zu priorisieren ist reine „Übungssache“ und der Workshop hat den Teilnehmern hoffentlich einige Sorgenfalten genommen.
Hat man einmal das entsprechende Format und für das Team den geeigneten Prozess gefunden, dann ist es sehr leicht schnell und pragmatische valide User Stories zu erstellen sowie einen belastbaren Produktbacklog aufzubauen.
Was sind Eure Erfahrungswerte beim schreiben von User Stories? Teilt diese und weitere Anregungen oder Einsatzmöglichkeiten gerne in den Kommentaren mit…
Kommende Events
- Thursday, 09.01.25, 09:30 - 11:30 Uhr
- STARTPLATZ, Speditionstraße 15A, 40221 Düsseldorf
- Friday, 10.01.25, 12:00 - 13:00 Uhr
- Remote per zoom call,
- Lorenz Gräf
