4.8 4 Votes
Artikel-Rating

Eine User Story ist die am weitesten verbreitete Form von Product Backlog Items. Für Neulinge in Scrum sind User Stories häufig recht gewöhnungsbedürftig und fühlen sich „irgendwie seltsam“ an. In diesem Artikel habe ich deshalb einmal alles Wissenswerte zu User Stories zusammengetragen, um Eurem Scrum Team die eine oder andere Stolperfalle im nächsten Backlog Refinement zu ersparen.

Vorteile von User Stories

User Stories haben zwei wichtige Vorteile gegenüber klassischen Anforderungen oder Feature-Beschreibungen. Erstens legen sie den Fokus Deines Teams auf den entstehenden Nutzen für den Kunden. Und zweitens bieten sie durch die Art und Weise, wie sie formuliert sind, ausreichend Spielraum sie umzusetzen. Dieser Freiraum ermöglicht Eurem Team kreative Lösungsansätze.

Fokus auf Kundennutzen

User Stories bieten den Vorteil, dass sie den Fokus Deines Scrum Teams weg von Eurem Produkt hin zu Eurem Nutzer verschieben. Für Euer Team geht es mit Hilfe von User Stories nicht mehr darum, „Anforderung xy zu programmieren“ oder „Modul 123 umzusetzen“, sondern zu wissen, was Eure Nutzer mit Eurem Produkt erreichen möchten.

Kreative Lösungsansätze

Durch diesen Fokus auf Kundennutzen wird gleichzeitig ein zweiter Vorteil von User Stories möglich. Denn durch weniger konkrete Vorgaben, wie eine Lösung genau auszusehen hat, werden kreative Lösungsansätze möglich. Eine User Story schreibt Euch nämlich nicht vor, wie eine bestimmte Funktion umzusetzen ist.

Aufbau einer User Story

Um diesen kreativen Freiraum und den Fokus auf den Kundennutzen zu ermöglichen, hat sich für User Stories ein Schema etabliert, das von dem meisten Scrum Teams genutzt wird. (Es gibt zwar noch einige Varianten dieses Schemas, aber die sollen uns hier nicht weiter interessieren.)

  • Erstens gibt eine User Story die Rolle desjenigen an, der etwas erledigen möchte.

  • Zweitens beschreibt sie, welche Aktion oder Handlung durchgeführt werden soll.

  • Und drittens beinhaltet sie auch den Grund oder Zweck, warum diese Aktion gewünscht ist.

Diese drei Punkte werden dann zu einer User Story zusammengefasst:

Als Rolle möchte ich Aktion, damit ich Grund/Zweck.

Für das Mitglied einer Krankenkasse könnte es beispielsweise folgende User Story geben:

Als Kassenpatient möchte ich Bilder und Screenshots von meinem Krankenschein an meine Krankenkasse übermitteln können, damit ich diese nicht mehr per Brief versenden muss.

Akzeptanzkriterien einer User Story

Für sich alleine genommen sind User Stories nach diesem Schema jedoch zunächst noch ziemlich ungenau. (Was ja wie eingangs erwähnt auch durchaus beabsichtigt ist.) Deshalb werden sie während Eures Product Backlog Refinements mit Hilfe sogenannter Akzeptanzkriterien konkretisiert.

Das Wichtige dabei ist jedoch, dass diese Klärung mit Hilfe von Akzeptanzkriterien gemeinsam und kollaborativ erfolgt und nicht durch feste Vorgaben des Product Owners, an denen nicht gerüttelt werden darf.

Für unsere Krankenkassen-User-Story wären beispielsweise folgende Akzeptanzkriterien denkbar:

  • Der Upload funktioniert mit den Formaten jpeg, png und webp.

  • Hochgeladene Bilder werden (automatisch) auf maximal 2MB verkleinert, um Platz auf dem Server zu sparen.

  • Der Upload ist sowohl über den Browser als auch über unsere App möglich.

  • Der Upload wird von allen gängigen Browsern (Chrome, Firefox & Safari) unterstützt.

„Schneiden“ von User Stories (Splitting)

Wenn die Entwickler Eures Scrum Teams gemeinsam mit Eurem Product Owner eine User Story im Refinement besprechen und dabei Akzeptanzkriterien festlegen, kommt es häufig vor, dass sich diese als „zu groß für einen einzigen Sprint“ entpuppt.

Damit Ihr jedoch in der Lage seid, zum Ende Eures Sprints ein nutzbares Inkrement zu liefern, muss eine User Story natürlich klein genug sein, um innerhalb eines Sprints umsetzbar zu sein.

Auch in diesem Fall bieten Akzeptanzkriterien eine gute Möglichkeit, ein sogenanntes User Story Splitting vorzunehmen. (Häufig wird das auch als „Schneiden“ von User Stories bezeichnet.)

Unsere User Story Upload Krankenschein ließe sich beispielsweise in zwei neue User Stories splitten: Eine User Story für den Upload über den Browser und eine User Story für den Upload per App. Auch die automatische Verkleinerung der Bildgröße ließe sich in einer andere User Story ausgliedern, um den Aufwand zu verringern.

Beim Schneiden von User Stories müsst Ihr jedoch darauf achten, dass jede neu entstehende User Story noch Nutzen stiftet!

User Stories schätzen

Die im Refinement ausgehandelten Akzeptanzkriterien geben Euch darüber hinaus ein Gefühl davon, was alles erledigt werden muss, um eine User Story zum Leben zu erwecken. Dieser Aufwand bei der Umsetzung einer User Story wird von den meisten Scrum Teams mit Hilfe von Story Points geschätzt.

Im Gegensatz zu Personentagen bieten sie einige Vorteile und sind in der Regel viel genauer, weil es sich um eine relationale Schätzung handelt (statt einer absoluten Schätzung in Stunden oder Tagen).

  • Mehr zu diesen Methoden der Aufwandsschätzung erfährst Du in meinen Artikeln zu Story Points, Planning Poker und Magic Estimation.

  • Gelegentlich kann eine User Story auch nicht schätzbar sein, weil entweder Deinem Team die notwendige Expertise fehlt oder weil die Softwarearchitektur zu komplex ist. In diesem Fall stellt eine sogenannte Spike Story einen möglichen Lösungsweg dar.

Die INVEST-Formel für User Stories

Die INVEST-Formel hilft Euch dabei, Euch alle in diesem Artikel genannten Punkte besser merken zu können, damit Ihr sie im Refinement nicht vergesst. (Ursprünglich stammt diese Formel übrigens aus dem Extreme Programming und geht auf Bill Wake zurück.)

INVEST ist ein Akronym und steht für:

  • Independent

  • Negotiable

  • Valuable

  • Estimatable

  • Short (enough for one Sprint)

  • Testable

Wenn Euer Team diese sechs Grundsätze für gute User Stories im Refinement beachtet, könnt Ihr potenziellem Ärger während Eures nächsten Sprints deutlich minimieren.

Darüber hinaus ist die INVEST-Formel auch eine gute Orientierung, falls Ihr eine sogenannte Definition of Ready entwerfen möchte.

User Stories, die alle sechs Punkte der INVEST-Formel erfüllen, werden dann von Eurem Team als sprint ready betrachtet.

Die Definition of Ready wird allerdings gar nicht im Scrum Guide erwähnt und Euer Team sollte sie (meiner Ansicht nach) mit Vorsicht genießen, da sie schnell zu einer Art „Gatekeeper“ mutiert. Schnell kann es passieren, dass sich Euer Scrum Team durch sie in Richtung Wasserfall-Denken bewegt.

Werfen wir noch einen kurzen Blick auf die sechs Punkte der INVEST-Formel, um sie ein wenig genauer zu fassen.

Independent

Eine gute User Story sollte (wann immer möglich) unabhängig sein. Und damit sind sowohl interne Abhängigkeiten (zu anderen User Stories) gemeint, als auch externe Abhängigkeiten zu anderen Abteilungen, Teams, Kunden etc.

Je unabhängiger Eure User Stories sind, desto besser kann Euer Scrum Team sein Sprintziel aus eigener Kraft erreichen. Je mehr Abhängigkeiten existieren, desto eher werden die Entwickler Eures Teams zum Spielball von Einflüssen, die sie selbst nicht auflösen können.

Versucht daher immer, Eure User Stories so zu gestalten, dass Abhängigkeiten zu anderen User Stories eliminiert werden. Wenn sich diese nicht vermeiden lassen, lohnt es sich, darüber nachzudenken, beide User Stories gleichzeitig in einem Sprint umzusetzen.

  • Besonders problematisch wird es immer dann, wenn drei oder mehr Teams voneinander abhängig sind. Das Scrum Framework Nexus, bei dem mehrere Teams an einem gemeinsamen Produkt Backlog arbeiten, löst diese Problematik mit Hilfe des Nexus Integration Teams und des Nexus Sprint Backlogs.

Gib es externe Abhängigkeiten, dann kann es manchmal auch sinnvoll sein, eine User Story nicht mit in Euren nächsten Sprint zu übernehmen, bis diese Abhängigkeit aufgelöst ist. Hier müsst Ihr jedoch besonders aufpassen. Denn durch dieses Vorgehen kann sehr schnell Wasserfall-Denken in Eurem Team entstehen: „Bevor wir nicht die Zusage vom Lieferanten haben, fangen wir gar nicht erst mit der Arbeit an.“

Solange Euer Scrum Team jedoch genügend andere (gleichermaßen wichtige) Aufgaben erledigen kann, die solche Abhängigkeiten nicht haben, ist es legitim, diese vorzuziehen. (Hier hat jedoch Euer Product Owner das letzte Wort.)

Externe Abhängigkeiten sind in der Regel Impediments und es ist die Aufgabe Eures Scrum Masters, diese aufzulösen, wenn es den Entwicklern nicht alleine gelingen sollte.

Falls externe Abhängigkeiten existieren, darf Dein Scrum Team nicht einfach warten, bis sich die Probleme in Luft auflösen, sondern muss aktiv daran arbeiten, sie aus dem Weg zu räumen.

  • Darüber hinaus ist es ist hilfreich, identifizierte Risiken und Impediments bereits beim Sprint Planning zu thematisieren und sie im besten Fall in Aufgaben zu transformieren. Wie das geht, erfährst Du in meinem Artikel Plannings mit der Team Alignment Map durchführen.

Negotiable & Negotiated

Jede User Story sollte außerdem verhandelbar sein. Das bedeutet, dass eine User Story eben kein kleinteiliger Auftrag oder präzise Vorgabe ist, sondern den Entwicklern Eures Teams Spielraum bei der Umsetzung bietet. User Story geben zwar vor, was Kunden, Nutzer oder Stakeholder brauchen und warum sie eine bestimmte Funktion benötigen, legen aber nicht fest, wie die Lösung genau auszusehen hat.
0
Wie frei und verhandelbar sind User Stories, wenn Ihr sie in Eurem Team besprecht? Welche Herausforderungen habt Ihr dabei?x

Das oben vorgestellte Schema hilft Euch dabei, diesen Spielraum zu ermöglichen und die genauen Details erst später gemeinsam im Refinement festzulegen.

Valuable

User Stories müssen einen Nutzen stiften und einen Wert haben. Damit wird sichergestellt, dass Ihr nur das entwickelt, was auch den Wert des Produktes steigert. Und keine Zeit für Funktionen verschwendet wird, die niemand braucht.

Auch hier ist natürlich wieder Euer Product Owner gefragt. Durch die Priorisierung des Product Backlogs kann er steuern, welche Features und User Stories als nächstes umgesetzt werden sollen.

Estimatable

Eine User Story muss außerdem schätzbar sein. Bevor es an die Umsetzung geht, muss allen Beteiligten klar sein, wieviel Aufwand dahintersteckt, sie zum Leben zu erwecken. Denn falls Ihr herausfinden solltet, dass der entstehende Aufwand den potenziellen Nutzen nicht rechtfertig, kann dies ein Argument dafür sein, eine bestimmte User Story gar nicht umzusetzen.

