Wie werden User Stories in Scrum richtig erstellt?

Ausarbeitung von User-Stories

User Stories werden von Anwendern, Product Ownern und anderen Stakeholdern erzählt. Diese Geschichten 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 schafft Werte

Ich bin nicht der Meinung, der <NUTZEN> Teil wäre optional. Das sehe ich anders als Andere. Würdest du Aufwand betreiben, 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.

Akzeptanzkriterien beschreiben aus Sicht der <ROLLE> , die Messpunkte. So wird geprüft, ob die Funktion erfolgreich umgesetzt ist. Bis hierher, ist für die User Story noch kein Requirements-Engineer, Business Analyst oder ähnliches involviert oder benötigt worden.

Wusstest du: User Stories 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).

Die neue User Story wird vom Product Owner im Backlog-Refinement, dem DEV-Team vorgestellt. Nach Mike Cohn und seiner CCC Definition:

  • Card,
  • Conversation,
  • Confirmation,

sind wir bei Card angekommen.

Die Story Card

Eine Story Card enthält auf der Vorderseite

  • das ausgefüllte User Story Template.
  • die Akzeptanzkriterien,
  • geschätzte Story Points (sieh auch: User Stories 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, dass Backlog sauber zu halten und User Stories am Tag des Verfalls auf weitere Notwendigkeit zu überprüfen.

Verwende kleinere User Story Cards

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 Stories teilen, ist wie Hamburger essen

Apropos Teilen. User Stories dürfen nur vertikal geteilt (geschnitten) werden.

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

Es ist wie beim 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 keine Fall schmeckt irgendetwas 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 Stories nicht zu nummerieren. Sehr leicht 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 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 Phantasie angewiesen nicht ihre Phantasie 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, das 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 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.

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“ akzeptierst du die Datenschutzbestimmungen und weisst, das du den Empfang von E-Mails jederzeit und in jeder E-Mail widerrufen kannst.