User Story: Format, Akzeptanzkriterien und Beispiele

Dein Team baut seit sechs Wochen an einem neuen Angebotsprozess. Gestern kam die erste Version. Und der Vertrieb sagt: „Das ist nicht das, was wir gemeint haben.“

Kennst du. Ich kenne es auch. Bei uns in Bochum arbeiten über 70 Mitarbeiter, davon mehr als 20 im Vertrieb. Jedes Mal, wenn wir intern etwas Neues bauen — ein Dashboard, einen Prozess, eine Automatisierung — entscheidet eine einzige Sache darüber, ob das Ergebnis passt: Wie präzise war die Anforderung, bevor jemand angefangen hat?

Genau dafür gibt es die User Story. Sie ist kein Software-Spielzeug und kein Berater-Vokabular. Sie ist ein Satz, der drei Dinge festhält: wer etwas braucht, was er braucht und warum. Und sie zwingt dich, das Warum zu beantworten — den Teil, den in klassischen Anforderungslisten fast immer jemand weglässt.

In diesem Artikel bekommst du das Format, das Qualitätsraster INVEST, die Akzeptanzkriterien und mehrere Beispiele aus dem Mittelstand. Nicht aus einem Software-Konzern. Aus Betrieben mit 8, 30 oder 120 Mitarbeitern.

Was ist eine User Story?

Eine User Story ist eine kurze Beschreibung einer Anforderung aus der Sicht dessen, der sie nutzen wird. Sie steht in einem Satz, sie ist bewusst unvollständig, und sie ist verhandelbar. Sie beschreibt einen Nutzen — keine Lösung.

Das ist der ganze Kern. Und trotzdem geht er in 90 Prozent der Betriebe verloren, weil dort Anforderungen so klingen: „Wir brauchen ein Feld für die Kundennummer im Formular.“ Das ist keine Anforderung. Das ist eine Lösung, die schon jemand vorentschieden hat, bevor überhaupt klar war, welches Problem sie löst.

Die Story dreht das um. Sie fragt zuerst: Wer sitzt vor dem Problem? Was will der Mensch erreichen? Und was hat er davon, wenn es funktioniert? Erst wenn diese drei Antworten stehen, redet das Team über die Umsetzung.

Der Begriff stammt aus dem Extreme Programming der späten 90er und wurde über die agile Bewegung zum Standard. Die dahinterliegende Haltung steht im Agilen Manifest, das seit 2001 im Originaltext auf Deutsch verfügbar ist: Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung. Die User Story ist das Werkzeug, das diesen Satz in den Arbeitsalltag übersetzt.

Die drei C: Karte, Gespräch, Bestätigung

Eine Story besteht nach der klassischen Lesart aus drei Bestandteilen. Merk sie dir als die drei C:

• Karte (Card): Der eine Satz. Kurz genug, dass er auf eine Karteikarte passt. Wenn du eine DIN-A4-Seite brauchst, ist es keine Story mehr, sondern ein Konzept.
• Gespräch (Conversation): Das Gespräch zwischen dem, der die Story schreibt, und dem, der sie umsetzt. Hier entstehen die Details. Die Karte ist der Anlass, nicht der Ersatz.
• Bestätigung (Confirmation): Die Akzeptanzkriterien. Sie legen fest, woran alle erkennen, dass die Story erledigt ist.

Der zweite Punkt ist der, den Betriebe am häufigsten überspringen. Sie schreiben die Karte, schicken sie per E-Mail weiter und wundern sich über das Ergebnis. Eine Story ohne Gespräch ist ein Zettel mit einem Wunsch drauf. Punkt.

Warum das nicht nur für Software gilt

Die meisten Texte zu diesem Thema erklären dir Anforderungen für Programmierer. Damit kannst du als Handwerksbetrieb, Maschinenbauer oder Dienstleister erst mal nichts anfangen.

Übersetz es. Eine User Story funktioniert überall dort, wo jemand etwas für jemand anderen baut oder verändert:

• Ein neuer Ablauf im Kundenservice
• Eine Vorlage, die der Außendienst benutzen soll
• Ein Bericht, den die Geschäftsführung monatlich lesen will
• Ein Onboarding-Ablauf für neue Mitarbeiter
• Eine Änderung an der Website

Der Hebel im Vertrieb ist dabei der größte, den ich kenne. Bei uns läuft jede Änderung am Vertriebsablauf über diese drei Fragen — vom Nachfassrhythmus bis zum Feld im Kontaktdatensatz. Der Grund ist simpel: Im Vertrieb kostet jede Fehlentwicklung doppelt. Einmal die Arbeitszeit, die in den Bau geflossen ist. Und einmal die Termine, die in der Zwischenzeit nicht stattgefunden haben. Wer vorher eine Story schreibt, die den Nutzen in Terminen oder Abschlüssen benennt, merkt beim Schreiben, ob sich der Aufwand überhaupt rechnet.

Überall gilt dieselbe Frage: Wer? Was? Wozu? Wer die Frage nicht beantworten kann, sollte nicht anfangen zu bauen. Das ist kein agiles Prinzip, das ist gesunder Menschenverstand — die agile Methodik hat ihm nur ein Format gegeben. Wie sich das in das größere Bild einordnet, steht im Überblick zum Projektmanagement.

Das Format: Als Rolle möchte ich Ziel, um Nutzen

Das Standardformat einer User Story lautet: „Als möchte ich , um .“ Drei Bausteine, feste Reihenfolge, kein Beiwerk.

Ein Beispiel aus unserem eigenen Betrieb:

Als Vertriebsmitarbeiter im Innendienst möchte ich beim Öffnen eines Kontakts sofort sehen, wann wir zuletzt gesprochen haben, um den Anruf ohne Vorbereitung starten zu können.

Lies den Satz noch mal und achte darauf, was nicht drinsteht: kein Wort über Datenbanken, keine Bildschirmmaske, keine Farbe. Die Story beschreibt das Problem. Die Lösung bespricht das Team.

Die Rolle: wer genau, nicht „der Nutzer“

Der häufigste Fehler steht schon im ersten Baustein. „Als Nutzer möchte ich …“ ist wertlos. Welcher Nutzer? Der Außendienstler mit dem Tablet im Auto? Die Buchhaltung? Der Kunde selbst?

Je präziser die Rolle, desto präziser das Ergebnis. Wenn du beschreiben kannst, wer da sitzt, weißt du auch, unter welchen Bedingungen er arbeitet — Zeitdruck, schlechtes Netz, Handschuhe an. Das verändert die Lösung komplett.

Wenn dir dabei auffällt, dass du deine eigenen Rollen gar nicht sauber kennst, ist die Kundensegmentierung die Hausaufgabe, die vorher fällig ist. Rollen sind keine Erfindung — sie sind Beobachtung.

Das Ziel: was, nicht wie

Der Mittelteil beschreibt, was die Rolle erreichen will. Die Versuchung ist riesig, hier schon die Lösung hineinzuschreiben. „… möchte ich einen Button oben rechts …“ — falsch. Der Button ist eine Antwort auf eine Frage, die noch keiner gestellt hat.

Prüf jede Story mit einem einzigen Test: Steht im Mittelteil ein Werkzeug oder ein Ziel? Steht dort ein Werkzeug, frag „wozu?“ und schreib die Antwort hin. Wiederhol das, bis der Satz ohne Werkzeug auskommt.

Der Nutzen: der Teil, den alle weglassen

Der dritte Baustein ist der wertvollste — und der, der in der Praxis zuerst gestrichen wird. „Um …“ beantwortet, warum sich der Aufwand lohnt.

Und genau hier entscheidet sich, ob eine Aufgabe überhaupt gemacht werden sollte. Wenn der Nutzen lautet „um es einheitlicher zu haben“, dann hast du eine Story ohne Geschäftswert. Wenn er lautet „um die Angebotsnachfassung von drei Tagen auf einen zu verkürzen“, dann redest du über Umsatz.

Das ist dieselbe Denkweise, die hinter einer sauberen Value Proposition steht: Nicht das Merkmal zählt, sondern was es für den anderen verändert. Wer intern kein Nutzenversprechen formulieren kann, formuliert es extern auch nicht.

Akzeptanzkriterien: woran alle erkennen, dass es fertig ist

Akzeptanzkriterien sind die überprüfbaren Bedingungen, die erfüllt sein müssen, damit eine User Story als erledigt gilt. Sie sind die Bestätigung aus den drei C — und sie sind der Grund, warum die Story am Ende nicht in einer Diskussion endet, sondern in einer Abnahme.

Ohne Akzeptanzkriterien ist „fertig“ Verhandlungssache. Mit ihnen ist es eine Prüfung, die jeder im Raum durchführen kann. Genau deshalb sind Akzeptanzkriterien der Punkt, an dem sich Betriebe die meisten Rückläufer sparen.

Zwei Schreibweisen, die funktionieren

Für Akzeptanzkriterien haben sich zwei Formen durchgesetzt. Beide sind erlaubt, beide sind gut — such dir eine aus und bleib dabei.

Erstens: die Checkliste. Eine Liste überprüfbarer Aussagen, jede für sich mit Ja oder Nein zu beantworten:

• Der letzte Kontaktzeitpunkt ist ohne weiteren Klick sichtbar.
• Bei Kontakten ohne bisherigen Kontakt steht dort „noch kein Kontakt“.
• Die Anzeige lädt in unter zwei Sekunden.
• Die Anzeige funktioniert auch auf dem Tablet im Außendienst.

Zweitens: Gegeben-Wenn-Dann. Diese Form beschreibt Szenarien statt Zustände und stammt aus dem verhaltensgetriebenen Testen:

• Gegeben, ein Kontakt hatte in den letzten 90 Tagen ein Telefonat, wenn der Mitarbeiter den Kontakt öffnet, dann erscheint das Datum des letzten Telefonats in der Kopfzeile.
• Gegeben, ein Kontakt hatte noch nie ein Telefonat, wenn der Mitarbeiter ihn öffnet, dann erscheint der Hinweis „noch kein Kontakt“.

Die Checkliste ist schneller. Gegeben-Wenn-Dann ist genauer, weil sie Randfälle sichtbar macht. Für die meisten Mittelständler reicht die Checkliste — nimm Gegeben-Wenn-Dann dort, wo Fehler teuer werden.

Wie viele Akzeptanzkriterien eine Story braucht

Drei bis sieben. Weniger als drei heißt meistens, dass jemand nicht nachgedacht hat. Mehr als sieben heißt fast immer, dass in der Story zwei Stories stecken.

Das ist übrigens der beste Test für den Zuschnitt: Wenn du beim Schreiben der Akzeptanzkriterien merkst, dass die Liste nicht endet, teil die Story. Die Kriterien sind der Lackmustest für die Größe.

Und noch etwas: Akzeptanzkriterien schreibt nicht der Umsetzer allein. Sie entstehen im Gespräch zwischen dem, der den Nutzen will, und dem, der es baut. Wer sie im stillen Kämmerlein formuliert, produziert genau die Missverständnisse, die er verhindern wollte.

Akzeptanzkriterien sind nicht die Definition of Done

Diese beiden Dinge werden ständig verwechselt. Der Unterschied ist simpel:

• Akzeptanzkriterien gelten für eine Story. Sie sind jedes Mal andere.
• Definition of Done gilt für alle Stories im Team. Sie ist jedes Mal dieselbe — zum Beispiel: getestet, dokumentiert, vom Verantwortlichen abgenommen.

Eine Story ist fertig, wenn beides erfüllt ist. Nicht wenn eins von beidem erfüllt ist. Die Details zum Zusammenspiel im Team stehen im Überblick zu Scrum.

User Story Beispiel: drei Fälle aus dem Mittelstand

Theorie ist billig. Hier sind drei ausgeschriebene Beispiele — jeweils mit Akzeptanzkriterien, jeweils aus einem anderen Betriebstyp.

Beispiel 1: Vertrieb — Angebote nachfassen

Als Vertriebsmitarbeiter möchte ich täglich eine Liste der Angebote sehen, die seit sieben Tagen unbeantwortet sind, um sie nachzufassen, bevor der Interessent woanders kauft.

Akzeptanzkriterien:

• Die Liste zeigt alle Angebote mit Versanddatum älter als sieben Tage ohne Rückmeldung.
• Jede Zeile zeigt Kundenname, Angebotssumme und Versanddatum.
• Angebote, die als „nachgefasst“ markiert wurden, verschwinden aus der Liste.
• Die Liste ist jeden Morgen um 7 Uhr aktuell.

Dieses Beispiel ist bewusst gewählt: Genau hier liegt in den meisten Betrieben sechsstelliges Geld auf der Straße. Was du mit der Liste dann machst, steht im Leitfaden zum Angebot nachfassen.

Beispiel 2: Handwerksbetrieb — Aufmaß vor Ort

Als Monteur möchte ich das Aufmaß direkt beim Kunden auf dem Tablet erfassen, um es nicht abends noch mal ins Büro tippen zu müssen.

Akzeptanzkriterien:

• Die Erfassung funktioniert ohne Internetverbindung und überträgt später automatisch.
• Pflichtfelder sind Kunde, Raum, Maße, Datum.
• Der Monteur kann Fotos anhängen.
• Das Büro sieht das Aufmaß spätestens 15 Minuten nach der nächsten Netzverbindung.

Beachte den Nutzen: „um es nicht abends noch mal eintippen zu müssen.“ Das ist eine Stunde pro Monteur und Woche. Bei zwölf Monteuren sind das über 600 Stunden im Jahr. So rechnest du eine Story, statt über Geschmack zu diskutieren.

Beispiel 3: Kundenservice — Reklamation annehmen

Als Mitarbeiterin im Kundenservice möchte ich bei einer Reklamation die letzten drei Bestellungen des Kunden sehen, um sofort einschätzen zu können, worum es geht.

Akzeptanzkriterien:

• Die letzten drei Bestellungen erscheinen mit Datum, Artikel und Betrag.
• Reklamationen zu diesen Bestellungen sind farblich markiert.
• Der Verlauf ist innerhalb von drei Sekunden geladen.

Das ist gelebte Kundenorientierung: Der Kunde soll seine Geschichte nicht zum dritten Mal erzählen müssen.

Und so sieht eine schlechte User Story aus

Als Nutzer möchte ich ein besseres CRM, um effizienter zu arbeiten.

Alles falsch: Die Rolle ist keine Rolle, das Ziel ist ein Wunsch ohne Kante, und der Nutzen ist eine Floskel. Aus diesem Satz kann niemand etwas bauen. Und jeder, der ihn liest, versteht etwas anderes.

INVEST: das Qualitätsraster für jede User Story

Bevor eine Story in die Umsetzung geht, prüfst du sie gegen sechs Kriterien. Das Akronym heißt INVEST und ist das schnellste Werkzeug, um schlechte Stories zu erkennen, bevor sie Geld kosten:

• I — Independent (unabhängig): Die Story lässt sich umsetzen, ohne dass drei andere vorher fertig sein müssen. Ketten von Abhängigkeiten blockieren jedes Team.
• N — Negotiable (verhandelbar): Sie schreibt keine Lösung fest. Das Wie bleibt Verhandlungssache zwischen Auftraggeber und Umsetzer.
• V — Valuable (wertvoll): Sie liefert einen erkennbaren Nutzen für jemanden. Wenn du den Nutzen nicht benennen kannst, ist es eine Aufgabe, keine Story.
• E — Estimable (schätzbar): Das Team kann den Aufwand grob einschätzen. Kann es das nicht, fehlt Wissen — dann steht Klärung vor Umsetzung.
• S — Small (klein): Sie passt in einen Arbeitszyklus. Faustregel: Was länger als ein paar Tage dauert, wird geteilt.
• T — Testable (überprüfbar): Es gibt Akzeptanzkriterien, gegen die jemand prüfen kann. Ohne sie ist „fertig“ eine Meinung.

Nimm dir dein aktuelles Aufgabenbrett und geh mit diesen sechs Punkten drüber. Ich verspreche dir: Die Hälfte deiner Einträge fällt bei mindestens zwei Kriterien durch. Und genau die Hälfte ist die, über die dein Team seit Wochen streitet.

Der Punkt „verhandelbar“ ist übrigens der, der den größten Unterschied zur klassischen Anforderungsplanung macht. Dazu gleich mehr.

Story Points: schätzen in Größe, nicht in Stunden

Kurz, weil es hier nicht das Hauptthema ist: Story Points sind eine relative Größenangabe. Das Team vergleicht eine neue Story mit einer bekannten und sagt: doppelt so groß, halb so groß, gleich.

Warum nicht in Stunden? Weil Menschen Stunden systematisch falsch schätzen, Größenverhältnisse aber ziemlich gut treffen. Nach ein paar Zyklen weiß dein Team, wie viele Punkte es pro Zyklus schafft — und ab da wird Planung zur Rechnung statt zum Bauchgefühl.

Für den Mittelstand hat das einen unterschätzten Nebeneffekt: Die Schätzung wird zur Diskussion über den Zuschnitt. Wenn drei Leute eine Story völlig unterschiedlich groß schätzen, haben sie sie unterschiedlich verstanden — und genau das kommt in dem Moment auf den Tisch, in dem es noch nichts kostet.

Zwei Regeln reichen fürs Erste: Punkte sind Teamwerte, keine Personenwerte. Und du vergleichst niemals die Punkte zweier verschiedener Teams. Wer das tut, bekommt aufgeblähte Schätzungen statt guter Arbeit.

User Story oder Lastenheft? Die klare Abgrenzung

Das ist die Frage, die im Mittelstand wirklich weh tut — weil beide Wege existieren und beide ihre Berechtigung haben.

Der Unterschied in einem Satz: Die User Story ist die agile Anforderung — aus Nutzersicht formuliert, bewusst unfertig, verhandelbar. Das Lastenheft und das Pflichtenheft sind die klassische Anforderung — vollständig beschrieben, vertraglich bindend, festgeschrieben.

Das ist keine Frage von modern gegen altmodisch. Es ist eine Frage der Situation:

• User Story: wenn du intern baust, wenn das Ziel klar und der Weg unklar ist, wenn du in kurzen Zyklen liefern und nachsteuern kannst.
• Lastenheft und Pflichtenheft: wenn du extern vergibst, wenn ein Vertrag mit Festpreis dranhängt, wenn Abnahme und Haftung geregelt sein müssen.

Praktisch heißt das: Vergibst du eine Maschinensteuerung an einen externen Dienstleister für 180.000 Euro Festpreis, schreibst du kein Kartendeck mit Stories. Da brauchst du ein Lastenheft — alles, was drinsteht, ist geschuldet, alles andere ist Nachtrag. Die vollständige Abgrenzung inklusive Aufbau und Vorlagen steht im Artikel zu Lastenheft und Pflichtenheft.

