Wo kann man Details zu den Akzeptanzkriterien einer User Story einfügen?

In diesem Blogbeitrag über Akzeptanzkriterien erklärt der Autor, dass gute Akzeptanzkriterien:

• Geben Sie eine Absicht an, keine Lösung (z. B. "Der Benutzer kann ein Konto auswählen" anstelle von "Der Benutzer kann das Konto aus einer Dropdown-Liste auswählen").

• Sind unabhängig von der Implementierung (im Idealfall ist die Formulierung dieselbe, unabhängig davon, ob diese Funktion / Story beispielsweise auf einem Web, einem Mobiltelefon oder einem sprachaktivierten System implementiert wird).

• Sind relativ hoch (nicht jedes Detail muss schriftlich sein)

Und weitere Details wie:

• Die Spaltenüberschrift lautet "Balance".
• Das Rolling Balance-Format ist 99.999.999.999,9 D / CR
• Wir sollten ein Dropdown-Menü anstelle von Kontrollkästchen verwenden

sollte entweder in eine teaminterne Dokumentation oder in automatisierte Abnahmetests verschoben werden

Ich höre jedoch oft Leute, die die Stirn runzeln, wenn sie Gurken oder ähnliche Frameworks für GUI-Tests verwenden. Darüber hinaus kann die Verwendung einer internen Dokumentation zu vielen Problemen führen, da die Dokumentation nicht regelmäßig aktualisiert wird.

Ich habe immer noch Probleme, einen effektiven Weg zu finden, um solche Details während des Gesprächs mit dem Kunden zu erfassen.

Ich habe zwei Plätze (als Product Owner)

Neues Feedback von Kunden kann zu mehr Geschichten, einer Änderung der Prioritäten der Geschichte oder einigen neuen Details zu einer Geschichte führen. Im Backlog mache ich mir Notizen zu diesen Details für zukünftige Geschichten, die ich sonst vielleicht vergessen würde. Das sind Notizen für mich.

Kurz vor dem Planungstreffen übersetze ich das, was sich in meinem Kopf befindet, + diese Notizen in etwas, das das Team überprüfen kann. Dieses Dokument (wir verwenden eine Wiki-Seite pro Benutzer-Epos) wird während der Sprint-Planung weiter verfeinert und vervollständigt, um die Geschichte mit dem Team zu besprechen.

Ich mag es, 'Constraints' am Ende meiner Geschichte als 'PS' festzuhalten.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Diese Einschränkungen sind Einschränkungen, die Kunden meinem Design auferlegen und die beim Abwägen verschiedener Lösungen berücksichtigt werden müssen. Ich muss sie im Voraus kennen, daher gebe ich ihnen große Priorität.

Ich definiere gerne Abnahmetests für jeden Story-BDD-Stil als Teil der allgemeinen Dokumentation (Features - Stories - Tests).

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Spezifische Details wie die oben genannten wären Teil eines Bildschirmmodells, das der Client abmeldet. Solche Details sind nicht immer im Voraus bekannt, fallen jedoch in jedem Fall unter „Designbeschränkungen“. Wenn die Modelle im Voraus bekannt sind, nehme ich die Modelle und vereinbarten Designeinschränkungen in die Dokumentation auf hoher Ebene auf, da der Kunde sie vor Arbeitsbeginn abzeichnen muss.

Obwohl ich konzeptionell getrennt bin, sehe ich keinen Schaden darin, es in dasselbe Dokument aufzunehmen. Auch wenn es für die Client-Abmeldung nicht erforderlich ist, ist es praktisch, alle Anforderungen für ein Feature / eine Story an einem Ort zu haben.

Ich gehe eher pragmatisch vor - wenn ein technisches Detail für die Akzeptanz einer Geschichte wichtig ist, sollte es in den Akzeptanzkriterien enthalten sein, unabhängig davon, was in einem Blogbeitrag steht. Wenn es wirklich von entscheidender Bedeutung ist, dass der Spaltenname "balance" lautet, muss dies Teil der Akzeptanzkriterien sein.

Dies kann zu zu langen Akzeptanzkriterien führen. In einem solchen Fall muss meines Erachtens ein Akzeptanzkriterium darin bestehen, dass "Testsuite X bestanden werden muss", und in "Testsuite X" werden alle wichtigen Details zum Produkt angegeben.