Beiträge

Abnahmekriterien schreiben, die tatsächlich Nacharbeit verhindern

Agile team collaborating around a table with sticky notes and a laptop, discussing requirements for a user story during a backlog refinement session Anforderungsbezogene Probleme verursachen fast die Hälfte aller Softwarefehler. Die meisten davon lassen sich auf dasselbe Grundproblem zurückführen: Das Team hat gebaut, was es dachte, dass verlangt wurde, nicht das, was tatsächlich benötigt wurde. Abnahmekriterien sind die Lösung. Sie verwandeln eine vage User Story in einen testbaren Vertrag zwischen dem Product Owner und dem Entwicklungsteam. Wenn sie gut geschrieben sind, beenden sie die "aber ich dachte, es sollte..."-Gespräche, die Sprint Reviews zum Entgleisen bringen. Dieser Leitfaden behandelt die beiden Hauptformate, echte Beispiele, die Sie anpassen können, und die Fehler, über die selbst erfahrene Teams stolpern.

Was Abnahmekriterien sind (und was nicht)

Abnahmekriterien sind die Bedingungen, die eine User Story erfüllen muss, bevor sie als abgeschlossen gilt. Sie beantworten eine Frage: "Woran erkennen wir, dass dies funktioniert?" Sie sind nicht dasselbe wie eine Definition of Done. Die DoD ist ein universeller Qualitätsstandard, der für alle Arbeiten gilt (Code geprüft, Tests geschrieben, auf Staging deployed). Abnahmekriterien sind spezifisch für eine einzelne Story.

	Abnahmekriterien	Definition of Done
Umfang	Eine User Story	Alle Work Items
Fokus	Was das Feature für Nutzer tut	Wie gut es gebaut ist
Wer schreibt	Product Owner + Team	Das gesamte Scrum Team
Beispiel	"Nutzer kann nach Datum filtern"	"Code von mind. 1 Dev geprüft"

Beide müssen erfüllt sein, bevor eine Story erledigt ist. Wenn Sie Ihre DoD noch aufbauen, kann unser Definition of Done Generator Ihnen den Einstieg erleichtern.

Die zwei Hauptformate

Checklisten-Format (regelbasiert)

Eine einfache Liste von Bestanden/Nicht-bestanden-Bedingungen. Am besten für unkomplizierte Features, bei denen das erwartete Verhalten klar ist.

Passwort-Zurücksetzen-Feature:
- Link "Passwort vergessen" erscheint auf der Login-Seite
- Klicken darauf fordert zur Eingabe einer E-Mail-Adresse auf
- Gültige E-Mail erhält einen Reset-Link innerhalb von 60 Sekunden
- Reset-Link läuft nach 24 Stunden ab
- Neues Passwort muss bestehende Passwort-Anforderungen erfüllen
- Nach dem Zurücksetzen wird der Nutzer mit einer Erfolgsmeldung zum Login weitergeleitet
- Ungültige E-Mail zeigt: "Falls diese E-Mail existiert, wurde ein Reset-Link gesendet"

Wann verwenden: Einfache Features, UI-Anforderungen, Geschäftsregeln, Validierungslogik. Die meisten Ihrer Stories werden dieses Format verwenden.

Given/When/Then-Format (Gherkin)

Ein strukturiertes Szenario-Format aus Behavior-Driven Development. Jedes Szenario beschreibt eine Vorbedingung, eine Aktion und ein erwartetes Ergebnis.

Scenario: Anwenden eines gültigen Rabattcodes
Given der Nutzer hat Artikel im Warenkorb mit einer Summe von 100€
And ein gültiger 20%-Rabattcode "SAVE20" existiert
When der Nutzer "SAVE20" in das Rabattfeld eingibt
And auf "Anwenden" klickt
Then aktualisiert sich die Warenkorb-Summe auf 80€
And eine Nachricht "Rabatt angewendet" erscheint

