Die absolute Untergrenze
Die absolute Untergrenze für eine Anforderung, um in einen Sprint aufgenommen werden zu können ist:
Wir (das Team) wissen, was der Product Owner umgesetzt haben möchte.
Was soll denn auch implementiert / programmiert werden, wenn noch nicht einmal das bekannt wäre?
Diese absolute Untergrenze ist absolut unzureichend, wenn das Team erfolgreich sein möchte. Es bedarf mehr.
Was noch Sinn macht.
Über das „Wir (das Team) wissen, was der Product Owner umgesetzt haben möchte.“ hinaus ist noch folgender Aspekt bekannt:
Wir (das Team) wissen in etwa, wie wir es (programmier-) technisch implementieren wollen.
Was das heißt, lässt sich ganz einfach erklären. Wir haben die Implementierungsschritte ganz grob im Kopf. Quasi den
High Level Task Breakdown
Wie sollten wir ansonsten behaupten können, dass wir „in etwa wissen, wie wir es (programmier-) technisch implementieren wollen“?
Absolut sinnvoll wäre es natürlich, wenn wir diesen High Level Task Breakdown mal eben – vielleicht in der User Story – niederschreiben, oder?
Ja und wenn wir uns nun schon in das Thema – also das, was der Product Owner von uns möchte – hineingekniet haben und uns Gedanken über das Wie gemacht haben, warum dann nicht auch gleich noch einen Gedanken daran verschwenden, wie lange wir denn dafür in etwa brauchen werden? Eine grobe
Aufwandsschätzung
durchführen und uns überlegen, ob
Abhängigkeiten
bestehen, die erst noch durch andere (Scrum) Teams aufgelöst werden müssen. Das sind „Vorarbeiten“, die geleistet werden müssen, bevor wir (das Team) mit unserem Teil der Arbeit anfangen können. Die werden dann im Rahmen des PI Plannings noch einmal aufgezeigt und dokumentiert.
Das Wer und Wann
Wann wird denn eine Anforderung (ein Issue / eine User Story) von wem in Richtung DoR – Definition of Ready – hin entwickelt? Das geschieht während des Refinements. SAFe siedelt das Refinement als Tätigkeit innerhalb des Continuous Exploration an. Soll heißen, dass parallel zur Umsetzung des Sprint Plans das gesamte Team auch immer mit der Analyse von Anforderungen beschäftigt ist, die in naher Zukunft umgesetzt werden sollen. Welche das sind, das entscheidet der Product Owner.
Scrum sagt, dass in das Refinement bis zu 10 % der Kapazität des Entwicklungsteams fließen können.
Conclusio
Ohne zu wissen was der Product Owner möchte und ohne – zumindest grob – zu wissen, wie es umgesetzt werden kann und wieviel Aufwand es in etwa kosten wird, lässt sich kein Planning durchführen. Wie möchte man denn ein Commitment dafür abgeben, was man (das Team) am Ende des Sprints / PIs abzuliefern gedenkt, wenn man sich keine Gedanken über den ungefähren Aufwand gemacht hat?
Siehe dazu auch: Was ist ein Commitment wert, wenn …
Sie wollen die Qualität Ihrer Refinements verbessern um damit einen besseren Output zu gewährleisten?
