Was ist eine User Story?

Wozu werden User Stories genutzt?

User Stories beziehen sich immer auf das Produkt und die Benutzererfahrung. Durch ihre Kürze und den Fokus auf den Kunden eignen sie sich besonders gut für Scrum und agiles Arbeiten.

User Stories werden oft im Zusammenhang mit Scrum genannt. Obwohl Scrum nicht vorgibt, wie ein Product Backlog Eintrag beschrieben wird. Eine User Story ist eine mögliche Technik, um einen Eintrag im Product Backlog zu beschreiben. Damit wird die Kommunikation zwischen Team und Kunden erleichtert.

Warum User Stories nutzen?

User Stories wurden ursprünglich, wie viele heute in der modernen Softwareentwicklung selbstverständlichen Entwicklungspraktiken, in der eXtreme Programming (XP) Community entwickelt. Wie ein Scrum Team fokussiert ein XP Team sich ganz darauf, ein fertiges Produkt-Inkrement zu liefern. Die höchste Form von "Fertig" erreicht das Team, wenn das neue Produkt-Inkrement den Wert für den Nutzer erhöht. Dazu möchte der Nutzer mit dem Produkt interagieren. Das Team muss ihm also die notwendigen Funktionen dazu designen.

Wie das Ganze umgesetzt und realisiert wird, steht nicht im Mittelpunkt einer User Story. Und tatsächlich interessiert sich der Nutzer herzlich wenig dafür, ob es für die Implementierung eine Datenbank, ein Microservice oder eine GUI Komponenten braucht. Er misst den Erfolg an dem, was das Produkt für ihn leistet. Damit sind die User Stories perfekt geeignet für das Product Backlog in Scrum, denn es dient dazu, den Wert des Produktes während der Entwicklung zu optimieren. In Scrum ist das Product Backlog die Liste der Dinge, welche das Produkt verbessert.

Wie schreibe ich eine User Story?

Mit diesem Wissen im Hintergrund ist es ganz leicht, eine User Story zu schreiben. Man muss sich nur merken: Eine User Story steht auf einer Karte als ein gut formulierter Satz, den andere leicht und gerne lesen möchten. Hier ist zum Beispiel die User Story für ein Online Scrum Training.

"Als Teammitglied verstehe ich, wie ich eine User Story klein machen kann, um regelmäßig das Product Backlog mit den Stakeholdern verfeinern zu können."

Dieser Satz enthält die drei wesentlichen Informationen auf einer User Story Karte: den Wert, den Nutzer und die Funktion. Gut, der Satz alleine macht natürlich noch keine wirklich komplette Nutzergeschichte. Vielmehr ergibt sich das Gesamterlebnis für den Nutzer durch eine Vielzahl solcher Karten, die bei Scrum im Product Backlog stehen. Wir bleiben aber agil, weil wir die Nutzergeschichte jederzeit ändern können, indem wir Karten umsortieren, verwerfen oder neue hinzufügen. Somit können wir auch während der Produktentwicklung den Wert für den Nutzer optimieren.

Es gibt noch einen guten Grund, warum wir User Stories gerne auf Karten schreiben. Ist sie zu lang und passt somit nicht mehr auf eine Karte, dann ganz einfach eine neue Karte schreiben. Somit bleiben wir flexibel und die User Story ist nicht zu groß und wird schwer umsetzbar.

Was ist ein Epic?

Dennoch findet man oft User Stories im Product Backlog, über die das Entwicklungsteam sagt, dass sie viel zu groß sind für die Realisierung in einem Sprint. Die Karte wird dann als Epic markiert. Das bedeutet, das Scrum Team muss sich rechtzeitig mit den Stakeholdern darum kümmern, diese kleiner zu machen.

Warum muss man User Storys kleiner machen?

