So kannst du richtig gute User Stories erstellen

User Stories erstellen

Anwendern, Product Owner und weitere Stakeholder mĂŒssen wissen, wie man eine User-Story erstellt. Diese User Storys sind ĂŒblicherweise nur einen Satz lang und basieren hĂ€ufig auf dem Template von Rachel Davies, die seinerzeit bei der englischen Firma Connextra arbeitete:

“Als <ROLLE> möchte ich <FUNKTION> damit <NUTZEN>”

Am Anfang einer Story, steht dieser eine Satz, der eine fĂŒr den Anwender nĂŒtzliche Funktion enthĂ€lt.

Der Nutzen, gut erstellter User Stories, schafft Werte

Ich bin nicht ĂŒberzeugt, der <NUTZEN> Teil wĂ€re optional. Das sehe ich anders als Andere. WĂŒrdest du Aufwand betreiben und eine User-Story erstellen, wenn daraus kein Nutzen entsteht? Ich nicht!

Wenn eine Funktion niemandem nĂŒtzt, schafft sie keinen Wert. Bei der agilen Produktentwicklung sind alle Beteiligten bestrebt ,den grĂ¶ĂŸtmöglichen Wert zu schaffen. Das funktioniert nur, wenn die Einzelteile des Produktes einen Nutzen bringen.

Das "Agile CatchUp" Briefing

E-Mail eintragen und "Abonnieren" klicken. Fertig!

Mit dem Briefing erhĂ€ltst du Tipps & Tricks zu Agile und Informationen rund um die Angebote von Frank Schatz. Mit Klick auf „Abonnieren“ akzeotierst du die Datenschutzbestimmungen und weisst, das du den Empfang von E-Mails jederzeit und in jeder E-Mail widerrufen kannst.

Wie werden User Storys erstellt

Akzeptanzkriterien beschreiben aus Sicht der <ROLLE> , die Messpunkte. So wird geprĂŒft, ob die Funktion erfolgreich umgesetzt ist. Bisher ist fĂŒr das Erstellen der User Story, kein Requirements-Engineer, Business Analyst oder Ă€hnliches involviert oder benötigt worden.

Wusstest du: User Storys wurden das erste Mal 1995 von Ward Cunningham beschrieben. Damals wurden die User Storys noch “Implied Requirements” genannt. Zur Story, also einer Geschichte, wurden die Implied Requirements erst spĂ€ter. Kent Beck beschreibt diese Geschichten erstmals in seinem Buch “Extreme Programming, Embrace changed”, vom Addison-Wesley Verlag (1999).

Eine neu erstellte User Story wird vom Product Owner im Backlog-Refinement, dem DEV-Team vorgestellt. Nach Ron Jeffries und seiner 3C Definition:

  • Card,
  • Conversation,
  • Confirmation,

sind wir bei Card angekommen.

Die richtige Story Card, wenn du User Storys erstellst

Wenn du eine User-Story erstellst, dann kommt auf die Vorderseite der Story Card:

  • der ausgefĂŒllte User Story Template.
  • die Akzeptanzkriterien,
  • geschĂ€tzte Story Points (sieh auch: User Storys schĂ€tzen oder nicht),
  • geschĂ€tzter Business Value,
  • ein Verfallsdatum

und auf der RĂŒckseite einige AnsĂ€tze fĂŒr das Testvorgehen.

Tools, wie zum Beispiel Atlassian Jira, lassen es zu, fast unbegrenzt Text auf den User Story “Karten” zu erfassen. Ich empfehle dir den Text so lang wie nĂŒtzlich und dann etwas kĂŒrzer zu schreiben.

Das Verfallsdatum hilft, das Backlog sauber zu halten und User Storys am Tag des Verfalls auf weitere Notwendigkeit zu ĂŒberprĂŒfen.

User Story auf  einer kleinen User-Story Card erstellen

Mary Poppendieck, Autorin von “Lean Software Development” hat gesagt:

“Wenn deine User Story nicht auf eine Karteikarte passt, dann nimm eine kleinere Karteikarte.”

Diese Aufforderung richtet sich an die Verfasser von User Storys. Bitte drĂŒcke dich prĂ€zise aus und halte dich an das Wesentliche. Passt die User Story dennoch nicht auf eine Karte, dann ist die User Storys zu groß und muss geteilt werden.

User Storys teilen, ist wie Hamburger essen

Apropos Teilen. User Storys dĂŒrfen nur vertikal geteilt (geschnitten) werden.

Andernfalls entstehen vielschichtige Probleme, die sich kaum kontrollieren, geschweige denn lösen lassen.

Es ist wie das Verspeisen eines saftigen Burgers. Wenn du so einen Burger horizontal in seine Zutaten trennst, bekommst du ein pappiges Brötchen, geschmackloses Hackfleisch, eine merkwĂŒrdig schmeckende Gurke usw.. Es ist alles andere als lecker und auf keinen Fall schmeckt etwas nach leckerem Burger.

