Schätzen nach Aufwand

Die agile Community diskutiert das Thema “Schätzen” immer wieder. Dabei geht es bis hin zu einer #noestimate Bewegung, die den Aufwand von Schätzungen insgesamt als “wertlos” betrachtet. Warum ich Schätzungen grundsätzlich sinnvoll finde, habe ich in bereits in meinem Blog-Beitrag “Schätzungen – muss das denn sein?” beschrieben.

In meinem Beitrag “Schätzen: Storypoints oder Stunden?” gehe ich darauf ein, warum ich eine relative Schätzung mit Story Points für sinnvoller halte, als eine Schätzung von Stunden. Aber was genau kann und sollte man mit Story Points schätzen?

Als gängige Praxis habe ich die Schätzung von Komplexität erlebt (und selbst lange vertreten) – Seibert Media beispielsweise äußert sich im Beitrag “Kontinuierliches Schätzen in agilen Projekten” dazu. Nach vielen Jahren Erfahrung damit, komme ich mittlerweile zu dem Schluss, dass eine Schätzung nach Komplexität einen geringen Wert hat.

Warum schätzen wir?

Der Prozess der Schätzung selbst durch das für die Umsetzung gesamtverantwortliche Team hat einen hohen Wert,  der sich aber – so wird auch die #noestimate Bewegung argumentieren – auch durch andere Fragen erreichen lässt: Eine intensive Auseinandersetzung mit den Themen sorgt für erste Umsetzungsideen, ein gemeinsames Verständnis und einen ersten Umsetzungsplan im Team.

Wenn dieser Wert auch durch die Diskussion anderer Fragen, als die Frage nach der geschätzten Komplexität, erreicht wird, braucht man Schätzungen dafür also nicht. Auch der Business-Wert eines Features lässt sich nicht zwingend anhand der Komplexität ablesen. Außerdem liegt die Bewertung des Business-Werts eher bei Product Owner und Stakeholder unterstützt durch das Team. Den Business-Wert zu schätzen hat Sinn, folgt aber anderen Regeln als eine übliche Team-Schätzung und verfolgt ein anderes Ziel.

Wofür hat eine Team-Schätzung dann dennoch Sinn?

Der Wert von Schätzungen liegt aus meiner Sicht darin, die kurz-, mittel- und langfristige Planung zu vereinfachen. Durch eine Schätzung wird

  • eine Prognose für die Umsetzungszeitpunkte von Funktionalitäten möglich.
  • die zeitliche Auswirkung von Repriorisierung überschaubarer.
  • Kosten/Nutzen von Funktionalitäten sichtbar.
  • es möglich, den Inhalt von Anforderungen vor dem Aufwandshintergrund mit dem Team gemeinsam zu formulieren um auf der Basis kleinstmögliche Lösungen zu konzipieren.

Was müssen wir dafür schätzen?

Die Schätzung von Komplexität gibt uns keinen verlässlichen Aufschluss über die Umsetzungsdauer und damit über die Kosten einer Umsetzung: Ein hohes Maß an Komplexität wird wahrscheinlich auch zu einer hohen Umsetzungsdauer führen. Ein geringes Maß an Komplexität ist aber keine Garantie für eine geringe Umsetzungsdauer – zum Beispiel bei einfachen Aufgaben mit einem hohen manuellen Aufwand, deren Automatisierung zu aufwändig wäre oder sich aus anderen Gründen nicht lohnt.

Das heißt: Nur der Aufwand kann Aufschluss über die Dauer einer Umsetzung geben und nur davon lassen sich die Kosten ableiten. Der hohe Wert der Schätzung als Planungsgrundlage und für eine Kosten/Nutzen Betrachtung kann also nur erreicht werden, wenn in der Schätzung nicht die Komplexität, sondern der Aufwand betrachtet wird.

Hinzu kommt, dass Komplexität ein schwammiger Begriff ist, der die ohnehin schon unscharfe Schätzung noch ungenauer macht und die Diskussionen während der Schätzung innerhalb des Teams weiter erschwert.

Wie schätzen wir?

Wenn Aufwand als zu schätzende Größe besser, weil relevanter und einfacher ist, als Komplexität, warum gibt es dann keine Rückkehr zu einer reinen Aufwandsschätzung nach absoluten Stunden oder Tagen? Warum ist eine relative Betrachtung des Aufwands von Features gegenüber dem Aufwand anderer Features besser, als eine absolute Zeit-Betrachtung?

Relativer Aufwand ist leichter abzuschätzen als absoluter Aufwand. Stellt man zwei unterschiedlich hoch mit Erbsen gefüllte Tassen nebeneinander ist es einfacher zu sagen, ob ein Glas im Verhältnis zum anderen Glas gleich voll oder doppelt so voll oder nur ein drittel so voll ist, als die genaue Anzahl der Erbsen zu bestimmen. Die absoluten Zahlen können auf Basis gemessener tatsächlicher Werte genannt werden. Die Schätzung geht schneller und ist im Mittel zuverlässiger.