Das kleiner machen oder auf die richtige Größe bringen ist für das Team nichts anderes, als die inhaltliche Klärung der User Story und die damit verbundene Reduzierung der Komplexität. User Stories helfen bei diesem Prozess ungemein, den Fokus auf das, was der Mehrwert ist, zu behalten. Allerdings schneiden Teams ihre User Stories oft an der falschen Stelle - und das eigentliche Ziel, einen Wert für den Nutzer zu liefern, geht verloren.

Wie groß soll eine User Story sein?

Eine der wichtigsten Fähigkeiten, welche ein Entwicklungsteam beherrschen muss, ist es mit den Stakeholdern seine Backlog-Einträge in die richtige Größe zu bringen. User Stories sind perfekt dazu geeignet, weil sie den Fokus auf echten Mehrwert für den Nutzer setzen. Die Praxis hat gezeigt das eine gute Größe erreicht ist, wenn eine User Story vom Team innerhalb einer Woche fertiggestellt werden kann. Wichtig: Damit ist die Dauer vom Beginn der Arbeit bis zum Zustand "Fertig" nach der Definition of Done gemeint, nicht die Arbeitszeit, welche investiert wird. Je nach Rahmenbedingungen kann das beträchtlich voneinander abweichen.

Techniken um User Stories zu zerlegen

1. Konjunktionen

Die erste und wohl einfachste Form eine Story Karte kleiner zu machen, sind Konjunktionen. Dazu braucht man oft nicht einmal die Karte durchzulesen, einfach nach Aufzählungskommas, Bindewörtern oder Bullet-Points Ausschau halten. Zum Beispiel:

Als Onlinekursteilnehmer kann ich mit einem Quiz über das Gelernte reflektieren, damit sich das Gesehene besser einprägt und das Ergebnis zum Ansporn meinen Teammitgliedern schicken.

Das sind potenziell zwei User Stories:

Das Ergebnis zum Ansporn meinen Teammitgliedern schicken.

und

Mit einem Quiz reflektieren, zum Einprägen des Gesehenen.

Nun, einfacher geht es nicht.

2. Akzeptanztests

Die zweite und wohl mächtigste Technik sind Akzeptanztests. Man stellt sich die Frage, was würde der User alles tun, um die neue Funktion darauf zu überprüfen, dass sie für ihn akzeptabel ist. Zum Beispiel, für die Quiz User Story von eben gibt es folgende Akzeptanztests:

• Quiz nach dem Video automatisch starten.
• Nach einer Frage erhalte ich Feedback, was ich richtig oder falsch gemacht habe.
• Der Fortschritt wird angezeigt.
• Es gibt eine Auswertung der Ergebnisse am Ende.

Jeder dieser Testfälle ist eine potentielle neue User Story. Es fehlt nur der Benutzer und warum er das möchte. Aus Auswertung der Ergebnisse wird:

Als Kursteilnehmer erhalte ich eine Auswertung meines Quizzes, damit ich erkenne, was ich noch nicht verstanden habe.

Hier sieht man das Potenzial von User Stories. Teile davon, wie im Beispiel die Auswertung des Quizzes am Ende, werde ich vielleicht erst in späteren Sprints oder gar nicht realisieren. Ein einfaches Quiz-Feedback nach jeder Frage reicht für den Anfang vielleicht aus und der Nutzer hat einen ersten echten Nutzen.

3. Objekte

Natürlich kann man eine User Story auch systematisch zerlegen. Zum Beispiel, indem man sich die Objekte anschaut. Das Quiz kann zum Beispiel aus verschiedenen Fragetypen bestehen, wie Ja/Nein Frage, Auswahlfrage, Puzzle, und so weiter. Jedes Objekt ist wiederum ein Kandidat für eine eigene User Story.

4. Aktionen

Oder aber man zerlegt anhand der Aktionen. Zum Beispiel kann der Trainer ein Quiz neu erstellen, verschieben, löschen und duplizieren. Auch wenn "erstellen und löschen" noch nicht viel Komfort bietet, um damit zu arbeiten, ist es aber ausreichend.

