Vorbereitung von User Stories

Eine User Story beschreibt, wie ein Endbenutzer eine Anwendung verwendet, um ein bestimmtes Ergebnis zu erzielen. Es handelt sich also um eine Methode, wie Geschäftsanforderungen in einem einfachen und klaren Format dokumentiert werden, das den Menschen in den Mittelpunkt rückt. Eine User Story stellt die kleinste zu entwickelnde Arbeitseinheit innerhalb der Anwendung dar.  

Der Hauptzweck von User Stories als Projektartefakte besteht darin, dem Entwicklerteam einen Überblick (innerhalb des Projekt-Backlogs) über alle Features zu geben, die sie für den Kunden erstellen und implementieren müssen. User Stories beschreiben, was benötigt wird, damit Features zur Zufriedenheit des Product Owner und letztlich des geschäftlichen Endbenutzers entworfen werden können. Ein Team erstellt eine User Story unter Zuhilfenahme seines kollektiven Wissens und Erfahrungsschatzes. 

Zu den wichtigsten Merkmalen einer User Story zählen:

• Sie stellt den Menschen in den Mittelpunkt.
• Sie ist leicht verständlich.
• Sie spiegelt klar den Geschäftswert wider, den der Kunde erhält.
• Sie kann getestet werden.

Zu Beginn dokumentieren Sie zwei wichtige Elemente in einer User Story, die eine klare Übersicht dessen schaffen, was entwickelt werden soll und welche Kriterien erfüllt sein müssen, damit die User Story als fertig eingestuft werden kann.   

Diese zwei Elemente sind:

• Beschreibung der User Story
• Akzeptanzkriterien 

Darüber hinaus fügen Sie jeder User Story optionale Elemente hinzu, um die Anforderungsdetails durch Anhänge und technische Hinweise zu verdeutlichen. 

Alle Stories haben eine Größe und einen Status, um die Verwaltung der User Stories zu erleichtern. Diese Angaben aktualisieren Sie während des Lebenszyklus der User Story von der ersten Version bis hin zu ihrer Fertigstellung.

Die Beschreibung der User Story dient dazu, die Geschäftsanforderungen des Kunden zusammenzufassen. Mithilfe der Beschreibung der User Story wird genau festgehalten, wer das Feature oder die Funktion benötigt, was benötigt wird und warum es benötigt wird. Die Beschreibung sollte kurz und bündig sein, leicht verständliche Businesssprache verwenden und den geschäftlichen Nutzen klar benennen.  

Die typische Formulierung einer User Story folgt einem einfachen Satzformat:

• Als… [Wer? – Benutzer einfügen]  
• möchte ich… [Was? – gewünschte Handlung einfügen]    
• damit… [Warum? – geschäftlichen Nutzen einfügen]

Die sorgfältige Vorbereitung und Besprechung der User Stories ist extrem wichtig. Dieses kollektive Verständnis kann nur im gemeinsamen Dialog gewonnen werden. Widerstehen Sie der Versuchung, das kollektive Verständnis in eine komplexe Dokumentation zu übersetzen. Konzentrieren Sie sich auf die Kernaussage der User Story und ergänzen Sie die Details durch Anhänge.

Im folgenden Beispiel wurde die Beschreibung aus einer Businessperspektive formuliert, die den Benutzer, den Bedarf und den geschäftlichen Nutzen der Implementierung der User Story klar benennt. Die Beschreibung ist außerdem kurz gehalten.

Die Akzeptanzkriterien präzisieren die User Story. Dadurch können Entwickler nachvollziehen, was die Anwendung leisten soll, und Tester verstehen, was getestet werden soll. Der Product Owner muss die von der User Story erwartete geschäftliche Funktionalität definieren und die Akzeptanzkriterien genehmigen. Die Akzeptanzkriterien für User Stories sind in klarer, eindeutiger Sprache verfasst, die von geschäftlichen und nicht-technischen Teammitgliedern leicht verstanden wird. 

