Agile 201 – User Stories

Mar 11 2023

Zweck von User Stories

User Stories sind eine praktische Möglichkeit, die Software in Teile aufzuteilen und zu beschreiben. Sie sind nützlich für die Priorisierung und Gespräche mit Stakeholdern.

User Stories sind eine praktische Möglichkeit, die Software in Teile aufzuteilen und zu beschreiben. Sie sind nützlich für die Priorisierung und Gespräche mit Stakeholdern. Der Begriff „Feature“ wird oft synonym mit User Stories verwendet, es ist jedoch wichtig zu verstehen, dass es sich bei User Stories nicht um detaillierte Softwareanforderungen handelt. User Stories dienen als Markierungen oder Titel von Softwarefunktionen und sind immer in der Sprache des Unternehmens verfasst. Sie werden verwendet, um auf ein bestimmtes Merkmal oder eine bestimmte Funktionalität des Softwaresystems zu verweisen.

User Stories-Formate

Es gibt verschiedene Formate zum Schreiben von User Stories. Am gebräuchlichsten ist das Format „Als [Benutzer] möchte ich [handeln], damit [ein Nutzen] entsteht“ :

"WHO? Was? Warum?" ist eine weitere praktische Möglichkeit, User Stories zu schreiben:

User Stories bestehen aus drei Teilen: dem Benutzer , der Aktion und dem Ziel .

Akzeptanzkriterium

Die Festlegung von Akzeptanzkriterien ist ein wichtiger Teil der Erstellung von User Stories. Akzeptanzkriterien legen die Bedingungen fest, die erfüllt sein müssen, damit die User Story als abgeschlossen und erfolgreich umgesetzt gilt. Akzeptanzkriterien werden verwendet, um sicherzustellen, dass das Entwicklungsteam und die Stakeholder ein gemeinsames Verständnis davon haben, was die User Story beinhaltet und was geliefert werden muss. Sie bieten auch eine Möglichkeit zu überprüfen, ob die User Story abgeschlossen wurde und die darin beschriebene Funktionalität wie vorgesehen funktioniert.

Akzeptanzkriterien sollten durch einen „binären Test“ überprüfbar sein, bei dem eine Frage, ob ein Akzeptanzkriterium erfüllt ist, mit „Ja“ oder „Nein“ beantwortet wird.

Akzeptanzkriterien können auch bequem in dem Format angegeben werden, das im verhaltensgesteuerten Design verwendet wird. Behavior-driven Design (BDD) ist eine Softwareentwicklungsmethodik, die sich auf die Definition und das Testen des Verhaltens von Softwaresystemen mithilfe von Klartextbeschreibungen des Systemverhaltens konzentriert. BDD baut auf den Prinzipien von Test-Driven Development (TDD) und Domain-Driven Design (DDD) auf und basiert auf der Idee, dass Softwaresysteme auf der Grundlage ihres Verhaltens und nicht auf der Grundlage ihrer Implementierungsdetails entworfen und getestet werden sollten.

User Stories aufteilen

Die Entscheidung, nach welchen Linien die User Stories aufgeteilt werden sollen, kann eine große Herausforderung sein. Es gibt jedoch hilfreiche Best Practices, die Sie befolgen sollten, z. B. Twenty Ways to Split User Stories . Welcher Ansatz auch immer gewählt wird, es ist wichtig sicherzustellen, dass jede User Story dennoch in der Lage ist, dem Endbenutzer einen Mehrwert zu bieten. Durch die Aufteilung von User Stories in kleinere, besser verwaltbare Teile können Entwicklungsteams sicherstellen, dass sie die Arbeit effektiver priorisieren und Risiken und Abhängigkeiten reduzieren können.

Die INVEST-Kriterien sind ein hilfreiches Akronym, das die Merkmale einer guten User Story definiert:

I steht für Independent, was bedeutet, dass jede User Story in sich abgeschlossen sein und unabhängig bearbeitet und getestet werden kann:
N steht für Negotiable, was bedeutet, dass User Stories nicht übermäßig präskriptiv sein sollten, sondern Raum für Diskussionen und verschiedene Arten der Implementierung der Story lassen sollten, um dem Benutzer den beabsichtigten Wert zu liefern.
V steht für Valuable, was bedeutet, dass jede User Story dem Endbenutzer oder Kunden einen Mehrwert bieten sollte.
E steht für Estimable, was bedeutet, dass jede User Story hinsichtlich ihres Aufwands bzw. ihrer Komplexität abschätzbar sein soll.
S steht für Small, was bedeutet, dass User Stories in kleine, überschaubare Teile zerlegt werden sollten.
T steht für Testable, was bedeutet, dass jede User Story getestet werden kann, um sicherzustellen, dass sie korrekt implementiert wurde.

Gute User Stories schreiben

Sehen wir uns einige Treiber und Hemmnisse beim Schreiben guter User Stories an. Das Erstellen von User Stories ist eine gemeinsame Anstrengung zwischen dem Product Owner, Stakeholdern und dem Entwicklungsteam. Eine gute Kommunikation, gute Arbeitsbeziehungen und eine vielfältige Teamzusammensetzung tragen dazu bei, bessere User Stories zu erstellen. Eine vielfältige Teamzusammensetzung trägt dazu bei, bessere User Stories zu schreiben, da die Teammitglieder verschiedene zusätzliche Perspektiven zur Wertschöpfung für die Benutzer bieten können.

Mangelnde Ausrichtung, fehlende Priorisierung von Geschäftszielen und fehlende Zeit für die Verfeinerung sind einige der Faktoren, die der Erstellung guter User Stories im Wege stehen. Der Produktmanager muss genügend Zeit in die Verfeinerung der User Stories investieren und sicherstellen, dass die Stakeholder die Vorteile und die Priorisierung der User Stories verstehen.

Es ist wichtig, dass sich der Produktmanager daran erinnert, dass die User Stories ein Gesprächsinstrument sind. Daher ist es wichtig, dass sich alle Teilnehmer über den Inhalt der Geschichten einig sind, was Zeit braucht, um dies zu erreichen.

Zusammenfassend lässt sich sagen, dass User Stories ein wesentlicher Aspekt der agilen Softwareentwicklungsmethodik sind. Es ist wichtig, die Investitionskriterien zu befolgen und ein geeignetes Aufteilungsmuster zu wählen. Das Erstellen von User Stories ist eine gemeinschaftliche Anstrengung, und eine gute Kommunikation und eine vielfältige Teamzusammensetzung können dabei helfen, bessere User Stories zu erstellen. Es ist außerdem wichtig, genügend Zeit in die Verfeinerung von User Stories zu investieren und sicherzustellen, dass die Stakeholder ihre Vorteile und Priorisierung verstehen.