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.