Was ist das Ergebnis?

Durch eine relative Schätzung des Aufwands mit Storypoints über mehrere Iterationen hinweg ergibt sich eine Zahl, wie viel Arbeit ein Team im Durchschnitt in einer Iteration schafft. Diese Zahl lässt sich für zeitliche Prognosen verwenden und umrechnen auf die Kosten pro Storypoint. Möglich werden Diskussionen mit dem Produktverantwortlichen, ob die Fertigstellung eines Features zu einem ungefähren Zeitpunkt ausreichend ist und ob die wahrscheinlichen Kosten für die Umsetzung dem Nutzen gerecht werden.

Das Ergebnis der Betrachtung des relativen Aufwands sind weiterhin Schätzungen. Durch die Betrachtung der in der Vergangenheit gemessenen Aufwandswerte (wie viel hat ein Team in der Vergangenheit pro Iteration geschafft) sind sie zuverlässiger, als subjektiv wahrgenommene Komplexität von Aufgaben. Außerdem führen Diskussionen über relativen Aufwand  schneller zu Schätzergebnissen, als die Betrachtung der viel schwerer zu greifenden technischen Komplexität.

Wichtige Ergänzungen:

Das Ziel einer relativen Schätzung nach Aufwand ist eine gute Planbarkeit. Damit ist das vorrangige Ziel des schätzenden Teams auch nicht, die Anzahl der Storypoints pro Sprint zu steigern, sondern möglichst gleich zu halten und den geplanten Umfang in einer Iteration auch zu erreichen.

Ein in Storypoints relativ geschätzter Aufwand liefert also keine Aussage über die Effizienz eines Teams oder deren Steigerung. Eine möglichst gleichbleibende Zahl pro Sprint ist ein hoher Wert, da er die Planbarkeit verbessert. Außerdem ist auch diese Art der Schätzung nicht über unterschiedliche Teams hinweg gültig oder vergleichbar.

Was bedeutet das für die Schätzung?

  • Das umsetzende Team schätzt die Aufwände.
  • Es wird alles geschätzt, was in den Sprint geplant einfließt (auch mögliche Themen aus Technik und Konzeption, die keinen direkten Kundennutzen erzeugen).
  • Der Aufwand für die Umsetzung von Incidents, Bugs und weiterem, das ungeplant während einer Iteration auftaucht, wird nicht geschätzt, sondern sollte zunächst über einen angenommenen Puffer berücksichtigt werden, dessen Größe sich durch Erfahrung nach und nach besser benennen lassen wird.

Hier gibt es weitere Beiträge zum Thema “Schätzen”.

Wie ist deine Meinung zum Thema “Schätzen” – nach Aufwand oder Komplexität oder besser gar nicht?

(Das verwendete Bild ist von Felix Meyer – vielen Dank!)

7 Comments

Leave a Comment
  1. Ich wollte das eigentlich lesen. Ich lese aber nicht gerne hellgraue Schrift auf weißem Grund (ja ich bin schon über 40).
    Sehr geehrter Web-Designer, ist es so schlimm Texte kontrastreich darzustellen? Viele Leute die ich kenne, empfinden Schrift gar nicht als so hässlich.

    1. Hallo lieber hdminspector,

      über eine Leserschaft über 40 freue ich mich, da ich davon eine altersunabhängige Relevanz ableite und nicht nur Millenials anspreche.

      Gleichzeitig stelle ich fest, dass ich selbst auch über 40 bin und keine Probleme mit dem Grauton der Schrift habe. Außerdem höre ich diese Rückmeldung erstmalig – insofern vermute ich das Problem woanders.

      Sollte ich diese Rückmeldung häufiger bekommen, denke ich über eine Anpassung nach. Bis dahin wäre eine schnelle Lösung des Problems, dass ich den Text “schwarz auf weiß” per E-Mail zusende – als wenig aufwändige Minimallösung sozusagen. Leider ist mir das nicht möglich, da “nospam@telekom.de” vermutlich nicht die richtige Adresse ist.

      Bei Interesse bitte einfach melden.

  2. Hi Daniel,

    wieder ein guter Artikel 🙂

    Ob und wie in einem Projekt geschätzt wird, hängt ja auch häufig von der Auftragssituation ab. Wenn der Kunde eine kleinteilige absolute Aufwandsschätzung auf Task-Basis verlangt, dann bekommt er sie halt. Auch wenn die Aussagekraft häufig gering ist.

    Unabhängig ob absolute oder relative Schätzung, halte ich (zumindest für die Teamentwicklung) den Umgang mit Schätzungen für den zentraleren Punkt.

    Meiner Erfahrung nach gibt es, nachdem eine Schätzung vom Entwicklerteam abgegeben wurde, selten eine weitere Auseinandersetzung damit. Nach Erledigung einer Aufgabe oder am Ende eines Sprints wird nicht geprüft, inwieweit die Schätzung zutreffend war und welche Aspekte man ggf. anders eingeschätzt hat, als sie dann tatsächlich eingetroffen sind.
    Die Schätzung wird dann nur gemacht, weil in der Story eine Zahl stehen muss. Sie wird nicht als nützliches Werkzeug zur Verbesserung der eigenen Fähigkeiten erkannt.

    Eine tiefergehende Auseinandersetzung mit Stories, den zur Umsetzung erforderlichen Schritten und den dafür geschätzten Aufwand erfordert natürlich relativ viel Zeit und Geduld. Aber gerade bei komplexen Stories kann eine entsprechende Betrachtung und nachfolgende Analyse für die Entwickler sehr hilfreich sein.

    Meiner Meinung nach, kann man es dadurch schaffen, dass eine Aufwandsschätzung sowohl für das Entwicklerteam als auch für den Kunden relevant wird.

    Viele Grüße,
    Julian

    PS: Bei absoluten Schätzungen in PT habe ich übrigens gute Erfahrungen mit Von-Bis-Schätzungen gemacht.

  3. Wenn schon Aufwand schätzen dann relativ, finde ich gerade auf Task-Ebene besser als in PT.
    ABER heißt nicht Aufwand schätzen, ich weis: was, wie und wer es macht und ist nicht was wieder Komplexität ….😐
    Wir haben in letzter Zeit user Stories nach Komplexität und value geschätzt und wsjf gebildet als Indikator für eine Sortierung der User Stories und als Eröffnung der Diskussion zu kosten/nutzen.
    Im Planning 2 dann tasks also Aufgaben so geschnitten das sie da nach einem Tag abgearbeitet sind.
    Und dann nur noch tasks gezählt. Das hilft dann auch am scrumboard und im burndown

    1. Hi Kurt. Danke für deine Antwort. Auf Task-Ebene schätzen wir aktuell keine Aufwände, haben aber die Regel, dass ein Task eine Größe hat, die innerhalb eines Tages abgeschlossen werden kann, um den Fortschritt transparent machen zu können. Für Stories gilt, dass sie innerhalb eines Sprints umsetzbar sein sollen und jetzt führen wir ein, dass Epics maximal 3 Sprints dauern dürfen.

      Für mich ist eine Schätzung eine Schätzung und ist damit keine Vorhersage. Wir schätzen Stories relativ nach Aufwand mit dem Team – insofern muss niemand wissen, wer tatsächlich die Umsetzung macht.

      Welchen Nutzen hat eine relative Schätzung von Komplexität? Ich habe eine Teameinschätzung, ob eine Aufgabe komplexer als eine andere ist – wie hilft mir das bei der weiteren Arbeit?

  4. Moin,

    das Schätzen über den Aufwand hat das Problem, dass dieser stark von den umsetzenden Personen abhängt (, wenn nicht im Swarming gearbeitet wird). Statistische Effekte greifen nicht in den kleinen Teams (und können auch in die Irre führen).

    Was ich sagen will: relative Schätzungen sind sicherlich sinnvoller als absolute. Aufwand zu schätzen ist jedoch problematisch. Eine Lösung sehe ich über Komplexitätsbetrachtungen und vergleichende Hochrechnungen, was aber die oben aufgezeigten Schwierigkeiten hat. Es bleibt spannend…

    1. Hallo Uwe,

      vielen Dank für deine Antwort. Ich bin bei dir, dass beides seine Schwierigkeiten hat – ich habe aber keine guten Erfahrungen mit Komplexitätsschätzungen gemacht, alleine schon weil selbst erfahrene Mitarbeiter und erfahrene Teams (die mehr als ein halbes Jahr zusammen verbracht haben) Schwierigkeiten hatten, “Komplexität” zu greifen und damit zu schätzen. Auf diesem Grund und weil Komplexität nicht mit Dauer gleichzusetzen ist, hatten die Aussagen einen geringen Wert.

      Aus meiner Sicht ist natürlich Schätzung von absolutem Aufwand durch Einzelne wenig förderlich – besser ist die Schätzung von relativem Aufwand im “Schwarm” – also als Team, gerne mit Storypoints. Das ist meiner Erfahrung nach hilfreicher weil

      1. einfacher zu diskutieren
      2. For Planung die relevantere Größe

      Malte Foegen erwähnte mal im Gespräch von “Aufwandskomplexität” – ich hatte aber keine Gelegenheit zu vertiefen, was er damit meinte. 😉

      Viele Grüße
      Daniel

Schreibe einen Kommentar zu Julian Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert