Viele Entwicklungsteams haben große Probleme beim Schätzen von Aufwänden. Noch größer werden diese Probleme, wenn Storypoints genutzt werden. Ich empfehle Ihnen, wirklich nur dann Punkte zu nutzen, wenn Sie auch die Entwicklungsgeschwindigkeit (Velocity) des Teams auswerten wollen (und selbst dann bin ich nicht wirklich von Punkten überzeugt – weiter unten erkläre ich Ihnen, woran das liegt). Wenn Ihnen das egal ist, können Sie auch auf das Schätzen mit Punkten verzichten, im Kopf schätzt jeder sowieso Zeiten.
Die große Schwierigkeit beim Schätzen mit Punkten liegt darin, dass eine zusätzliche Abstraktion eingeführt wird. Ein Entwickler ist durchaus in der Lage, Ihnen eine Auskunft darüber zu geben, wie lange er voraussichtlich mit einer Anforderung beschäftigt ist, wenn er sich kurz damit auseinandergesetzt hat und weiß, welche bösen Überraschungen ihn im Code erwarten. Dieser Entwickler wird Ihnen ohne große Probleme eine Zeit nennen können – zwei Stunden für eine kleine Kleinigkeit, zwei Tage, zwei Wochen.
Wenn wir denselben Entwickler bei der selben Aufgabe jedoch nach Punkten fragen, wird er zunächst wieder eine Zeit schätzen und diese dann in einen Punktwert übersetzen. Wirklich hilfreich ist das nicht. Dazu zunächst ein kurzer Überblick über das Schätzen mit Punkten, wie wir uns das wünschen.
Ziel ist es, die Aufwände einzelner Anforderungen miteinander vergleichen zu können, um irgendwann eine Aussage darüber zu treffen, ob sich unser Entwicklungsteam verbessert hat und wie viel es in einem Sprint zu leisten vermag (Velocity). Selbstverständlich benötigen wir auch irgendeine Information über die Möglichkeiten des Teams, wenn wir einen Releaseplan erstellen wollen. Das grundsätzliche Problem, das uns dabei begegnet, ist die Schwierigkeit, Softwareentwicklung in irgendeiner Form zu bewerten. Alternativ zur Punktevergabe können Sie auch Codezeilen zählen, was selbstverständlich nicht wirklich sinnvoll ist (auch wenn ich das durchaus schon in einigen Unternehmen gesehen habe).
Gerne orientiert man sich bei der Punktevergabe an der Fibonacci-Reihe (wenn Sie irgendeinen Verschwörungstheorienroman gelesen haben, kennen Sie die: 1, 2, 3, 5, 8, 13 usw.). Man nimmt sich eine sehr kleine Aufgabe, die man sehr gut kennt, und nutzt diese als Urmeter für alle zu bewertenden Aufgaben. Diese kleine Aufgabe, mit der alle Entwickler vertraut sind, repräsentiert einen Punkt. Das ist schon eine extrem schwammige Grundlage, die sich im Laufe der Zeit auch noch verändert. Mit wachsender Routine in Ihrem Team (oder bei geänderten Abläufen – eine zusätzliche Testinstanz, andere Regeln zum automatisierten Testen oder was auch immer) wird sich auch die Wahrnehmung dieser Urmeter-Aufgabe verändern. Machen Sie sich das bitte immer bewusst, wenn Sie versuchen, die Velocity in Ihrem Team auszuwerten.
Die Punktevergabe wird nun jedoch noch viel ungenauer. Ausgehend von unserer ersten und bekannten Aufgabe, die wir mit einem Punkt bewerten, bauen wir nun diese Reihe auf. Der doppelte Aufwand eben dieser Anforderung wird mit zwei Punkten gleich gesetzt. So erstellt man sich eine Reihe von Aufwänden, die mit den Punkten korrespondieren. Wenn Sie sich das noch einmal aus der Entfernung ansehen: wes denken Sie, wie belastbar die Zahlen sind, die Sie mit der Auswertung aus einer solchen Aufwandsreihe und Schätzung bekommen?
Und ganz genau deswegen bin ich kein riesiger Freund des Schätzens mit Punkten. Sie bekommen einfach keine verlässlichen Daten, schlimmer noch: Sie bekommen eine Scheingenauigkeit, die Ihnen vorgaukelt, dass Sie die Dinge sehr genau auswerten könnten. Stattdessen ist aber bereits die Grundlage Ihrer Auswertung so unpräzise, dass alles was darauf aufbaut (inklusive aller Auswertungen) kaum noch eine echte Aussagekraft hat. Ungenauigkeiten gleichen sich nur selten aus, in der Regel verstärken sie sich nur.
Daraus ergibt sich natürlich die Frage, wie man denn sonst die Velocity eines Teams auswerten kann, worauf ich Ihnen antworten muss: im Nachhinein. Lassen Sie Ihr Team ruhig Zeiten schätzen. Dabei fühlt es sich eh sehr viel wohler. Zunächst ist für uns wichtig, dass wir die einzelnen Sprints gut im Griff haben. Wenn wir dort mit der gewohnten Größe Zeit umgehen können, dann hilft uns das sehr. Nach einem festgelegten Zeitraum von drei, sechs, oder zwölf Monaten (oder zum Ende des Projekts) nehmen sich Product Owner, Scrum Master und Team ein wenig Zeit, um alle erledigten Anforderungen in Punkten zu bewerten.
Der Vorteil bei diesem Vorgehen ist der, dass alle Anforderungen zur gleichen Zeit bewertet werden. Damit kann man sicherstellen, dass für alle Anforderungen die gleichen Massstäbe angesetzt werden, die sich bei der Bewertung zu jedem Sprint viel zu leicht verschieben können, wie wir inzwischen wissen.
Bei umfangreichen Projekten wird man mehrmals eine solche Auswertungssitzung ansetzen. Achten Sie hierbei jedoch unbedingt darauf, dass Sie nicht bei der ersten die ersten drei Monate betrachten, bei der zweiten die nächsten drei Monate usw. Bei jeder Sitzung muss alles von Anfang an berücksichtigt werden, damit wir den Effekt der Wahrnehmungsverschiebung aufheben können. Das ist natürlich ein recht großer Aufwand, für den Sie bei umfangreicheren Projekten, die weit fortgeschritten sind, durchaus einen vollen Tag veranschlagen können.
Achten Sie bei dieser Auswertung darauf, dass Sie die Zeiten, die Ihr Team für die Anforderungen gebraucht hat, nicht sichtbar machen, da sich ansonsten die Punktvergabe wieder an den Zeiten orientiert. Gerade das wollen wir jedoch vermeiden.
Solche Auswertungen brauchen Sie nur dann, wenn Geschäftsleitung oder Controlling einen Überblick über die Leistungsfähigkeit der Entwicklung wünschen. Ein erfahrener Product Owner benötigt eine solche Auswertung nicht. Der sieht die Veränderungen in seinem Team und merkt, wenn es nicht mehr rund läuft, oder wenn sich die Dinge im Laufe der Wochen verbessern. Gerade weil aufgrund der Velocity manchmal weitreichende Entscheidungen getroffen werden (z.B. das Personal betreffend), sollten wir uns bemühen, wirklich aussagefähige Zahlen zu liefern und auf die Scheingenauigkeit des Schätzens mit Punkten zu verzichten.
Wie gehen wir jedoch mit dieser Sache um, wenn wir einen Releaseplan erstellen wollen und daher eine Information über die Leistungsfähigkeit des Teams benötigen? Dazu kann ich Ihnen sagen, dass das nur dann überhaupt möglich ist, wenn wir über ein gut aufeinander eingespieltes Team sprechen. Wird die Entwicklergruppe neu zusammengesetzt, ändert sich die Velocity in den ersten Wochen und Monaten viel zu stark, als dass wir überhaupt eine vernünftige Aussage treffen könnten.
Selbst wenn wir über ein Team verfügen, dass seit längerer Zeit zusammen arbeitet, und das wir sehr gut kennen, verändern sich die einzelnen Personen doch ständig und entwickeln sich weiter. Ein Entwickler, der seinen Job ernst nimmt, ist mit seinem früheren Ich von vor einem Jahr nicht mehr zu vergleichen. Die Entwicklungsgeschwindigkeit eines Teams ist einem stetigen Wandel unterworfen. Das ist einer der Gründe, warum eine Releaseplanung auch in Scrum selten stimmt.
Daher gebe ich Ihnen folgenden Rat mit auf den Weg: Machen Sie Ihre Releaseplanung gröber, und vermeiden Sie die Scheingenauigkeit einer Punktevergabe einzelner Anforderungen. Nutzen Sie lieber grobe Punkte für ganze Epics, und beziehen Sie Ihr Team in diese Sache mit ein.