Bei der Formulierung der Akzeptanzkriterien kommt es auf das gewünschte Ergebnis an, nicht auf technische Anweisungen an das Entwicklerteam. Die Kriterien sind bewusst verhandelbar gehalten und bieten dem Entwicklerteam so die Möglichkeit, gemeinsam mit dem Businessteam an der Lösung zu arbeiten. Akzeptanzkriterien sind zwar verhandelbar, müssen aber auch spezifisch genug sein, um sie testen zu können. 

Im folgenden Beispiel werden die Akzeptanzkriterien als spezifische und testbare Ergebnisse formuliert.

Die beispielhafte User Story veranschaulicht einen Ansatz zur Formulierung Ihrer Akzeptanzkriterien, bei dem klare Aussagen getroffen werden. Es gibt aber eine Vielzahl weiterer Stile für die Dokumentation von Akzeptanzkriterien, z. B. die Nutzung von szenariobasierten Kriterien. Ihr Team kann beispielsweise den „Given, When, Then“-Ansatz verwenden, der wie folgt formatiert ist:

• Given…{pre-condition}: Beispiel: „Wenn ein Premium-Mitglied Anspruch auf ein kostenloses Angebot hat, …“
• When…{something is done}: – Beispiel: „... sie haben ihre bevorzugten Angebotskategorien ausgewählt und den Registrierungsprozess abgeschlossen ...“
• Then…{expected result} Beispiel: „... wird das System das Mitglied automatisch zu den ausgewählten kommenden Angeboten hinzufügen.“

Zu Beginn des Projekts legt Ihr Team fest, was unter „Definition of Ready“ (DoR) zu verstehen ist. Das Team einigt sich in der Prepare-Phase auf die DoR, damit es eine einheitliche Basis für die Qualitätsprüfung der User Stories gibt. Bei jedem Projekt wird diese Vereinbarung mit den relevanten geschäftlichen und technischen Beteiligten im Team getroffen. Die DoR führt Kriterien auf, die erfüllt werden müssen, bevor eine User Story in die Build-Phase überführt werden kann. Sobald Ihre User Story gemäß der DoR fertig ist, können Sie die Story als für die Sprintplanung geeignet markieren. 

Typischerweise besteht die DoR aus einer Checkliste mit Kriterien. Die Kriterien definieren den Inhalt, der in der Story vorhanden sein muss, alle Überprüfungsprozesse oder Abnahmen, die stattgefunden haben müssen, sowie alle Artefakte, die gesammelt oder angehängt werden müssen. Die folgende Tabelle zeigt eine User Story mit 12 Beispielkriterien, die zu erfüllen sind.

Eine vordefinierte DoR stellt sicher, dass sich alle Teammitglieder über die Mindestanforderungen an eine User Story im Klaren sind. Damit wird bestätigt, dass alle User Stories, die in einem Sprint platziert sind, einer Qualitätsprüfung unterzogen wurden und innerhalb des Sprints erfolgreich geliefert werden können.

Durch die Optimierung einer User Story soll sichergestellt werden, dass Ihr Team die Intention und den Umfang vollständig versteht. Die Optimierung der Story ist ein iterativer Prozess, der den Inhalt der Story so reifen lässt, dass er der DoR entspricht. Der Bereitstellungsansatz von Pega Express fördert die direkte Erfassung von Zielen (Directly Capture Objectives, DCO), um die Zusammenarbeit mit allen relevanten Beteiligten sicherzustellen. DCO kommt während des gesamten Optimierungsprozesses zum Einsatz, damit in jeder User Story sämtliche Informationen enthalten sind, und zwar aus allen Blickwinkeln. 

Die Optimierung der User Story beginnt mit einem Entwurf der Story, der nicht viel mehr als eine kurze Beschreibung enthalten muss. Die Optimierung endet, wenn Sie die User Story zur Dimensionierung an das technische Team übergeben. 

Entwurf von User Stories

Der Business Architect, der Product Owner und andere relevante Beteiligte besprechen die User Story, damit die Geschäftsziele und Benutzeranforderungen klar definiert sind. Sobald dies geschehen ist, teilen die Interessengruppen die User Story mit dem technischen Team zur weiteren Optimierung.

Optimierung