Der zweite Unterschied liegt im Zeitpunkt. Ein Lastenheft entsteht einmal, vor dem Start, und wird danach über Änderungsanträge gepflegt. Storys entstehen laufend — du schreibst die nächsten fünf, während die letzten fünf schon laufen. Das ist kein Nachlässigkeitsbonus, sondern eine bewusste Entscheidung: Du kaufst Anpassungsfähigkeit und bezahlst mit Planungssicherheit. Wenn du diese Währung nicht ausgeben darfst, weil ein Vertrag dagegensteht, nimm das Lastenheft.

Und die ehrliche Kombination, die in vielen Betrieben am besten funktioniert: Das Lastenheft beschreibt den Rahmen und die Abnahme gegenüber dem Auftragnehmer. Die Story organisiert die Arbeit innerhalb dieses Rahmens. Beides schließt sich nicht aus. Es arbeitet auf verschiedenen Flughöhen.

Was beide gemeinsam haben: Sie sind nur so gut wie die Erhebung dahinter. Wer nicht sauber fragt, schreibt sauber formulierten Unsinn — egal in welchem Format. Deshalb ist die Bedarfsanalyse das Handwerk, das vor jedem Format kommt.

Wer schreibt die User Storys — und wer entscheidet?

Die Verantwortung für die Stories liegt beim Product Owner. Er ist die Rolle, die zwischen dem Team und allen anderen steht: Er sammelt die Anforderungen, formuliert sie als Story, sorgt für Akzeptanzkriterien und entscheidet, was als Nächstes gebaut wird.

Wichtig — und das wird ständig falsch gemacht: Schreiben darf jeder. Der Monteur, die Buchhaltung, der Vertriebsleiter. Eine gute Story kann von jedem kommen, der ein Problem hat. Entscheiden, in welcher Reihenfolge daran gearbeitet wird, darf nur einer. Sonst hast du fünf Prioritäten, und das heißt: keine.

Wie diese Reihenfolge zustande kommt, welche Verfahren dafür taugen und wie ein Backlog gepflegt wird, führe ich hier nicht aus — das gehört in den Artikel zum Product Owner. Im Mittelstand ist diese Rolle übrigens fast nie eine eigene Stelle. Sie hängt meistens am Geschäftsführer oder an einem Bereichsleiter. Das ist in Ordnung, solange die Rolle benannt ist. Nicht in Ordnung ist es, wenn sie niemand hat.

Die fünf Fehler, die User Storys im Mittelstand scheitern lassen

Ich sehe dieselben fünf Fehler in fast jedem Betrieb, der damit anfängt.

Fehler 1: Die Story ist eine getarnte Aufgabe. „Als Nutzer möchte ich, dass Feld X befüllt wird.“ Da steht kein Nutzen, da steht eine Anweisung im Story-Kostüm. Streich den Satz und frag nach dem Warum.

Fehler 2: Der Nutzen ist eine Floskel. „… um effizienter zu arbeiten.“ Wie viel effizienter? Für wen? Gemessen woran? Wenn der Nutzen keine Zahl verträgt, ist er meistens keiner.

Fehler 3: Die Story ist zu groß. Alles, was drei Wochen dauert, ist ein Projekt. Teil es. Am besten nach Arbeitsschritten des Nutzers, nicht nach technischen Bausteinen — sonst hat nach jeder Teilstory immer noch niemand einen Nutzen.

Fehler 4: Akzeptanzkriterien fehlen oder kommen zu spät. Wer sie erst bei der Abnahme formuliert, formuliert sie nach dem, was gebaut wurde. Das ist keine Prüfung, das ist eine Rechtfertigung.

Fehler 5: Die Story ersetzt das Gespräch. Der schlimmste Fehler von allen. Eine Story ist ein Gesprächsanlass, kein Vertrag. Wer sie per E-Mail durchreicht und auf das Ergebnis wartet, hat den Sinn nicht verstanden — und bekommt genau die Missverständnisse zurück, die er mit dem Format vermeiden wollte.

So führst du User Storys in deinem Betrieb ein

Du brauchst dafür keine Software, kein Zertifikat und keinen Berater. Du brauchst vier Wochen und Disziplin.

