Pauschal kann man sagen:
Grade so detailliert, dass das Team offene Fragen während des Sprints, in dem die Story umgesetzt wird, rechtzeitig klären kann.
Das hängt also auch von den vorhandenen Skills im Team ab. Wenn z.B. kein Konzepter-Skill im Team vorhanden ist, dann muss das UI/UX-Konzept im Vorfeld erstellt werden. Auch dann, wenn es so umfangreich ist, dass es in dem Sprint nicht rechtzeitig genug fertiggestellt werden kann, um die Folgetätigkeiten auch noch abzuschließen.
Szenario: Bei Versuchen mit dem neuen Raketenantrieb stellt die NASA Vibrationen fest, die sich niemand erklären kann. Welche Frage ist sinnvoller: a) Frage an die Astronauten: Ist es für die Astronauten akzeptabel, dass sie bei Ihrem Flug Virbrationen spüren die aber nur geringfügig unangenehm sind? b) Frage an die Ingenieure: Wie hoch ist das Risiko, dass noch ein Problem exisitiert, welches für die Astronauten lebensbedrohlich ist?
Stories oder Aufgaben, die bekanntermaßen nicht im aktuellen Sprint abgeschlossen werden können, sollten nicht ins Sprint Backlog aufgenommen werden. Das ist oft z.B. bei teamexternen Abhängigkeiten der Fall.
Aber wohin gehören sie denn dann?
Entweder teilt man so ein Issue in kleinere Teile auf, die innerhalb eines Sprint umgesetzt werden können, oder markiert es im Backlog als WARTEND.
Für den zweiten Fall kann man im Backlog eine Trennlinie eingetragen. Z.B. „— WAITING ON SOMETHING above this line —„.
Niedrig priorisierte Bugs oder Aufgaben, die prinzipiell startklar sind, und nur noch auf Zeit bzw. Priorisierung warten, gehören ans untere Ende des Backlogabschnittes, welcher fertig für den Sprint ist. D.h. direkt über eine Trennlinie „— READY FOR SPRINT above this line —„.
Was tun, damit solche Einträge nicht in Vergessenheit geraten?
Manchmal scheinen selbst Entwickler zu viel zu reden. Grade in frühzeitigen Estimation- (bzw. Grooming- oder Product Backlog Refinement) Workshops verliert man leicht den Fokus und diskutiert zu früh über fachliche und technische Feinheiten.
Mit dieser Spielaufstellung hat das Team eine spielerische Hilfe sich auf die wichtigsten Dinge zu konzentrieren.
Jeder Spieler auf dem Feld steht für einen wichtigen Aspekt bei einer User Story.
Darüber hinaus kann man sich noch weitere Spielregeln ausdenken. Ersatzspieler, z.B. für die typischen INVEST Kriterien oder zu speziellen Team Herausforderungen. Oder Punktregelungen.
Diese Präsentation mit der Spielaufstellung kann gerne weiterverwendet werden. Enjoy!