5. Zeitliche Reihenfolge

Oft ist es aber auch leichter einfach die User Story in zeitlicher Reihenfolge beziehungsweise der Sequenz der Aktivitäten eines längeren Prozesses zu zerlegen. Zum Beispiel Account anlegen, Zahlungsmittel auswählen, Kauf bestätigen, Link zum Zugang zusenden.

Wir können jetzt die Auswahl des Zahlungsmittels als eigenständige User Story formulieren. Nur hat davon der User leider nicht allzu viel, denn er kann immer noch nicht den Kurs bearbeiten. Davon abgesehen, dass uns nur wenig zum Mehrwert einfällt, warum wir den Nutzer durch so einen viel zu komplizierten Verkaufsprozess quälen. Dennoch ist es für das Team vielleicht sinnvoll hier zu beginnen, weil Anbindung des Zahlungsmittels am meisten Risiko für die Umsetzung beinhaltet.

6. Aspekte

Meistens und besonders in der Softwareentwicklung sind diese fünf Schritte ausreichend zum Zerkleinern von User Stories. Wenn nicht, dann gibt es noch die Möglichkeit Aspekte herauszunehmen. Dazu mehr im Abschnitt nicht-funktionale Eigenschaften.

Nicht-funktionale Eigenschaften

Was sind nicht-funktionale Eigenschaften?

Nehmen wir an Sie haben zwei Fahrzeuge beim Autohändler vor sich stehen. Einen Standard VW Polo und einen Porsche 911. Alle haben die funktionale Eigenschaft: "Als Berufstätiger kann ich von zu Hause zur Arbeit fahren" und "Als Familienvater kann ich meine zwei Kinder zur Schule bringen." Gut im Falle des Porsches sitzt mindestens ein Kind nicht gerade bequem auf dem Notsitz im Heck und schneller als mit dem Polo sind Sie mit dem Porsche im Berufsverkehr auch nicht bei der Arbeit. Dennoch besteht ein großer Unterschied zwischen den beiden, wie zum Beispiel Kompaktheit, sportliches Design, Comfort, Übersichtlichkeit oder Kurvenverhalten. Wir sprechen hier von nicht-funktionalen Eigenschaften eines Produktes. Bei einem Online-Training sind es vielleicht Eigenschaften wie Verfügbarkeit, Sicherheit der Nutzerdaten oder Mehrsprachigkeit.

Wie erkennt man nicht-funktionale Eigenschaften?

Oft werden nicht-funktionale Eigenschaften auch als Aspekte oder Constraints bezeichnet, denn daran erkennt man sie. Sie beschränken oder sind eine Grundeigenschaft jeder einzelnen funktionalen Eigenschaft im Product Backlog. Und User Stories sind per se eher funktional, denn sie beschreiben eine Funktion für den Nutzer. Jede einzelne User Story im Product Backlog muss eben in fünf Sprachen verfügbar sein, und kann von 1000 Nutzern gleichzeitig genutzt werden.

Warum sind nicht-funktionale Eigenschaften so wichtig?

Es wird schnell klar, dass eine solche Eigenschaft einen viel grundlegenderen Einfluss auf das Produkt hat als eine einfache User Story. Eine Quelle ist daher oft auch die Produktvision. Der Product Owner muss die nicht-funktionalen Eigenschaften von Anfang an in seine Überlegungen zu Wert, Kosten und Risiko der Produktentwicklung einfließen lassen. Sie bestimmen somit stark die Reihenfolge der User Story im Product Backlog mit. Für das Entwicklungsteam sind die nicht-funktionalen Eigenschaften die Grundlage für die Entscheidung wie sie die Architektur und das Design aufbauen oder welche Qualitätskriterien sie berücksichtigen müssen.

Zusammenspiel von der Definition of Done und User Stories

