agileno.

Bessere User Stories schreiben

User Stories schreiben
Inhalt

Anwendern, Product Owner und weitere Stakeholder mĂŒssen wissen, wie man User Stories schreiben kann. 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.

Gute User Stories schreiben 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.

So kannst du User Stories schreiben

Akzeptanzkriterien beschreiben aus Sicht der <ROLLE> , die Messpunkte. So wird geprĂŒft, ob die Funktion erfolgreich umgesetzt ist. Bisher ist fĂŒr das User Stories schreiben, 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 Stories schreiben willst

Wenn du User Stories schreiben willst, dann kommt auf die Vorderseite der Story Card:

  • der ausgefĂŒllte User Story Template.
  • die Akzeptanzkriterien,
  • geschĂ€tzte Story Points (siehe auch: Story Points schĂ€tzen),
  • 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.

Auf  einer kleinen User-Story Card, User Stories schreiben

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 diejenigen die User Stories schreiben. 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.

Vom User Stories schreiben direkt 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 User Stories schreiben fĂŒr essentiell.

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.

P.S. Wenn du das professionelle schreiben von User Stories lernen möchtest, schau mal in Das User Story Essential Training fĂŒr Product Owner.

Teilen:

11 geniale Tipps fĂŒr

Product Owner

Product Owner Tipps

Lese unser fast tÀgliches Agile Briefing und wir schenken dir das E-Book

„11 geniale Tipps fĂŒr

Product Owner“

Du wirst damit Teil unserer exklusiven E-Mail-Liste und wir schenken dir ein E-Book. Abmeldung jederzeit möglich.

Auch interessant:

Frank Schatz

Frank Schatz ist der Experte in agilen Methoden und lehrt so verstÀndlich wie kein Zweiter, behaupten einige seiner Kunden.

Er ist ACI, MCP, SMA, PAL, SPF zertifiziert und geprĂŒfter SachverstĂ€ndiger. Er hat das Real  Agile© System fĂŒr stressfreie agile Transformationen entwickelt.

dgusv-siegel
User-Story-Professional-Badge-2k
professional-agile-leadership-i-pal-i
CertiProf-Remote-Work_100x
psfs-badge
gepr-sv-siegel-email

ISO-17024

Unsere Multiple-Choice Tests und Quizze werden an die entsprechenden Level der Anforderungen angepasst. Wir verwenden eine adaptierte Taxonomie nach Bloom. Daher basieren die Fragen auf sechs verschiedenen Fragetypen fĂŒr den beruflichen Bereich: Erinnern, Verstehen, Anwenden, Analysieren, Evaluieren, Kreieren

Erhalte jetzt unsere Checklisten

FĂŒlle das Formular aus und wir schicken dir die Checklisten zum Download zu. Ausserdem nehmen wir dich in unseren Agile Briefing Verteiler auf. Du kannst dich jedoch jederzeit wieder austragen.

Stopp ....

Erhalte 11 Nuggets fĂŒr
noch mehr AgilitÀt

So werden du und dein Team agiler – mit weniger Aufwand.

Du wirst damit Teil der exklusiven E-Mail Liste und erhÀltst Gratis ein E-Book.
Abmeldung jederzeit möglich.

11 Agile Nuggets