Vertikal geschnitten oder abgebissen, erhĂ€ltst du die gewĂŒnschte Geschmacksexplosion. Die Kombination der Bestandteile macht den Geschmack.

Kein User Story Anschluss unter dieser Nummer

Im Übrigen empfehle ich, User Storys nicht zu nummerieren. Schnell werden die Storys unpersönlich und “nicht eingeweihte” wissen nicht ĂŒber was gesprochen wird. Es ist informativer, wenn anstelle von “Die 312 ist done”, “Das Login ist done” gesagt wird.

Von der erstellten User Story Card zur Konversation

FĂŒr eine User-Story ist es essenziell, dass die Details gemeinsam mit dem Dev-Team ausgearbeitet werden. Das ist das zweite “C” – Conversation.

Das Dev-Team stellt VerstĂ€ndnisfragen zu der Story und fĂŒgt weitere Details hinzu. Diese Details können:

  • Flowcharts
  • Scribbles
  • UI-Wireframes
  • Testideen

usw. sein.

Erlaubt ist alles, was notwendig ist, um gemeinsames VerstÀndnis bei den Beteiligten herzustellen und Interpretationsfehler von Prosa zu vermeiden.

Geteilte Dokumente sind kein geteiltes VerstÀndnis

Diese Kommunikation ĂŒber eine Story, hat laut Jeff Patton, Autor von “User Story Mapping”, einen weiteren wichtigen Aspekt. Die an der Kommunikation Beteiligten, erinnern sich an die Diskussionen und Ergebnisse und sind nicht auf ihre individuelle Fantasie angewiesen, nicht ihre Fantasie zu strapazieren, wie es beim Lesen eines Prosa-Dokuments, mit all seinen Interpretations-Fallen, notwendig wĂ€re.

InterdisziplinÀr soll es sein

Diese iterative Detaillierung einer User-Story ist der eigentliche Requirements Engineering Teil, welcher vom Scrum-Team geleistet wird. Um diese Leistung zu bringen, können im Dev-Team Business-Analysten, UX-Designer, Requirement-Spezialisten, Architekten und viele andere Rollen vertreten sein.

Anmerkung: In der Softwareentwicklung ist es gĂ€ngige Praxis, die Dev-Teams ĂŒberwiegend mit Programmierern und Testern zu besetzen. Dennoch sollten wĂ€hrend des Refinements und auch im Planning, die fehlenden Expertisen erreichbar sein.

Noch mehr Details und die Definition of Ready

Das Refinement ist der geeignete Zeitpunkt, die Kriterien der Definition of Ready zu erfĂŒllen.

In den zyklischen Refinements wird sichergestellt, dass die User Story ausreichend mit Details angereichert wird. Dadurch wird die Umsetzung durch das Dev-Team möglich. Andererseits enthĂ€lt die User Story so wenig Details, dass sie noch Raum fĂŒr kreative Entwicklung im Dev-Team zulĂ€sst.

Das dritte C vereint die Beteiligten

Das dritte “C” ist die Confirmation. Die User Story ist von allen verstanden und weist einen ausreichenden Detailgrad auf, der eine Umsetzung innerhalb eines Sprints ermöglicht. So eine User-Story ist fĂŒr das Sprint Planning qualifiziert.

Was geschieht, wenn eine User-Story nicht “confirmed” wird? Dann werden die Punkte ĂŒber die keine Einigkeit herrscht genauer betrachtet.

Fazit

Ich halte diese Vorgehensweise beim Erstellen einer User-Story fĂŒr essenziell.

Grobe VerstĂ¶ĂŸe enden oft in Projekten, die mit viel Stress, MissverstĂ€ndnissen und schier endlosen Diskussionen qualitativ minderwertigen Outcome zu ĂŒberhöhten Kosten liefern.

Argumente wie zum Beispiel: “DafĂŒr haben wir keine Zeit.” wird in der Regel von den Personen gefĂŒhrt, denen das agile Vorgehen noch unverstĂ€ndlich ist. In diesem Fall sind Scrum Master oder Agile Coaches gefordert, Abhilfe zu schaffen.

Ich wĂŒnsche dir eine stressfreie Zeit.
Frank

Frank Schatz

Frank Schatz

Als Trainer, Mentor und Coach ist Frank Schatz vielleicht einer der gefragtesten T-Shaped Agilisten im deutschsprachigen Raum. Er ist geprĂŒfter SachverstĂ€ndiger fĂŒr agiles Projektmanagement und seit ĂŒber 25 Jahren IT-Unternehmer, Agile Work Experte und Certified Instructor. Frank Schatz, damit es agil wird.

Agile Work

Die Agile Transformation

Agiles Mentoring