Zusammen müssen Product Owner und Entwicklungsteam sich überlegen, wie sie stetig diese Aspekte und Constraints einhalten. Daher halten sie diese als Testkriterien in der Definition of Done fest. Umgekehrt sollte sich jeder Eintrag der Definition of Done auf eine nicht funktionale Eigenschaft zurückführen lassen. Ansonsten muss ich das Team fragen, warum sie diese Kriterien berücksichtigen, denn umsonst sind sie nicht.

Aspekte entfernen: Die 6. Technik, um User Stories zu zerlegen

Aspekte sind auch der Zugang zur sechsten Technik, um User Stories kleiner zu machen oder besser gesagt, um ihre Komplexität für die Umsetzung zu reduzieren. Ein Aspekt lässt sich vom Product Owner leicht nach hinten im Product Backlog einreihen. Allerdings bedeutet das ein erhöhtes Risiko das hohe Kosten zu einem späteren Zeitpunkt entstehen.

Zum Beispiel lässt sich eine barrierefreie Benutzerschnittstelle zu einem späteren Zeitpunkt leicht herstellen, wenn das Team diese im Softwaredesign vorgesehen hat. Aspekte wie Skalierbarkeit und Sicherheit sind allerdings nur sehr teuer nachträglich einzubauen. Auch, dass das Produkt auf einem Testsystem installiert wird, oder erst einmal als Prototyp im Labor steht, ist ein Aspekt und kann bewusst genutzt werden, um von Sprint zu Sprint die Qualität des Produktes und damit den Umfang der Definition of Done zu erhöhen.

Nicht umsonst sprechen wir von einem potenziell auslieferbaren Produkt-Inkrement. Damit es auslieferbar wird, benötigt das Produkt neben funktionalen sehr oft auch noch nicht funktionale Verbesserungen. Das Team webt sozusagen mit jedem Sprint neue Aspekte in das Produktdesign ein. Manche Teams müssen diesen Prozess auch rückwärts gehen. Sie sprechen dann nicht von Aspekten oder Constraints, welche sie auch umsetzen wollen, sondern von technischen Schulden, welche sie abbauen müssen.

Wann sollen User Stories nicht genutzt werden?

Bei nicht-funktionalen Eigenschaften macht es oft keinen Sinn mehr, User Stories noch zu benutzen. Gerade bei stark Hardware-zentrierten Produkten sind echte User Stories eher selten. Zum einen, weil es keine oder nur wenige Nutzerinteraktionen gibt. Zum Beispiel bei einer Produktionsmaschine der Ein- oder Ausschalter, denn den Rest macht die Maschine von selbst. Oder bei einer Kamera der Autofokus, der für sich genommen schon hochkomplex ist und ein Team etliche Sprints benötigt, bis dieser gut genug ist für eine Auslieferung. Zum anderen soll Hardware ja gerade die stabile Basis bilden, um stetig den Nutzer per Software neue Funktionen anbieten zu können oder bestehende zu verbessern. Hier bieten sich Designziele und Testfälle als Einträge für das Product Backlog an.

Software-Tools, User Stories und Scrum

Leider verwirren manche Softwaretools wie z.B. JIRA damit, dass sie einen Backlog-Eintrag als generell als "Story" bezeichnen. Dadurch geht oft der eigentliche Zweck dieser sehr leichtgewichtigen und eleganten Technik verloren.

Stakeholder und Teams folgen oft blind den Vorgaben des Tools. Sie versuchen alles mit User Stories zu spezifizieren. Ein Backlog-Eintrag ist aber lediglich als eine Erinnerung für ein Gespräch zu verstehen. Dieses Gespräch muss geführt werden, bis der Produkt Backlog Eintrag fertig umgesetzt, und nicht etwa bis er perfekt formuliert wurde. User Stories helfen dem Team in vielen Fällen dabei, das Gespräch auf das Wesentliche zu fokussieren.