Schätzen: Wie man den Aufwand für agile Softwareprojekte ermittelt

Vor Projektbeginn stellt sich die Frage nach den notwendigen Investitionen. Ein Dilemma entsteht, wenn, wie in agilen Projekten üblich, der genaue Leistungsumfang noch nicht vollständig bekannt oder ausreichend definiert ist. Wie soll man sich dann auf eine Investitionshöhe festlegen? In der Projektierung gibt es auch für diese Herausforderung Lösungen. Mit unseren Methoden können wir flexibel darauf reagieren, dass noch nicht alle Details bekannt und spezifiziert sind. Mit erprobten Vorgehensweisen lässt sich zum einen der Aufwand abschätzen, zum anderen können dabei mögliche Unsicherheiten und Risiken frühzeitig erkannt werden. Claas Weiß, Anforderungsmanager bei der HEC GmbH, erläutert, worauf es dabei ankommt.

Claas Weiß: Ein Kunde möchte natürlich wissen, welches Budget erforderlich ist, um beurteilen zu können, ob sich das Vorhaben lohnt beziehungsweise rentiert. Im Rahmen der Projektierung ermitteln wir den notwendigen Investitionsaufwand für das Projekt.

Claas Weiß: Ein wesentliches Merkmal ist, dass wir relativ schätzen. Bei einer klassischen Aufwandschätzung kommt eine Zahl raus: Aufwand in Stunden oder Tagen. Man schätzt in Absolutwerten. Absolutes Schätzen fällt den Menschen allerdings sehr schwer. Wenn man zum Beispiel die Anzahl der Erbsen in einem Glas schätzen soll, liegen die meisten extrem falsch. Erst wenn man einen Vergleich hat, zum Beispiel ein anderes Glas mit einer bekannten Menge Erbsen, wird das Schätzen genauer. Und das machen wir uns beim Schätzen zunutze.

Claas Weiß: Wir schätzen Anforderungen in Form von User Stories oder Epics im Vergleich zu bekannten oder bereits umgesetzten Anforderungen oder Aufgabenstellungen, um eine konsistente Einschätzung der Aufwände zu ermöglichen. Dabei werden die Komplexität, der Aufwand und das Risiko einer Aufgabenstellung berücksichtigt.

Das Team legt für sich eine Metrik fest, anhand derer es die einzelnen Anforderungen aus dem initialen Backlog vergleichen kann. Das sind in der Regel zwei oder drei Referenzstories oder Epics. Das Team ist in der Lage, den Umsetzungsaufwand und die Komplexität sowie das Risiko dieser Stories vergleichend einzuschätzen, etwa aus vorherigen Projekten. Dazu bewertet dann das Team diese User Stories mit Storypoints, einer Maßeinheit zur Bewertung der Komplexität, des Aufwands und des Risikos von Aufgaben.

Claas Weiß: Die Storypoints schätzen wir häufig nach der Fibonacci-Reihe: 1, 2, 3, 5, 8, 13 und so weiter. Diese mathematische Folge zeigt eine charakteristische Wachstumskurve und hilft, zunehmend größere Unsicherheiten und Komplexitäten bei der Schätzung größerer Aufgaben besser abzubilden. Die Maßeinheit Storypoints ist manchen zu abstrakt, man kann zum Beispiel auch mit T-Shirt-Größen arbeiten, mit S, M, L, XL oder XXL.

Jeder bewertet die zu schätzende Story anhand von Vergleichsstories. Wenn die Story für mich eine 2 ist und für den anderen eine 8, dann sagen wir nicht: Okay, lass uns auf den Mittelwert einigen – den Wert 5. Wir haben einen Dissens und das heißt wir müssen miteinander reden. Irgendwo liegen wir beim Verständnis der Aufgabe auseinander. In der Diskussion versuchen wir das gemeinsame Verständnis der Aufgabe zu schärfen und zu einer gemeinsamen Einschätzung zu kommen.

Wir sagen dem Kunden nicht: Das ist dein Budget X. Sondern: Da ist noch eine Varianz drin. Dazu bewerten wir den Reifegrad des Backlogs oder der Userstories.  Reifegradmodelle sind ein methodischer Ansatz, um den Entwicklungsstand (Reifegrad) eines Backlogs zu bewerten. Und aus diesem Reifegrad leiten wir eine Aufwandsspane ab. Desto besser die Reife, desto geringer ist die Aufwandsspanne.

