User Stories in agilen Projekten
Was sind User Stories?
User Stories werden von agilen Teams verwendet, die sowohl das Scrum Framework als auch andere Ansätze praktizieren. Jede User Story ist in ihrer Größe und Komplexität begrenzt. Oft wird die Story initial auf eine kleine Karte aus Papier geschrieben. Dadurch wird sichergestellt, dass sie nicht zu groß wird.
User Stories werden aus dem Blickwinkel der fachlichen Anwender eines Systems geschrieben. Beim Extreme Programming werden die User Stories direkt von den Benutzern des Systems geschrieben. Im Scrum-Framework werden sie vom Product Owner geschrieben oder genehmigt. Für die Benutzer eines Systems sind User Stories das wichtigste Werkzeug, um die Softwareentwicklung zu beeinflussen.
In der agilen Entwicklung muss der Entwickler in der Lage sein, in der Sprache des Anwenders zu kommunizieren, nicht der Anwender in der IT-Sprache. Effektive Kommunikation ist die Basis des Projekterfolges und deshalb ist es notwendig, eine gemeinsame Sprache zu finden. User Stories bieten diese gemeinsame Sprache, um eine Verständigung zwischen dem Anwender und dem Umsetzungsteam zu erreichen.
Wie schreibe ich eine User Story?
Um zu verdeutlichen, wie User Stories aussehen, sind hier einige Beispiele für User Story Vorlagen:
- Das häufigste Schema (Connextra, 2001):
Als < Rolle > will ich < Ziel/Wunsch >, damit < Nutzen >
"As a < role >, I want < goal/desire > so that < benefit >" - Mike Cohn, der Autor des User Stories-Konzepts, lässt den letzten Teil manchmal weg:
Als < Rolle > möchte ich < Ziel/Wunsch >
As a < role >, I want < goal/desire > - Chris Matts schlug vor, sich mehr auf den Nutzen für den Anwender zu konzentrieren:
Um als < Rolle > einen Nutzen zu erhalten, möchte ich < Ziel/Wunsch >
In order to < receive benefit > as a < role >, I want < goal/desire > - Ein elegantes Format, das auf den fünf W's basiert:
Als < wer > < wann > < wo >, ich < was > weil < warum >
As < who > < when > < where >, I < what > because < why > - Ein Muster entwickelt bei Capital One im Jahr 2004:
Als < Rolle > kann ich, damit < externer Nutzen >
As a < role >, I can < action with system > so that < external benefit > - Eine Vorlage, die explizit die Verwendung von Pragmatic Personas impliziert:
Als < Persona > will ich < was? >, damit < warum? >
As < persona >, I want < what? > so that < why? >
Wie formulieren Sie also eine Anforderung in einem User Story-Format? Versuchen wir es mal. Nehmen wir das erste Muster.
Ich, als < Rolle >, will < Ziel/Wunsch >, um < Nutzen > zu haben
Im Original klingt die Anforderung so: Informationen über das verfügbare Kreditkartenguthaben über das Telefonmenü der Bank erhalten. Versuchen wir es mit einer Korrektur: Als Kreditkartennutzer möchte ich meinen Kartensaldo kennen, damit ich weiß, wie viel ich noch ausgeben kann. Was sehen wir hier? Im ersten Fall wird eine bestimmte Implementierung beschrieben, ohne genau zu spezifizieren, wofür sie benötigt wird.
Was muss ich beachten?
Bei der Formulierung im Format der User Story gibt es keine Fixierung auf eine technische Lösung sondern auf den aktuellen Bedarf des Endnutzers. Um diesen Bedarf zu decken, können verschiedene technische Lösungen vorgeschlagen werden. Dem Nutzer kann eine USSD-Abfrage angeboten werden, oder vielleicht auch nur eine SMS, die nach jeder Kartentransaktion den aktuellen Kontostand anzeigt, so dass eine Abfrage nicht notwendig ist.
Ein Bonus für den Auftraggeber kann hier sein, dass das System bereits über eine Funktionalität verfügt, die die Kundenanforderungen entspricht, und statt einer großen Überarbeitung könnte es auf kosmetische Änderungen in der Software hinauslaufen.
User Stories sind eine Möglichkeit, Kundenanforderungen zu dokumentieren, ohne umfangreiche formalisierte Dokumente zu entwickeln und anschließend Ressourcen für deren Pflege aufzuwenden. Das Ziel von User Stories ist es, rasch und ohne großen Aufwand auf sich schnell ändernde reale Anforderungen reagieren zu können.
In Extreme Programming sind User Stories das Ergebnis eines Planning-Games und definieren, was im Produkt implementiert werden soll. Vor der Implementierung sollten die Entwickler nach Möglichkeit die User Story mit dem Kunden besprechen. Stories können schwer zu verstehen sein, spezifische Kenntnisse erfordern oder die Anforderungen können sich seit ihrer Erstellung geändert haben.
Warum brauche ich User Stories überhaupt?
User Stories sind kurz. Sie stellen kleine Teile des Produktes dar, und können über einen Zeitraum von Tagen bis Wochen implementiert werden.Sie ermöglichen die Abstimmung der Anforderungen zwischen Entwicklern und Kunden während der Projektlaufzeit.
Sie benötigen sehr wenig Wartung
Sie fördern einen engen Kontakt zwischen den Entwicklern und dem Kunden
Sie erlauben die Unterteilung des Projekts in kleine Schritte
Sie sind geeignet für die Projekte, bei denen die Anforderungen unbeständig oder unklar sind
Sie erleichtern die Arbeitsbewertung.
Akzeptanzkriterien und Abnahmetests
Die User Story bleibt eine informelle Definition der Anforderungen, bis ein Abnahmetestverfahren eingerichtet ist. Vor der Implementierung einer User Story muss der Auftraggeber ein geeignetes Abnahmeverfahren definieren, um sicherzustellen, dass die Ziele der User Story erreicht wurden. Dies geschieht durch die Beschreibung von Akzeptanzkriterien (Acceptance Criteria) und Abnahmetests (Acceptance Tests).
Bei jeder User Story sollten ein oder mehrere Akzeptanzkriterien hinterlegt werden. So weiß der Entwickler, wann die User Story fertig ist und wie der Kunde dies verifizieren wird. Ohne die exakte Formulierung der Anforderungen zum Zeitpunkt der Produktauslieferung kann es zu langen und wenig konstruktiven Diskussionen kommen.
Beispiel: Lassen Sie uns die Akzeptanzkriterien für unsere Kreditkarten-Salden-Story aufschreiben, für den Fall, dass wir uns doch noch für die Umsetzung über das Telefonmenü entscheiden.
- Der Saldo muss auf den Cent genau angegeben werden.
- Der Kunde sollte im Tonmodus nicht mehr als 3 Tasten betätigen müssen, um sein Guthaben zu hören.
- Wenn der Benutzer mehr als eine Kreditkarte hat, sollte man ihm per Tonwahl die Möglichkeit zur Auswahl der Kreditkarte geben
Akzeptanzkriterien erweitern die ursprüngliche User Story, daher werden sie in der Regel von derselben Person geschrieben, die die Story verfasst hat.
In der Regel beginnen die Tester ihre Arbeit mit bereits vorhandenen Akzeptanzkriterien. Sie können dem Product Owner Feedback geben, wie diese Kriterien verbessert werden können, aber ihre Hauptaufgabe ist es, die fertigen Kriterien zu nehmen und darauf basierend Tests zu erstellen. Idealerweise sind diese Tests automatisiert, aber wenn nicht, sollte es eine einfache Beschreibung geben, wie man diese Tests durchführt.
Die User Story und die Akzeptanzkriterien bilden zusammen die Anforderungen für die Abnahmetests.
Agile Teams verbringen viel Zeit mit dem Recherchieren, dem Ausarbeiten und dem Analysieren von User Stories. Das ist auch gut so, wie die folgende Aussage bestätigt:
Code für einen bereits verstandenen Zweck zu schreiben, erweist sich nicht unbedingt als der schwierigste Teil der Produktentwicklung, der schwierigste Teil ist vielmehr zu verstehen, was der eigentliche Zweck des Schreibens des Codes ist.
Kriterien für User Stories
Es lohnt sich also für das Team, in hochwertige User Stories zu investieren. Deshalb hat Bill Wake das Akronym INVEST ins Leben gerufen, um die Eigenschaften einer guten User Story zu beschreiben:
- Independent – Unabhängig
- Negotiable – Verhandelbar und veränderbar
- Valuable – Wertvoll für den Endbenutzer
- Estimable – Einschätzbar
- Small – Klein genug
- Testable – Testbar
Unabhänig
Unabhängigkeit bedeutet, dass eine Story getrennt von anderen entwickelt, getestet und an die Endnutzer ausgeliefert werden kann. Unabhängigkeit ist wichtig, weil wir eine begrenzte Anzahl von User Stories bearbeiten können. Wenn eine von den Storys mit derjenigen zusammenhängt, die nicht in den Sprint passte, müssen wir sie ersetzen, was bedeutet, dass wir die Aufgaben nicht nach Priorität bearbeiten werden.
Beispiel:
Lassen Sie uns ein Beispiel mit abhängigen User Stories beschreiben:
- Als Administrator kann ich Regeln für die Kennwortsicherheit festlegen, so dass die Benutzer sichere Kennwörter erstellen und verwenden müssen.
- Als Benutzer muss ich die vom Administrator festgelegten Passwort-Sicherheitsregeln befolgen, um die Sicherheit meines Kontos zu gewährleisten.
In diesem Beispiel hängt die User Story des Benutzers von der Story des Administrators ab. Die User Story des Administrators ist nur in Bezug auf das Setzen, Löschen und Verwenden von Sicherheitsrichtlinien testbar, aber nicht in Bezug auf die Anwendung der Richtlinie auf den Endbenutzer. Darüber hinaus ist die Implementierung der Administrator-Story ohne die Implementierung der zweiten User Story wertlos.
Wir können die Abhängigkeiten aufheben, indem wir die Stories auf eine andere Art und Weise unterteilen - in unserem Fall nach der Art der Sicherheitsrichtlinie und die Verbindung zwischen der Festlegung der Richtlinie und ihrer Anwendung in jeder Story:
- Als Administrator kann ich eine Gültigkeitsdauer für Passwörter festlegen, so dass die Benutzer ihre Passwörter regelmäßig ändern müssen.
- Als Administrator kann ich die Komplexität von Passwörtern festlegen, so dass die Benutzer aufgefordert werden, Passwörter zu erstellen, die schwer zu knacken sind.
Verhandelbar und veränderbar
Im Gegensatz zu traditionellen Anforderungen ist die User Story keine Vereinbarung über eine bestimmte Funktionalität, sondern ein Speicher für solche Anforderungen, die erst noch diskutiert, implementiert, getestet und übernommen werden müssen.
In Unternehmen mit einer starren Trennung nach " Funktionsbereichen" (Abteilungen) implizierten die im Pflichtenheft festgehaltenen Anforderungen eine geringe Kommunikation zwischen den Abteilungen und dienten als Aufzeichnung der bisherigen Vereinbarungen. Agile hingegen basiert auf der Idee, dass ein funktionsübergreifender Teamansatz für die Lösung von Problemen in einer sich verändernden Umgebung effektiver ist. Eine User Story ist ein strukturiertes Mittel, um Anforderungen innerhalb eines Teams zu kommunizieren.
Schließlich ermöglicht die Verhandelbarkeit von User Stories den Teams, terminliche Planungssicherheit zu gewinnen. Das Fehlen von zu restriktiven und zu detaillierten Anforderungen verbessert die Fähigkeit des Teams und des Unternehmens, Kompromisse zwischen dem Funktionsumfang und dem Liefertermin zu schließen. Da jede Story eine gewisse Flexibilität zulässt, hat das Team auch mehr Spielraum bei der Einhaltung der Release-Ziele, was die Zuverlässigkeit und das Vertrauen des Kunden erhöhen kann.
Wertvoll für den Endbenutzer
Das Ziel eines agilen Teams ist einfach - in der verfügbaren Zeit und mit den verfügbaren Ressourcen den maximalen Wert zu liefern. Daher ist der Wert das wichtigste Attribut im INVEST-Modell. Die Prioritäten werden in erster Linie auf der Grundlage des Wertes der Story für den Endnutzer festgelegt.
Eine typische Herausforderung für agile Teams ist es, zu lernen, wie man kleine, inkrementelle User Stories schreibt, die für eine effektive Wertlieferung geeignet sind. Traditionelle Ansätze fokussieren sich auf den Algorithmus der funktionalen Zerlegung von Anforderungen in technische Komponenten. Dieser technische Ansatz zur Systementwicklung verlangsamt die Lieferung an den Endnutzer, bis alle Schichten durch mehrere Iterationen (Sprints) verbunden sind. Bill Wake bietet seine Vision einer funktionalen (vertikalen) statt einer technischen (horizontalen) Schichtung an.
Stellen Sie sich ein Produkt als einen mehrschichtigen Kuchen vor. Wenn wir das Produkt technisch, also horizontal aufteilen, servieren wir mit jeder Auslieferung nur eine Schicht des Kuchens. Aber wir wollen dem Benutzer einen Vorgeschmack auf den ganzen Kuchen auf einmal geben, und der beste Weg, dies zu erreichen, ist ein vertikaler Schnitt durch die Schichten. Entwickler haben sehr oft die Tendenz, immer nur mit einer Schicht zu arbeiten (und es damit "richtig" zu machen); aber eine vollständige Ebene für den Datenzugriff (zum Beispiel) ist für den Benutzer wenig oder gar nicht von Wert, wenn es keine Benutzeroberfläche im System gibt.
Das Erstellen nützlicher Stories erfordert, dass wir unser Denken durch Aufschlüsselung von der Horizontalen zur Vertikalen neu ausrichten. Wir erstellen User Stories, die sich durch die Anwendungsarchitektur "schneiden", so dass wir dem Benutzer einen Mehrwert bieten und so früh und so oft wie möglich sein Feedback einholen. Obwohl sich der Wert in der Regel auf den Endbenutzer richtet, der mit dem System interagiert, müssen auch andere Stakeholder berücksichtigt werden.
Beispiel:
Der Marketingleiter eines Energieunternehmens wünscht sich eine höhere Klickrate auf die Banner der Website. Zwar kann die User Story aus der Sicht des Benutzers so geschrieben werden:
Als Benutzer kann ich andere Tarife sehen, welche mein Interesse stärker wecken, so dass ich mich für einen Tarif anmelden kann, der besser zu meinem Lebensstil passt.
Um jedoch eine klarere Vorstellung vom tatsächlichen Wert zu vermitteln, wäre es natürlicher, die Geschichte aus der Sicht des Marketingleiters aufzuzeichnen:
Als Marketingleiter kann ich den Anwendern neue Tarife anbieten, damit sie bereit sind, weiter Strom von uns zu beziehen.
Eine weitere Herausforderung, der sich Teams stellen müssen, ist die Rechtfertigung des Nutzens von technischen Aspekten wie Refactoring, Komponenten-Upgrades usw.
Wie kann der Product Owner den Wert einer solchen Story bestimmen wie die Überarbeitung des Fehler-Meldesystems? Den Wert einer technischen Lösung als User Story zu formulieren, hilft, ihren Nutzen für das Unternehmen zu kommunizieren.
Beispiel:
Als Verbraucher kann ich an jeder Stelle im Produkt einen aussagekräftigen und verständlichen Fehlerbericht bekommen, damit ich weiß, was ich gegen das Problem tun kann.
Oder:
Als Support-Ingenieur möchte ich, dass der Benutzer überall in der Anwendung eine aussagekräftige und verständliche Meldung erhält, so dass er das Problem lösen kann, ohne den technischen Support zu kontaktieren.
In diesen Beispielen ist der Wert für den Benutzer, den Product Owner, die Stakeholder und das Team klar.
Einschätzbar
Obwohl das Backlog User Stories von beliebiger Größe enthalten kann, sollte das Team in der Lage sein, eine grobe Schätzung der Komplexität und des Arbeitsumfangs der Stories mit der höchsten Priorität vorzunehmen, um zu verstehen, wie viele Stories das Team im kommenden Sprint erledigen kann.
Wenn das Team irgendein Element des Backlogs nicht einschätzen kann, wird die Story als zu groß oder zu unklar formuliert markiert. Wenn eine User Story zu groß ist, um sie abzuschätzen, sollte sie in kleinere Teile zerlegt werden. Wenn sie zu unklar ist, sollten zusätzliche Analysen oder Untersuchungen durchgeführt werden, um die Unsicherheit zu verringern.
Einer der Hauptvorteile der User Story-Evaluation ist nicht nur der Überblick über den genauen Arbeitsumfang, sondern auch die Möglichkeit, versteckte Annahmen und fehlende Akzeptanzkriterien herauszufinden und die Wahrnehmungen der Story unter den Teammitgliedern abzugleichen. Daher ist der Dialog, der den Evaluierungsprozess begleitet, genauso wichtig, wenn nicht sogar wichtiger, als die Evaluierung selbst.
Klein genug
User Stories müssen grundsätzlich so klein sein, dass sie innerhalb einer einzigen Iteration abgeschlossen werden können. Wenn jedoch nur eine Story es in den Sprint schafft, wird es am Ende des Sprints keine einzige fertige Story geben, wenn etwas schief geht. Es lohnt sich also, die Stories so aufzuteilen, dass die Möglichkeit besteht, mehrere Stories in einer einzigen Iteration zu bearbeiten.
Viele Teams schneiden Stories so, dass die Anzahl der Stories in einem Sprint mindestens so groß wie die Anzahl Tage im Sprint ist. Wenn wir täglich die Fertigstellung von Stories sehen, können wir immer mit Zuversicht sagen, dass es am Ende des Sprints etwas geben wird, das wir den Benutzern und den Kunden zeigen können.
Kompaktere User Stories durchlaufen den Entwicklungsprozess schneller, nicht nur wegen ihres kleineren Umfangs, sondern auch wegen ihrer geringeren Komplexität. Dies steht im Einklang mit der Empfehlung für Clean Code Development, so schlägt Robert Martin die folgenden Regeln für Systemfunktionen vor:
- Implementieren Sie eine Funktion nach der anderen.
- Halten Sie den Umfang der Aufgabe klein
- Machen Sie es noch kleiner
Es stellt sich die legitime Frage nach dem Verhältnis zwischen Umfang und Unabhängigkeit, da es logisch erscheint, dass kleinere User Stories die Anzahl der Abhängigkeiten erhöhen. Allerdings liefern kleine Stories, auch bei etwas mehr Abhängigkeiten, einen höheren Durchsatz.
Testbar
In der vollwertigen agilen Umgebung müssen alle fertigen User Stories getestet werden. Daraus ergibt sich die Forderung nach Testbarkeit. Wenn eine Story nicht oder nur schwer zu testen ist, dann ist sie schlecht formuliert oder übermäßig komplex, oder sie hängt möglicherweise von anderen User Stories ab.
Um sicherzustellen, dass Stories nicht in die Iteration gehen, wenn sie nicht erfolgreich getestet werden können, verwenden viele Agile Teams die Definition von "Ready", die alle Bedingungen beschreibt, unter denen eine Story in Arbeit genommen werden kann. Dabei kann es sich um Akzeptanzkriterien, Abnahmetests, Anforderungen an die Größe der Story, usw. handeln. Es hängt alles von der Reife und Erfahrung des Teams ab. Die fortschrittlichsten Teams im Sinne des Engineerings beschreiben beispielsweise die Anforderungen in Form einer Spezifikation mit Beispielen (Specification by Examples).
Aufgrund der Testbarkeit tappen User Stories in die gleichen "Fallen" wie Anforderungen. Unscharfe Wörter wie "schnell", "verwalten", "schön", "sauber" sind leicht zu schreiben, aber extrem schwierig zu testen, weil sie für verschiedene Menschen unterschiedliche Dinge bedeuten, und sollten daher vermieden werden. Klare und exakte Formulierungen helfen dem Team und dem Unternehmen, die Erwartungen an das Ergebnis zu synchronisieren und Überraschungen zu vermeiden.
Fazit
User Stories sind ein Mittel, um das Systemverhalten so zu definieren, dass es sowohl für Entwickler als auch für Benutzer Sinn ergibt. Bei diesem Ansatz der Anforderungsbeschreibung liegt der Schwerpunkt der Arbeit auf dem Wert für die Endbenutzer und nicht auf der strukturierten Aufteilung in Aufgaben, wie es traditionell gemacht wird. User Stories bieten damit einen leichtgewichtigen und effizienten Ansatz für das Anforderungsmanagement im System.
Sie möchten regelmäßig über neue Artikel informiert werden? Abonnieren Sie unseren Newsletter!
Nach Materialen des Kurses "Agile Methodologien im Management von Projekten" (e-mba.ru). Übersetzt und adaptiert von Elena Semenova. Redaktion: Carsten Negrini