User Stories in Scrum erfolgreich einsetzen

Vermutlich haben Sie den Begriff “User Story” auch schon gehört – besonders, wenn Sie sich schon mit agilen Projekten befasst haben. Wenn Sie noch wenig Erfahrung im agilen Projektmanagement haben, dann ist dieser Artikel genau richtig für Sie. Hier erkläre ich Ihnen detailliert, was User Stories sind und wie diese erstellt und dokumentiert werden. Lesen Sie weiter und erfahren Sie mehr!

User Stories kennt der Scrum Guide nicht

Im Scrum Guide finden Sie den Begriff User Story oder Anforderung nicht, Der Scrum Guide 2020 hat den Begriff Anforderung, etwas unglücklich, durch den neuralen Begriff „Product Backlog Item” (PBI) ersetzt. Es hat sich jedoch in der Scrum-Praxis bewährt, gewünschte Funktionalitäten (also Anforderungen) in Form einer User Story zu beschreiben.

Eine User Story (Anwendererzählungen) ist eine aus der Sicht des Anwenders in Alltagssprache formulierte Software-Anforderung. Sie definiert einen Wert (Value) für den Nutzer oder Käufer des Produktes. Eine User Story ist bewusst kurzgehalten und umfasst in der Regel nicht mehr als zwei Sätze, die auf die Vorderseite einer Karteikarte geschrieben werden.

User Stories beschreiben Anforderungen aus der Sicht des Anwenders”.

Der Unterschied zu Anforderungen ist, dass Anforderungen mehr spezifische Details definieren, während User Stories mehr Raum für Diskussionen offenlassen. Diese Diskussionen werden dann im Sprint Planning gehalten. Die Anforderung sind eigentlich in den User Stories „versteckt“. Man lässt bewusst offen, wie die User Stories genau umgesetzt werden.

User Stories werden in einer bestimmten Form mit drei Variablen ge­schrieben:

• Rolle (Wer?)
• Ziel/Wunsch (Was? Funktionsbeschreibung, Aktion)
• Nutzen/Grund (Warum?)

Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen/Grund> erreichen.

Beispiel: Als <Datenerfasser> möchte ich <nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen>, <um Zeit zu sparen>.

Rolle – Mit den meisten Softwaresystemen arbeiten verschiedene Benutzer. Dies kann ein Sachbearbeiter sein, der Daten erfasst, ein Administrator, der das System konfiguriert oder ein Verkaufsmitarbeiter, der Aufträge bearbeitet. Sehr oft haben Softwaresysteme ein Rollen- und Rechtesystem, dass bestimmte Rollen unterscheidet und die Zugriffsrechte auf Daten definiert. Auch aus diesem Grund ist es für Sie wichtig zu wissen, welche Rolle etwas aufführt.

Ziel/Wunsch – Hier steht die Funktionsbeschreibung, die Aktion, welche die Rolle ausführt. Die Beschreibung muss nicht detailliert sein. Auch sollten Sie vermeiden Lösungsansätze zu beschreiben. Beschreibung Sie also nur das WAS gemacht werden soll und nicht auch das WIE.

Nutzen/Grund – Dieser wichtige Teil der User Story wird oft vergessen oder einfach nicht beschrieben. Dies, weil es nicht immer so einfach ist den Nutzen zu definieren. „Warum-Fragen“ helfen hier weiter. Der Nutzen ist ein wesentliches Element, wenn es später darum geht Lösungsmöglichkeiten zu diskutieren.

Es werden oft noch weitere Informationen auf die User Story Karte geschrieben. Dazu gehören:

• Eine Identifikationsnummer (sinnvoll, wenn die User Story in einer Software gespeichert wird)
• Verweise (z. B. wer hat die Anforderung eingebracht)
• Eine Aufwandschätzung (in Story Points)
• Akzeptanzkriterien

Beispiele für User Stories

Einer der Vorteile agiler User Stories ist, dass sie in unterschiedlichem Detaillierungsgrad geschrieben werden können. Wir können eine User Story schreiben, um große Mengen an Funktionalität abzudecken. Diese großen User Stories werden Epics genannt. Hier ist ein Beispiel für eine große User Story aus einem Desktop-Backup-Produkt:

• Als Benutzer kann ich meine gesamte Festplatte sichern.

Da eine Epic oft zu groß ist, als dass ein agiles Team diese in einer Iteration abschließen kann, wird diese vor der Bearbeitung in mehrere kleinere User Stories aufgeteilt. Die obige Epic könnte in verschiedene User Stories aufgeteilt werden, einschließlich dieser beiden:

• Als Power-User kann ich die zu sichernden Dateien oder Ordner auf der Grundlage von Dateigröße, Erstellungsdatum und Änderungsdatum angeben.
• Als Benutzer kann ich Ordner angeben, die nicht gesichert werden sollen, damit mein Sicherungslaufwerk nicht mit Dingen gefüllt wird, die ich nicht sichern muss.

User Stories auf Karteikarten zum Diskutieren

User Stories werden bevorzugt auf Kartei- oder Pinwandkarten geschrieben und für jeden sichtbar aufgehängt, damit darüber diskutiert werden kann. Ja, das kann umständlich sein oder scheint altmodisch für Sie. Dies hat aber seinen speziellen Nutzen, denn die „Zettel“ sind so für alle immer präsent. Eines der Prinzipien von Scrum ist der gegenseitige Austausch (Kommunikation) und gute Sichtbarkeit – und dafür sind Karteikarten ideal.

Wenn Sie mit einer Software das Backlog verwalten und dort alle User Stories speichern haben Sie zwar alles schön verwaltet und vor der Putzfrau sicher, dies aber mit dem Nachteil, dass wenig oder nicht über die User Stories gesprochen wird. Oder haben Sie schon einmal vier Developer vor einem Bildschirm über eine User Story diskutieren gesehen?

Das heißt aber nicht, dass User Stories nicht auch (zusätzlich) elektronisch in einer Software erfasst werden können. Dies hat zum Beispiel einen Vorteil bei verteilten Teams – oder wenn alle Teammitglieder im Home-Office sind wegen einer Pandemic.

User Stories sind Teil des agilen Ansatzes, der den Schwerpunkt vom Schreiben über Anforderungen auf das reden über diese Anforderungen verlagert.

Die folgende Abbildung zeigt die Vorderseite einer Karteikarte, auf der eine User Story geschrieben wird. Auf der Rückseite hat es dann Platz für weitere Informationen, wie z.B. Abnahmekriterien oder Abhängigkeiten zu anderen Stories oder Risiken.

User Stories nach den 3C-Kriterien

Zusätzlich zu den guten Merkmalen von User Stories von Bill Wake (INVEST), werden auch noch oft die „3C Kriterien“ von Ron Jeffries angewendet. Diese haben folgende Bedeutung:

Cards (Story Cards) – Schon als die agile Bewegung startete wurden User Stories bevorzugt auf Kärtchen (oder Post-it’s) festgehalten. Daran hat sich bis jetzt nichts geändert. Die Idee dahinter ist: Auf einer kleinen Karte kann man nicht viel schreiben – es haben keine Details oder Spezifikationen darauf Platz.

Conversation – Die Beschreibung auf der Story Card ist absichtlich so knapp gehalten, damit darüber diskutiert werden muss. Das Gespräch zwischen Developern, Product Owner und Kunde ist wesentlich, um Details zu klären und Unklarheiten zu beseitigen.

Confirmation – Die User Story muss überprüfbar und testbar sein. Die Akzeptanzkriterien werden aus praktischen Gründen oft auf die Rückseite der Story Card geschrieben.

Wer schreibt User Stories und wann?

Jeder kann User Stories schreiben. Der Product Owner ist jedoch verantwortlich, dass ein Product Backlog mit User Stories existiert. Das bedeutet aber nicht, dass der Product Owner derjenige ist, der sie schreibt – dies können die Teammitglieder aber auch Stakeholder sein. Es kommt weniger darauf an, wer eine User Story schreibt, als darauf, wer an den Diskussionen darüber beteiligt ist.

User Stories werden während der gesamten Projektdauer geschrieben. Gewöhnlich wird zu Beginn eines agilen Projekts ein Workshop durchgeführt, an dem erste User Stories verfasst werden. Jeder im Team nimmt daran teil, mit dem Ziel, ein Produkt-Backlog zu erstellen, das Funktionalitäten mindestens für die nächsten zwei bis drei Releases beschreibt.

User Stories sollten „klein“ sein

Wenn einige User Stories für die nächsten zwei Sprints zu groß sind, z.B. größer als „8“, dann sollte das Scrum-Team versuchen diese weiter aufzusplitten. Für größere Stories, die erst später umgesetzt werden, lohnt sich diese Arbeit nicht. Denn diese sehen bis in ein paar Wochen vielleicht ganz anders aus oder werden gar nie realisiert. Diese Stories können auch grösser sein.

Warum ist das Aufsplitten von grossen User Stories wichtig? Die kurze Antwort darauf ist: Damit diese in einen Sprint passen. Aber das ist nur die halbe Wahrheit. Ich zeige Ihnen zwei weitere wichtige Gründe dafür:

1.    „The power of small wins“ :Je häufiger Teams ein Fortschrittsgefühl erfahren, auch wenn dies in kleinen Schritten geschieht, desto eher wird das Team langfristig kreativ, produktiv und motiviert sein (Amabile, 2011).

2.    Stories aufsplitten in Kleinere ist auch wichtig, um das 90%-Syndrom zu vermeiden. Tom Cargill von den Bell Labs hat dies 1985 für die Softwareentwicklung mit der „ninety-ninety rule“ folgendermaßen ausgedrückt:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Tom Cargill, Bell Labs

Hervorgerufen wird dieser Effekt, typischerweise durch die erworbene Kenntnis des Lösungsweges und die Unkenntnis der noch auftretenden Störungen und Probleme. User Stories aufsplitten ist nicht immer einfach – machen Sie sich aber die Mühe!

Hier gibt es noch mehr Wissen