Die geschäftlichen und technischen Teams arbeiten zusammen. Involviert sind dabei der Product Owner, Fachexperten, Spezialisten für UX-Design, versierte Tester, Business Architects und System Architects sowie IT-Spezialisten. Die Teams überprüfen die User Story und klären weitere Details. Die Optimierung der User Story kann mehrere DCO-Sitzungen in Anspruch nehmen, bevor das Team zu dem Ergebnis kommt, dass die User Story im Detail besprochen und angemessen dokumentiert wurde. 

Je nach Art der User Story müssen Sie eventuell zusätzliche Artefakte hinzufügen: 

• E-Mails mit Genehmigungen der User Story
• UI-Wireframes
• Prozesslandkarten, Geschäftsregeln
• Entscheidungslogikdiagramme

Im Rahmen der Optimierungssitzungen interpretiert das technische Team die Akzeptanzkriterien und übersetzt die Ergebnisse in Komponenten, die innerhalb der Anwendung konfiguriert werden müssen. Das technische Team ermittelt außerdem alle Abhängigkeiten von anderen User Stories, die die Story aufweisen kann, sowie die Auswirkungen, die die Story auf bestehende Funktionen und Bereiche mit besonderer Komplexität haben kann.

Möglicherweise muss das technische Team nicht-funktionale Anforderungen berücksichtigen, z. B. spezielle Benutzeranforderungen an die Barrierefreiheit. Diese Anforderungen können verloren gehen, wenn sie nicht in der User Story dokumentiert werden. Während der Optimierung dokumentiert das Team diese Details in der User Story durch zusätzliche Anhänge oder spezifische Akzeptanzkriterien. 

Im Zuge der Optimierung Ihrer User Story werden Sie möglicherweise feststellen, dass sie zu groß oder zu komplex ist. In diesem Fall sollten Sie sie in mehrere User Stories aufteilen. Auch kann es passieren, dass Sie durch die Optimierung eine Anforderungslücke aufdecken und es dadurch nötig wird, zusätzliche User Stories zu Ihrem Backlog hinzuzufügen.

Nach der Optimierung der User Stories

Der Optimierungsprozess endet, wenn folgende Punkte erfüllt sind:

• Das Team bestätigt, dass es die User Story verstanden hat.
• Alle Zusatzinformationen wurden zur User Story hinzugefügt.
• Der Product Owner genehmigt die Akzeptanzkriterien.  

Sobald die Story optimiert wurde, kann das technische Team mit der Dimensionierung der User Story fortfahren. Damit ist die Optimierung der Story abgeschlossen.

Im Rahmen des Optimierungsprozesses bestimmt das technische Team die zu erledigenden technischen Aufgaben, die die Akzeptanzkriterien einer User Story erfüllen. Einige technische Konfigurationen bedürfen dabei besonderer Aufmerksamkeit. Das Team kann diese Aufgaben von den normalen Konfigurationsarbeiten trennen. Um die Aufteilung der Arbeit innerhalb von Scrum zu erleichtern und sicherzustellen, dass wiederverwendbare Komponenten mit den entsprechenden Akzeptanzkriterien erstellt werden, kann sich das Scrum-Team für die Erstellung einer technischen Story entscheiden, die nur technische Elemente enthält.  

Typische Beispiele für technische Stories sind:

• Konfiguration von Schnittstellen-Konnektoren
• Testumgebungen
• DevOps-Repository
• Neue Umgebungen
• Weitere technische Elemente zur Unterstützung mehrerer User Stories

Bei der Optimierung wird die technische Story als Abhängigkeit für alle User Stories aufgeführt, die diese allgemeinen technischen Komponenten benötigen. Technische Stories ermöglichen es Teammitgliedern, parallel zu arbeiten, um verwandte User Stories im selben Sprint zu liefern. Das Team trennt außerdem den Aufwand für die Erstellung technischer Assets von dem für die Erstellung von Geschäftslösungen.

Für technische Stories gelten die folgenden gleichen Regeln wie für User Stories:

• Die Stories müssen der DoR entsprechen, um einem Sprint zugewiesen zu werden.
• Die Dimensionierung der Stories findet auf dieselbe Weise statt wie bei nicht-technischen User Stories.