Woche 1: Ein Vorhaben auswählen. Nimm ein reales, mittelgroßes Vorhaben — nicht das größte. Etwas, das in vier bis sechs Wochen fertig sein kann und wo der Nutzen sichtbar ist.

Woche 1: Rollen benennen. Wer ist der Product Owner? Wer setzt um? Zwei Namen, aufgeschrieben, allen bekannt.

Woche 2: Stories schreiben, gemeinsam. Setzt euch zwei Stunden zusammen. Jeder bringt seine Probleme mit. Ihr formuliert sie im Format „Als … möchte ich … um …“. Keine Lösungen im Raum, das ist die einzige Regel.

Woche 2: INVEST anwenden. Geht jede Story gegen die sechs Kriterien durch. Was durchfällt, wird umgeschrieben oder geteilt. Rechne damit, dass ihr die Hälfte anfasst.

Woche 3: Akzeptanzkriterien ergänzen. Für die Stories, die als Nächstes drankommen — nicht für alle. Drei bis sieben Kriterien pro Story, Checkliste reicht.

Woche 3 und 4: Bauen und abnehmen. Nach jeder fertigen Story: Abnahme gegen die Kriterien. Ja oder nein. Keine Grauzone.

Der eigentliche Gewinn zeigt sich in Woche 4. Dann streitet ihr nicht mehr darüber, ob etwas fertig ist. Ihr lest die Kriterien vor und hakt ab. Das ist der Unterschied zwischen einem Betrieb, der diskutiert, und einem, der liefert.

Wenn du deine Abläufe insgesamt so aufstellen willst, dass sie auch ohne dich funktionieren, findest du die sieben Anleitungen dafür im Unternehmer-Paket — kostenlos, sofort zum Download, aus 35 Jahren Praxis und über 10.000 trainierten Unternehmern. Hol es dir und fang mit dem ersten Vorhaben an.

Häufige Fragen zur User Story

Wie lang darf eine User Story sein?

Ein Satz. Wenn du mehr brauchst, ist es keine Story, sondern ein Konzept oder ein Epic — also eine Sammelstory, die noch geteilt werden muss. Die Details gehören nicht in den Satz, sondern in die Akzeptanzkriterien und ins Gespräch.

Was ist der Unterschied zwischen User Story und Epic?

Ein Epic ist eine große Anforderung, die noch nicht in einen Arbeitszyklus passt. Es wird in mehrere Storys zerlegt. Praktische Faustregel: Was länger als eine Woche dauert, ist ein Epic und wird geteilt. Was in wenigen Tagen erledigt ist, ist eine User Story.

Braucht jede User Story Akzeptanzkriterien?

Jede, die in Umsetzung geht — ja. Stories, die noch weit hinten in der Reihenfolge liegen, brauchen sie noch nicht. Kriterien für Dinge zu schreiben, die vielleicht nie gebaut werden, ist Verschwendung. Formuliere sie kurz bevor die Story dran ist, gemeinsam mit dem Team.

Funktioniert das auch ohne Scrum?

Ja. Die User Story ist ein Format, kein Rahmenwerk. Du kannst sie in Kanban einsetzen, in klassischen Projekten oder ganz ohne Methode — überall dort, wo jemand eine Anforderung aufschreibt. Der offizielle Scrum Guide von Schwaber und Sutherland schreibt Storys übrigens gar nicht vor; er kennt nur Backlog-Einträge. Das Format hat sich unabhängig davon durchgesetzt, weil es funktioniert.

Wer nimmt eine User Story ab?

Der Product Owner — gegen die Akzeptanzkriterien, die vorher vereinbart wurden. Nicht der Umsetzer, nicht der Chef nach Bauchgefühl, nicht das Team im Konsens. Eine Person, ein klares Ja oder Nein. Alles andere führt dazu, dass „fertig“ wieder Verhandlungssache wird — und genau das wolltest du ja abschaffen.