Wenn Sie Scrum einsetzen und sich der Product Owner mit dem Team auf ein Sprintziel verständigt, können Sie dieses Planungsmeeting in zwei Schritten oder in einem Schritt durchführen, doch was sind die Vorteile dieser beiden Optionen? Und warum ist es sinnvoll, den nächsten Sprint schon einmal vor der Planungssitzung mit einem Entwickler durchzugehen?
Nur noch einmal ganz kurz zur Einführung: Wenn Sie die Planungssitzung in zwei Schritten durchführen, entscheidet das Team im ersten Meeting darüber, was es im nächsten Sprint verlässlich in ein Produktinkrement umsetzen kann, im zweiten Schritt entscheidet es darüber, wie es das tun will. Im zweiten Meeting muss der Product Owner nicht einmal mehr anwesend sein. Erinnern wir uns: es kann ihm vollkommen egal sein, wie das Entwicklungsteam vorgeht. Das entscheidet es selbst. Der Product Owner ist kein Entwickler und kein Entwicklungsleiter. Auch wenn er das einmal gewesen sein sollte, im Rahmen von Scrum ist er es nicht mehr.
Ein Meeting oder zwei? Diese Diskussion ist so alt wie Scrum selbst, dabei liegt die Antwort doch eigentlich auf der Hand, oder etwa nicht? Ich will ganz offen sein, ich habe einen ganz eindeutigen Favoriten in dieser Frage. ich möchte Ihnen im Folgenden lediglich erklären, warum ich ein Freund der Ein-Meeting-Lösung bin.
Für die Aufteilung der Planungssitzung in zwei Einheiten spricht in meinen Augen lediglich die Trennung des Was vom Wie, und die damit verbundene Autonomie des Entwicklungsteams, das im Rahmen des zweiten Meetings selbst entscheidet, wie es vorgehen möchte. Das bremst übereifrige Product Owner, die sich nur zu gern in die Fragen der Entwicklung einmischen möchten. Das ist zwar durchaus sinnvoll, aber dafür haben wir schließlich auch einen Scrum Master, nicht wahr?
Für mich liegt in der Trennung des Was vom Wie jedoch ein Problem. Wenn es Team darüber entscheiden möchte, was es in einem Sprint verlässlich umsetzen kann, dann muss es auch schon eine grobe Idee davon haben, was dafür notwendig ist, ansonsten kann es keine verlässliche Aufwandsschätzung abgeben, ist doch logisch, oder?
Für mich hat sich folgendes Vorgehen am besten bewährt:
Der Product Owner hat das Backlog sauber priorisiert und die Aufgaben bereits im Vorfeld mit einem Entwickler kurz besprochen. So kann er sicher gehen, dass alle Bedingungen erfüllt sind, um mit einer Aufgabe überhaupt beginnen zu können, und auf der anderen Seite gibt es so immer mindestens einen Entwickler, der sich zumindest schon einmal kurz mit der Aufgabe beschäftigt hat. Dieser kann im Zweifel den anderen auch schon etwas über einen möglichen Lösungsansatz sagen, oder er hat schon einmal in den Code gesehen (und festgestellt, dass man das Bestehende am besten wegwerfen sollte). Sie haben also bei der Frage des Wie schon immer eine informierte Person.
Der Product Owner stellt in der Planungssitzung eine Aufgabe nach der anderen vor und folgt dabei seiner Priorisierung. Bei jeder Aufgabe bespricht sich das Team kurz, was es dafür tun muss, wie aufwändig die Sache ist, und ob alle Bedingungen erfüllt sind, mit der Aufgabe zu beginnen und sie auch fertigstellen zu können. Das wird so lange fortgesetzt, bis die Ressourcen des Teams erschöpft sind. Das erfordert ein wenig Disziplin, sich nicht in endlosen Diskussionen zu verlieren, aber das sollte schnell erlernbar sein.
An diese Stelle möchte ich noch kurz erwähnen, dass ich kein Fan eines ganz fest gesetzten Zeitrahmens für das Planungsmeeting bin. Wenn man sich im Vorfeld auf eine Stunde verständigt, und es dauert 15 Minuten länger, dann ist das in meinen Augen kein Problem. Was sollen Sie sonst machen? Nach 60 Minuten abbrechen und den Sprint damit ungeplant lassen? Und was machen Sie dann?
Wenn Sie jedoch nach drei Stunden noch immer nicht fertig sind, dann haben Sie entweder ein größeres Problem in der Sprintvorbereitung (weil die Aufgaben evtl. nicht klar formuliert sind) oder in der Diskussionskultur (wobei das natürlich Aufgabe des Scrum Masters ist).
