Manchmal ist gerade das Durcheinander inspirierend, weil es mich zum Sortieren animiert – so erlebte ich es kürzlich auf dem (übrigens in jeder Hinsicht inspirierenden!) PM Camp Berlin1 beim Diskutieren über Aufwandsschätzungen.
Ob agil oder nicht – solange man nicht zufällig Anhänger der #noEstimates-„Bewegung“2 ist, kommt man über kurz oder lang in die Situation, (Projekt‑)Aufwände schätzen zu müssen. Ansätze und Methoden dafür gibt es zuhauf, in vielen Diskussionen scheinen mir aber die Dimensionen des Themas wild durcheinander geworfen zu werden – meine ganz persönliche „Sortierung“ dieses „Kuddelmuddels“ möchte ich hier darstellen:
Die Methode: Wie schätze ich?
Vorgehensweisen zur Aufwandsschätzung gibt es wie erwähnt zuhauf, und die Diskussion darüber, welche denn nun „die eine beste“™ Methode ist, nimmt m. E. oftmals geradezu dogmatische Züge an3. Oftmals verlaufen die Gräben hier ganz grundsätzlich zwischen Anhängern agiler und solchen der „klassischen“ Methoden – und beispielsweise einen langjährigen COCOMO-Nutzer von den Vorteilen des Planning Pokers zu überzeugen, dürfte ebenso schwierig sein wie der umgekehrte Fall. An dieser Diskussion möchte ich mich hier nicht beteiligen – sicher ist: Die Wahl der Schätzmethode bzw. des Vorgehens ist eine (aber eben auch nur eine und genau eine) Dimension des Themas.
Die Größe: Was schätze ich?
Bevor ich schätze, muss ich Klarheit darüber haben, welche Größe ich eigentlich schätze. Im Moment scheint es mir hier zwei übliche Ansätze zu geben: Ich kann einerseits „klassisch“ den Aufwand i. S. von Zeit (Arbeit oder Dauer – auch das ist natürlich ein Unterschied!) oder von Geld zu schätzen versuchen, andererseits kann ich versuchen, die Komplexität beispielsweise in Form von Story Points oder Function Points zu schätzen – gerade in agilem Umfeld ein verbreiteter Ansatz. Die „Faustregel“ scheint mir an dieser Stelle zu sein: Muss ich Termine oder Kosten möglichst exakt kennen (bspw. für die Erstellung eines verbindlichen [Festpreis-]Angebots), muss ich auch genau diese Größe schätzen. Möchte ich hingegen die (hoffentlich) steigende Velocity4 eines agil arbeitenden Teams messen können, schätze ich Komplexität und messe die Zeit lediglich ex post.
Update 24.09.2018: Lars Richter weist in seinem sehr lesenswerten Artikel „Messen Story Points eigentlich Aufwand oder Komplexität?“5 völlig zu Recht darauf hin, dass mir (wohl in dem Versuch, einen pointierten Gegensatz zu „Zeit“ auszudrücken) durch die Reduktion des „agilen Schätzens“ auf „Komplexität“ eine grob verfälschende Vereinfachung unterlaufen ist: Es ist in der Tat so, dass Komplexität nur ein Aspekt der Schätzung ist, geschätzt wird eine generische „Größe“ („size“6) – und auch die bezieht sich natürlich auf den Aufwand, der ja Gegenstand dieses Artikels ist.
Das/die Intervall(e)
Gerade beim Schätzen des Aufwands ist es nicht unüblich, anstelle einer einzelnen (Schätz‑)Zahl ein Intervall zu schätzen – also beispielsweise Minimum und Maximum oder Minimum, „wahrscheinlichster Wert“ und Maximum7. Die Definition des Minimums ist dabei meist recht klar8, anders die des Maximums: Muss man bei der Schätzung des Maximums auch unwahrscheinliche Ereignisse wie Meteoriteneinschläge berücksichtigen? Möchte man ein Maximum schätzen, möchte man also schätzen, wie lange etwas „schlimmstenfalls“ dauert, sollte man vorher sehr genau definieren, was „schlimmstenfalls“ bedeutet.
Ebenfalls festlegen sollte man m. E., welche dieser Werte wie weitergegeben werden sollen: Nicht immer ist es sinnvoll, die geschätzten Intervalle komplett an (interne oder externe) Kunden zu kommunizieren – das Minimum kann ohne begleitende Erläuterungen ebenso einen falschen oder gar verheerenden Eindruck entstehen lassen wie die Summe der Maxima.
Schätzt man Minimum und Maximum, erscheint mir übrigens das Einplanen von Puffern unlogisch und sinnlos.
Die Genauigkeit
Schätze ich beispielsweise Zeit, kann ich das in Stunden, (Personen‑)Tagen oder gar Wochen oder Monaten tun – eine m. E. sehr wichtige Entscheidung. Zwar könnte man einwenden, dass acht Stunden ein Personentag sind und diese Einheiten verlustfrei ineinander umrechenbar sind, aber dennoch ist diese Frage wichtig: Praktisch niemand, der um eine Schätzung gebeten wird, schätzt „0,125 Tage“ oder „3,625 Wochen“. Ebenso wird kaum jemand seine Schätzung abrunden, sondern eher grundsätzlich mehr oder minder großzügig aufrunden – und auf diese Weise womöglich unabsichtlich (oder gar beabsichtigt) einen zusätzlichen Puffer schaffen. Je größer meine Einheit ist, desto stärker kommt dies zum Tragen – und je kleiner meine Granularität ist (s. u.), desto öfter. Dementsprechend erscheint es mir sinnvoll, die verwendete Einheit in einem angemessenen Verhältnis zur erfahrungsgemäß möglichen Genauigkeit der Schätzung zu wählen – und im Zweifel eher feiner als gröber.
Die Granularität
Etwas (in diesem Fall: ein Projekt) in kleinere Teile zu zerlegen, diese dann zu schätzen und anschließend die Summe zu bilden, ist ein naheliegendes (analytisches) Vorgehen. Praktisch habe ich allerdings beobachtet: Je feiner man ein Projekt in Teilaufgaben und Arbeitspakete (oder Epics, User Stories o. ä.) zergliedert, desto größer wird häufig die Summe, der geschätzte Gesamtaufwand: Aufrundungen (s. o.) und (bewusst oder unbewusst hinzugefügte) Puffer addieren sich. Es empfiehlt sich also, die Dekomposition an dieser Stelle möglichst nicht weiter zu treiben, als für die Schätzung notwendig ist.
Die Skala
Schätze ich Aufwände, tue ich das sinnvollerweise meist auf Basis einer linearen Kardinal- oder Invervallskala. Schätze ich aber Komplexität, ist es durchaus üblich, dies auf Basis von Ordinalskalen zu tun – beispielsweise mit der Metapher der T‑Shirt-Größen (S/M/L/XL) oder auch (z. B. häufig beim „Planning Poker“) Story Points auf einer auf die Fibonacci-Folge o. ä. basierende Skala. Verwendet man diese Skalen, sollte man nicht vergessen: Die „Abstände“ zwischen den Werten sind nicht wirklich scharf definiert (der quantitative Unterschied zwischen „S“ und „M“ kann ein anderer sein als zwischen „M“ und „L“) – und Werte einer Ordinalskala mögen jeweils für sich mit spezifischen Werten auf einer Kardinalskala korrespondieren, es gibt aber i. d. R. keine „Umrechenformel“. Noch weniger lässt sich übrigens Komplexität direkt in Zeit umrechnen – das wäre, als würde man beim Reisen Kilometer in Stunden umrechnen wollen, ohne die Geschwindigkeit des jeweiligen Fahrzeugs zu kennen.
Lege ich ein Vorgehen für eine (Aufwands‑)Schätzung fest, sollte ich m. E. in allen sechs Dimensionen eine Entscheidung treffen, nicht nur über die Methode selbst – und je genauer ich darüber nachdenke, desto mehr beschleicht mich der Verdacht: Die Methode – das Vorgehen – ist erstaunlich unwichtig; die anderen fünf Dimensionen des Themas haben häufig einen größeren Einfluss auf die Validität der Schätzung als die „hart umkämpfte“ Frage nach der Wahl der Methode.
Footnotes:
- ↑ Vgl. <https://www.openpm.info/display/openPM/PM+Camp+Berlin+2018+-+Sessiondokumentation> (08.09.2018).
- ↑ Vgl. bspw. <http://zuill.us/WoodyZuill/beyond-estimates/> (08.09.2018).
- ↑ Im englischsprachigen Wikipedia-Artikel zu Aufwandsschätzungen bei der Softwareentwicklung findet sich eine recht umfangreiche Liste.
- ↑ Also eigentlich die Beschleunigung.
- ↑ <https://flowwork.rocks/story-points-aufwand-oder-komplexitaet/> (24.09.2018).
- ↑ Vgl. Cohn, Mike: Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall Professional Technical Reference 2006. S. 35 ff.
- ↑ Bspw. im Falle von PERT.
- ↑ Kartoffelpüree herzustellen, dauert mindestens so lange, wie die Kartoffeln kochen müssen. Transporte sind nach derzeitigem Kenntnisstand mindestens durch die Lichtgeschwindigkeit begrenzt.