Scenario: Anwenden eines abgelaufenen Rabattcodes
Given der Rabattcode "OLD10" ist gestern abgelaufen
When der Nutzer "OLD10" eingibt und auf "Anwenden" klickt
Then bleibt die Warenkorb-Summe unverändert
And eine Fehlermeldung "Dieser Code ist abgelaufen" erscheint

Wann verwenden: Komplexe Workflows mit mehreren Pfaden oder Features, die Sie mit BDD-Tools wie Cucumber oder SpecFlow automatisieren möchten. Two side-by-side documents showing the checklist format and Given/When/Then format for acceptance criteria, with colorful annotations highlighting the differences

Welches Format sollten Sie wählen?

Die meisten Teams landen bei einem hybriden Ansatz: Checkliste für einfache Stories, Given/When/Then für alles mit komplexer Verzweigung oder mehreren Nutzerpfaden. Denken Sie nicht zu viel darüber nach. Wählen Sie das Format, das die Anforderungen für diese spezifische Story klarer kommuniziert.

Fünf Regeln für gute Abnahmekriterien

1. Definieren Sie das Was, nicht das Wie

Schlecht: "Verwende eine Modal-Komponente mit 400ms Fade-in-Animation" Gut: "Bestätigungsdialog erscheint, bevor das Element gelöscht wird" Kriterien beschreiben Ergebnisse. Die Implementierung ist die Aufgabe des Entwicklers.

2. Machen Sie jedes Kriterium testbar

Wenn Sie nicht mit "Ja" oder "Nein" beantworten können, ob ein Kriterium erfüllt ist, ist es zu vage. Schlecht: "Die Seite sollte schnell laden" Gut: "Suchergebnisse laden innerhalb von 2 Sekunden bei bis zu 500 Ergebnissen"

3. Decken Sie den Fehlerfall ab

Für jeden Happy Path schreiben Sie mindestens ein Fehler-Szenario. Was passiert bei ungültiger Eingabe? Einer unterbrochenen Verbindung? Fehlenden Berechtigungen?

4. Halten Sie Kriterien unabhängig

Jedes Kriterium sollte für sich allein überprüfbar sein. Wenn Kriterium #4 nur Sinn ergibt, nachdem Sie Kriterien #1 bis #3 gelesen haben, haben Sie eine Spezifikation geschrieben, keine Abnahmekriterien.

5. Schreiben Sie sie vor dem Sprint Planning

Abnahmekriterien, die während der Entwicklung geschrieben werden, sind Beschreibungen, keine Anforderungen. Schreiben Sie sie während des Backlog Refinements, damit das Team während des Planning Poker genau schätzen kann.

Praxisbeispiele

E-Commerce-Suchfilter

User Story: "Als Käufer möchte ich Produkte nach mehreren Kategorien filtern können, damit ich die Ergebnisse auf das eingrenzen kann, wonach ich suche."

• Filter zeigen alle verfügbaren Produktkategorien an
• Nutzer können mehrere Kategorien gleichzeitig auswählen
• Ergebnisse aktualisieren sich in Echtzeit ohne Seiten-Reload
• Angewendete Filter werden als entfernbare Badges angezeigt
• Button "Alle löschen" entfernt alle aktiven Filter
• Ergebnisanzahl aktualisiert sich entsprechend der aktiven Filter (z.B. "47 Ergebnisse")
• Keine passenden Ergebnisse zeigt: "Keine Produkte entsprechen Ihren Filtern. Versuchen Sie, Ihre Auswahl zu erweitern."
• Filterstatus bleibt erhalten beim Zurückkehren von einer Produktdetailseite

Team-Einladungs-Flow

User Story: "Als Teamleiter möchte ich Mitglieder per E-Mail einladen können, damit wir mit der Zusammenarbeit beginnen können."

Scenario: Erfolgreiche Einladung
Given ich bin auf der Team-Einstellungsseite
When ich "alex@company.com" in das Einladungsfeld eingebe
And auf "Einladung senden" klicke
Then wird eine Einladungs-E-Mail innerhalb von 60 Sekunden gesendet
And die E-Mail erscheint in meiner Liste "Ausstehende Einladungen"
And eine Erfolgsmeldung bestätigt, dass die Einladung gesendet wurde

Scenario: Doppelte Einladung
Given ich habe bereits "alex@company.com" eingeladen
When ich dieselbe E-Mail eingebe und auf "Einladung senden" klicke
Then erscheint eine Warnung: "Einladung bereits an diese E-Mail gesendet"
And ich kann wählen, ob ich erneut senden oder abbrechen möchte

Scenario: Ungültiges E-Mail-Format
Given ich bin auf der Team-Einstellungsseite
When ich "keine-email" eingebe und auf "Einladung senden" klicke
Then erscheint ein Inline-Fehler: "Geben Sie eine gültige E-Mail-Adresse ein"
And keine Einladung wird gesendet

Benachrichtigungseinstellungen

User Story: "Als Nutzer möchte ich steuern können, welche Benachrichtigungen ich erhalte, damit ich nicht von Meldungen überwältigt werde."

• Einstellungsseite zeigt Toggle für jede Benachrichtigungskategorie
• Änderungen speichern sich automatisch (kein separater "Speichern"-Button)
• Das Deaktivieren einer Kategorie stoppt alle Benachrichtigungen dieses Typs innerhalb von 5 Minuten
• Mindestens ein Benachrichtigungskanal muss aktiv bleiben (verhindert versehentliches Abmelden von allem)
• "Auf Standard zurücksetzen" stellt die ursprünglichen Benachrichtigungseinstellungen wieder her
• Änderungen gelten auf allen Geräten

A developer reviewing a user story card with clearly written acceptance criteria, checking items off one by one

Häufige Fehler

Zu vage sein. "Das System sollte benutzerfreundlich sein" ist nicht testbar. Ersetzen Sie subjektive Sprache durch messbare Bedingungen. Implementierung vorschreiben. "Verwende Redux für State Management" gehört in einen Tech Spike, nicht in Abnahmekriterien. Beschreiben Sie, was der Nutzer erlebt, nicht wie der Code funktioniert. Nur den Happy Path schreiben. Wenn Ihre Kriterien nur das Sonnenschein-Szenario abdecken, wird Ihr Team Edge Cases mitten im Sprint entdecken und entweder Abstriche machen oder die Schätzung sprengen. Kriterien zu spät schreiben. Kriterien, die während der Entwicklung geschrieben werden, sind nachträgliche Rechtfertigungen, keine Anforderungen. Definieren Sie sie während des Refinements, verfeinern Sie sie während des Sprint Plannings. Kriterien zu granular machen. Wenn Ihre Kriterien wie ein Testskript mit 30 Schritten aussehen, sind Sie zu weit gegangen. Streben Sie 5-10 Kriterien pro Story an. Wenn Sie mehr brauchen, ist die Story wahrscheinlich zu groß und sollte in kleinere Stories aufgeteilt werden.

Eine schnelle Selbstprüfung

Bevor Sie eine Story in einen Sprint aufnehmen, gehen Sie dies durch: Wenn eines davon fehlschlägt, braucht die Story eine weitere Runde Backlog Refinement, bevor sie sprint-ready ist.

Abnahmekriterien schneller schreiben

Der "Three Amigos"-Ansatz funktioniert: Holen Sie den Product Owner, einen Entwickler und einen Tester für jede Story in denselben Raum. Der PO erklärt die Absicht, der Entwickler entdeckt technische Edge Cases, und der Tester bohrt mit "Was wäre wenn...?"-Fragen nach. Wenn Sie User Stories schreiben und einen Ausgangspunkt brauchen, kann unser Acceptance Criteria Generator erste Kriterien aus einer Story-Beschreibung entwerfen. Es gibt Ihnen schnell die ersten 80%, sodass Ihr Team die Refinement-Zeit für die kniffligen Edge Cases verwenden kann, statt auf eine leere Seite zu starren.