Agile Aufwandsschätzung reloaded

Aufwandsschätzungen für Entwickler: Mit Story Points die Komplexität erfassen

Michael Thomas

© Shutterstock.com/alphaspirit

Sie sind ein steter Quell für Konflikte, nicht nur zwischen Entwicklern und Kunden: Die berühmt-berüchtigten Aufwandsschätzungen. Die Ursachen für inkorrekte Schätzungen sind dabei ähnlich zahlreich wie die Versuche, ihnen mit besseren Methoden zu Leibe zu rücken.
Im Hinblick auf die agile Aufwandsschätzung verspricht aktuell ein Modell des Softwareentwicklers Bikram Sinha Besserung: Durch Einbeziehung von Story-Größe sowie der sich aus Complexity Map und Testkomplexität ergebenden Gesamtkomplexität soll ein genaueres Bild gezeichnet werden.

Die Senior Softwarearchitektin Dr. Carola Lilienthal verriet im Interview mit JAXenter, dass sie bei den Schätzungen von Entwicklern generell einen Aufschlag von 100 % miteinrechnet, um zu einer genauren Prognose zu gelangen. Der Agile-Ethusiast John Sonmez geht gar so weit, sämtlichen Schätzungen, die weiter als 2 Stunden in die Zukunft reichen, für komplett wertlos zu erklären. Diese beiden Stimmen können stellvertretend für eine häufig anzutreffende Ansicht herangezogen werden: Aufwandsschätzungen sind die Achillesverse zahlreicher Entwickler und Projekte.

Dabei können zahlreiche Faktoren und Unwägbarkeiten die Ursache für inkorrekte Schätzunegn sein. So existieren neben formalen Gegebenheiten (so z. B. die von Sonmez angesprochenen „unbekannten Unbekannten“) auch solche, die in der Person des jeweiligen Entwicklers liegen, z. B. Verhaltensmuster wie Selbstüberzeugung (Menschen tendieren dazu, das eigene Wissen zu überschätzen), die Illusion der Kontrolle (Menschen handeln oft so, als hätten sie über etwas Kontrolle), Wunschdenken (Wahrscheinlichkeit eines Ereignisses wird überschätzt, weil man es sich besonders stark wünscht) und Fehlplanung (Besonders bei schwierigen Aufgaben tendieren Menschen dazu, die benötigte Zeit zu unterschätzen).

Zwar können Aufwandschätzungen regelmäßig geübt, im agilen Kontext zur Routine gemacht und dadurch schlussendlich genauer werden. Doch selbst wenn einem keine unternehmenspolitischen Entscheidungen in die Parade fahren, macht Übung alleine nicht den Meister. Auch passende Methoden tun Not.

Lesen Sie auch: Kanban: Pünktlich und zuverlässig liefern

So schlug etwa der Softwareentwickler Nadav Azaria im vergangenen Jahr eine neue Form der agilen Aufwandsschätzung vor, die das sog. Planning Poker (auch als Scrum Poker bekant) einbezieht, anders als dieses jedoch eine Trennung von Lern- und Arbeitszeit vornimmt: Aufwandsschätzungen sollen sich aus der Zeit, in der Neues gelernt werden soll und der Zeit, in der tatsächlich die Arbeit und die Umsetzung dessen stattfindet, zusammensetzen. Dabei wird den Team-Mitgliedern eine individuelle Lernzeit eingeräumt und nur die Arbeitszeit im Planning Poker festgelegt. Auf diesem Weg sollen nicht nur genauere Aufwandsschätzungen möglich, sondern anhand von „Learning Charts“ gleichzeitig der Zeitaufwand für das Erlernen neuer Technologien messbar werden.

Komplexität erfassen

Doch agile (bzw. Scrum-)Aufwandsschätzungen können, worauf der Softwareentwickler Bikram Sinha aktuell hinweist, potentiell noch mehr leisten: Die Softwareprojekten inhärente Komplexität erfassen. Wie Sinha berichtet, bestand in seinem ersten agilen Projekt ein Hauptproblem darin, dass alle beteiligten Entwickler nur die aus traditionellen Wasserfallprojekten oder aus der iterativen Entwicklung bekannten Schätzmethoden kannten und ihnen die Festlegung der Story Points deshalb besonders schwer fiel. Vor allem der Grad der Komplexität bereitete ihnen Kopfzerbrechen.

Im Rückgriff auf selbst gesammelte Erfahrungen sowie Anregungen anderer Entwickler schlägt Sinha folgende Formel vor, um die Komplexität zu definieren: Complexity = Complexity Map × Testing Complexity. Der Story Point wird in seinem Modell anhand der Formel Story Pointing = Story Sizing × Complexity ermittelt, wobei der Wert „Story Sizing“ aus vordefinierten Kriterien abgeleitet wird.

In einem weiteren Schritt werden die Story-Größen- und Komplexitätswerte weiter aufgeschlüsselt: Die Größe einer Story (klein, mittel, groß) ist dabei u. a. von Faktoren wie dem Zeitaufwand (Tage, Wochen) und der Klarheit der Anforderungen abhängig. Die Komplexität spaltet sich wiederum in zwei Bereiche auf: Die Complexity Map mit Faktoren wie der Anzahl der Abhängigkeiten, der Anzahl der Unbekannten, der Höhe des Risikos, der notwendige Refaktorisierungen etc. einerseits, die Testkomplexität (niedrig, mittel, hoch) andererseits. Durch Multiplizierung aller Werte erhält man den finalen Wert der Story Points.

Wie Sinha einräumt, wirft diese Technik jedoch ein nicht unbedeutendes Problem auf: Bei größeren Stories erhält man nach Einbeziehung der Komplexität eine mitunter zu große Anzahl an Story Points. In diesen Fällen empfiehlt er, die Story in mehrere kleinere Stories aufzuspalten.

Aufmacherbild: Business team drawing a new complex project von shutterstock.com / Urheberrecht: alphaspirit

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: