← Zur Übersicht

Die Kunst der Zeitschätzung

Zeitschätzungen sind für die meisten Softwareentwickler eine ungeliebte Notwendigkeit, für Projektleiter ein Alptraum und für Kunden so undurchsichtig wie ein Blogpost von Stephen Hawking. Sie sind mehr Kunst als Wissenschaft und etwas, das man nicht strikt nach Handbuch machen kann. Es gehört einiges an Erfahrung dazu, diese Kunst soweit zu beherrschen, dass am Ende ein Ergebnis steht, mit dem man gut arbeiten kann. Im Grunde versucht man dabei schließlich in die Zukunft zu sehen und in der Regel wird aufgrund einer Zeitschätzung ein Termin gemacht, den es dann zu halten gilt.

Egal wie viel Erfahrung man als Entwickler oder Projektmanager hat, eine hundertprozentige Aussage über kommende Aufgaben und deren Aufwände ist ab einer gewissen Komplexität leider nicht möglich. Das ist allerdings kein Grund, das Thema nicht strukturiert anzugehen oder gar eine Entschuldigung dafür, es ganz links liegen zu lassen. Nur was heißt in dem Fall strukturiert? Dieser Artikel soll einige Anregungen und Gedanken dazu vermitteln. Ganz sicher gibt es nicht DIE eine Methode, die alle Probleme dieser professionellen Wahrsagerei löst. Aber eins hilft immer: Aufschreiben!

Eine Liste, sie alle zu schätzen

Fragt der Projektleiter einen Entwickler nach einer Zeitschätzung, passiert oft folgendes: er schaut nach oben rechts, geht im Geiste eine mögliche Implementierung durch und nennt dann eine ungefähre Zahl für den Aufwand. “Fünf Tage. Oder sagen wir mal lieber sechs. Vielleicht auch noch ein bisschen Puffer...”. Diese Zahl steht dann im Raum und es ist schwer, sie später zu korrigieren, wenn es neue Erkenntnisse gibt.

Statt nun eine Gesamtzahl als Aufwand zu nennen und dann erst für die Implementierung das Feature in technische Tasks zu zerlegen, hat sich folgendes für mich bewährt: man schreibt zuerst alles in eine Excel-Tabelle, was für die Fertigstellung des Features notwendig ist, OHNE zunächst über den genauen Aufwand nachzudenken. Dabei achtet man darauf, dass die einzelnen Tasks in ihrem Umfang überschaubar sind und die Formulierungen kurz und knapp.

Beispiel

Wenn man nun die Liste Punkt für Punkt durchgeht, über die Umsetzung und den Aufwand für die einzelnen Tasks nachdenkt (möglichst zusammen mit einem oder zwei Kollegen) und sie daneben schreibt, erhält man in der Regel eine genauere und vor allem kleinere Zahl. Kommt man auf mehr als 3-4 Tage, sollte am besten weiter aufgeteilt werden. Ich war am Ende immer wieder erstaunt, wie weit die Summe der Einzelschätzungen von dem abwich, was ich aus dem Bauch heraus für das gesamte Feature veranschlagt hätte.

Weiß man bereits bei der Planung, wer das Feature umsetzen wird, dann ist es sinnvoll, auch diesen Entwickler die Schätzung machen zu lassen. Am besten sollte immer noch ein anderer Entwickler dabei sein oder zumindest über das Ergebnis schauen und es sich erklären lassen, um nichts zu vergessen und die Genauigkeit zu erhöhen. Weiß man das nicht, dann schätzen am besten ein erfahrener und ein unerfahrener Entwickler zusammen, die sich dann jeweils auf einen mittleren Wert einigen, mit dem beide leben können. Damit soll vermieden werden, dass ein Entwickler 2 Tage schätzt und dann jemand die Umsetzung macht, der aufgrund seiner geringeren Erfahrung viel langsamer ist. Außerdem gibt es durch die gemeinsame Diskussion natürlich auch einen willkommenen Lerneffekt für beide.

