Fehler beim Umgang mit Akzeptanzkriterien – Akzeptanzkriterien gelten in vielen Projekten als lästige Pflicht. Schnell hingeschrieben, „damit die Story vollständig ist“, und dann nie wieder angeschaut. Die Folgen: Missverständnisse, unnötige Schleifen, Frust im Team und unzufriedene Stakeholder.
Dieser Beitrag zeigt typische Fehler beim Umgang mit Akzeptanzkriterien – und wie Sie es konkret besser machen. Mit klaren Beispielen, Formulierungen und Checklisten, die Sie direkt in Ihren Projekten einsetzen können.
1. Was sind Akzeptanzkriterien – und wozu dienen sie wirklich?
Kurzdefinition:
Akzeptanzkriterien beschreiben klare, überprüfbare Bedingungen, die erfüllt sein müssen, damit ein Ergebnis von Auftraggeber, Product Owner oder Fachseite als „fertig“ und akzeptiert gilt.
Sie dienen vor allem dazu:
- Erwartungshaltung zu klären
- den Umfang einer Anforderung einzugrenzen
- Missverständnisse zwischen Fachbereich und Umsetzung zu vermeiden
- Testfälle abzuleiten
- „fertig“ messbar zu machen (Done vs. „gefühlt fertig“)
Akzeptanzkriterien beschreiben das Was und Wann (wann ist etwas akzeptabel), nicht das Wie (technische Umsetzung).
2. Typische Fehler beim Umgang mit Akzeptanzkriterien – Überblick
Die häufigsten Fehlermuster:
- Keine oder nur sehr vage Akzeptanzkriterien
- Vermischung von Lösung und Ergebnisbeschreibung
- Unklare Verantwortlichkeiten für Erstellung und Pflege
- Akzeptanzkriterien, die nicht testbar sind
- Widerspruch zu Anforderungen, User Stories oder Fachkonzept
- „Einmal geschrieben, nie wieder angefasst“
- Zu detailverliebt oder zu grob
- Ignorierte Abnahmekriterien in Reviews und Tests
- Keine Einbindung der richtigen Stakeholder
- Copy & Paste und generische Standardkriterien
- Akzeptanzkriterien als „Wunschliste“ statt Priorisierung
- Kein Bezug zu Risiken, Nichtzielen und Randbedingungen
Im Folgenden gehen wir diese Fehler Schritt für Schritt durch – jeweils mit Praxisbeispielen und konkreten Handlungsempfehlungen.
3. Fehler 1: Keine oder nur sehr vage Akzeptanzkriterien
Woran Sie den Fehler erkennen
- User Story ohne Abschnitt „Akzeptanzkriterien“
- Allgemeine Aussagen wie „System muss stabil laufen“ oder „Funktion soll selbsterklärend sein“
- Im Review diskutieren alle, ob die Story „eigentlich“ fertig ist
Warum das problematisch ist
- Jeder im Team hat ein anderes Bild vom Ziel
- Scope-Drift: es kommt immer „noch schnell etwas dazu“
- Abnahmen ziehen sich in die Länge, weil sich niemand auf klare Bedingungen berufen kann
Besser machen – konkrete Schritte
Formulieren Sie Akzeptanzkriterien so, dass ein Außenstehender prüfen kann, ob sie erfüllt sind:
- Präzise
- messbar
- binär bewertbar („erfüllt / nicht erfüllt“)
Schwaches Kriterium:
Die Anwendung ist benutzerfreundlich.
Besser:
Nutzer können eine Bestellung mit maximal 5 Klicks ohne Hilfetext abschließen.
Praktische Checkliste für klare Akzeptanzkriterien:
- Wer prüft das Kriterium?
- Welche konkrete Handlung oder welches konkrete Ergebnis?
- Wie wird geprüft (manuell, Testfall, Metrik)?
- Wann gilt es eindeutig als erfüllt?
4. Fehler 2: Vermischung von Lösung und Ergebnisbeschreibung
Typisches Muster
Die Akzeptanzkriterien beschreiben die technische Umsetzung statt der erwarteten Wirkung.
Beispiele für lösungsgetriebene Kriterien:
- „Es wird eine Oracle-Datenbank verwendet.“
- „Der Export erfolgt in einer Excel-Datei mit VBA-Makros.“
Damit binden Sie das Team an eine konkrete Implementierung, obwohl das Problem vielleicht anders – einfacher, sicherer, zukunftsfähiger – lösbar wäre.
Warum das problematisch ist
- Innovations- und Optimierungspotenzial geht verloren
- Technische Entscheidungen werden außerhalb des Entwicklungsteams getroffen
- Spätere Architekturänderungen werden unnötig teuer
Besser machen – wirkungsorientierte Akzeptanzkriterien
Konzentrieren Sie sich darauf, was der Fachbereich braucht, nicht wie es gebaut wird.
Statt:
Daten werden in einer Oracle-Datenbank gespeichert.
Besser:
Alle erfassten Daten bleiben nach einem Neustart des Systems vollständig erhalten und stehen für Auswertungen zur Verfügung.
Statt:
Es gibt eine Excel-Export-Funktion mit Makro.
Besser:
Benutzer können die angezeigten Daten in ein maschinenlesbares Format exportieren, das in gängigen Office-Programmen geöffnet werden kann.
5. Fehler 3: Unklare Verantwortlichkeiten für Akzeptanzkriterien
Symptome
- Jeder schreibt „irgendwie“ Kriterien
- Niemand fühlt sich verantwortlich, sie zu pflegen
- Fachbereich, Product Owner und Entwickler widersprechen sich im Review
Typische Konstellationen
- Product Owner geht davon aus, dass Fachbereich die Kriterien liefert
- Fachbereich erwartet, dass „die IT“ das schon passend beschreibt
- Testteam ergänzt Akzeptanzkriterien erst am Ende
Besser machen – Rollen klären
Definieren Sie für Ihr Projekt:
- Wer initiiert und verantwortet die Akzeptanzkriterien?
- In agilen Kontexten meist Product Owner gemeinsam mit Fachseite
- Wer prüft die fachliche Vollständigkeit?
- Wer leitet Testfälle daraus ab und hält sie aktuell?
Praktischer Ansatz:
- Akzeptanzkriterien werden im Refinement gemeinsam von
- Product Owner
- fachlicher Ansprechpartner
- Vertreter Entwicklung / Test
erarbeitet oder geschärft.
- Im Review referenzieren Sie explizit die Akzeptanzkriterien:
- Kriterium vorlesen
- zeigen, wie es erfüllt wurde
- Zustimmung oder Nachbesserungsbedarf festhalten
6. Fehler 4: Akzeptanzkriterien, die nicht testbar sind
Woran Sie das erkennen
- Formulierungen mit „schnell“, „einfach“, „benutzerfreundlich“, „intuitiv“
- Subjektive Begriffe ohne messbare Referenz
- Kein klarer Testfall ableitbar
Warum das problematisch ist
- Subjektive Diskussionen im Review: „Ich finde aber, das ist intuitiv.“
- Keine saubere Grundlage für Abnahmetests
- Risiken (Usability, Performance, Sicherheit) werden unterschätzt
Besser machen – testbare Kriterien formulieren
Machen Sie vage Aussagen messbar:
Statt:
Die Seite lädt schnell.
Besser:
Die Startseite lädt bei normaler Last in weniger als 2 Sekunden (95 %-Perzentil).
Statt:
Die Anwendung ist leicht verständlich.
Besser:
8 von 10 Testpersonen können die Kernaufgabe ohne Hilfe in unter 3 Minuten erledigen.
Pragmatische Regel:
Wenn Sie nicht innerhalb von 1–2 Minuten einen Testfall daraus formulieren können, ist das Akzeptanzkriterium noch zu unkonkret.
7. Fehler 5: Widerspruch zu Anforderungen oder User Stories
Typische Situation
- Fachkonzept sagt A, Akzeptanzkriterium sagt B
- Ein Kriterium schränkt eine Funktion stärker ein als ursprünglich beschrieben
- Akzeptanzkriterien werden isoliert angepasst, ohne die zugehörige Story zu aktualisieren
Beispiele
- User Story: Als Nutzer möchte ich meine E-Mail-Adresse ändern können. Akzeptanzkriterium: Änderung der E-Mail-Adresse nur durch den Support möglich.
- Fachkonzept: Rolle „Manager“ darf alle Berichte sehen. Akzeptanzkriterium: Manager sieht nur Berichte seiner Abteilung.
Folgen
- Umsetzungs- und Testteams wissen nicht, welcher Stand gilt
- Diskussionen im Review kosten Zeit und Nerven
- Vertrauen in Artefakte sinkt („steht ja doch überall was anderes“)
Besser machen – Konsistenz sicherstellen
- Jede Änderung an Akzeptanzkriterien mit der zugehörigen Story oder Anforderung synchronisieren
- Einfache Regel in Refinements einführen:
- „Passen die Kriterien noch zur Story und zum übergeordneten Ziel?“
- Konflikte früh adressieren:
- Klärung mit Fachbereich
- saubere Dokumentation der Entscheidung
8. Fehler 6: „Einmal geschrieben, nie wieder angefasst“
Woran Sie das erkennen
- Akzeptanzkriterien stammen aus einer sehr frühen Projektphase
- Nach Änderungen im Umfang bleiben sie unverändert
- Im Review heißt es: „Das ist veraltet, das gilt so gar nicht mehr.“
Warum das problematisch ist
- Die Kriterien verlieren ihre Steuerungswirkung
- Das Team arbeitet nach aktuellen Absprachen, die nirgends dokumentiert sind
- Neue Teammitglieder oder externe Partner haben keine verlässliche Orientierung
Besser machen – lebendes Artefakt statt totem Dokument
Behandeln Sie Akzeptanzkriterien wie lebende Dokumente:
- In jedem Refinement aktiv prüfen:
- „Sind die Kriterien noch aktuell?“
- „Müssen wir sie anpassen?“
- Anpassungen direkt vornehmen und versionieren
- Bei wesentlichen Änderungen:
- Stakeholder informieren
- Abhängige Testfälle aktualisieren
9. Fehler 7: Zu detailverliebt oder zu grob
Zwei Extreme
- Zu grob:
- „Nutzer kann Daten exportieren.“
- Es bleibt offen: Welche Daten? Welches Format? Welche Filter?
- Zu detailliert:
- 30 einzelne Kriterien für eine kleine Story
- technische Details, Edge Cases und UI-Spezifika im Kriterium vergraben
Beides bremst:
- Zu grob: Nacharbeiten und Missverständnisse
- Zu detailliert: Verzettelung, hoher Pflegeaufwand, mangelnde Flexibilität
Besser machen – „genau richtig“ finden
Richtwerte:
- Für eine normale User Story: 3–7 Akzeptanzkriterien
- Pro Kriterium: 1 klarer Gedanke, nicht mehrere Bedingungen vermischen
Beispiele für sinnvolles Granularitätsniveau:
- Welche Nutzertypen betrifft es?
- Welche Kernfunktion muss verfügbar sein?
- Welche zentralen Einschränkungen gelten?
- Welche Fehlerfälle müssen abgefangen werden (nur die geschäftskritischen)?
10. Fehler 8: Akzeptanzkriterien werden im Review ignoriert
Symptome
- Review besteht aus einer Demo ohne Bezug zu den Kriterien
- Abnahmen basieren auf „Gefühl“ statt auf vereinbarten Bedingungen
- Unerwartete Nachforderungen nach dem Review
Warum das problematisch ist
- Vereinbarte Kriterien verlieren an Bedeutung
- Review wird zur Show, nicht zur fachlichen Abnahme
- Technische und fachliche Schulden wachsen
Besser machen – Review an den Kriterien ausrichten
Strukturieren Sie das Review so:
- Kurze Erinnerung an die User Story.
- Akzeptanzkriterien nacheinander durchgehen.
- Zu jedem Kriterium kurz zeigen, wie es erfüllt wurde.
- Zustimmung oder konkrete Nachbesserung dokumentieren.
Dadurch:
- steigt die Qualität der Abnahme
- reduziert sich Diskussion über Nebenschauplätze
- stärken Sie das Verständnis der Stakeholder für den Wert sauberer Akzeptanzkriterien
11. Fehler 9: Keine Einbindung der richtigen Stakeholder
Häufiger Fall
- Akzeptanzkriterien entstehen im „IT-Elfenbeinturm“
- Fachbereich sieht sie erstmals im Review
- Betriebs- oder Compliance-Anforderungen sind nicht abgebildet
Konsequenzen
- Späte Überraschungen: Datenschutz, Sicherheit, Revision
- Verzögerte Abnahmen durch nachträgliche Anpassungen
- Konflikte zwischen Fachanforderungen und regulativen Anforderungen
Besser machen – Stakeholder früh einbinden
Identifizieren Sie für jede größere Anforderung:
- fachliche Entscheider
- betroffene Stakeholder (z. B. Betrieb, Support, Compliance, Datenschutz)
- eventuell: externe Parteien (z. B. Partner, Prüfer)
Binden Sie mindestens einen Vertreter dieser Gruppen in die Erarbeitung oder Freigabe der zentralen Akzeptanzkriterien ein – vor der Entwicklung, nicht danach.
12. Fehler 10: Copy & Paste und generische Standardkriterien
Typisches Muster
- „Standard-Akzeptanzkriterien“ werden blind unter jede Story kopiert
- Formulierungen wie „Funktion ist bedienbar und performant“ tauchen immer wieder auf
- Team beschäftigt sich nicht mehr bewusst mit dem konkreten Inhalt
Risiken
- Kriterien verlieren ihre Trennschärfe
- Irrelevante Aussagen blähen Stories auf
- Wichtige, spezifische Anforderungen werden übersehen
Besser machen – bewusst mit Vorlagen arbeiten
Standardisierte Kriterien können sinnvoll sein, wenn:
- Sie bewusst auf wiederkehrende Anforderungen (z. B. Sicherheit, Logging, Barrierefreiheit) angewendet werden
- das Team entscheidet, welche davon für die konkrete Story relevant sind
Praxisvorschlag:
- Erstellen Sie einen „Baukasten“ typischer Qualitätskriterien (Security, Performance, Usability, Logging, Monitoring).
- Wählen Sie im Refinement aktiv aus, welche davon zur Story passen.
- Ergänzen Sie story-spezifische Kriterien immer separat.
13. Fehler 11: Akzeptanzkriterien als Wunschliste statt priorisierte Basis
Woran Sie das erkennen
- Lange Liste an „nice to have“-Wünschen im Kriterienteil
- Kein Unterschied zwischen Muss- und Kann-Kriterien
- Diskussionen im Review, was jetzt wirklich erforderlich ist
Warum das problematisch ist
- Umfang wird unnötig aufgebläht
- Zeit und Budget fließen in Detailwünsche statt in Kernnutzen
- Team verliert Fokus
Besser machen – Priorisierung einbauen
Markieren Sie Kriterien:
- Muss (ohne dieses Kriterium keine Abnahme)
- Soll (stark erwünscht, aber verhandelbar)
- Kann (Option für spätere Iterationen)
In agilen Kontexten:
- „Muss“-Kriterien gehören in die aktuelle Story
- „Soll“ und „Kann“ ggf. in nachgelagerte Stories oder Verbesserungs-Backlog verschieben
14. Fehler 12: Kein Bezug zu Risiken, Nichtzielen und Randbedingungen
Häufig übersehen
Akzeptanzkriterien fokussieren oft nur auf die gewünschte Funktion. Risiken und klare Nichtziele bleiben außen vor.
Beispiele für Lücken:
- es ist nicht dokumentiert, was die Lösung bewusst nicht leisten soll
- kritische Randbedingungen wie regulatorische Vorgaben fehlen
- bekannte Risiken tauchen nicht in den Kriterien auf
Besser machen – bewussten Rahmen setzen
Ergänzen Sie für kritische Anforderungen:
- zentrale Randbedingungen (z. B. „Keine Speicherung von personenbezogenen Daten außerhalb der EU“)
- bekannte Einschränkungen („Keine Unterstützung für Browser X in der ersten Version“)
- risikobezogene Kriterien (z. B. „Fehlerhafte Buchungen dürfen nicht ohne Genehmigung ausgeführt werden“)
Diese Punkte können entweder in eigenen Kriterien oder in einem klaren Abschnitt „Nichtziele/Randbedingungen“ zur Story festgehalten werden – entscheidend ist, dass sie bei der Abnahme eine Rolle spielen.
15. Praxisleitfaden: Gute Akzeptanzkriterien entwickeln – Schritt für Schritt
Damit Sie die typischen Fehler im Alltag vermeiden, hier ein kompakter Ablauf, den Sie in Ihren Projekten etablieren können.
Ziel und Nutzen klären
- Was soll der Fachnutzer konkret erreichen?
- Welches Problem löst die Anforderung?
- Welche Kennzahl oder Wirkung soll sich verändern?
Relevante Stakeholder einbinden
- Fachverantwortliche
- ggf. Betrieb, Sicherheit, Compliance, Datenschutz
- Vertreter Test / Qualitätssicherung
Kurze, fokussierte Abstimmung reicht oft: 15–30 Minuten pro zentraler Story.
Erste Akzeptanzkriterien skizzieren
- In Alltagssprache, nicht juristisch oder übertechnisch
- Pro Kriterium eine klare Bedingung
- Fokus auf beobachtbares Verhalten und Ergebnis
Testbarkeit prüfen
Für jedes Kriterium die Frage stellen:
- „Wie würden wir das konkret testen?“
- „Wer prüft es und womit?“
Wenn die Antwort unklar ist oder lange Diskussionen auslöst, muss das Kriterium geschärft werden.
Granularität ausbalancieren
- Sind es zu viele Kriterien? Welche lassen sich zusammenfassen?
- Sind essenzielle Aspekte noch zu grob?
- Bleibt die Story umsetzbar innerhalb des geplanten Zeitraums?
Kriterien im Refinement finalisieren
- Kriterien gemeinsam lesen
- Konsistenz mit Story, Fachkonzept und Randbedingungen prüfen
- offenen Diskussionsbedarf festhalten
Review stringent an den Kriterien ausrichten
- Kriterium nennen
- Umsetzung zeigen
- Abnahme / Nachbesserung dokumentieren
Kontinuierlich verbessern
- Retrospektiven nutzen:
- „Welche Akzeptanzkriterien waren hilfreich?“
- „Wo hatten wir trotz Kriterien Missverständnisse?“
- Beispiele sammeln und verfeinern
- Best Practices in einer internen Guideline festhalten
16. Beispiele für gute und schlechte Akzeptanzkriterien
Beispiel 1: Login-Funktion
Schlechte Kriterien:
- System ist sicher.
- Nutzer kann sich einloggen.
Bessere Kriterien:
- Nutzer können sich mit gültigem Benutzernamen und Passwort einloggen.
- Bei drei aufeinanderfolgenden Fehlversuchen wird der Zugang für 15 Minuten gesperrt.
- Passwörter werden nicht im Klartext gespeichert.
- Bei erfolgreichem Login wird der Nutzer auf die persönliche Startseite weitergeleitet.
Beispiel 2: Berichtsgenerierung
Schlechte Kriterien:
- Bericht wird schnell erzeugt.
- Bericht ist übersichtlich.
Bessere Kriterien:
- Nutzer kann einen Monatsbericht für eine frei wählbare Organisationseinheit erzeugen.
- Die Berichtserstellung dauert bei bis zu 100.000 Datensätzen maximal 10 Sekunden.
- Der Bericht enthält mindestens: Umsatz, Kosten, Marge, Anzahl der Transaktionen.
- Bericht kann im PDF- und CSV-Format exportiert werden.
17. Wie Sie als Entscheider und Projektleiter Akzeptanzkriterien steuern
Für Entscheider, Projektmanager und Führungskräfte zählen vor allem:
- Termintreue
- Budgettreue
- fachlich brauchbare Ergebnisse ohne dauernde Nachschleifen
Gute Akzeptanzkriterien sind dafür ein zentraler Hebel.
Konkrete Steuerungsmöglichkeiten
- Qualitätsstandard definieren:
- „Keine Story ohne nachvollziehbare, testbare Akzeptanzkriterien in der Planung.“
- Review-Format vorgeben:
- „Im Review gehen wir explizit alle Kriterien durch, nicht nur eine Demo.“
- Rollen und Verantwortung klarziehen:
- Product Owner und Fachbereich gemeinsam für die fachliche Qualität der Kriterien verantwortlich machen.
- Erfolg kontrollieren:
- In Retrospektiven oder Statusrunden gezielt nachfragen:
- „Wo haben uns Akzeptanzkriterien geholfen?“
- „Wo waren sie unklar oder fehlend?“
- In Retrospektiven oder Statusrunden gezielt nachfragen:
So entwickeln Sie im Team ein Bewusstsein für den Wert sauber formulierter Kriterien – und reduzieren ganz nebenbei die Anzahl an Schleifen und Nacharbeiten.
18. Fazit: Fehler beim Umgang mit Akzeptanzkriterien vermeiden – Ihr Mehrwert
Wenn Sie die beschriebenen Fehler vermeiden, erreichen Sie:
- weniger Missverständnisse zwischen Fachbereich und IT
- klarere, schnellere Abnahmen
- reduzierte Nacharbeiten und Scope-Änderungen
- bessere Planbarkeit von Aufwand und Terminen
- höhere Zufriedenheit von Nutzern und Stakeholdern
Akzeptanzkriterien sind kein bürokratischer Zusatz. Sie sind ein zentrales Steuerungsinstrument. Richtig eingesetzt, bringen sie Struktur und Klarheit in komplexe Vorhaben – vom agilen Softwareprojekt bis zur Prozessinitiative.
Wenn Sie Ihre bestehenden Praktiken zu Anforderungen und Akzeptanzkriterien hinterfragen oder verbessern wollen, kann ein externer Blick helfen. In fokussierten Workshops lassen sich in kurzer Zeit Standards etablieren, Beispiele erarbeiten und direkt im laufenden Projekt anwenden – ohne den Arbeitsalltag zu blockieren.