Schätzungen in (großen) agilen Projekten

Wie lange dauert es? Hätte Charles Babbage seine Analytical Engine bauen können, dann wäre Ada Lovelace wohl die erste Entwicklerin gewesen, die mit dieser nervigen Frage konfrontiert worden wäre. Auf den ersten Blick eigentlich eine berechtigte Frage, besonders wenn es um sehr kleine und überschaubare Tätigkeiten geht und sich die Antwort im Stundenbereich befindet. Nur leider wird Entwicklerinnen und Entwicklern diese Frage auch regelmäßig für viel größere Sachen gestellt. Wie soll man diese Frage beantworten, wenn zu diesem Zeitpunkt noch nicht einmal alle Anforderungen klar sind, geschweige denn verstanden wurden? Deren Ausarbeitung ist doch überhaupt der größte Teil der Arbeit, also versucht man zu schätzen. Umso unklarer und komplexer die Aufgabe ist, desto mehr ähnelt diese Schätzung dem Blick in die Glaskugel. Wir hoffen, dass unsere Schätzung nicht als Versprechen gesehen wird und wir hoffen immer wieder.

In der agilen Welt hat man dies zum Glück erkannt. Man schätzt nun den Aufwand nicht mehr in absoluter Zeit, sondern im Verhältnis zu einer Standardaufgabe und unter Berücksichtigung der Komplexität, und nennt dies „Story Points“. Von Sprint zu Sprint werden die Story Points (SP) der fertiggestellten Backlog-Items gezählt, woraus dann die „Velocity“ des Teams ermittelt wird. Und auf dieser Velocity basieren dann die Prognosen über den Fortschritt und die Kosten des Projektes.

Hierbei ist es unerlässlich, dass zwischen dem Team und allen Stakeholdern die SPs lediglich als Planungsgröße für genau das jeweilige Team verstanden werden und für nichts anderes!

Wie in der Tabelle zu erkennen ist, sind zwölf Sprints vorgesehen – aktuell ist Sprint fünf in Arbeit. Aufgrund der vergangenen Sprints wird eine Team-Velocity von „27“ angenommen. Die Velocity ist der Mittelwert der bisher „gelieferten“ SP pro Sprint. Ausgehend von diesem Wert lässt sich nun relativ einfach eine Prognose für die kommenden Sprints erstellen. Einfach durch die simple Annahme, dass weiterhin pro Sprint 27 SP geliefert werden könnten. Da Prognosen über die Zukunft eine gewisse Unsicherheit beinhalten, ist ein weiterer wichtiger Wert die Standardabweichung. Durch Subtraktion und Addition der Standardabweichung entstehen eine pessimistische und eine optimistische Prognose. Das bedeutet: Pessimistisch gesehen können 22 SP und im optimistischsten Fall 32 SP pro Sprint geliefert werden. Zum Start des fünften Sprints kann daher von einer wahrscheinlichen Umsetzung von insgesamt 261 bis 357 SP bis Sprint zwölf ausgegangen werden. Selbstverständlich ist auch eine Prognose keine exakte Vorhersage der Zukunft und genau wie eine Schätzung von einer stabilen Grundlage abhängig. Der wesentliche Unterschied liegt in der Transparenz.

Herausforderungen und Stoplersteine

So einfach die Berechnung der Prognose auch ist, so ergeben sich doch einige Herausforderungen:

• Wie kommt man zu einer Prognose vor Sprint 1?
• Wie kann man Aussagen zu Feature X machen, wenn für dieses Feature noch keine vom Team geschätzten Product-Backlog-Items vorliegen?
• Auf welcher Basis kommen die SP zustande und was ist, wenn die Referenzgrundlage, nach der geschätzt wird, vom Team geändert wird?
• Wie funktioniert das in einem skalierten Umfeld (zum Beispiel mit Nexus), wenn jedes Team eine eigene Referenzgrundlage für die Schätzung verwendet?

Der erste Punkt ist in der Regel auch der erste Stolperstein, an dem viele agile Projekte ins Straucheln kommen. Der Gedanke, zuerst auf die Kosten, die man hat, beziehungsweise auf potentielle Gewinne zu schauen, die nicht realisiert werden können, wenn man nicht startet, ist ein Wesenskern agiler Unternehmen. Warum zwei, drei oder mehr Wochen für eine Analyse investieren, um eine traditionelle Schätzung vornehmen zu können, die am Ende auch nicht genauer ist als eine erste Prognose nach dem dritten Sprint? Dann doch lieber direkt sofort anfangen. Bei einer ungünstigen ersten Prognose (nach den ersten Sprints) kann genauso gut wie nach einer klassischen Analysephase abgebrochen werden. Mit dem Unterschied, dass im besten Fall etwas umgesetzt wurde, das bereits produktiv eingesetzt werden kann. Die Investition muss so nicht komplett abgeschrieben werden. In jeden Fall wurde neues Wissen generiert.

Wenn es sich nicht vermeiden lässt, eine initiale Schätzung zu erstellen, sind die klassischen Ansätze, auf die hier nicht weiter eingegangen wird, in der Regel gut genug. Hierbei ist darauf zu achten, sich darauf zu beschränken, was in den ersten Wochen umgesetzt werden sollte (Umfang, Komplexität und Reduktion). Diese klassische Schätzung sollte dann so schnell wie möglich von tatsächlich gemessenen Fakten abgelöst werden!

Zum Glück sind die anderen Punkte wesentlich einfacher zu lösen. Verwendet einfach keine vom Team geschätzten Story Points. Ja richtig, wie soll das Team auch etwas schätzen, was nur grob bekannt ist? Daher benötigt man eine andere Größe, die leicht zählbar, transparent und leicht nachvollziehbar ist.

Dabei ist das Ganze eigentlich einfach: Man schätzt in „Funktionalität“. So schlägt es Steve McDonnel in seinem Buch „Software Estimation: Demystifying the Black Art“ vor. Nehmen wir zum Beispiel einen Wasserkocher. An, aus, Deckel auf und Deckel zu. Schon haben wir ein Funktions-Basis-Set, bestehend aus vier Function Points (FP). Dafür braucht es kein Ingenieursstudium und jeder relevante Stakeholder kann in diese Art der Schätzung einbezogen werden. Ein weiteres Plus ist es, eine getrennte Schätzung vom Umsetzungsteam und vom Fachbereich vornehmen zu lassen. So kann leicht erkannt werden, wo noch Redebedarf ist, wenn die Abweichung der Schätzung signifikant ist.

Wenn sich nach einigen Sprints die Velocity des Teams – natürlich in FP – einpendelt, wird es für den Project Owner wesentlich leichter, Prognosen über ein neues Feature, bestehend aus x FP, zu treffen. Da eine Funktion etwas Atomares und Allgemeingültiges ist, ist sie auch vollkommen unabhängig von den beteiligten Personen oder der Projektlänge. Eine eventuell notwendige Skalierung kann hier ebenfalls problemlos prognostiziert werden.

Auch wenn es verführerisch ist: Genau wie bei Story Points sollte die Anzahl der durchschnittlich gelieferten FP pro Sprint unter keinen Umständen dafür genutzt werden, um Teams zu vergleichen!

Fazit

Für die Planung in großen Projekten ist es wichtig, dass die dafür notwendigen Prognosen auf nachvollziehbaren Fakten basieren und kontinuierlich angepasst werden. Function Points sind hier ein ideales Mittel, da sie leicht erhoben werden können und von allen Projektbeteiligten verstanden werden. Die Glaskugel kann nun in der Vitrine bleiben.