Abgesehen von eben dieser höheren Genauigkeit hat eine schriftliche Liste noch weitere Vorteile:

  • Allein durch das Aufschreiben fallen einem oft noch Tasks ein, die man vorher vielleicht gar nicht bedacht hätte oder die bestimmte Implikationen haben, die spätestens der Projektmanager berücksichtigen muss. Ein Beispiel wären Übersetzungen oder Schnittstellenbeschreibungen, die er ggf. rechtzeitig vom Kunden besorgen muss.
  • Die Risikobewertung kann sehr detailliert für einzelne Punkte der Liste gemacht werden statt für das gesamte Feature. Im Beispiel wurden 2 Tage für 2 einfache Versanddokumente geschätzt, der Aufwand kann sich aber drastisch erhöhen, wenn die Layout-Vorgaben vom Kunden kommen oder es sich herausstellt, dass mehr Dokumente benötigt werden.
  • Es ist leichter zu erkennen, an welchen Stellen es noch Klärungsbedarf gibt, damit man eine Schätzung abgeben kann. Für diese Punkte lässt man die Spalte mit dem Aufwand einfach erst einmal leer oder markiert sie als zu klären.
  • Neben den nötigen Tasks für die Implementierung fallen beim Aufschreiben auch oft Todos darum herum auf (Bereitstellungstermine für Testdaten, Infrastruktur, fehlende Konzepte, zu bestellende LIzenzen uvm.)
  • Man kann auch nach Wochen nachvollziehen, wie ein Aufwand/Angebot zustande kam bzw. was vielleicht noch gefehlt hat. Oft ist es so, dass Projektleiter, Chefs und Kunden nachträglich noch Dinge in eine Schätzung hinein interpretieren, die ihrer Meinung nach mit dem genannten Aufwand abgedeckt wären.
  • Teilaufgaben lassen sich besser auf mehrere Entwickler verteilen, wenn sie als Liste greifbar sind.
  • Entwickler fühlen sich sicherer beim Schätzen und werden besser darin, wenn sie es schriftlich machen und noch einmal mit Kollegen diskutieren können.
  • Auch Post Mortems und Retrospektiven werden erst möglich, wenn man den tatsächlichen Aufwand erfassen und mit dem geplanten vergleichen kann, um daraus zu lernen. Dazu muss man diesen aber irgendwo erfasst haben.
  • Wenn dem Kunden der Gesamtaufwand für sein Feature zu hoch ist, kann man mit ihm über die Liste sprechen und den Aufwand besser belegen. Gegebenenfalls kann man Dinge weglassen, vereinfachen, verschieben etc., um den Gesamtaufwand und damit die Kosten zu drücken.
  • Statt einen Sicherheitspuffer nach Gefühl für das gesamte Feature einzuplanen, kann man selektiv Puffer für einzelne Tasks mit Unsicherheiten und Risiken einplanen, während man die Tasks unberührt lässt, bei denen man sich sicher ist.

Apropos Puffer

Am Ende erhält man also den Aufwand, den die Entwickler für realistisch halten. Wichtig: Zeitliche Puffer, die zur Sicherstellung eines Liefertermins benötigt werden, sollten erst zusammen mit dem Projektmanager abgesprochen und geplant werden, für den es sehr wertvoll ist, die “realen” Implementierungs-Zeiten zu kennen und zu wissen wo und warum es Unwägbarkeiten gibt. Was er dann letzten Endes als Aufwand an den Kunden kommuniziert, kann aus verschiedenen Gründen davon abweichen. Damit ist nicht gemeint, dass die Entwickler ihre “Implementierungs-Reserve” weglassen und allzu knapp schätzen sollen. Wenn diese allerdings Tage beträgt, dann besteht Klärungsbedarf bei den Anforderungen, die entweder unklar formuliert oder von den Entwicklern noch nicht verstanden wurden.

Außerdem ist zu beachten, dass man jetzt zwar einen Aufwand hat, aber keine realistische Dauer für die Fertigstellung. Den Kunden interessieren eigentlich zwei Zahlen: wann ist das Feature fertig und was kostet es ihn. Die Kosten können wir aus den Schätzungen ableiten. Allerdings bedeuten 3 Tage Aufwand nicht, dass es in 3 Tagen fertig ist, da es selten ist, dass Entwickler tatsächlich 8 Stunden am Tag produktiv an einem Feature arbeiten können.

Es hat sich bewährt, die geschätzten Zeiten je nach Projektsituation mit einem Prozentwert für die Produktivität umzurechnen. Im Beispiel oben beträgt die Produktivität 80%, aus 3 Tagen werden also 3,75 Tage - ein signifikanter Unterschied. Das heißt, 20% seiner Zeit wird ein Entwickler Mails beantworten, telefonieren, Kollegen helfen, in Meetings sitzen, Code reviewen, mit der Build Pipeline kämpfen und einiges mehr. Für einen Entwickler, der in mehreren Projekten gleichzeitig tätig ist, kann dieser Wert sogar noch geringer sein, weil es mehr Reibungsverluste durch das Wechseln zwischen den Projekten oder Teams gibt.

Die beschriebenen Praktiken basieren auf persönlicher, langjähriger Erfahrung mit Projekten von 4 Wochen bis 2 Jahren mit kleinem Team und großen Kunden. Natürlich muss jedes Team hier die Methode(n) finden, die am besten passen. Egal wie diese letzten Endes aussieht: der Anteil der Wissenschaft sollte größer werden und der künstlerische geringer.