Eine Story kann auf verschiedene Weise dimensioniert werden. „Story Pointing“ (das Vergeben von Punkten für jede Story) ist eine Aktivität, die am Ende der Optimierungsbesprechung durchgeführt wird. Der Sinn der Aktivität ist es, die Komplexität der Story zu erfassen. Je höher die Punktzahl, desto komplexer ist die Story und desto höher ist auch ihr erforderlicher Konfigurations-, Test- und Implementierungsaufwand. Ein weit verbreiteter Ansatz ist die Verwendung der Fibonacci-Zahlenfolge. Diese Zahlenfolge ermöglicht es dem Team, Stories nach ihrer relativen Komplexität zu ordnen.

Die nachstehende Fibonacci-Skala bestimmt die Story-Punkte:

• 1 Story-Punkt = sehr kleine Story
• 2 Story-Punkte = klein
• 3 Story-Punkte = mittel
• 5 Story-Punkte = mittel bis groß
• 8 Story-Punkte = groß
• 13 Story-Punkte = sehr groß
• 21 und mehr Story-Punkte = die Story ist als EPIC zu erachten und in kleinere Einheiten zu unterteilen

Schätzung mit Komplexitäts-Buckets

Es ist nicht immer leicht, die Komplexität einer Story einheitlich zu bewerten, da jedes Teammitglied die Komplexität anders einschätzen kann. In diesem Fall helfen Komplexitäts-Buckets, mit denen Sie die Komplexität einer Story abschätzen und Ihrem Team die einheitliche Dimensionierung erleichtern können. Dazu wird jede Story mit vordefinierten Komplexitätskriterien verglichen, bevor die endgültige Punktzahl vergeben wird.   

In der Prepare-Phase muss sich das Team auf geeignete Kriterien zur Bewertung der Story-Komplexität einigen. Jedes Kriterium wird zu einem Komplexitäts-Bucket. Innerhalb jedes Buckets muss sich das Team auf eine Einstufung der Komplexität von gering über mittel bis hoch oder komplex einigen. Entwickler sollten beispielsweise bei der Vergabe der Dimensionierungspunkte die Auswirkungen der User Story auf die UI, den Umfang der Tests, die Konfiguration, die Anzahl der Geschäftsregeln und die Datenintegrationen berücksichtigen. Für jede Komplexitätsstufe vergeben Sie einen Punktwert. 

Typische Komplexitäts-Buckets beinhalten beispielsweise:

• Benutzeroberfläche
• Business-Logik 
• Daten
• Integrationsaspekte
• Tests   

Während der Dimensionierungssitzung prüft das Team jede Story anhand aller Kriterien und berechnet die Gesamtpunkte der Story aus den Komplexitätsbewertungen der einzelnen Kategorien. Der Gesamtwert wird dann mit der Fibonacci-Folge abgeglichen. Wenn der Gesamtwert nicht exakt einer Fibonacci-Zahl entspricht, sondern zwischen zwei Fibonacci-Zahlen liegt, einigt sich das Team darauf, welche der zwei umschließenden Zahlen die Komplexität am besten repräsentiert, und weist der Story dann diesen Wert zu.

Sobald eine User Story eingeschätzt wurde, kann sie vom Projekteigentümer in der nächsten Sprintplanungssitzung berücksichtigt werden. 

Eine der häufigsten Fragen in einem Agile-Projekt lautet: „Wie sieht eine gute User Story aus?“ Es gibt kein Patentrezept für User Stories; jedes Team arbeitet individuell. Verschiedene Erfahrungswerte und Branchenkenntnisse prägen die gemeinsamen Anforderungen an die User Story.   

Das folgende Beispiel zeigt, wie eine gute Story aussehen könnte, wenn sie vollständig ausgearbeitet, mit dem technischen Team optimiert, anhand der „Definition of Done“ überprüft und für entwicklungsbereit erklärt wurde. Achten Sie im Beispiel auf folgende Elemente:

• Name der Story
• Beschreibung 
• Akzeptanzkriterien
• Größe der Story  
• Status der Story
• Weitere Informationen 

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.