Antwort.

Historisch gesehen lag die Formulierung der Akzeptanzkriterien (Akzeptanzkriterien) in den Händen von Testern oder Entwicklungsteams. Mit dem Übergang zu agilen skalierbaren Prozessen (SAFe, LeSS, Scrum-of-Scrums) kommen jedoch ohne formalisierte Testszenarien Risiken für abweichende Erwartungen verschiedener Teilnehmer eines großen Projekts auf: Geschäftsbereich, Tests, Entwickler und Support können die Vollständigkeit der Aufgabe unterschiedlich interpretieren.

Das Problem in Multi-Team- oder verteilten Projekten: verschiedene Verantwortungsbereiche, unterschiedliche Prozesse und Werkzeuge, sprachliche oder kulturelle Unterschiede zwischen den Teams. Selbst detailliert ausgearbeitete Anforderungen können in konfliktreiche oder unvollständige Akzeptanzkriterien umschlagen, was zu Bugs und Unzufriedenheit im Geschäftsbereich führt.

Die Lösung besteht darin, den Systemanalytiker frühzeitig in die Entwicklung der Akzeptanzkriterien einzubeziehen, die Anforderungen zwischen den Teams abzustimmen, strenge Formalisierungen und die gemeinsame Diskussion von Szenarien und Randfällen (Edge-Cases) in einem gemeinsamen Demo oder Gruppen-Workshop durchzuführen.

Wesentliche Merkmale:

Akzeptanzkriterien müssen eindeutig, messbar, reproduzierbar und validierbar sein.
Vorab-Abstimmung der Kriterien (manuelle Checkliste + Beispiele erwarteter Daten/Verhalten).
Gegenseitige Rückverfolgbarkeit: Kriterien müssen immer auf Anforderungen, Fälle und User Stories verweisen, um jedes Ziel zurückverfolgen zu können.

Fragen mit einem Hintergedanken.

Kann die Formulierung der Akzeptanzkriterien vollständig den Testern überlassen werden?

Nein, der Analyst muss teilnehmen. Nur er kennt die Vollständigkeit des Geschäftskontexts und weiß alle Facetten der Anforderungen.

Müssen die Akzeptanzkriterien nur positive Szenarien abdecken?

Nein, negative und Grenzfälle (Edge Cases) müssen unbedingt hinzugefügt werden, da sonst Lücken in der Umsetzung und im Test entstehen können.

Kann man Akzeptanzkriterien mündlich in Multi-Team-Projekten festlegen?

Nein, mündliche Vereinbarungen halten der Belastung einer verteilten Interaktion nicht stand und führen zu Konflikten. Kriterien müssen nur formal (zum Beispiel in Form von Gherkin/BDD oder strukturierten Checklisten) akzeptiert werden.

Typische Fehler und Anti-Patterns

Formulierung der Akzeptanzkriterien "standardmäßig" ohne Verweise auf Anforderungen und Spezifikationen.
Fehlendes Feedback von den Endteams.
Ignorieren von Interaktionsszenarien zwischen Komponenten verschiedener Teams, insbesondere bei Integrationen.

Beispiel aus dem Leben

Negativer Fall: In einer Banking-App wurden die Akzeptanzkriterien für den Überweisungsfunktionen nur mit einem Team abgestimmt. Ein zweites Team implementierte seine internen Schnittstellen ohne Berücksichtigung des ersten Blocks von Kriterien, was zu Inkonsistenzen im Format der Transaktions-IDs führte.

Vorteile:

Schneller Beginn der Umsetzung.

Nachteile:

Notwendigkeit zur Refaktorisierung der API.
Zeitverlust bei der Behebung von Kollisionen.

Positiver Fall: Der Analyst führte eine Reihe von Workshops mit visuellen Szenarien und Details für alle beteiligten Teams durch, mit verbindlicher schriftlicher Festlegung der Akzeptanzkriterien in Confluence/JIRA mit bidirektionaler Rückverfolgbarkeit zu den Anforderungen.