Inhalt : "No Estimates" - Problematiken von Schätzungen

Created by Robert Weißgraeber, last modified by Planio on 23. Jun 2016

Vom Fragen wird die Straße länger.

 ~ Bernhard Schloß, 2013


Als "Gegenentwurf" zur klassischen Pflicht zur Schätzung von Aufwänden gilt die #noEstimates-Bewegung. Im folgenden sind einige Argumente, Alternativen und Hintergründe kurz angerissen.

Im Vordergrund der Kritik an Schätzungen steht dabei insbesondere, dass der Grund für Schätzungen in der Hauptsache externe Kräfte (Management, Kunde,...) sind, und diese meist geliefert werden, weil es "üblich ist", und nicht weil das Projektteam darin einen intrinsischen Sinn sieht. Der Gegenentwurf "NoEstimates" sieht eher eine Ableitung/Extrapolation von vorhandenen Informationen (z.B. bekannte Durchlaufzeit in einem Kanban-Fluß) vor, als immer bessere Methoden zu entwickeln eine nicht vorhersehbare Zukunft vorauszusagen. Darüber hinhaus stellt sich ein solches System deutlich besser auf Veränderungen im Team oder der Organisation ein, da es nicht möglich ist, diese in Voraussagen zu berücksichtigen. 

Machen Schätzungen überhaupt Sinn?

These: Schätzungen in einem Projekt sind unsinnig, da ein Projekt (oft oder immer?) die Erstellung von etwas "Neuem" beinhaltet. Das Neue ist nicht mit bereits existierenden Erfahrungen ausreichend vergleichbar/erfassbar. Daher wird jede Schätzung falsch sein. In IT-Projekten entstehen in eher kurzen Zyklen neue technische Möglichkeiten, um Projekte umzusetzen. Die hier fehlenden Erfahrungen fühen zwangsläufig zu falschen Schätzungen.

Machen Schätzungen dann überhaupt noch Sinn? Wenn ja, dann vielleicht nur in grober/abstrahierter Form?

  • "die neue Newsletter Applikation wird in weniger als 1 Jahr fertiggestellt sein"
  • "die Integration des Payment Moduls wird ca. 3 Monate dauern"

 

Ansatzpunkte für die Kritik an Schätzungen

Schätzung von Dauer

