Akzeptanzkriterien: Beispiele für kleine IT-Aufträge
Kurz gesagt: Akzeptanzkriterien sind prüfbare Sätze, die festlegen, wann ein Auftrag erledigt ist. Ein gutes Kriterium nennt eine Ausgangslage, eine Handlung und ein beobachtbares Ergebnis mit konkreten Werten, etwa: Nach dem Absenden kommt die Anfrage innerhalb von fünf Minuten in info@ an. Für kleine Aufträge reichen meist drei bis sieben solcher Sätze.
„Das Formular soll funktionieren.“ Für den Auftraggeber ist der Satz eindeutig. Der Entwickler liest ihn so: Das Formular schickt etwas ab und zeigt keine Fehlermeldung. Ob die Mail auch ankommt, ob sie im Spam landet, ob sie auf dem Handy abgeschickt werden kann, steht nicht drin.
Diese Lücke zwischen „funktioniert“ und „funktioniert so, wie ich es meinte“ ist bei kleinen Aufträgen ein typischer Grund für Nacharbeit, über die dann gestritten wird. Akzeptanzkriterien schließen sie, bevor die erste Zeile Code entsteht.
Was ein gutes Akzeptanzkriterium ausmacht
Ein Akzeptanzkriterium beschreibt ein Ergebnis, das jemand von außen prüfen kann. Es sagt nicht, wie der Entwickler es erreichen soll. Drei Fragen helfen beim Formulieren:
- Kann eine dritte Person das Kriterium in wenigen Minuten prüfen, ohne den Code zu kennen?
- Steht ein konkreter Wert drin, wo einer hingehört? Fünf Minuten, drei Testmails, 2,5 Sekunden.
- Beschreibt es, was passiert, und nicht, was jemand tun soll?
„Die Seite soll schnell laden“ fällt durch alle drei Fragen. „Die Startseite erreicht im Lighthouse-Test für Mobilgeräte einen Largest Contentful Paint von höchstens 2,5 Sekunden“ besteht sie. Die 2,5 Sekunden sind übrigens nicht erfunden. Google nennt sie in seiner Dokumentation zu den Core Web Vitals als Grenze für einen guten Wert.
Zwei Schreibweisen: Checkliste oder Gegeben-Wenn-Dann
Die einfachste Form ist eine Liste von Aussagen, die nach der Lieferung wahr sein müssen. Für die meisten kleinen Aufträge reicht das völlig.
Bei Abläufen mit mehreren Schritten hilft eine festere Struktur. Sie stammt aus der Testbeschreibungssprache Gherkin und heißt auf Englisch Given, When, Then. Auf Deutsch funktioniert sie genauso:
- Gegeben ist eine Ausgangslage, zum Beispiel ein eingeloggter Kunde mit Artikel im Warenkorb.
- Wenn eine Handlung passiert, etwa der Klick auf „Jetzt kaufen“.
- Dann tritt ein beobachtbares Ergebnis ein: Die Bestellbestätigung kommt per Mail.
Die Gherkin-Referenz von Cucumber empfiehlt drei bis fünf Schritte pro Beispiel. Mehr macht ein Szenario schwer lesbar. Wer zehn Zeilen braucht, beschreibt meist zwei Fälle auf einmal.
Zwölf Beispiele für typische kleine Aufträge
Die folgenden Beispiele kannst du anpassen und direkt in deine Auftragsbeschreibung für den Programmierer übernehmen. Die Werte sind Vorschläge, keine Normen.
Kontaktformular reparieren
- Drei Testnachrichten von drei verschiedenen Absenderadressen kommen innerhalb von fünf Minuten im Postfach info@ an.
- Keine der Testnachrichten landet bei Gmail oder Outlook im Spam-Ordner.
- Das Formular lässt sich auf einem aktuellen iPhone und einem Android-Gerät abschicken.
Neues Feld im Shop-Checkout
- Gegeben ist ein Gast im Checkout. Wenn er das Feld „Umsatzsteuer-ID“ ausfüllt und bestellt, dann erscheint der Wert in der Bestellübersicht im Backend und auf der Rechnung.
- Bleibt das Feld leer, lässt sich die Bestellung trotzdem abschließen.
Individuelles WordPress-Plugin
- Das Plugin läuft ohne Fehlermeldungen mit der aktuellen WordPress-Version und der PHP-Version des Hosters.
- Beim Deaktivieren bleibt die Website erreichbar, beim Löschen werden die eigenen Datenbanktabellen entfernt.
Schnittstelle zwischen Shop und Buchhaltung
- Gegeben ist eine bezahlte Bestellung. Wenn sie im Shop als „abgeschlossen“ markiert wird, dann liegt innerhalb von 15 Minuten ein Beleg mit identischem Bruttobetrag in der Buchhaltung.
- Schlägt die Übertragung fehl, bekommt eine festgelegte Adresse eine Mail mit Bestellnummer und Fehlermeldung.
Ladezeit verbessern
- Die Startseite erreicht im Lighthouse-Test für Mobilgeräte einen Largest Contentful Paint von höchstens 2,5 Sekunden.
Fehler beheben
- Die Schritte aus dem ursprünglichen Fehlerbericht führen nicht mehr zum Fehler, geprüft auf dem dort genannten Gerät und Browser.
- Die Bereiche, die der Entwickler geändert hat, sind in einer kurzen Notiz aufgelistet.
Das letzte Beispiel wirkt unscheinbar. Es ist aber das, was dir beim nächsten Fehler eine Stunde Suche erspart.
Schlechte und gute Kriterien im Vergleich
Unbrauchbare Kriterien scheitern meist an ähnlichen Mustern. Sie bewerten statt zu beschreiben, sie lassen Werte offen oder sie verlangen etwas, das niemand prüfen kann.
| Kriterium | Unbrauchbar | Prüfbar |
|---|---|---|
| Formular | funktioniert zuverlässig | 3 Testmails kommen in 5 Min. an, keine im Spam |
| Ladezeit | lädt schnell | LCP mobil höchstens 2,5 s im Lighthouse-Test |
| Design | sieht modern aus | entspricht dem angehängten Entwurf bei 375 und 1440 px Breite |
| Schnittstelle | synchronisiert alles | bezahlte Bestellungen erscheinen binnen 15 Min. mit gleichem Betrag |
| Sicherheit | ist sicher | Admin-Login nur mit zweitem Faktor möglich |
Beim Design lohnt ein Zusatz. „Entspricht dem Entwurf“ funktioniert nur, wenn es einen Entwurf gibt. Ein Screenshot mit eingezeichneten Änderungen genügt. Ohne Vorlage entscheidet bei der Abnahme der Geschmack, und darüber lässt sich endlos streiten.
Das vergessene Kriterium: was nicht kaputtgehen darf
Fast alle Beispiele oben beschreiben, was neu funktionieren soll. Mindestens genauso wichtig ist, was danach noch genauso funktionieren muss wie vorher. Ein Plugin-Update repariert das Formular und legt nebenbei die Newsletter-Anmeldung lahm. Das merkt oft erst ein Kunde.
Schreib deshalb ein Kriterium dazu, das die zwei oder drei geschäftskritischen Abläufe deiner Website absichert. Zum Beispiel: „Nach der Änderung lassen sich eine Testbestellung mit PayPal und eine Anfrage über das Kontaktformular erfolgreich abschließen.“ Das kostet den Entwickler zehn Minuten Test. Dir erspart es im schlechtesten Fall einen Tag ohne Bestellungen. Damit sich der alte Zustand im Notfall zurückholen lässt, gehört ein aktuelles Backup der Website vor jeden Eingriff.
Wie viele Kriterien braucht ein kleiner Auftrag?
Drei bis sieben. Weniger als drei bedeutet meistens, dass Sonderfälle fehlen: leeres Feld, falsche Eingabe, mobiles Gerät. Mehr als sieben deutet darauf hin, dass der Auftrag gar nicht so klein ist und sich besser in zwei Teile zerlegen ließe.
Jedes Kriterium hat einen Preis. Ein Entwickler, der zusagt, dass keine Testmail im Spam landet, muss die Mailkonfiguration prüfen, vielleicht SPF- und DKIM-Einträge im DNS anpassen. Das ist sinnvoll, aber es ist Arbeit. Gute Kriterien machen ein Angebot deshalb manchmal teurer. Dafür bekommst du, was du brauchst, und der Preis ist ehrlich. Wie sich solche Unterschiede auf die Kosten auswirken, zeigt der Vergleich Festpreis oder Stundensatz.
- Von außen prüfbar, ohne den Code zu kennen
- Enthält einen konkreten Wert (Zeit, Anzahl, Betrag, Breite)
- Beschreibt ein Ergebnis, keine Bauanleitung
- Nennt Gerät oder Browser, wenn es darauf ankommt
- Deckt mindestens einen Sonderfall ab (leer, falsch, mobil)
Vom Kriterium zur Abnahme
Akzeptanzkriterien entfalten ihren Wert erst am Ende. Bei der Abnahme gehst du sie der Reihe nach durch und hakst ab. Was erfüllt ist, ist erledigt. Was nicht erfüllt ist, geht mit Beschreibung zurück. Dieses Vorgehen lässt sich direkt in ein Abnahmeprotokoll übertragen, das du mit dem Entwickler unterschreibst oder per Mail bestätigst.
Wer regelmäßig Aufträge vergibt, merkt schnell, dass sich viele Kriterien wiederholen: Backup vor dem Livegang, Test auf dem Handy, kurze Notiz zu den Änderungen. Diese Punkte kannst du einmal als feste Liste formulieren und an jede Beschreibung anhängen. Teams, die Software dauerhaft entwickeln und betreiben, arbeiten aus genau diesem Grund mit einer festen Definition of Done.
Nimm dir für deinen nächsten Auftrag zehn Minuten, schreib drei Kriterien nach dem Muster oben und lass sie den Entwickler gegenlesen, bevor er ein Angebot schickt.
Häufige Fragen
Was ist der Unterschied zwischen Akzeptanzkriterien und Definition of Done?
Akzeptanzkriterien gelten für eine bestimmte Aufgabe, etwa ein Formular. Die Definition of Done gilt für alle Aufgaben eines Teams, zum Beispiel „Code ist im Repository, Backup vor Livegang gemacht“. Bei Einzelaufträgen an Freelancer brauchst du meist nur die Akzeptanzkriterien.
Wer schreibt die Akzeptanzkriterien, ich oder der Entwickler?
Du schreibst den ersten Entwurf, weil nur du weißt, was du brauchst. Der Entwickler ergänzt technische Punkte und sagt, wenn ein Kriterium nicht prüfbar oder unverhältnismäßig teuer ist. Am Ende stehen sie im Angebot oder in der Auftragsbestätigung.
Muss ich die Gegeben-Wenn-Dann-Form verwenden?
Nein. Sie hilft bei Abläufen mit mehreren Schritten. Für einfache Dinge wie eine Textänderung oder ein neues Feld genügt ein klarer Satz oder eine Checkliste.
Was passiert, wenn ein Kriterium nach der Lieferung nicht erfüllt ist?
Dann ist die Leistung nicht so geliefert wie vereinbart, und du kannst Nachbesserung verlangen. Genau dafür sind die Kriterien da: Sie machen aus einem Gefühl eine überprüfbare Aussage.
