User Story

Wenn ein Team eine App oder eine Webseite baut, muss vorher jemand aufschreiben, was gebaut werden soll. Eine User Story ist eine sehr kurze Form dieser Beschreibung, meist nur ein oder zwei Sätze. Sie erzählt aus Sicht eines Menschen, der das Programm später benutzt: Wer ist er, was will er tun, und was hat er davon? Ein Beispiel: „Als Kundin möchte ich meine Bestellung verfolgen können, damit ich weiß, wann das Paket kommt.“ Auffällig ist, was nicht drinsteht: kein Wort darüber, wie die Sache technisch gelöst wird. Genau das ist Absicht, denn die Lösung sollen die Entwickler finden, nicht der Auftraggeber.

Warum Teams in Wünschen statt in Funktionen denken

Früher schrieben Firmen dicke Lastenhefte, in denen jede Funktion vorab festgelegt war. Das Problem: Bis so ein Dokument fertig war, hatten sich die Anforderungen oft schon geändert. Außerdem stand darin, was das Programm können soll, aber nicht, wofür jemand es überhaupt braucht. So entstanden Funktionen, die technisch korrekt waren und trotzdem niemand nutzte.

Die User Story dreht das um. Sie zwingt zu der Frage nach dem Nutzen, weil das „damit“-Ende sonst leer bleibt. Wer keinen Grund formulieren kann, hat vielleicht auch keinen guten. Auf diese Weise fällt schon beim Aufschreiben auf, wenn eine Idee eigentlich überflüssig ist.

Ein zweiter Vorteil ist die Größe. Eine Story soll klein genug sein, dass ein Team sie in wenigen Tagen fertigstellen kann. Dadurch gibt es regelmäßig etwas Vorzeigbares, statt monatelang nur Zwischenstände. Diese Arbeitsweise gehört zu einem Ansatz, den man agile Entwicklung nennt: in kurzen Runden bauen, zeigen, Rückmeldung einsammeln, nachbessern.

Aufbau, Akzeptanzkriterien und Schätzpunkte

Die verbreitetste Form folgt einer festen Schablone: „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“. Die Rolle ist wichtig, weil verschiedene Menschen verschiedene Dinge brauchen. Eine Lehrerin will andere Ansichten in einer Schul-App als ein Schüler. Steht dort nur „der Benutzer“, geht diese Unterscheidung verloren.

Zur Story gehören meist Akzeptanzkriterien. Das ist eine kurze Liste von Bedingungen, die erfüllt sein müssen, damit die Aufgabe als erledigt gilt. Bei der Paketverfolgung könnte dort stehen: Der Status ist ohne Anmeldung sichtbar, und bei fehlender Sendungsnummer erscheint eine verständliche Meldung. Ohne solche Kriterien streiten Team und Auftraggeber später darüber, ob etwas fertig ist oder nicht.

Vor der Umsetzung schätzt das Team den Aufwand, oft in sogenannten Story Points. Das sind keine Stunden, sondern Vergleichswerte: Eine Story mit acht Punkten ist ungefähr doppelt so aufwendig wie eine mit vier. Nach einigen Wochen weiß das Team aus Erfahrung, wie viele Punkte es pro Runde schafft. Ein häufiger Irrtum ist, die Story selbst für ein vollständiges Konzept zu halten. Sie ist eher eine Erinnerung an ein Gespräch, das noch geführt werden muss.

Vom Ticketsystem bis zum KI-Assistenten

In Firmen begegnen User Stories vor allem in Werkzeugen wie Jira, Trello oder Azure DevOps. Dort steht jede Story auf einer eigenen Karte, die von Spalte zu Spalte wandert: geplant, in Arbeit, getestet, fertig. Die gesammelten offenen Stories bilden das Backlog, also die Vorratsliste des Teams. Wer ein Praktikum in einer Softwarefirma macht, sieht diese Karten fast garantiert.

Auch außerhalb der IT taucht die Denkweise auf. Marketing-Abteilungen, Behörden und Schulen formulieren Vorhaben inzwischen ähnlich, weil die Frage nach dem Nutzen überall hilft. In Stellenanzeigen liest man deshalb oft, dass Bewerber Erfahrung mit User Stories mitbringen sollen.

Neuerdings spielen Sprachmodelle eine Rolle: Teams lassen sich Entwürfe für Stories und Akzeptanzkriterien von einem KI-Assistenten vorschlagen. Das spart Tipparbeit, ersetzt aber nicht das Gespräch mit echten Nutzern. Eine KI kann formulieren, was plausibel klingt. Ob es jemand wirklich braucht, weiß nur, wer nachfragt.