z.B. Personentage: schon Scrum verzichtet auf Zeit-Schätzungen, da eine Dauer einer Aufgabe von der Produktivität, und damit mehr von der umsetzenden Person oder deren Zustand zum Umsetzungszeitpunkt oder externen Einflußgrößen abhängt. (Literatur: http://scrum.jeffsutherland.com/2013/04/why-hours-dont-work.html)

"Parkinson'sche Gesetz"

“Work expands so as to fill the time available for its completion.”

„Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“

Abgeleitet heißt das: Schätzen wir eine Aufgabe auf eine Dauer X, wird sie nie in weniger als dieser Zeit fertiggestellt.

fehlende Wertschöpfung (Muda)

Die Schätzung an sich, als Tätigkeit, gibt keinen Beitrag zur Wertschöpfung des Produktes, oder auch provokativ formuliert: "Durch Schätzung wird die Arbeit nicht früher fertig." 

Systemische-Problematiken

Probleme ergeben sich auch aus der Interaktion zwischen Schätzenden und Auftraggebern. Diskussionen über die Schätzung ("das ist zu viel") führen zur Einführung von verdeckten Puffern in die Schätzung. (Literatur: http://www.estherderby.com/2012/03/estimating-is-often-helpful-estimates-are-often-not.html)

Wissenschaftliche Studien

Studienergebnis zur Produktivitätsmessung ohne Schätzung: (Quelle siehe: http://books.google.de/books?id=TVQUAAAAQBAJ&pg=PT19&lpg=PT19&dq=%22table+5-3.+Productivity+by+Estimation+Approach%22&source=bl&ots=OYO9fGteYU&sig=_kX02jh7bgAFmj1TQu2B9knSF6c&hl=de&sa=X&ei=lMQ9UuqsCYSXtAbPpIGwDg&ved=0CDIQ6AEwAA#v=onepage&q=%22table%205-3.%20Productivity%20by%20Estimation%20Approach%22&f=false )


Zwischenlösungen

Einige Frameworks, besonders im Agilen Bereich, beantworten diese Defizite mit abweichenden Schätzungs-Methoden.

Relative Schätzung (z.B. in Gummipunkten)

Die Ermittlung von relativen Größen (oft verwendet z.B. Story Points, T-Shirt-Größen) der einzelnen Aufgaben innerhalb eines Projektes wird dazu verwendet, zumindest fiktive Zahlen an die Aufgaben anhängen zu können. Über Auswertungen der erreichten Punkte werden Größen wie eine relative Projektgeschwindigkeit (Velocity) oder projizierte Endtermine mittels Burndown Chart ermittelt.

Planning Poker

Beim Planning Poker steht der Prozeß der Schätzung im Vordergrund. Durch Spiegelung der unterschiedlichen extremenen Meinungen im Expertenteam und der daraus folgenden Diskussion wird ein gezielter Austausch über die Aufgabe bzw. deren Ansätze zur Umsetzung gefördert. Insbesondere getroffenen Annahmen können dabei aufgedeckt werden.

Function Points

Eine mittlerweile schon "alte" Variante zur Aufwandsermittlung in der Softwareentwicklung: siehe Wikipedia: http://de.wikipedia.org/wiki/Function-Point-Verfahren

 

Expertenschätzung

Ähnlich wie beim Planning Poker tauschen sich die Experten auf dem Gebiet aus und geben jeweils ihre Schätzung ab, beruhend auf Erfahrungen aus früheren Projekten. 

Funktioniert allerdings nur dann gut, wenn die Experten genügend Erfahrung haben und über eine Datenbasis mit
den Aufwendungen für vergleichbare, in der Vergangenheit abgewickelte Projekte verfügen.

Gegenvorschläge

Nichtsdestotrotz sollte man in der Lage sein, den berechtigten Fragestellungen vom Typ "Bis wann ist XY fertig" qualifiziert zu beantworten. Dazu wird zur Messung von Fortschritt, etc.  u.a. Folgendes vorgeschlagen:

  • Messung & Plot von aktueller Durchlaufzeit
  • Messung von Durchsatz (Anzahl der gelieferten Tickets, Stories etc. pro Zeitraum)
  • -> Bei Nutzung von WIP-Limit lässt sich mittels Warteschlangentheorie (z.B. Littles Gesetz) eine Voraussage für ganze Teams treffen

Der grundsätzliche Ansatz seitens des Mangements/Kunde ist einer von Vertrauen & Beobachtung mit Regulierungsmöglichkeit, statt der einer Kontrolle von fiktiven Zahlen. 

 

Stabile Teams ermöglichen verlässliche Schätzungen

Teams, die über einen längeren Zeitraum mehrere Projekte gemeinsam bearbeiten sind in der Lage neue Aufgaben gemeinsam zu bewerten. Durch ein funktionierendes Team werden eventuelle Fehleinschätzungen auf mehreren Wegen ausgeglichen. Ein stabiles (Kern-)Team ist somit eine Vorraussetzungen für eine möglichst geringe Falscheinschätzung, unabhängig von der gewählten Methodik. 

Informationen zu #noEstimates

 

Entstanden aus dieser Twitter-Diskussion: https://twitter.com/fogbird/statuses/326636695946661888
 

 



Attachments:

noestimates.jpg (application/octet-stream)

Comments:

Blöde Frage: Wie können wir Schätzung und Planung voneinander abgrenzen?
Posted by bschloss at 07. Mai 2013 13:26

Guter Punkt, ich versuche das mal im Artikel noch auszuführen. Es geht ja hier darum, explizit Schätzungen (Estimates) als Raten (aka "Guesstimate") zu überdenken; und für die Planung andere beobachtete, Messwerte heranzuziehen (z.B. Bei Einsatz von Kanban: Durchsatz an Tickets, Vorlaufzeiten, etc.)
Posted by rweissgraeber at 07. Jun 2013 18:40

Glen Alleman geht in seinem Blog (http://herdingcats.typepad.com/my_weblog/) immer wieder auf die NoEstimates-Diskussion ein. Sein Argument ist, dass ein Auftraggeber das Recht hat, zu wissen, wie viel etwas kostet. Für viele Bereiche gibt es gute Informationen, Methoden und Referenzklassen. Er hat den Eindruck, dass sich manche mit dieser Diskussion aus der Affäre ziehen wollen.
Posted by jan.fischbach at 07. Mai 2014 17:12

Ja, es ist so eine Sache mit den Aufwandsschätzungen. Ich bin derzeit in der kundennahen Projektierung tätig.

In diesem Umfeld mache ich die Erfahrung, dass die reine technische Umsetzung maximal 10-20% des Gesamtaufwandes bedeuten.

Der überwiegende Aufwand wird durch Vorgänge und Mitarbeiter beim Kunden verursacht. Klären was wirklich die Ursache ist; Leute zum Mitarbeiten bewegen; banale Entscheidung abwarten; zum Hundert tausendsten Male die Fakten darlegen; Entscheiden wollen ohne Sachkompetenz

Viele Kunden lassen sich bedienen und wollen nicht einsehen, dass Projekte auch mitmachen bedeuten.

 

Die Kunden selbst sind regelmäßig der größten Kostentreiber, vor allem wenn sie sparen möchten.
Posted by stefanbachert at 08. Mai 2014 14:17

Natürlich hat der Kunde ein Recht zu erfahren, wie viel Aufwand etwas vermutlich nach sich zieht. Nur muss man dabei auch noch mehrere Dinge festhalten

  • Schätzungen sind keine Festpreisangebote
  • Schachern um Aufwände ist absurd, und führt zu "Kunde/Management will belogen werden"
  • In der Fachliteratur werden Aufwände in der Spanne x*(1...3) für die gleiche Sache angegeben. Das hängt nicht alleine von der Kompetenz der Projektmitarbeiter ab. Auch der beste Mitarbeiter mag nicht die zündende Idee haben und einen speziellen Trick nicht kennen.
  • Meine praktischen Erfahrungen zeigen dass Abstimmungsaufwände bei projektunerfahrenen Kunden den Aufwand um Faktor 5-10 multiplizieren
  • Kunden beklagen sich bitterlich wenn Schätzungen um 100% überschritten wurden, selbst wenn sie objektiv selbst den Anlass gegeben haben.
  • Kunden und Projektarbeiter wissen kaum was von einander. Kunden fühlen sich durch obige Fakten "über den Tisch gezogen".
  • Projektarbeiter fühlen sich ebenso über den Tisch gezogen wenn sie trotz Unwägbarkeiten belastbare Aussagen machen sollen
  • Es hilft einem Kunden nicht wenn er weiß wie viel ihn eine Klasse oder Methode kostet. Der Kunde, und der Entwickler kann nicht auf Anhieb sagen wie viele Artefakte ein Anwendungsfall nach sich zieht
  • Kleinprojekte schwanken aus statischen Gründen mehr als Großprojekte wo sich Unsicherheiten teilweise kompensieren
Posted by stefanbachert at 08. Mai 2014 15:55