Sinn und Unsinn von Schätzungen – Teil 3

Nachdem wir uns in den letzten beiden Teilen eher mit theoretischen Möglichkeiten der Verbesserung von Schätzprozessen befasst haben, soll es in diesem Teil um ganz konkrete Anwendungsmöglichkeiten gehen. 

Unser Szenario sieht wie folgt aus: Wir haben drei identisch große Teams (6 erfahrene Entwickler und ein Scrum Master), die seit einigen Wochen Scrum einsetzen. Die Grundlagen und Regeln sind soweit geklärt und werden von Teams auch eingehalten. Geschätzt wird jeweils auf Basis von Story Points unter Verwendung von Planning Poker.

Während der letzten Retrospektive kam es allerdings in allen Teams zu einer intensiven Diskussion darüber, dass das Schätzen doch sehr aufwendig ist und entsprechend viel Zeit kostet. Es wurde die Frage aufgebracht, ob der zeitliche Aufwand, den das Team momentan dafür treibt, den daraus resultierenden Nutzen rechtfertigt. Man war sich einig, dass sowohl für die Arbeit des Product Owners als auch für die eigene Einschätzung für das Committment und den Fortschritt innerhalb eines Sprints die Schätzwerte wichtig sind. So viel Zeit wie bisher möchte man aber nicht mehr in das Schätzen stecken.

Obwohl die Voraussetzungen für alle Teams gleich sind, haben sie drei komplett unterschiedliche Anpassungen beschlossen. Team A ist eher konservativ und bevorzugt kleinere Veränderungen. Team B hingegen ist mutig bis ungeduldig und wählt lieber die große Lösung. Team C stellt gerne auch Grundsätzliches in Frage und ist revolutionären Vorschlägen gegenüber immer offen. Entsprechend gestalten sich auch die Veränderungen, die die Teams beschlossen haben.

Team A hat sich für eine sanfte Anpassung des bisherigen Prozesses entschieden. Struktur und Zeremonien bleiben bestehen. Anstelle des bisher verwendeten Planning Pokers möchte man zukünftig aber auf eine effizientere Methode wechseln und wird für das kommende Planning Meeting das Team Estimation Game ausprobieren. Die Steigerung der Effizienz kommt hier vorwiegend zustande, indem die Diskussionen über die User Stories auf diejenigen Stories reduziert werden, deren Größe innerhalb des Teams wirklich strittig sind. Die gleichzeitige Einführung von Color Coding, bei dem über farbliche Markierungen Zusammenhänge zwischen User Stories visualisiert werden, wird zunächst abgelehnt, aber nicht komplett verworfen. Zu einem späteren Zeitpunkt und mit etwas Erfahrung in der Anwendung des Team Estimation Games möchte man diesen Punkt noch einmal aufgreifen.

Für den Product Owner des Teams hat die Veränderung kaum Auswirkungen. Er bereitet sich wie bisher auf die Vorstellung der User Stories vor dem Team vor und erhält neue Schätzwerte als Ergebnis für seine weitere Planung.

Team B setzt hingegen auf einen größeren Umbruch. Das bisherigen Sprint Planning wird umgestellt. Der Vorstellung der User Stories durch den Product Owner wird mehr Zeit eingeräumt und dafür das Abschätzen derselben komplett gestrichen. Das entsprechende Meeting wird in „Story Telling“ umbenannt. Statt per Planning Poker Story Points zu ermitteln, zählt das Team zukünftig nur noch, wie viele User Stories im vergangenen Sprint geschafft wurden. Entsprechend viele Stories werden für den kommenden Sprint in Betracht gezogen. Per Bauchgefühl wird dann im Team ermittelt, ob etwas mehr oder weniger Stories Bestandteil des Committments werden. Für die Zukunft möchte man noch beobachten, ob und wie man die Werte der letzten Sprints mitteln kann, um eine bessere Vorhersage für den nächsten Sprint zu treffen.

Auf den Product Owner kommen dadurch natürlich einige Änderungen zu. Zunächst einmal erhält er keine Größenschätzungen für die User Stories mehr. Dazu wurde er vom Team auch noch aufgefordert, stärker als bisher darauf zu achten, die User Stories in möglichst gleichmäßig große Häppchen zu schneiden.

Noch einen Schritt weiter geht Team C. Sie wollen zukünftig weder schätzen noch zählen. Stattdessen soll die Zeit gemessen werden, die die User Stories vom Start ihrer Bearbeitung bis zum Abschluss benötigen. Daraus soll dann ermittelt werden, wie lange die Bearbeitung einer User Story durchschnittlich benötigt. Da man auch bisher bereit ein elektronisches Trackingtool verwendet hat, liegen sogar schon Daten aus den letzten Sprints dazu vor. Aus diesen werden die ersten Durchschnittswerte ermittelt und für die nächste Planung verwendet. Sobald das Team erste Erfahrungen mit dieser Methode gemacht hat, soll noch überlegt werden, ob man die Genauigkeit der Werte mit einer Kategorisierung der User Stories verbessern kann. Ähnlich Team B soll die Zeit für das bisherige Sprint Planning dazu genutzt werden, dass der Product Owner die User Stories intensiv vorstellt und diese bei Bedarf auch diskutiert werden.

Auch hier hat der Product Owner einige Veränderungen an seiner Arbeit vor sich. Größenschätzungen gibt es nicht mehr. Dafür erhält er durchschnittliche Bearbeitungszeiten als Grundlage für seine Planung. Seine User Stories kann er allerdings in gewohnter Form erstellen. Allerdings überlegt er von sich aus, ob kleinere User Stories nicht genauere Messwerte ergeben würden.

Die Lösungen der drei Teams sollen natürlich nur verdeutlichen, dass es sich lohnt, über den eigenen Schätzprozess einmal intensiv nachzudenken und andere Möglichkeiten in Betracht zu ziehen. Auch wenn es die drei beschriebenen Teams (zumindest bei mir) so nicht gegeben hat, wurden alle beschriebenen Massnahmen erfolgreich eingesetzt. Welche der beschriebenen Wege man ausprobieren kann und möchte, hängt aber immer vom gesamten Umfeld ab. Ein wichtiges Puzzleteil ist dabei immer der Product Owner, dessen Arbeit von der gewählten Lösung mehr oder minder stark beeinflusst wird. Zumindest er sollte in jegliche Überlegungen zur Schätzmethodik mit einbezogen werden.

Auch wenn hier die Einführung von Scrum quasi als Voraussetzung für die beschriebenen Szenarien verwendet wird, lassen sich viele in dieser Artikelserie beschriebene Mechanismen auch in traditionell geführten Projekten einsetzen. Dabei gilt es aber noch viel stärker, sich der Auswirkungen auf das Umfeld bewusst zu werden, z.B. bezüglich Reporting.

 

 

Dieser Beitrag wurde unter Agile Blog abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.