Nachdem ich bereits über absolutes Schätzen in Personentagen und relatives Schätzen mit Hilfe von Story Points geschrieben habe, möchte ich im Folgenden ein sehr einfaches und schnelles Verfahren vorstellen, mit dem man sehr unkompliziert ein umfangreiches Backlog abschätzen kann. Beim Bucket Estimation schätzt man Anforderungen, indem man sie dem Aufwand nach sortiert, sie anschließend gruppiert und dann allen Product Backlog Items in einer Gruppe (Bucket)  die gleiche Anzahl an Story Points zuweist.

Zum Schätzen eines Backlogs mit 50 bis 75 Backlog Items benötigt man mit dieser Methode in der Regel 1,5 bis 2 Stunden.

Vorbereitungen

Für Bucket Estimation empfiehlt sich ein möglichst großer Meetingraum. Gerne kann man störende Stühle entfernen, da das Meeting ohnehin im Stehen stattfindet.

Die Anforderungen sollten bereits in User Stories geschnitten sein. Geschätzt wird immer das gesamte Backlog, so dass alle User Stories auf einzelnen Karten ausgedruckt werden  müssen.

Falls man ein Ticketsystem wie Jira benutzt, in dem weitere Informationen zu den einzelnen User Stories abgelegt sind, macht es Sinn Tablets und Notebooks auszulegen. So hat jeder für sich die Möglichkeit sich über Details der Anforderungen ein Bild zu machen.

Zusätzlich benötigt man noch einen Satz Planning Poker Karten. Es werden einmal die Karten von 1 bis 100 benötigt. Die Kaffetasse wird bei dieser Methode nicht gebraucht.

Zu Beginn des Schätz-Meetings versammelt sich das gesamte Team um einen großen Tisch. Die ausgedruckten User Stories werden gemischt und zu gleichen Teilen an die Mitglieder des Entwickler-Teams verteilt.

Eine User Story wird in die Mitte des Tisches gelegt.

Ablauf

Die Schätzung läuft in 3 Phasen ab:

1. Phase: Sortieren des Backlogs

2. Phase: Zuweisung der Story Points

3. Phase: Besprechen und Schätzen der unklaren Tickets

Phase 1 – Sortieren des Backlogs

Die erste Phase findet in mehreren Runden statt. Ist ein Entwickler an der Reihe, so haben die anderen Entwickler im Team Funkstille. Hintergrund ist, dass man bei Bucket Estimation unter allen Umständen unnötige Diskussionen verhindern will.

Aktionen während Phase 1

Ist ein Entwickler an der Reihe, kann er aus einer der folgenden Aktionen wählen:

1. Eine seiner User Stories auf dem Tisch einsortieren
2. Eine User Story, die bereits auf dem Tisch liegt umsortieren

Entscheidet sich der Entwickler dafür, ein Item umzusortieren, so muss er dies begründen. Wird ein Product Backlog Item häufiger umsortiert, als Entwickler an der Schätzung beteiligt sind, so wird es vom Tisch genommen und in Phase 3 besprochen.

Der Entwickler, der an der Reihe ist, hat die Möglichkeit durch Rückfragen an den Product Owner oder sonstige anwesende Personen Informationen zu einer User Story zu erhalten. In jedem Fall ist nur er derjenige, der während seiner Runde jemandem das Wort erteilen darf. Wie bereits beschrieben: Diskussionen sollten in jedem Fall vermieden werden.

Ziel der Phase 1

Ziel der Phase 1 ist es, dass das gesamte Backlog dem Aufwand nach sortiert auf dem Tisch liegt. Das Product Backlog Item, welches die geringste Komplexität und die geringste Zeit zur Umsertung benötigt liegt ganz links auf dem Tisch. Das Backlog Item mit der höchsten Komplexität liegt rechts. Alle anderen Items sortieren sich zwischen ihnen ein. Einige wenige Anforderungen befinden sich nicht in dieser sortierten Reihe und werden in Phase 3 geschätzt.

Phase 2 – Zuweisung der Story Points

Nun geht es darum, die Story Points zu verteilen. Hierzu nimmt ein Moderator die niedrigste Karte im Planning-Poker-Kartenset. In der Regel ist dies die 1. Diese Karte führt er nun vom einfachsten Backlog Item beginnend an den Tickets entlang, bis das Entwickler-Team der Meinung ist, dass die Kosten der nächsten Anforderung auf dem Tisch,  den auf der Karte angezeigten Wert überschreitet. Alle Product Backlog Items links von dieser Anforderung erhalten nun den Wert der Karte und können vom Tisch genommen werden. Sie gehören zu einem Bucket mit dem Wert 1.

Dieses Prozedere wird wiederholt bis entweder alle Product Backlog Items geschätzt wurden oder nur noch die Karte mit der 100 übrig ist.

Items, die mit der 100 bewertet wurden, werden in Phase 3 erneut betrachtet.

Phase 3 – Besprechen und Schätzen der Unklaren Tickets

Alle Anforderungen, die bis jetzt nich nicht geschätzt wurden, werden nun noch einmal vom Product Owner oder vom Projektleiter erklärt. Danach werden sie per Planning Poker geschätzt. Kann eine Anforderungen auch mit Planning Poker nicht geschätzt werden, so geht sie an den Product Owner oder den Projektleiter zurück, der nun den Auftrag hat mehr Informationen über diese Anforderung zu sammeln und diese später erneut schätzen zu lassen.

Schätzen während des Projektes

Bucket Estimation eignet sich besonders gut zu Beginn eines Projektes, wenn es zwar reichlich Anforderungen, aber noch keine Schätzungen gibt. Aber auch im laufenden Projekt macht Bucket Estimation Sinn.

Hierzu legt man zunächst alle Tickets, die bereits geschätzt wurden, nach ihren Story Points sortiert auf den Tisch und verteilt nur die noch nicht geschätzten Product Backlog Items an das Entwickler-Team.