Wie bereits im letzten Artikel erwähnt ist eine saubere Planung ein wesentlicher Garant für einen erfolgreichen Sprint. Mit den vorgestellten Methoden sollte man relativ einfach einen Umfang an Story Points errechnen können, den man in einem Sprint leisten kann.
Damit dies funktioniert, müssen natürlich zuerst alle Einträge des Product Backlogs beschätzt werden, um für jeden Eintrag einen Aufwand zu erhalten, mit dem man dann weiter planen kann.
Es gibt viele Möglichkeiten, Arbeitspakete zu schätzen.
Die einfachste Methode ist dabei ganz einfach, eine User Story dem Team zur Diskussion zu stellen und so lange zu warten, bis sich auf eine Zahl geeinigt haben. Dies wird in Fällen auch tatsächlich so gehandhabt, hat allerdings einen gravierenden Nachteil:
Im Laufe der Zeit hat sich nämlich gezeigt, daß die Diskussion üblicherweise so abläuft, daß ein Teammitglied, welches die Story gut versteht (oder zumindes denkt, dies zu tun) mit einer schnellen Schätzung rausplatzt. Dies führt dann jedoch dazu, daß andere Teammitglieder, die sich ihrer Sache nicht ganz so sicher sind, in ihrer Schätzung beeinflusst werden könnten (und wenn es nur unterbewusst ist).
In der Fachsprache nennt man dies „Anchoring“. Man sollte es wenn möglich vermeiden.
Eine einfache Methode, die dies tut, und die bei Scrum immer gerne eingesetzt wird, ist „Planning Poker“.
Sie besticht vor allem dadurch, daß sie leicht zu erlernen und relativ schnell in der Durchführung ist, dabei aber trotzdem genügend genaue Ergebnisse liefert.
Sie funktioniert wie folgt:
Zu Beginn erhält jeder Teilnehmer einen Satz Pokerkarten (ideal ist es übrigens, wenn das ganze Team teilnimmt). Ein Satz besteht aus 13 Karten mit den aufgedruckten Werten 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, [Kaffetasse] .
Wenn nun eine neue User Story beschätzt werden soll, so wird nun wie bisher so lange im Team diskutiert, bis alle soweit verstanden haben, worum es geht. In der Diskussion sind übrigens ausschliesslich sachbezogene Beiträge erlaubt. Statements mit vorauseilenden Wertungen („das ist ja einfach“) sind strikt verboten und werden mit einem nicht zu geringen Beitrag in die Kaffekasse bestraft :).
Nach Abschluss der Diskussion geht es dann an die Schätzung: Jeder Teilnehmer nimmt dann aus seinem Kartensatz diejenige Karte, von der er meint, daß sie dem Aufwand der zu schätzenden User Story (in Story Points) entspricht, und legt sie verdeckt (!) vor sich auf den Tisch.
Erst wenn auch der Letzte seine Karte Schätzung abgegeben hat werden alle Karten gleichzeitig umgedreht.
Auf diese Weise stellt man sicher, dass sich jeder seine eigenen Gedanken machen muss, und sich nicht an einem seiner Kollegen orientieren kann.
Ihnen ist vielleicht schon aufgefallen, daß die auf den Karten aufgedruckten Zahlen nicht ganz linear sind, sondern vor allem bei den höheren Zahlen größere Lücken aufweisen. Dies geschieht ganz bewusst: Auf diese Weise soll verhindert werden, daß größere Arbeitspakete mit einem falschen Sinn für Genauigkeit beschätzt werden. Je höher, je ungenauer. Aus diesem Grund ist es übrigens auch nicht erlaubt, mehr als eine Karte für eine Schätzung auszuwählen. 40+20 = 60 ist somit also nicht erlaubt. Man muss sich schon für einen Wert entscheiden.
Möchte man genauere Schätzungen erhalten, so sollte man die Story noch weiter aufteilen, und dann die einzelnen Teile beschätzen.
Der Kartensatz enthält übrigens 3 Jokerkarten: „0“, „?“ und „[Kaffeetasse]“.
- „0“ bedeutet „dieses Feature ist bereits implementiert oder nur eine Sache von wenigen Minuten.
- „?“ heisst: „Ich habe nicht mal ansatzweise eine Ahnung, worum es hier eigentlich geht“
- Kaffeetasse: „Mir langt’s erstmal. Machen wir eine kurze Pause.“
Nun decken alle „Mitspieler“ ihre Karten auf und vergleichen ihre Schätzungen. Weichen zwei der Werte stark voneinander ab, so wird dieser Umstand nochmal diskutiert und anschließend die Schätzung wiederholt. Dies geschieht so lange, bis alle Beteiligten in etwa denselben Wert schätzen.
Ob man nun den Mittelwert aller Karten nimmt, den höchsten und niedrigsten Wert ausser Acht läßt und den verbleibenden Rest mittelt, den Wert der mittleren Karte nimmt oder eine andere Metrik verwendet um auf den abschließenden Schätzwert zu kommen ist dabei jedem Team selbst überlassen. Im Laufe der Zeit wird man hier sicherlich etwas finden, womit alle Beteiligten einverstanden sind.
Nun sind wir mit der Schätzung dieses Features fertig. Diesen Vorgang müssen wir jetzt auch noch mit allen anderen Einträgen des Product Backlog machen, die für den aktuellen Sprint in Frage kommen.
Zusammen mit der im letzten Artikel vorgestellten Abschätzung des maximal in diesem Sprint zu leistenden Arbeitsumfangs ist es nun auch möglich, die zu realisierenden Features auszuwählen: Man beginnt am oberen Ende der Liste (die ja nach Geschäftswert sortiert ist) und übernimmt die entsprechende Anzahl an Einträgen ins „Sprint Backlog“. So nennt man die für die Realisierung in einem Sprint ausgewählten User Stories.
Einmal erstellt, soll das Sprint Backlog übrigens nur noch in absoluten Ausnahmefällen geändert werden, etwa wenn sich abzeichnet, daß man sich zu viel oder zu wenig vorgenommen hat.
Das Sprint Backlog wird ausschliesslich durch das Team erstellt. Der Product Owner darf keinen direkten Einfluss darauf nehmen.
Er verfügt aber über mehrere indirekte Möglichkeiten der Einflussnahme. Welche dies sind ?
Diese Frage wird im nächsten Artikel beantwortet….
BFI
Wird geladen ...
