Das Scrum Estimation Meeting wird ein- oder zweimal pro Sprint durchgeführt. Bei dem Meeting kommt das Scrum Team zusammen (bestehend aus Scrum Master, Developer und Product Owner) zusammen, um neue und/oder bestehende User Stories zu besprechen. Bei dem Meeting geht es weniger um eine Aufwandsschätzung mit Story Points, als vielmehr darum, eine Grundlage für zukünftige Sprints zu legen. Das Scrum Estimation Meeting sollte dabei zwar nicht als Vorbereitungsmeeting für das Sprint Planning gesehen werden, dennoch werden hier zum Teil User Stories besprochen, die der Product Owner dann in das Sprint Planning mitbringen wird. Die im Sprint Planning vorgestellten User Stories sind dem Development Team dann bereits bekannt. Gemeinsam werden dann die Details der User Stories besprochen. Wir haben im Folgenden die einzelnen Elemente der Estimation Session beschrieben.
4 Scrum Estimation Meeting Elemente
1. Unklarheiten beseitigen
Der Product Owner präsentiert im Estimation Meeting User Stories, die mit den Developern zusammen diskutiert werden. Das Team stellt Fragen und der Product Owner verbessert die User Story, indem er alle Fragen beantwortet und die Ergebnisse in der User Story notiert. Gegebenfalls wird das Team feststellen, dass eine User Story zu komplex für einen Sprint ist. In diesem Fall bricht es zusammen mit dem Product Owner die User Story in mehrere kleinere User Stories herunter.
Auch die Developer haben die Möglichkeit, neue User Stories einzubringen. Das kann zum Beispiel beim Schneiden einer zu komplexen User Stories in mehrere kleine User Stories der Fall sein. Oder User Stories, um das Produkt zu verbessern. Wenn im letzten Sprint Review neue Aufgaben für das Team entstehen, können diese neuen User Stories auch im Rahmen der Estimation Session weiter verfeinert werden.
2. Schätzungen anpassen
Von Zeit zu Zeit wird der Product Owner nicht nur neue User Stories mit dem Team besprechen, sondern bereits bekannte User Stories erneut diskutieren. Gründe hierfür können neue Erkenntnisse mit Auswirkungen auf die Aufwandsschätzung sein, oder auch der Aufbau von Erfahrungen im Team. Durch das wiederholte Betrachten der User Stories werden die Schätzungen im Product Backlog kontinuierlich optimiert. Dies führt zu einer besseren Vorhersagbarkeit bei der Roadmap-Gestaltung.
Es gibt unterschiedliche Ansätze, wie das Schätzverfahren abläuft. Zum einen kann in altbekannten Personen- oder Projekttagen geschätzt werden. Oder das Team verwendet Stories Points, um die Komplexität der User Stories zu schätzen. Auch hier gibt es unterschiedliche Methoden: Magic Estimation, Planning Poker oder Analogie. Um nur mal drei Schätzverfahren und -methoden zu nennen.
Wenn Du das gesamte Backlog schätzen möchtest, bietet sich der Einsatz von Magic Estimation an.
3. Vorbereitung auf das Sprint Planning
In der Anfangsphase eines neuen Projekts liegt der Fokus auf der Planung des nächsten Sprint Plannings. Product Owner und Team besprechen dann bereits bekannte User Stories, bei denen die Rückfragen bereits geklärt sind. Dadurch wird die benötigte Zeit im Sprint Planning 1 reduziert. Das Sprint Planning wiederum kann sich dann darauf konzentrieren, zu ermitteln, welche User Stories im nächsten Sprint umgesetzt werden können. Somit muss das Team nicht zusätzlich noch die Inhalte diskutieren.
Im Laufe des Projekts verändert sich der Fokus in der Estimation Session zunehmend. Wird es am Anfang vor allem für die Vorbereitung auf das nächste Sprint Planning eingesetzt, wird das Estimation Meeting nach und nach ein strategisches Meeting. Die Weichen für die zukünftige Produktentwicklung werden hier gestellt. Dies geschieht durch das Besprechen von neuen User Stories, die erst in weiter entfernten Sprints umgesetzt werden. Dies erlaubt das Erstellen einer agilen Roadmap.
4. Voraussetzung für eine Roadmap
Im weiteren Projektverlauf diskutiert der Product Owner auch User Stories, die erst in der Zukunft relevant sein werden. Vielleicht im übernächsten Sprint, nächsten Monat oder auch in drei Monaten. Wenn zusätzlich die User Stories auch geschätzt werden (z.B. mit Hilfe von Story Points) und die Velocity bekannt ist, dann hat der Product Owner alles zur Hand, um daraus eine Roadmap zu generieren.
Es handelt sich dabei dann um eine agile Roadmap. Sie basiert auf den jeweils aktuellen Erfahrungsstand im Hinblick auf die Velocity und den bereits bekannten User Stories. Die Velocity ist in dem Zusammenhang der Durchsatz an Story Points, den das Team pro Sprint erledigt. Damit kann eine Vorhersage getroffen werden, wie viele Story Points vermutlich auch in der Zukunft umgesetzt werden können. Bei Schätzungen handelt es sich allerdings immer um eine Vermutung. Um eine Wette auf die Zukunft. Daher handelt es sich hier um eine agile Roadmap. Mit den prognostizierten Umsetzungsdaten und den Inhalten muss vorsichtig umgegangen werden.
Das könnte Dich auch interessieren:
