Aufwandsschätzungen in Softwareentwicklungsprojekten – hätten Sie’s lieber klassisch oder agil?

In meinem letzten Blog „Gut geschätzt ist halb gewonnen“ habe ich verschiedene Verfahren zur Aufwandsschätzung vorgestellt, die – so wie ich selbst – allesamt ihre Wurzeln im klassischen Projektmanagement haben. Bewusst hatte ich dabei die agile Methodik ausgeklammert.

Heute möchte ich eine kleine Brücke zwischen den damals vorgestellten „klassischen“ Verfahren und dem Schätzverfahren nach Scrum schlagen. Zu häufig höre ich Postulate wie „Scrum ist etwas völlig Neues“, „Nur der agile Ansatz ist richtig“ oder „Das klassische Projektmanagement ist altmodisch, out, zum Scheitern und zum Aussterben verdammt“.

Ich werde zunächst sehr kurz das Vorgehen bei der Schätzung nach Scrum in seiner einfachsten Form vorstellen und dann mit den klassischen Schätzmethoden vergleichen, die ich in meinem vorhergehenden Blog beschrieben habe. Abschließend erlaube ich mir eine persönliche Wertung, die zusammengefasst lauten wird: die Schätzung à la Scrum ist zwar nichts revolutionär Neues, aber etwas Besseres!

1.    Aufwandsschätzung à la Scrum

Im Scrum werden die einzelnen fachlichen Anforderungen in Form von „User Stories“ beschrieben. Die Gesamtheit der User Stories bildet das „Product Backlog“.

Die Schätzung wird häufig als Schätzpoker durchgeführt, das einigen Regeln unterliegt:

  1. Das gesamte Team ist an der Schätzung beteiligt.
  2. Jedes Teammitglied erhält einen Satz von Pokerkarten – in der Regel beginnend mit den Zahlen der Fibonacci-Folge: 1, 2, 3, 5, 8, 13, …
  3. Das Vorgehen beim Schätzpoker ist:
    • Der Product Owner stellt die Story vor und beantwortet Fragen dazu.
    • Jedes Teammitglied schätzt zunächst verdeckt den Aufwand für die Story (legt die entsprechende Karte vor sich auf den Tisch),
    • dann werden alle Schätzkarten aufgedeckt und
    • wenn die Schätzungen der Teammitglieder voneinander abweichen, wird die Ursache für die Abweichung gesucht: wurde die Story von allen gleich verstanden, gibt es bei der Umsetzung besondere Unwägbarkeiten, hat jemand die Lösung schon „in der Schublade“ liegen, …?
  4. Geschätzt wird der relative Aufwand einer Story zu einem Vergleichswert oder einer „Normstory“; dafür werden „Story Points“ vergeben.

Mit dieser Methode lassen sich relativ schnell viele Storys schätzen, eventuell bereits zu Projektbeginn das gesamte Backlog (aus Gründen, die ich noch nennen werde, haben wir in meinen Projekten gleich zu Beginn das gesamte Backlog durchgeschätzt).

Zum Zeitpunkt der Schätzung ist allerdings noch unklar, welcher absolute Aufwand (in Personentagen) hinter einer Story bzw. hinter dem gesamten Backlog steckt. Dies wird in der Regel erst nach dem ersten Sprint errechnet, wenn klar ist, wie viele Storys das Team in einem Sprint umsetzen kann. Diesen Durchsatz bezeichnet Scrum als „Velocity“.

2.    Vergleich Scrum versus klassische Methode

Die Leser meines letzten Blogs werden den Vergleich schon vor ihrem geistigen Auge durchgeführt haben – die Begriffe in der Spalte „Klassische Methodik“ der folgenden Tabelle stammen aus dem o.g. Blog.

Scrum und klassische Methoden meinen häufig das Gleiche und nennen/machen es unterschiedlich:

 

3.    Meine persönliche Meinung…

Wie man sieht, wurde für Scrum keine wirklich „neue Schätzmethodik“ entwickelt, sondern es werden bestehende Verfahren günstig miteinander kombiniert.

Sehr typisch für Scrum finde ich, dass das Ganze in eine „leichte“ Form gebracht wird, sprich: das Vorgehen ist dem Team sehr schnell vermittelbar, und die Anwendung der Methode (in dem Fall insbesondere der Einsatz der Pokerkarten) hat Vorteile gegenüber dem gemeinsamen Blick auf ein Excel Sheet an Beamer, Flipchart oder Whiteboard:

  • Jedes Teammitglied ist eingebunden: jeder muss eine Schätzung abgeben, und bei Abweichungen muss der Abweichler seine Schätzung begründen. So kommt im Workshop automatisch jeder zu Wort, auch die ruhigeren Teammitglieder.
  • Es macht mehr Spaß.
  • Der allgemeine Konzentrationslevel war nach meinem Empfinden höher als bei den klassischen Workshop-Formaten
  • und auch der Durchsatz (geschätzte Items pro Stunde) erschien mir subjektiv höher, wobei ich hier keine wissenschaftlich fundierte Messung vorgenommen habe.

Im Scrum wurden die Methoden verwendet, die sich aus meiner Sicht in der Praxis sehr gut bewährt haben – z. B. das ganze Team zu beteiligen, statt einen Einzelnen für die Schätzung verantwortlich zu machen, die Risiken (sichtbar an den abweichenden Schätzungen einzelner Teammitglieder) besonders zu berücksichtigen und vergleichend (Story Points) statt absolut (Personentage) zu schätzen.

4.    …und meine Erfahrung

Bei meinen Projekten war der Endtermin die konstanteste aller Konstanten.

Auch haben wir eher „Scrum in der Blase“ angewendet (vgl. Lipowksy, „Steuerung im agilen Multiprojektumfeld“) – d.h. schon zu Beginn des Projektes mussten wir dem Produktmanagement zusagen, dass zum Termin auch der gesamte angeforderte Umfang umgesetzt sein wird.

Deswegen war mir als Projektmanager (sorry, Scrum Master) die Berechnung der Velocity extrem wichtig. Daher hatte ich mein – in der reinen Lehre eigentlich überflüssiges – „old school“ Excel Sheet, in dem ich nach jedem Sprint die umgesetzten Story Points und die verbrauchten Personentage eingetragen und anhand des Projektscopes (sorry, des Product Backlogs) das erwartete Budget und – unter Berücksichtigung anstehender Urlaube und der Teamkapazität – den Fertigstellungstermin hochgerechnet habe.

Was ich anfangs überraschend, aber im weiteren Projektverlauf äußerst erfreulich fand: die Velocity blieb bereits nach dem zweiten Sprint sehr konstant. Die Abweichung je Sprint bewegte sich im Bereich von +/- 10%, sodass meine ersten Hochrechnungen den tatsächlichen Wert am Projektende schon recht gut getroffen haben.

Mir hat sich bereits sehr früh angedeutet, dass wir – ohne Gegenmaßnahmen – das Projektziel nicht erreichen würden; dem Team war das allerdings gar nicht transparent. Meine Erklärung ist, dass das Team eher den Fokus auf dem nächsten Sprint-Ziel hatte, als auf dem Projektende.

Wir sind daher relativ rasch dazu übergegangen, neben dem Sprint Burndown noch ein zusätzliches „Release Burndown Chart“ auf einem Flipchart zu führen, auf dem wir die Anzahl von Sprints bis zum Endtermin visualisiert und die zu leistenden den bereits geleisteten Story Points gegenübergestellt haben.

5.    Ausblick

Was mir persönlich an der agilen Community sehr gut gefällt, ist die permanente Suche nach weiteren Verbesserungen. Das hier geschilderte Verfahren zum Schätzpoker wurde in ganz mannigfaltigen Varianten erweitert, ergänzt und verbessert, um spezielle Anforderungen wie z. B. ein sehr großes oder ein sich häufig änderndes Product Backlog zu schätzen oder noch schneller auf höherem Abstraktionslevel zu guten Ergebnissen zu gelangen.

Das Schätzvorgehen aus Scrum hat sich nach meiner Erfahrung jedenfalls bewährt, und angereichert mit einem guten alten Excel Sheet ließ sich ein mittelgroßes Projekt damit auch sehr gut steuern.

 

Links, Quellen, weitere Informationen:

[1] Mein eigener Blog – Thomas Pressler: Gut geschätzt ist halb gewonnen, 15.01.2014
(http://www.it-economics.de/blog/-/blogs/gut-geschatzt-ist-halb-gewonnen)

[2] Stefan Lipowsky: Master-Arbeit „Steuerung im agilen Multiprojektumfeld“, 2012

[3] PMBOK Guide, A Guide to the Project Management Body of Knowledge, 4th Edition, Project Management Institute (http://www.pmi.org), 2008

[4] Oliver Hummel: Aufwandsschätzungen in der Software- und Systementwicklung, Spektrum Verlag, 2011

[5] Projektmagazin: Spotlight „Wie schätze ich Aufwände“, 2012 (https://www.projektmagazin.de/spotlight/wie-schaetze-ich-aufwaende)

[6] Boris Gloger: Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind, Hanser Verlag, 2014