User-Story-Beispiel
Sechs ausformulierte User Storys mit Akzeptanzkriterien zu einer Funktion: Anforderungen, die sich schätzen, umsetzen und abnehmen lassen.
1 Überblick
Eine User Story beschreibt in einem Satz, was eine bestimmte Person mit einer Anwendung tun möchte und wozu: Als Rolle möchte ich ein Ziel erreichen, damit ich einen Nutzen habe. Sie ist die kleinste Form einer Anforderung, die auch ohne technisches Wissen verständlich bleibt. Mehrere Storys zu einer Funktion sagen dem Entwicklungsteam, was gebaut werden soll, und Ihnen, was Sie vor der Abnahme prüfen.
Der Satz allein reicht dafür nicht. Brauchbar wird eine Story erst durch ihre Akzeptanzkriterien: eine kurze Liste von Bedingungen, die erfüllt sind oder nicht. Sie machen aus einem Wunsch etwas, das sich schätzen, umsetzen und testen lässt.
Was zu einer guten Story gehört
- Eine konkrete Rolle. Schreiben Sie nicht „der Nutzer“, sondern Einkäuferin, Disponent oder Administratorin. Verschiedene Rollen brauchen von derselben Seite Verschiedenes.
- Genau ein Ziel. Steht im Satz ein „und“, sind es meist zwei Storys.
- Der Nutzen. Er erklärt dem Team das Warum und hilft bei Details, die niemand geregelt hat. Fällt Ihnen kein Nutzen ein, ist die Story vielleicht überflüssig.
- Drei bis sieben Akzeptanzkriterien, die sich jeweils mit Ja oder Nein beantworten lassen, einschließlich der Fälle, in denen etwas schiefgeht.
- Eine Priorität, damit klar ist, was bei Zeitknappheit entfallen kann.
- Ein Vermerk, was ausdrücklich nicht zur Funktion gehört.
Akzeptanzkriterien formulieren
Beschreiben Sie, was sich beobachten lässt, und nicht, wie es gebaut wird. „Die Bestellung erscheint am Folgetag in der Tourenplanung“ kann jeder prüfen. „Das System nutzt eine Warteschlange“ ist eine technische Entscheidung und gehört nicht hierher.
Ersetzen Sie unscharfe Wörter durch Zahlen. „Rechtzeitig“ oder „schnell“ lässt sich nicht testen, „bis 12 Uhr am Vortag“ schon.
Denken Sie an die Ausnahmen: Ein Artikel ist nicht lieferbar, die Frist ist abgelaufen, die Lieferung fällt auf einen Feiertag. Bei der Abnahme wird fast immer über Fälle gestritten, die niemand aufgeschrieben hat.
Häufige Fehler
Storys ohne Rolle und Nutzen, die in Wahrheit Arbeitsaufträge sind: „Button im Dashboard ergänzen“.
Zu große Storys. „Als Kunde möchte ich meine Bestellungen verwalten“ enthält Anlegen, Ändern, Pausieren und Beenden. Was sich nicht in wenigen Tagen umsetzen und vorführen lässt, wird geteilt.
Technische Aufgaben im Story-Format. „Als Entwickler möchte ich eine Datenbanktabelle“ hat weder Nutzer noch Nutzen. Solche Arbeiten sind nötig, gehören aber in die Aufgabenliste des Teams.
Kriterien, die das Layout bis ins Detail vorgeben. Beschreiben Sie das Verhalten und überlassen Sie die Gestaltung dem Entwurf.
Die eigenen Beschäftigten vergessen. Fast jede Funktion für Kundinnen und Kunden erzeugt Arbeit oder Informationsbedarf im Innendienst. Diese Storys gehören dazu.
Die Story als Ersatz für das Gespräch behandeln. Sie ist der Anlass, ein Detail gemeinsam zu klären; das Ergebnis steht danach in den Kriterien.
So verwenden Sie das Beispiel
Lesen Sie die sechs Storys als Einheit: Sie decken Kundschaft, Innendienst und Sonderfälle einer einzigen Funktion ab. Für Ihre eigene Funktion notieren Sie zuerst die Rollen, schreiben pro Ziel eine Story und ergänzen Kriterien, bis Sie die Story selbst testen könnten, ohne nachzufragen.
2 Beispiel
Die Storys beschreiben eine Funktion im Kundenportal eines erfundenen Getränkegroßhandels: die Dauerbestellung für Gastronomiekunden. Unternehmen, Personen und alle Zahlen sind frei erfunden und dienen nur der Veranschaulichung.
Funktion: Dauerbestellung im Kundenportal
Getränkehandel Ibenhorst GmbH. Verfasst von Carla Wiegmann (Leitung Innendienst) mit Tobias Rehfeld (Entwicklung). Stand: Version 2.
Hintergrund: Rund 180 Gastronomiekunden bestellen jede Woche fast dasselbe, bisher per Telefon oder E-Mail. Vereinbarte Regel: Änderungen sind bis 12 Uhr am Werktag vor der Lieferung möglich.
Story 1: Dauerbestellung anlegen (Muss)
Als Einkäuferin eines Gastronomiebetriebs möchte ich eine Bestellung als Dauerbestellung speichern, damit ich meine Standardlieferung nicht jede Woche neu aufgeben muss.
Akzeptanzkriterien:
- Aus jedem Warenkorb und aus jeder früheren Bestellung lässt sich eine Dauerbestellung anlegen.
- Wählbar sind der Liefertag (Montag bis Freitag) und der Rhythmus wöchentlich oder vierzehntäglich.
- Vor dem Speichern zeigt das Portal das Datum der ersten Lieferung.
- Pro Kundenkonto sind höchstens drei Dauerbestellungen möglich; beim Versuch, eine vierte anzulegen, erscheint ein Hinweis.
Story 2: Einzelne Lieferung anpassen (Muss)
Als Einkäuferin möchte ich die Mengen für eine einzelne Lieferung ändern, damit ich auf Veranstaltungen oder ruhige Wochen reagieren kann, ohne die Dauerbestellung zu verändern.
Akzeptanzkriterien:
- Die nächsten vier Lieferungen werden mit Datum und Positionen angezeigt.
- Mengen lassen sich bis 12 Uhr am Werktag vor der Lieferung ändern, Artikel hinzufügen oder entfernen.
- Die Änderung gilt nur für diese Lieferung; die folgenden bleiben unverändert.
- Nach Ablauf der Frist sind die Felder gesperrt, und das Portal nennt die Telefonnummer des Innendienstes.
Story 3: Dauerbestellung pausieren (Muss)
Als Einkäuferin möchte ich die Dauerbestellung für einen Zeitraum aussetzen, damit während der Betriebsferien nichts geliefert wird.
Akzeptanzkriterien:
- Wählbar sind ein Start- und ein Enddatum; die Pause dauert höchstens acht Wochen.
- Das Portal zeigt, welche Lieferungen entfallen und wann die nächste wieder stattfindet.
- Eine Pause lässt sich bis zu ihrem Beginn wieder aufheben.
Story 4: Hinweis bei nicht lieferbaren Artikeln (Muss)
Als Einkäuferin möchte ich vor der Lieferung erfahren, wenn ein Artikel fehlt, damit ich rechtzeitig Ersatz bestellen kann.
Akzeptanzkriterien:
- Ist ein Artikel am Werktag vor der Lieferung um 8 Uhr nicht lieferbar, geht eine E-Mail mit Artikel und Menge an die hinterlegte Adresse.
- Die E-Mail enthält einen Link zur betroffenen Lieferung.
- Die übrigen Positionen werden unverändert geliefert.
Story 5: Dauerbestellungen in der Tourenplanung sehen (Muss)
Als Disponent möchte ich die Lieferungen aus Dauerbestellungen in der Tagesübersicht erkennen, damit ich die Touren am Werktag vor der Lieferung vollständig planen kann.
Akzeptanzkriterien:
- Lieferungen aus Dauerbestellungen erscheinen ab 12 Uhr am Werktag vor der Lieferung in der Übersicht und sind gekennzeichnet.
- Geänderte Mengen sind gegenüber der Standardmenge hervorgehoben.
- Fällt der Liefertag auf einen gesetzlichen Feiertag, wird die Lieferung auf den vorherigen Werktag gelegt und der Kunde per E-Mail informiert.
Story 6: Dauerbestellung im Kundenauftrag ändern (Soll)
Als Mitarbeiterin im Innendienst möchte ich die Dauerbestellung eines Kunden bearbeiten, damit ich telefonische Änderungswünsche sofort erledigen kann.
Akzeptanzkriterien:
- Die Bearbeitung ist nur mit der Rolle Innendienst möglich.
- Jede Änderung wird mit Name, Datum und Uhrzeit protokolliert und ist für den Kunden im Portal sichtbar.
Nicht Teil dieser Funktion
Abweichende Lieferadressen je Lieferung, Preisvereinbarungen, Pfandabrechnung.
3 Für wen das relevant ist
Produktmanagement
Sie erhalten einen vollständigen Satz von Storys zu einer Funktion, mit Prioritäten und Sonderfällen, als Muster dafür, wie Sie eigene Funktionen in schätzbare und einzeln abnehmbare Teile zerlegen.
Betriebsleitung
Sie sehen, wie Abläufe aus dem Tagesgeschäft, etwa Fristen, Feiertage und nicht lieferbare Artikel, als prüfbare Kriterien festgehalten werden, damit die Software später zu Ihrem Betrieb passt.
Projektleitung
Sie können die Akzeptanzkriterien direkt als Checkliste für die Abnahme verwenden, und die Einteilung in Muss und Soll zeigt, wie sich ein Termin halten lässt, wenn die Zeit knapp wird.
4 Fragen und Antworten
Wie viele Akzeptanzkriterien braucht eine User Story?
In der Regel drei bis sieben. Bei weniger als drei fehlen meist die Ausnahmefälle. Bei mehr als sieben oder acht ist die Story vermutlich zu groß und sollte geteilt werden, häufig entlang der Grenze zwischen Normalfall und Sonderfällen.
Wer schreibt die User Storys, Auftraggeber oder Entwickler?
Satz und Nutzen schreibt, wer die Anwenderinnen und Anwender am besten kennt, also meist der Auftraggeber oder die Produktverantwortliche. Die Akzeptanzkriterien entstehen am besten gemeinsam mit dem Entwicklungsteam, weil es nach Sonderfällen fragt, an die Fachleute aus dem Betrieb nicht denken.
Ersetzen User Storys ein Lastenheft?
Für eine einzelne Funktion oder ein agiles Projekt oft ja. Bei einem Festpreisvertrag brauchen Sie meist zusätzlich ein Dokument, das den Gesamtumfang, Anforderungen an Leistung und Sicherheit sowie die Abgrenzungen festhält. Die Storys können dessen fachlichen Teil bilden.
Sie planen ein ähnliches Projekt?
Schildern Sie uns Ihr Vorhaben. Sie erhalten eine klare Einschätzung zu Umfang, Vorgehen und Aufwand.