Claas Weiß: Wichtig ist, dass alle Gewerke an der Schätzung beteiligt sind: Entwicklung, Qualitätssicherung, Scrum Master und Product Owner und - wenn möglich - auch Vertreter des Fachbereichs des Kunden.

Gerade bei den größeren Projektierungen wünschen wir uns, dass sich auch spätere Nutzer am Schätzen beteiligen. Als Entwicklungsteam haben wir möglicherweise nicht alle Details vollständig verstanden oder es fehlen noch Informationen. Im Workshop können wir mit dem Kunden eine direkte Klärung herbeiführen und müssen dies nicht im Nachhinein tun. Das spart Zeit.

Claas Weiß: Es ist wichtig, die Leistungsfähigkeit des Teams zu kennen, insbesondere die Geschwindigkeit, mit der es arbeitet. Diese Werte basieren auf unseren bisherigen Erfahrungen. Das Team schafft beispielsweise X Storypoints in einem Sprint von zwei Wochen. Damit lässt sich ermitteln, wie viele Sprints wir ca. benötigen. Unter der Berücksichtigung des Reifegrades ist das immer eine Spanne, z.B. 7-9 Sprints. Da wir die Teamstärke kennen, wissen wir auch, was ein Sprint kostet. Damit kann die Investitionshöhe sehr transparent bestimmt werden.

Claas Weiß: Natürlich erleben wir, dass Kunden solche Prozesse noch nie zuvor durchlaufen haben und anfangs etwas unsicher sind. Doch erfahrungsgemäß verschwindet diese Unsicherheit schnell. Die Kunden verstehen rasch, wie die Methodik funktioniert, und beteiligen sich dann mit Begeisterung. So können sie das Ergebnis aktiv mitgestalten.

Man könnte annehmen, dass Kunden den niedrigsten Wert schätzen, um Kosten zu drücken. Das ist nicht so. Vielmehr wird ein gemeinsames Verständnis aufgebaut, wie sich die Aufwände zusammensetzen. Weil der Kunde direkt in diesen Prozess involviert ist, erspart das viel Diskussion im Nachgang.

Claas Weiß: Man kann Planning-Poker spielen. Das ist eine Methode, bei der das Schätzteam den Aufwand der einzelnen Aufgaben mithilfe von Karten mit Zahlen aus der Fibonacci-Reihe einschätzt. Und Planning Poker geht übrigens auch virtuell: Wir haben dafür mit unserem HEC Scrum-Buddy ein digitales Tool entwickelt. Weitere Methoden sind das Team Estimation Game oder die Magic Estimation.

Claas Weiß: Schwierig zu schätzen sind meist Integrationsthemen und sehr komplexe Anforderungen sowie wenn es darum geht eine Schätzung auf Basis unbekannter, neuer Technologien vorzunehmen.

Integrationsthemen bzw. Schnittstellen sind oft schwer einzuschätzen, da sie vielfach unerwartete technische Herausforderungen und Anpassungen an bestehende Systeme mit sich bringen. Komplexe Anforderungen sind schwer einzuschätzen, da sie viele unbekannte Details und Wechselwirkungen enthalten können, die erst im Laufe der Entwicklung deutlich werden. Bei neuen und unbekannten Technologien fehlen zudem meist unmittelbar Erfahrungswerte, was zu zusätzlichen Lernphasen und unvorhersehbaren Herausforderungen führen kann.

Claas Weiß: In jedem Projekt gibt es natürlich Veränderungen und damit ggf. auch Abweichungen. Die Frage ist, in welcher Projektphase man das merkt. Im agilen Vorgehen haben wir genügend Mechanismen, um rechtzeitig die Stellen zu identifizieren, an denen es Abweichungen gab. Im Projektfortschritt kann es dazu kommen, dass man neue Erkenntnisse sammelt oder zusätzliche Informationen vom Kunden bekommt, die dazu führen, dass man eine Schätzung korrigieren muss. Es ist halt nur eine Schätzung.

Claas Weiß: Ja, genauso so. Bei einigen Projekten haben wir zu Beginn oft noch nicht alle Detailinformationen. Das heißt: Wir ermitteln einen initialen Aufwand auf Basis eines niedrigeren Reifegrades. Dadurch ergibt eine größere Aufwandsspanne. Mit der Erfahrung aus den im Projekt bereits umgesetzten Stories können wir den Restaufwand immer besser abschätzen. Nach jedem Sprint wissen ein Stück besser, wo wir gerade im Projekt stehen, und welcher geschätzte Restaufwand noch erbracht werden muss.