Nutzen und Wert alleine helfen Euch also nicht dabei, zu entscheiden, was umgesetzt werden soll.

Short

Eine gute User Story sollte kurz sein. Und zwar vor allem kurz genug für einen einzigen Sprint. Der Grundgedanke von Scrum ist es ja, zum Ende Eures Sprints in der Sprint Review ein fertiges und nutzbares Inkrement präsentieren zu können. Wenn Ihr Euch mit Dingen beschäftigt, die länger als einen Sprint dauern, führt Ihr diese Grundidee von Scrum ad absurdum.

Und ja, natürlich gibt es große Anforderungen, die länger als einen Sprint dauern können. Aber (fast) jede noch so große Anforderung lässt sich in zwei oder mehrere Teile zerlegen.

Ihr müsst allerdings darauf achten, dass jede einzelne User Story noch immer eine neue Funktion für Euren Nutzer darstellt.

Testable

Zu guter Letzt sollten Eure User Stories testbar sein. Zu wissen, wie etwas später getestet werden muss, ist ein guter Indikator dafür, dass alle verstanden haben, was eine User Story bzw. ein neues Feature tatsächlich bewirken soll.

  • Beim Testen von User Stories spielen natürlich sowohl Eure Definition of Done als auch Eure Akzeptanzkriterien eine wichtige Rolle.

User Story Mapping

Einzelne User Stories bieten für sich alleine genommen zwar bereits neue Möglichkeiten für den Nutzer Eures Produktes, allerdings sind für einen kompletten Arbeitsschritt häufig mehrere User Stories notwendig.

Deshalb ist es sehr hilfreich, einzelne User Stories nicht isoliert zu betrachten. Sondern gemeinsam zu überlegen, welche Teilschritte sich zu einem ganzen Prozess zusammenfügen.

Eine Lösung, um diesen Umstand abzubilden, ist das sogenannte User Story Mapping. Hierbei werden User Stories einem gesamten Prozess zugeordnet und können so besser im Product Backlog priorisiert werden.

Darüber hinaus ist User Story Mapping für Euren Product Owner sehr hilfreich, um einzelne Releases zu festzulegen.

Nachteile von User Stories

User Stories sind für Euer Scrum Team ein erster guter Schritt in die richtige Richtung, um den Kundennutzen in den Fokus Eures Denkens zu nehmen. Allerdings haben sie auch einen Nachteil, den ich an dieser Stelle nicht verschweigen möchte.

Fehlender Kontext

Der grundsätzliche Problem, das durch User Stories entsteht, steckt schon in der Bezeichnung selbst. Mit User Stories gehen wir davon aus zu wissen, wie wir eine Funktion gestalten sollten, nur weil wir wissen, wer etwas erledigen möchte. Das ist jedoch gar nicht (immer) der Fall.

Oft ist der Kontext, in dem eine Aufgabe erledigt werden soll, viel ausschlaggebender als die Frage, wer diese Aufgabe erledigen möchte. Beim Kontext geht es vielmehr um die Fragen Wann?, Wo?, Wie? oder Wer ist noch dabei?

Wenn ich auf Netflix abends mit meinen Kindern einen Film aussuchen möchte, dann sind die Anforderungen ganz andere, als wenn es früher Nachmittag ist und meine Ehefrau neben mir auf dem Sofa sitzt.

  • Eine Antwort auf diese Fragen gibt die sogenannte Job Story, die auf der Jobs to Be Done Methodik basiert. Sie sind damit eine gute Alternative zu klassischen User Stories, wenn Ihr den Kundenfokus in Eurem Scrum Team noch weiter vertiefen möchtet.

Fazit zu User Stories

Richtig angewendet haben User Stories das Potenzial, den Fokus Eurer Produktentwicklung auf den Nutzen für Eure Kunden zu lenken. Darüber hinaus sind sie eine gute Hilfestellung, inkrementelle Produktentwicklung in Eurem Scrum Team zu verankern.

Du hast noch Fragen, Ideen, Anregung oder Kritik zu diesem Artikel? Dann hinterlasse mir einen Kommentar hier unten auf der Seite! Ich freu mich auf Dein Feedback.