Die User Story als Einladung zu einer Diskussion

Viele meiner Kunden fragen, wie viele Anforderungen eine User Story beinhalten sollte und wo denn die „anderen“ Anforderungen abgespeichert werden sollen.Diese Frage ist meiner Meinung nach ein Widerspruch in sich. Denn eine User Story besteht ja nicht nur aus dem berühmten Satz „Als <Rolle> möchte ich <Funktion>, um <Nutzen> zu haben“, sondern enthält einiges mehr an Informationen.Zunächst mal: Was braucht man, um ein Produkt zu entwickeln? Natürlich das Wissen darüber, wie dieses Produkt am Ende aussehen soll. Was *braucht* der User? Was *will* der User? Was sind die Rahmenbedingungen (Budget/Ressourcen, Gesetze etc.)?Um all diese Fragen zu beantworten, sollte also eine User Story diese Informationen beinhalten:

• Eine Kurzbeschreibung, zum Beispiel im bekannten Format „Als <Rolle/Persona> möchte ich <Funktion>, um <Nutzen> zu haben“. Dies muss aber gar nicht sein. Wichtig dabei ist nur, dass die Teammitglieder sich Gedanken darüber machen: „Für wen mache ich das?“, „Was mache ich überhaupt?“ und „Warum mache ich das?“
• Akzeptanzkriterien: Was muss diese User Story erfüllen, damit sie vom PO abgenommen wird?
• Akzeptanztests: Damit überprüfe ich, ob die Akzeptanzkriterien erfüllt sind (nicht zu verwechseln mit Fachtests).
• Rahmenbedingungen/Constraints (nicht zu verwechseln mit Akzeptanzkriterien): Rahmenbedingungen können zum Beispiel sein: Das Betriebssystem, für das diese User Story entwickelt wird (nur für „iOS“ oder nur für Windows oder „muss auf beiden funktionieren“), Gesetze, denen Genüge getan werden muss, verschiedene Sprachen etc.
• Weitere Beschreibung: Hier werden alle Informationen eingefügt, die notwendig sind, damit alle Beteiligten verstehen, was diese Funktionalität tun soll. Das kann von einer simplen Skizze bis zu einem UML-Diagramm reichen, solange diese noch keine Designvorlage sind. Denn das „Wie“ wird ja bekanntlich erst im Sprint Planning 2 besprochen und festgelegt.

Wie umfassend soll diese „Dokumentation“ sein? Ich beobachte, wie lange mein Team beim Refinement darüber geredet hat – das ist mein Richtwert. Denn das ist genau das, was in diesem Meeting passieren soll: darüber reden. So lange bis jeder weiß, was diese Funktionalität können muss.Jetzt werden viele sagen: „Wir arbeiten ja nur mit Kärtchen, da passt das alles nicht drauf.“ Das ist schon richtig. Es spricht allerdings nichts dagegen, zusätzlich zum Kärtchen auch andere Medien zu verwenden, die separat geführt werden. Ein Flipchart reicht oft völlig aus.Wie sieht bei Ihnen eine User Story aus?