Zweck

1. Mit dem Estimation Meeting werden zwei Ziele verfolgt: Die Teammitglieder lernen die Inhalte der Stories aus dem Backlog kennen, und sie bekommen durch das kontinuierliche Einschätzen der Stories ein klares Bild des Produkts.
2. Die Teammitglieder schätzen den Funktionsumfang der Stories.
3. Durch das Aufteilen bereits vorhandener Stories oder durch neue Ideen entstehen während des Meetings neue Stories.

Grundlagen

Nur das Team schätzt die Funktionalität ein. Der Product Owner steht für Fragen zur Verfügung. Zusammen mit dem Entwicklungsteam werden Stories in - aus Businesssicht - sinnvolle, kleinere Teile gesplittet.

Zutaten

• Das vom Product Owner nach Business Value priorisierte Product Backlog

Farbiges Symbol = Pflichtteilnehmer

Graues Symbol = möglicher Teilnehmer

Tipp: Probiere ebenfalls aus, mit mehreren Product Ownern nach dem gleichen Verfahren den Business Value von Stories einzuschätzen.

Was man NICHT tun sollte

1. Arbeitsaufwand statt Funktionsumfang schätzen.
2. Der Product Owner schätzt oder moderiert das Meeting.
3. Stories erst während des Sprint Planning Meeting #1 schätzen.

Ablauf

1. Der Product Owner präsentiert die Product Backlog Items, die geschätzt werden sollen.
2. Das Team schätzt mit Hilfe von Magic Estimation.
3. Große Backlog Items, die wahrscheinlich in einem der nächsten Sprints zu bearbeiten sind, müssen in kleinere Teile aufgeteilt werden. Die neuen Items werden wiederum mit Magic Estimation geschätzt.
4. Es werden immer alle Backlog Items, auch schon geschätzte, aber noch nicht entwickelte, eingeschätzt.
5. Die geschätzten Product Backlog Items sollten mindestens die nächsten 3 Sprints umfassen.

Dauer

Timebox 35 Minuten oder weniger.

Diese Meetings sollten wöchentlich stattfinden.

Ergebnis

• Das geschätzte Product Backlog
• Kleinere Backlog Items
• Eine Liste von Stories, über die genauer nachgedacht werden muss