Akzeptanzkriterien (englisch: acceptance criteria) sind klare, testbare Bedingungen, die eine User Story oder ein Feature erfüllen muss, damit es als abgeschlossen gilt. Sie beschreiben das erwartete Verhalten aus Sicht der Nutzenden, ohne die technische Umsetzung vorzuschreiben.

Wer ein Website-Projekt mit einer Agentur abstimmt, kennt die Situation: Kurz vor der Abnahme stellt sich heraus, dass Agentur und Auftraggeber unterschiedliche Vorstellungen hatten, was "fertig" bedeutet. Akzeptanzkriterien verhindern genau das. Wer diese Bedingungen vor Beginn der Entwicklung schriftlich festhält, gibt dem Team eine eindeutige Messlatte und schützt beide Seiten vor nachträglichen Diskussionen.

Was sind Akzeptanzkriterien?

Der Begriff stammt aus dem agilen Projektmanagement (Scrum, Kanban) und wird heute in nahezu jedem strukturierten Website- und Softwareprojekt eingesetzt, unabhängig von der Methodik. Im Deutschen trifft man gelegentlich auch den Begriff "Abnahmekriterien". Gemeint ist dasselbe.

Wichtig ist die Abgrenzung: Akzeptanzkriterien beschreiben, was ein System leisten muss, nicht wie es das tut. Sie sind kein Pflichtenheft und kein technisches Konzept, sondern eine gemeinsam vereinbarte Prüfliste, die Auftraggeber und Agentur gleichermaßen verstehen und anwenden können.

Akzeptanzkriterien in User Stories: Formate und Abgrenzung

Eine User Story beschreibt eine Funktion aus Nutzersicht: "Als Besucherin möchte ich über ein Kontaktformular eine Anfrage stellen können, damit die Agentur mich zurückrufen kann." Die User Story beantwortet aber nicht, was genau passieren muss, damit diese Funktion als fertig gilt. Genau das leisten die Akzeptanzkriterien.

Format 1: Checkliste

Die Checkliste ist das am einfachsten zugängliche Format: eine Auflistung von Bedingungen, die das Feature erfüllen muss. Jede Bedingung lässt sich eindeutig mit Ja oder Nein beantworten. Das Format eignet sich gut für einfachere Funktionen und für Auftraggeber ohne technischen Hintergrund, weil es keine Vorkenntnisse voraussetzt.

Format 2: Given-When-Then (Gegeben-Wenn-Dann)

Das szenariobasierte Format beschreibt, welche Ausgangssituation vorliegt (Given), welche Aktion ausgelöst wird (When) und welches Ergebnis das System liefert (Then). Es eignet sich besonders für interaktive Funktionen wie Formulare, Login-Prozesse oder Filterfunktionen, weil es das Systemverhalten Schritt für Schritt nachvollziehbar macht. Entwickler können daraus direkt automatisierte Tests ableiten.

Was ist der Unterschied zwischen Akzeptanzkriterien und der Definition of Done?

Akzeptanzkriterien beziehen sich auf eine einzelne User Story: Sie legen fest, was dieses Feature leisten muss. Die Definition of Done (DoD) ist eine teamweite Qualitätscheckliste, die für alle Aufgaben gilt: Code-Review abgeschlossen, automatisierte Tests vorhanden, Dokumentation aktualisiert. Ein Feature kann alle Akzeptanzkriterien erfüllen und trotzdem die Definition of Done verfehlen, wenn etwa ein vorgeschriebener Test fehlt. Beide Konzepte ergänzen sich, ersetzen sich aber nicht.

Praxisbeispiel: Akzeptanzkriterien für ein Webflow-Kontaktformular

Angenommen, eine User Story lautet: "Als Besucherin möchte ich über ein Kontaktformular eine Anfrage stellen können." Die Akzeptanzkriterien im Checklisten-Format könnten so aussehen:

• Alle Pflichtfelder (Name, E-Mail, Nachricht) sind als solche gekennzeichnet.
• Das Formular zeigt eine Inline-Fehlermeldung, wenn ein Pflichtfeld leer bleibt oder die E-Mail-Adresse ungültig ist.
• Nach erfolgreichem Absenden erscheint eine Bestätigungsmeldung auf derselben Seite, ohne Seitenreload.
• Die Anfrage wird als neuer Kontakt im verbundenen CRM angelegt.
• Das Absenden löst ein "form_submit"-Event im Google Tag Manager aus.
• Das Formular ist per Tastatur vollständig bedienbar und erfüllt die Anforderungen der WCAG 2.2 auf Stufe AA.

Dasselbe Kriterium zum Tracking-Event im Given-When-Then-Format:

• Gegeben: Die Besucherin befindet sich auf der Kontaktseite.
• Wenn: Sie das Formular korrekt ausfüllt und auf "Absenden" klickt.
• Dann: Sendet der Tag Manager ein "form_submit"-Event an Google Analytics.

Die CRM-Übergabe und das Tracking-Event fallen in Webflow-Projekten erfahrungsgemäß am häufigsten durch den Test, weil sie technisch außerhalb des Formular-Designs liegen. Wer die technischen Voraussetzungen für die CRM-Integration in die Website genauer verstehen möchte, findet dort einen praxisnahen Einstieg.

Warum Akzeptanzkriterien für B2B-Webprojekte und Relaunches wichtig sind

Bei der Neugestaltung einer Unternehmenswebsite treffen häufig mehrere Stakeholder mit unterschiedlichen Erwartungen aufeinander: Marketing denkt an Leadgenerierung, IT besteht auf technischen Standards, die Geschäftsführung hat ein bestimmtes Erscheinungsbild vor Augen. Ohne Akzeptanzkriterien fehlt die gemeinsame Referenz, an der all diese Erwartungen gemessen werden.

Klare Abnahme ohne subjektive Diskussionen

Die Agentur kann anhand der Kriterienliste zeigen, was erfüllt ist. Der Auftraggeber prüft Punkt für Punkt, nicht nach Gefühl. Was schriftlich vereinbart wurde, lässt sich nach dem Test nicht mehr anders auslegen. Das schützt beide Seiten vor nachträglichen Missverständnissen.

Weniger nachträgliche Änderungen

Wer als Auftraggeber "es sollte schnell laden" fordert, bekommt von einer guten Agentur die Gegenfrage: Wie schnell, gemessen womit, auf welchem Gerät? Akzeptanzkriterien zwingen beide Seiten zur Klarheit, bevor der Aufwand entsteht. Scope Creep, also das schleichende Anwachsen des Projektumfangs, entsteht fast immer aus zu vage formulierten Anforderungen.

UX- und SEO-Anforderungen messbar machen

Ob eine Seite "gut bedienbar" ist, lässt sich kaum objektiv abnehmen. Ob alle interaktiven Elemente per Tastatur erreichbar sind oder alle Bilder Alt-Texte haben, dagegen schon. Wer mit einer Webflow-Agentur zusammenarbeitet, kann UX- und SEO-Anforderungen als messbaren Bestandteil der Akzeptanzkriterien vereinbaren, statt sie als vages Qualitätsziel offen zu lassen.

Was eine Webflow-Website für Unternehmen leisten kann und welche Anforderungen in Projekten typischerweise auftauchen, beschreibt unser Überblicksartikel zu diesem Thema.

Häufige Fehler bei Akzeptanzkriterien

Zu vage formuliert

"Das Formular soll gut aussehen" oder "die Seite soll schnell laden" sind keine Akzeptanzkriterien. Jede Bedingung muss so präzise sein, dass eine unabhängige Person sie eindeutig als erfüllt oder nicht erfüllt bewerten kann. Wenn ein Kriterium Interpretationsspielraum lässt, wird er genutzt.

Lösung statt Ergebnis beschreiben

Ein häufiger Fehler: Das Kriterium schreibt die technische Umsetzung vor statt das erwartete Ergebnis. Statt "Das Formular wird mit JavaScript-Validierung entwickelt" lieber: "Das Formular zeigt eine Fehlermeldung, bevor die Seite neu geladen wird." Das erste legt fest, wie etwas gebaut wird. Das zweite beschreibt, was es leisten muss. Nur das zweite ist ein echtes Akzeptanzkriterium.

Nicht testbar

Jedes Kriterium muss in einen konkreten Test überführt werden können. "Die Nutzer sollen zufrieden sein" ist ein nachvollziehbares Ziel, aber kein messbares Kriterium. Die Testfrage lautet immer: Wie genau prüfe ich, ob diese Bedingung erfüllt ist?

Nachträgliche Änderungen ohne Absprache

Akzeptanzkriterien sind keine erweiterbare Wunschliste, die während der Entwicklung wächst. Jede Änderung nach Sprint-Start erhöht den Aufwand und muss neu vereinbart, priorisiert und in den Projektscope aufgenommen werden. Wer das nicht konsequent handhabt, schafft ungeplanten Mehraufwand, der im Abschlussbudget auftaucht.