Laut Ticket ist ein Feature fertig. Die Demo sieht gut aus. Dann treffen Support-Nachrichten ein, die QA öffnet die Story wieder, und im Gründungsteam fragt man sich, warum die ausgelieferte Version nicht das tut, wovon alle ausgegangen sind.
Meist ist das kein Fehler im Code. Es ist ein Fehler in der Spec.
Teams schreiben oft eine ordentliche User Story und hören dann auf. „Als User möchte ich mein Passwort zurücksetzen, damit ich wieder Zugriff bekomme.“ Nützlich, aber unvollständig. Eine Story erklärt die Absicht. Sie legt nicht fest, was erfüllt sein muss, damit die Arbeit als fertig gilt. Genau in dieser Lücke schleichen sich Nacharbeit, enttäuschte Erwartungen und KI-generierter Unsinn ein.
Akzeptanzkriterien für User Stories schließen diese Lücke. Sie machen aus einem Wunsch einen gemeinsamen Vertrag. Für ein menschliches Team heißt das: weniger Annahmen. Für Teams, die mit Cursor, Claude Code, Codex oder einer Orchestrierungsschicht arbeiten, heißt es: Die Maschine hat ein klareres Ziel und weniger Spielraum, in die falsche Richtung zu improvisieren.
Inhaltsverzeichnis
- Warum User Stories scheitern und wie Akzeptanzkriterien das beheben
- Klare und testbare Akzeptanzkriterien formulieren
- Akzeptanzkriterien, die eine KI ausführen kann
- Akzeptanzkriterien für Sicherheit, Performance und Skalierbarkeit
- Typische Anti-Patterns bei Akzeptanzkriterien
- Akzeptanzkriterien prüfen und in deinen Workflow einbinden
Warum User Stories scheitern und wie Akzeptanzkriterien das beheben
Eine schwache Story scheitert meist auf vertraute Weise. Das Produktteam sagt: „Die Nutzenden brauchen ein schnelleres Onboarding.“ Das Design entwirft einen polierten Screen. Das Engineering baut den Flow. Die QA prüft den Happy Path. Das Release geht live, aber die Leute brechen trotzdem ab, weil niemand festgelegt hat, ob das Onboarding eine Option zum Überspringen braucht, welche Daten Pflicht sind und was als erfolgreicher Abschluss zählt.
Das ist der Unterschied zwischen einer Story und einem Lieferergebnis. Die Story beschreibt das Problem. Die Akzeptanzkriterien legen fest, wie Erfolg aussieht.
Die Lücke zwischen Absicht und Lieferung
Historisch wurden Akzeptanzkriterien in der Ära des Agilen Manifests 2001 als „Conditions of Satisfaction“ formalisiert, und Mike Cohns Buch User Stories Applied von 2004 machte den Product Owner zur einzigen Instanz, die Akzeptanzkriterien schreibt. Vor diesem Wandel sollen Softwareprojekte wegen mehrdeutiger Anforderungen Fehlschlagquoten von 30–50 % gehabt haben; mit der Einführung von Akzeptanzkriterien sank die Quote bis 2010 auf 20–30 %, weil Teams auf messbare Ergebnisse umstellten. So steht es in Meegles Zusammenfassung zu Geschichte und Praxis von Akzeptanzkriterien.
Diese Zahlen sind wichtig, weil sie zu dem passen, was Teams bis heute täglich erleben. Mehrdeutigkeit wirkt anfangs nicht dramatisch. Sie klingt nach „Das klären wir später“, „Das Engineering weiß schon, was ich meine“ oder „Die Edge Cases können warten“. Dann zeigt die Story ihre Zähne.
Das Ergebnis:
- Nacharbeit nach der Demo: Das Feature funktioniert technisch, aber das Business lehnt es ab.
- Widersprüchliche Auslegungen: Produkt, QA und Engineering arbeiten jeweils mit einer anderen Definition of Done.
- Falsche Velocity: Tickets werden schnell geschlossen und dann wieder geöffnet, sobald die Lücken sichtbar werden.
- KI-Drift: Ein Coding-Agent füllt nicht festgelegte Details mit plausiblen, aber falschen Entscheidungen.
Was Akzeptanzkriterien wirklich leisten
Gute Akzeptanzkriterien für User Stories liegen zwischen der Story und der Implementierung. Sie ersetzen weder Design noch Architektur noch Tests. Sie stecken ab, was erfüllt sein muss, bevor das Team die Arbeit als abgeschlossen bezeichnen kann.
Faustregel: Wenn ein Stakeholder die Story ablehnen würde, sobald eine Bedingung nicht erfüllt ist, gehört diese Bedingung in die Akzeptanzkriterien.
Diese Sichtweise hält Akzeptanzkriterien nützlich. Ein Team braucht nicht jedes Implementierungsdetail im Ticket. Es braucht die entscheidenden Bedingungen, die Akzeptables von Inakzeptablem trennen.
Ein starkes Beispiel sieht so aus:
- User Story: Als wiederkehrender User möchte ich das Onboarding fortsetzen, damit ich nicht von vorn anfangen muss.
- Schwaches Ergebnis: „User kann das Onboarding problemlos fortsetzen.“
- Klares Akzeptanzkriterium: „Verlässt ein angemeldeter User das Onboarding vor dem Abschluss, wird der Fortschritt gespeichert, und beim nächsten Login landet der User beim zuletzt abgeschlossenen Schritt.“
Ein Satz. Klar bestanden oder nicht bestanden. Kein Rätselraten.
Klare und testbare Akzeptanzkriterien formulieren
Viele Teams machen das komplizierter als nötig. Entweder schreiben sie einen vagen Satz, oder sie kippen einen halben Testplan in die Story. Beides hilft nicht.
Die Aufgabe ist einfacher. Schreib Akzeptanzkriterien für User Stories als aussagekräftige Regeln für die Fertigstellung. Sie sollten so präzise sein, dass sich Produkt, Engineering, QA und KI-Tools einig sind, was fertig bedeutet, aber nicht so vorschreibend, dass sie das Team auf eine einzige Implementierung festlegen.
Bei der Story anfangen, aber für die Prüfung schreiben
Eine User Story erklärt, wer, was und warum. Akzeptanzkriterien erklären, was sich überprüfen lässt.
Ein hilfreicher Filter:
- Welches beobachtbare Verhalten muss es geben?
- Welche Geschäftsregel muss gelten?
- Welche Fehlerbedingung oder welcher Edge Case würde uns die Story ablehnen lassen?
Lautet die Antwort „Es soll sich einfach intuitiv anfühlen“, ist die Story nicht bereit. Lautet sie „Der Link zum Zurücksetzen läuft nach einer festgelegten Zeit ab, und ungültige Links zeigen eine Fehlermeldung“, ist sie testbar.
Eine grundlegende agile Richtlinie empfiehlt höchstens 3 Akzeptanzkriterien pro Story, und Stories mit mehr als 6 Kriterien sollten in der Regel aufgeteilt werden. Dieselbe Quelle berichtet, dass Teams mit 3 oder weniger Akzeptanzkriterien pro Story eine um 25–40 % höhere Sprint-Velocity erreichen, laut der Analyse von UX Planet zu Akzeptanzkriterien und Story-Größe.
Das heißt nicht, dass jede Story genau drei Punkte haben muss. Es heißt: Wenn die Liste immer weiter wächst, steckt in der Story wahrscheinlich mehr als ein Anliegen.
Drei Formate, die sich in der Praxis bewähren
Nimm das Format, das zu der Art von Entscheidung passt, die das Team treffen muss.
| Format | Am besten für | Beispiel | Eignung für die Umsetzung durch KI |
|---|---|---|---|
| Checkliste | Einfache Features mit direkten Ergebnissen | User erhält eine E-Mail zum Zurücksetzen, nachdem das Zurücksetzen des Passworts angefordert wurde | Gut, wenn der Scope eng und die Begriffe präzise sind |
| Regelbasiert | Geschäftslogik und Validierungsregeln | Der Link zum Zurücksetzen läuft nach 10 Minuten ab und kann einmal verwendet werden | Stark bei regellastigen Features und Bedingungen im Backend |
| Angenommen/Wenn/Dann | Mehrstufige Szenarien und Verhaltensabläufe | Angenommen, ein registrierter User fordert das Zurücksetzen an, wenn er auf einen gültigen Link klickt, dann kann er ein neues Passwort festlegen | Am stärksten, wenn der Ablauf explizite Auslöser und Ergebnisse braucht |
Nimm eine Story und formuliere sie in allen drei Formaten.
User Story: Als registrierter User möchte ich mein Passwort zurücksetzen, damit ich wieder auf mein Konto zugreifen kann.
Checklisten-Format
- User kann auf dem Login-Screen das Zurücksetzen des Passworts anfordern.
- Das System schickt einen Link zum Zurücksetzen an die registrierte E-Mail-Adresse.
- User sieht eine Bestätigung, nachdem das neue Passwort erfolgreich gesetzt wurde.
Regelbasiertes Format
- Nur registrierte E-Mail-Adressen können Links zum Zurücksetzen erhalten.
- Links zum Zurücksetzen laufen nach dem festgelegten Gültigkeitszeitraum ab.
- Ein bereits verwendeter oder abgelaufener Link gibt einen Fehler zurück und erlaubt keine Passwortänderung.
Angenommen/Wenn/Dann-Format
- Angenommen, ein registrierter User ist auf dem Login-Screen, wenn er mit der E-Mail-Adresse seines Kontos das Zurücksetzen des Passworts anfordert, dann schickt das System einen Link zum Zurücksetzen.
- Angenommen, der User öffnet einen gültigen Link zum Zurücksetzen, wenn er ein neues Passwort absendet, das den Vorgaben entspricht, dann wird das Passwort aktualisiert und der User sieht eine Bestätigung.
- Angenommen, der Link zum Zurücksetzen ist abgelaufen oder wurde bereits verwendet, wenn der User versucht, ihn zu öffnen, dann blockiert das System das Zurücksetzen und zeigt den nächsten Schritt an.
So wählst du das richtige Format
Teams müssen sich nicht für immer auf ein Format festlegen. Sie brauchen Konsistenz innerhalb eines Backlogs und Urteilsvermögen bei jeder einzelnen Story.
Diese kurze Entscheidungshilfe hilft dir:
- Checkliste funktioniert, wenn die Story geradlinig ist und das Risiko unterschiedlicher Auslegungen gering.
- Regelbasierte Akzeptanzkriterien passen zu allem mit Berechtigungslogik, Zugriffsrechten, Validierung, Abrechnung oder Compliance-Vorgaben.
- Angenommen/Wenn/Dann hilft, wenn ein Workflow Zustandswechsel, Verzweigungen oder viel Fehlerbehandlung enthält.
Wenn das Team dieselbe Art von Story immer wieder missversteht, passt das Format wahrscheinlich nicht zu dieser Kategorie von Arbeit.
Daraus lässt sich auch etwas über Dokumentation lernen. Teams, die schon mit Prozessdokumentation arbeiten, schreiben oft bessere Akzeptanzkriterien, weil sie es gewohnt sind, wiederholbare, überprüfbare Schritte festzuhalten. Wenn deine Specs uneinheitlich sind, lohnt sich ein Blick auf Best Practices für Standard Operating Procedures, damit dein Team Workflows, Zuständigkeiten und Review-Punkte genauer festlegt.
Ein paar Gewohnheiten verbessern die Qualität schnell:
- Beobachtbare Sprache verwenden: „Zeigt eine Fehlermeldung an“ ist besser als „geht souverän mit Fehlern um“.
- Ablehnungskriterien schreiben: Nimm nur Bedingungen auf, die wichtig genug sind, um die Story scheitern zu lassen.
- Ergebnisse statt Bauanleitungen: Sag, was passieren muss, nicht welche Klasse, welches Framework oder welche Komponente es tun soll.
- Überladene Stories aufteilen: Wenn die Liste der Akzeptanzkriterien wie ein Mini-PRD aussieht, ist die Story zu breit.
Der letzte Punkt rettet mehr Teams als jeder Formatierungstrick.
Akzeptanzkriterien, die eine KI ausführen kann
Früher bedeutete „klar genug“: klar für Menschen. Ein Dev konnte Lücken selbst füllen, im Team nachfragen oder Unklarheiten während der Implementierung auflösen. Für ein eng abgestimmtes Team funktioniert das immer noch.
Es bricht schneller zusammen, wenn AI Agents einen Teil des Baus übernehmen.
Klassisches Gherkin oder Checklisten-Formate gehen oft nicht auf die Zuverlässigkeit von KI und die Vermeidung von Merge-Konflikten ein. Einer zitierten Behauptung zufolge zeigte der GitHub-Report von 2025, dass 62 % der Indie-Projekte wegen mehrdeutiger Kriterien mit KI-bedingten Konflikten zu kämpfen haben; empfohlen wird, Kriterien so weiterzuentwickeln, dass sie Kennzahlen zur Überprüfbarkeit durch KI enthalten. So fasst es Meegles Beitrag zu den Lücken KI-orientierter Akzeptanzkriterien zusammen.
Warum klar für Menschen nicht immer klar für Maschinen ist
Wer als Mensch entwickelt, kann oft ableiten, was mit „Nutzereinstellungen speichern“ gemeint ist. Ein Coding-Agent braucht dagegen womöglich Antworten auf Fragen, die dein Team nie aufgeschrieben hat:
- Welches Modul im Repository ist für dieses Verhalten zuständig?
- Welches Modell soll aktualisiert werden?
- Welcher bestehende API-Vertrag muss unverändert bleiben?
- Was passiert, wenn benötigte Abhängigkeiten fehlen?
- Welche Dateien dürfen nicht geändert werden?
Das heißt nicht, dass Akzeptanzkriterien zu Design-Dokumenten werden sollen. Es heißt, dass sie genug operativen Kontext brauchen, um die Umsetzung einzugrenzen.
Hier der Unterschied.
Akzeptanzkriterium für Menschen
- Nutzereinstellungen werden gespeichert und beim nächsten Login wiederhergestellt.
Akzeptanzkriterium, das eine KI ausführen kann
- Wenn ein angemeldeter User die Benachrichtigungseinstellungen ändert und auf Speichern klickt, schreibt das System die neuen Werte in das bestehende Modell für User-Einstellungen, gibt Erfolg im aktuellen Antwortformat der Settings-API zurück und stellt diese Werte beim nächsten Login wieder her, ohne andere Profilfelder zu verändern.
Die zweite Version konzentriert sich weiterhin auf das Ergebnis. Sie räumt nur die gefährlichste Mehrdeutigkeit aus.
So schreibst du Kriterien für die Umsetzung durch KI um
Ein praktisches Muster: Füge vier Ebenen an Präzision hinzu.
Auslöser Leg fest, was das Verhalten startet. Eine Aktion im UI, ein Webhook, ein Cron-Event, eine Änderung im Admin-Bereich oder importierte Daten.
Grenze Leg fest, wo die Änderung passieren soll. Ein bestehender Endpunkt, das aktuelle Modell, ein bestimmtes Modul oder ein benannter Service.
Prüfung Leg fest, welches beobachtbare Ergebnis den Erfolg belegt. Eine Antwort, ein gespeicherter Zustand, eine Anzeige im UI, ein Log-Event oder ein Testergebnis.
Leitplanke Leg fest, was nicht kaputtgehen darf. Authentifizierung, Schema-Kompatibilität, intakte Abhängigkeiten oder keine Änderungen außerhalb des festgelegten Bereichs.
Ein Vorher-nachher-Beispiel macht das deutlich.
Lockeres Akzeptanzkriterium
- Das Feature soll Rechnungen automatisch erstellen.
KI-taugliches Akzeptanzkriterium
- Angenommen, es gibt eine freigegebene Bestellung, wenn der Abrechnungsjob läuft, dann wird für diese Bestellung genau ein Rechnungsdatensatz im aktuellen Abrechnungsschema angelegt, die Rechnung nutzt den bestehenden Service zur Steuerberechnung, für dieselbe Bestellung entstehen keine doppelten Rechnungen, und eine fehlgeschlagene Rechnungserstellung schreibt einen Fehler ins Log, ohne andere Abrechnungsjobs zu blockieren.
Dieses Kriterium lässt einem AI Agent weniger Raum, an der falschen Stelle zu „helfen“.
Wenn du tiefer in diese Art von Spec einsteigen willst, lohnen sich die Ideen aus Spec-driven Development für KI-gestützte Teams, denn dort geht es darum, die Rahmenbedingungen der Umsetzung explizit zu machen, bevor der Code beginnt.
Was AI Agents brauchen und Teams oft nicht festhalten
Teams vergessen gern die unsichtbaren Rahmenbedingungen. Menschen arbeiten um sie herum. Agents rennen gegen sie an.
Die fehlenden Details fallen meist in diese Kategorien:
- Zuordnung im Repository: Welcher Bereich der Codebase für die Änderung zuständig ist.
- Bewusstsein für Abhängigkeiten: Auf welche Services, Modelle, Jobs und gemeinsamen Hilfsfunktionen das Feature angewiesen ist.
- Sicherheitsanforderungen: Welche Regeln zu Authentifizierung, Berechtigungen oder Validierung weiterhin gelten müssen.
- Nicht-Ziele: Was unangetastet bleiben soll.
- Verhalten im Fehlerfall: Was das System tun soll, wenn der Happy Path wegbricht.
Klare Akzeptanzkriterien, die eine KI ausführen kann, sagen nicht nur, was Erfolg ist. Sie legen den erlaubten Bereich fest, in dem der Agent nach Erfolg suchen darf.
Das ist der Wandel. Gute Akzeptanzkriterien haben früher Missverständnisse im Team verhindert. Heute verhindern sie auch, dass die Maschine improvisiert.
Akzeptanzkriterien für Sicherheit, Performance und Skalierbarkeit
Akzeptanzkriterien fürs UI bekommen Teams meist ganz gut hin. Schwer tun sie sich, wenn die Anforderung unsichtbar ist.
„Mach es sicher.“
„Halt es schnell.“
„Sorg dafür, dass es skaliert.“
Das sind keine Akzeptanzkriterien. Das sind Wünsche. Wenn niemand sie überprüfen kann, halten sie weder der Planung noch der QA noch dem Release-Review stand.
Warum nicht-funktionale Kriterien übersprungen werden
Für kleine Teams ist das ein echter Schmerzpunkt. Laut einer zitierten Zusammenfassung zeigen Foren wie Reddits r/ProductManagement, dass 70 % der Threads aus 2025–2026 zur Frage, wie man Akzeptanzkriterien für nicht-funktionale Anforderungen schreibt, ungelöst bleiben, und Atlassians State of Agile Report 2025 zeigt, dass 55 % der kleinen Teams Stories wegen nicht testbarer nicht-funktionaler Anforderungen vorschnell ablehnen. Dieselbe Zusammenfassung empfiehlt statt vager Ziele quantifizierbare Kriterien wie „Das System verarbeitet 10.000 gleichzeitige User mit <200 ms Latenz“, laut AltexSofts Überblick zu Best Practices für Akzeptanzkriterien.
Das passt zu dem, was in Produkten in der Frühphase passiert. Funktionale Arbeit wird festgehalten, weil sie sichtbar ist. Nicht-funktionale Anforderungen werden aufgeschoben, weil sie technisch wirken und Product Owner Sorge haben, ihre Kompetenzen zu überschreiten. Dann liefert das Team Features aus, die in der Demo funktionieren, aber im echten Einsatz oder beim Security-Review scheitern.
Templates, die nicht-funktionale Anforderungen testbar machen
Für bessere nicht-funktionale Akzeptanzkriterien brauchst du kein eigenes Architektur-Team. Du brauchst messbare Ablehnungskriterien.
Nutze Templates wie diese.
Sicherheit
- Ohne die erforderliche Rolle wird der Zugriff verweigert.
- Eingaben werden vor dem Speichern gegen erlaubte Formate validiert.
- Secrets tauchen nicht in Logs, Antworten oder im Client gerenderten Payloads auf.
Performance
- Der Endpunkt antwortet unter der festgelegten Last innerhalb der vereinbarten Antwortzeit.
- Die Seite bleibt nutzbar, während die Verarbeitung im Hintergrund abgeschlossen wird.
- Massenoperationen blockieren keine anderen Requests.
Skalierbarkeit
- Der Job verarbeitet das festgelegte Volumen ohne Datenverlust oder doppelte Datensätze.
- Das System bleibt funktionsfähig, wenn gleichzeitige Requests denselben Workflow treffen.
- Wiederholungen in der Queue erzeugen keinen inkonsistenten Zustand.
Ein Team, das Akzeptanzkriterien so schreibt, braucht auch einen glaubwürdigen Weg, sie zu prüfen. Für Stories rund um Performance helfen praktische Ressourcen zu Last- und Performance-Tests, um „schnell genug“ in wiederholbare Checks zu übersetzen, die am tatsächlichen Verhalten des Systems hängen.
Wie gute nicht-funktionale Kriterien klingen
Vergleiche schwache und starke Versionen.
| Schwaches Akzeptanzkriterium | Besseres Akzeptanzkriterium |
|---|---|
| Die API soll sicher sein | Requests ohne gültige Authentifizierung werden abgelehnt |
| Das Dashboard soll schnell laden | Die Daten des Dashboards laden unter der erwarteten Nutzung innerhalb des festgelegten Schwellenwerts |
| Das System soll skalieren | Das System verarbeitet gleichzeitige Requests weiter, ohne doppelte Datensätze oder fehlgeschlagene Schreibvorgänge |
Die stärkere Version lässt dem Engineering weiterhin Raum für eigenes Urteil. Sie schreibt keine Library, keinen Cloud-Service und keine Implementierungstaktik vor. Sie legt fest, was erfüllt sein muss, damit die Arbeit abgenommen wird.
Diese Unterscheidung zählt auch bei technischen Specs. Wenn dein Team Hilfe braucht, eine grobe Produktabsicht in Anforderungen zu übersetzen, die sich sicher implementieren lassen, ist das Schreiben technischer Specs, die testbar bleiben, die Disziplin, von der du dir etwas abschauen kannst. Gute technische Specs und gute Akzeptanzkriterien stärken sich gegenseitig. Die einen liefern den Kontext. Die anderen definieren die Schwelle.
Eine nicht-funktionale Anforderung wird erst real, wenn jemand belegen kann, dass sie bestanden hat oder gescheitert ist.
Nutze diesen Satz im Backlog-Review. Er zeigt sofort, welche „Anforderungen“ noch reines Wunschdenken sind.
Typische Anti-Patterns bei Akzeptanzkriterien
Teams scheitern selten, weil sie nicht wissen, dass es Akzeptanzkriterien gibt. Sie scheitern, weil sie Akzeptanzkriterien schreiben, die formal aussehen, aber trotzdem für Verwirrung sorgen.
Das typische Muster ist vorhersehbar. Jemand ergänzt mehr Details, um sich sicherer zu fühlen. Die Story wird länger, aber nicht klarer. Das Produktteam glaubt, das Risiko gesenkt zu haben. Das Engineering sieht eine Textwand. Die QA muss die Absicht trotzdem interpretieren.
Eine hilfreiche Sichtweise aus Mike Cohns Empfehlungen: Akzeptanzkriterien sollten wie ein grobes Inhaltsverzeichnis funktionieren, nicht wie kleinteilige Testfälle. Dieselbe Quelle nennt drei typische Fehler: Kriterien, die zu spezifisch sind und Kreativität einschränken, Kriterien, die Lösungen statt Ergebnisse vorschreiben, und Kriterien, die über den Scope der Story hinausgehen, wie in den Empfehlungen von Mountain Goat Software zu User Stories und Akzeptanzkriterien erklärt.
Wenn Kriterien zu Rauschen werden
Schwache Akzeptanzkriterien erkennst du meist daran, wie sie im Planning klingen.
Wenn jemand das Ticket liest und fragt: „Was soll denn gebaut werden?“, sind die Akzeptanzkriterien vage. Wenn das Engineering fragt: „Warum sagt ihr uns, welche Komponente wir nehmen sollen?“, schreiben die Akzeptanzkriterien die Lösung vor. Wenn die Liste mit jedem neuen Anliegen weiter wächst, sollte die Story aufgeteilt werden.
Das sind die teuersten Anti-Patterns:
- Vage Sprache: „Einfach“, „intuitiv“, „schnell“ und „sicher“ ohne testbare Bedingung.
- Aufgabenlisten, getarnt als Akzeptanzkriterien: „Endpunkt anlegen“, „Tests schreiben“, „Schema aktualisieren“.
- Lösungsdesign in den Akzeptanzkriterien: Implementierungsdetails benennen, die verhandelbar bleiben sollten.
- Stories mit allem Drum und Dran: Jeden Edge Case, jedes Nicht-Ziel und jede künftige Erweiterung in ein einziges Ticket packen.
- Losgelöste Kriterien: Akzeptanzkriterien in einem separaten Dokument führen, in das beim Bauen oder im Review niemand schaut.
So, nicht so
Ein kurzer Selbstcheck fängt die meisten Probleme ab.
| Nicht so | Sondern so |
|---|---|
| User hat ein angenehmes Nutzungserlebnis | User sieht eine Validierungsmeldung, wenn Pflichtfelder fehlen |
| Ein React-Modal zum Zurücksetzen des Passworts bauen | User kann auf dem Login-Screen das Zurücksetzen des Passworts anfordern |
| Daten in Service X und Klasse Y speichern | Änderungen des Users werden im bestehenden Einstellungs-Datensatz gespeichert und erscheinen beim nächsten Login |
| 9 Kriterien aufnehmen, die mehrere Workflows abdecken | Die Story in kleinere Scheiben mit jeweils eigenen Abschlusskriterien aufteilen |
Schreib Kriterien, die jemand im Review prüfen kann, ohne deine Gedanken zu lesen.
Dieser eine Test ist brutal und wirkungsvoll. Hängt die Prüfung von Wissen ab, das nur in einzelnen Köpfen steckt, sind die Akzeptanzkriterien schwach.
Akzeptanzkriterien prüfen und in deinen Workflow einbinden
Viele Teams behandeln Akzeptanzkriterien als etwas, das man einmal schreibt, damit das Ticket vollständig aussieht. Die eigentliche Arbeit passiert dann woanders. Slack-Threads, Kommentare im Code Review, QA-Notizen und mündliche Klärungen ersetzen nach und nach die ursprüngliche Spec.
Genau deshalb verschiebt sich „fertig“ ständig.
Besser ist es, Akzeptanzkriterien für User Stories als verbindliche Referenz zu behandeln, vom Backlog Grooming bis zum Release-Review. Die Scrum Alliance betont, Stakeholder einzubinden, bevor die Entwicklung beginnt, warnt davor, Akzeptanzkriterien zu früh oder zu spät zu schreiben, und empfiehlt, sie als lebendige Dokumente zu behandeln, die in regelmäßigen Abstimmungen aktualisiert werden, wie im Artikel der Scrum Alliance zum guten Umgang mit Akzeptanzkriterien beschrieben.
Akzeptanzkriterien vor dem Bau nutzen
Die schnellste Lösung ist eine Frage des Ablaufs. Warte nicht auf die Implementierung, um unklare Kriterien zu entdecken.
Ein schlankes Review vor dem Bau sollte diese Fragen beantworten:
- Klarheit für Stakeholder: Spiegelt die Story wider, was die anfragende Seite braucht?
- Testbarkeit: Kann die QA oder jemand im Review allein anhand der Formulierung über bestanden oder nicht bestanden entscheiden?
- Passender Scope: Ist das eine Story oder sind es drei, die sich als eine ausgeben?
- Fehlende Rahmenbedingungen: Bleiben Annahmen zu Sicherheit, Fehlerverhalten oder Abhängigkeiten unausgesprochen?
Wenn ein Team diese Fragen im Grooming nicht beantworten kann, ist die Story nicht bereit. Das ist keine Bürokratie. Es ist Schutz vor Nacharbeit.
Die Prüfung zum Teil der Lieferung machen
Sobald die Entwicklung beginnt, sollten Akzeptanzkriterien an echten Checkpoints im Workflow auftauchen.
Nutze sie in:
- Desk Checks: Prüf vor dem Merge jedes Kriterium gegen die Implementierung.
- QA-Szenarien: Mach aus jedem Akzeptanzkriterium einen Prüfschritt oder, wo sinnvoll, einen automatisierten Test.
- Demo-Skripten: Zeig, wie das ausgelieferte Verhalten jedes Kriterium erfüllt.
- Release-Reviews: Lehn „größtenteils fertige“ Arbeit ab, wenn ein Kriterium nicht erfüllt ist.
Ein einfaches Template hilft ebenfalls. Wenn dein Team mit Jira arbeitet, kann ein strukturiertes Jira-Issue-Template für klarere Specs Stories, Akzeptanzkriterien, Abhängigkeiten und offene Fragen an einem Ort bündeln, statt sie über Kommentare zu verstreuen.
Die Quelle der Wahrheit an einem Ort halten
Der größte Fehler im Workflow ist nicht die schlechte Formulierung. Es ist die Zersplitterung.
Wenn die Story in Jira liegt, die eigentliche Anforderung in Slack, die Edge Cases auf einer Notion-Seite und die QA-Entscheidungen in irgendjemandes Kopf, verlieren Akzeptanzkriterien ihre Autorität. Dann entsteht bei jeder Übergabe dasselbe Auslegungsproblem von Neuem.
Halte die Akzeptanzkriterien direkt am Arbeitspaket. Aktualisiere sie, wenn sich eine wichtige Entscheidung ändert. Nutze sie in Planung, Bau, Test und Review. So werden sie zu einem echten Vertrag statt zu einer zeremoniellen Checkliste.
Ein Team, das das gut macht, liefert mit weniger Überraschungen aus, weil alle, auch jeder AI Agent im Loop, mit derselben Definition von akzeptabel arbeiten.
Akzeptanzkriterien von Hand zu schreiben, ist der manuelle Weg. In Tekk.coach lesen Loops, was sich in deinem Code geändert hat, und bringen dir Proposals; gibst du eines mit Greenlight frei, wird es zu einer Spec auf deinem Board, deren Akzeptanzkriterien schon geschrieben sind. Du kannst eine Spec auch weiterhin von Hand schreiben, auf dasselbe Board. So oder so baut dein Coding-Agent sie über den Tekk-MCP-Server, und die Spec ist abgeschlossen, wenn der PR, der sie schließt, mit abgehakter Checkliste gemergt wird. Akzeptanzkriterien sind dann keine Zeremonie mehr, sondern das, was die Arbeit abschließt.