TL;DR: Entwickler in kleinen Software-Teams schätzen systematisch zu niedrig, weil sie nur die reine Code-Zeit sehen. Der echte Aufwand — Ticket lesen, eindenken, testen, deployen — ist höher als die geschätzte Kernaufgabe. Ein Software-Unternehmer hat das mit einem simplen Experiment aufgedeckt: Stoppuhr neben die Entwicklerin setzen. Die Lücke zwischen seiner Schätzung (700–800 Euro) und ihrer (200–300 Euro) lag an der Perspektive.
30 Minuten geschätzt, 20 Stunden aufgeschrieben
Sie schreibt ins Ticket: „Ich rechne mit ca. 30 Minuten." Am Ende stehen 20 Stunden auf der Uhr. Dann fragt sie, ob sie 40 oder 50 Euro abrechnen soll.
Ihr Chef — ein Software-Unternehmer mit einem kleinen Entwicklungsteam — schätzt dieselbe Aufgabe auf 700 bis 800 Euro. Sie auf 200 bis 300. Faktor drei. Für dieselbe Arbeit, am selben Tag, im selben Projekt.
Der Unterschied liegt in dem, was beide als „Aufgabe" zählen.
Die 5-Minuten-Illusion
Sie denkt in Netto-Zeit. Die 5 Minuten, in denen sie tatsächlich eine Zeile ändert. Das ist für sie die Aufgabe.
Alles andere — Ticket lesen, sich in den Kontext eindenken, die richtige Codestelle finden, testen, committen, den Kommentar schreiben, auf das Deployment warten — zählt sie nicht mit. Nicht bewusst. Es passiert einfach nebenher, in ihrem Kopf gehört es nicht zur Aufgabe.
Als einer von uns (anne&thorsten.) mit dem Inhaber darüber sprach, war die Empfehlung simpel: „Setz Dich neben sie. Stopp jeden einzelnen Schritt. Wirklich jeden." Nicht als Kontrolle. Damit beide sehen, was wirklich passiert.
Die Hypothese: Allein das Erfassen des Tickets, das Telefonat mit dem Kunden und die Schätzung selbst kosten mehr Zeit als das, was sie überhaupt geschätzt hat. Die 30 Minuten sind schon verbraucht, bevor sie den Editor aufmacht.
Netto denken ist das teuerste Muster in kleinen Teams
Das Problem dieser Entwicklerin ist kein Einzelfall. Es ist ein strukturelles Muster in kleinen Software-Teams.
Entwickler lernen, in Aufgaben zu denken. User Story lesen, Code schreiben, fertig. Die Ausbildung trainiert Netto-Denken. Niemand bringt ihnen bei, den Brutto-Aufwand zu sehen — den gesamten Bogen von „Ticket kommt rein" bis „Kunde hat das Feature in Produktion".
Und weil der Brutto-Aufwand unsichtbar bleibt, passieren mehrere Dinge gleichzeitig:
Rechnungen sind zu niedrig. Der Kunde bekommt 20 Stunden Arbeit und zahlt für 2. Er gewöhnt sich an dieses Preisniveau. Wenn der Inhaber später realistisch kalkuliert, fühlt sich das für den Kunden wie eine Preiserhöhung an — obwohl es eine Korrektur ist.
Die Marge stimmt nicht. Der Inhaber sieht in der BWA, dass Umsatz und Aufwand nicht zusammenpassen. Er kann es nicht genau benennen. Es fühlt sich an, als würde „irgendwo Geld versickern". In Wahrheit wird es einfach nicht berechnet.
Das Team verliert das Vertrauen in eigene Schätzungen. Wenn jede Aufgabe „länger dauert als gedacht", entsteht das Gefühl, schlecht zu planen. Aber die Planung war nicht schlecht. Der Rahmen war falsch. Die Aufgabe war nie 30 Minuten. Sie war es nie.
Der Hebel liegt darin, die Definition von „Aufgabe" zu ändern. Solange ein Entwickler nur die Code-Zeit sieht, wird jede Schätzung zu niedrig sein. Egal wie erfahren er ist.
Das Experiment — Stoppuhr, jeden Schritt mitstoppen — macht das sichtbar. Einmal reicht. Die Entwicklerin in diesem Fall hat zum ersten Mal gesehen, dass 45 Minuten vergehen, bevor sie eine Zeile schreibt. Das war kein Vorwurf. Das war eine Erkenntnis, die sie selbst gemacht hat.
Wo verschwindet Deine Marge?
Nimm eine Aufgabe, die Dein Team letzte Woche abgeschlossen hat. Vergleiche die Schätzung mit dem tatsächlichen Aufwand. Dann frag: Hat die Schätzung den gesamten Bogen enthalten — vom Ticket bis zum Deployment? Oder nur die Code-Zeit?
Wenn die Antwort „nur die Code-Zeit" ist, weißt Du, wo Deine Marge steckt.
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Wie bringe ich meinem Team bei, Brutto-Aufwand statt Netto-Aufwand zu schätzen?
Am einfachsten mit einem einmaligen Experiment: Setz Dich neben einen Entwickler und stopp jeden Schritt von Ticket-Eingang bis Deployment. Wenn das Team selbst sieht, dass 45 Minuten vergehen, bevor eine Zeile Code entsteht, ändert sich die Perspektive von allein. Danach könnt ihr gemeinsam eine Checkliste bauen, die den gesamten Bogen abbildet.
Warum schätzen erfahrene Entwickler trotzdem zu niedrig?
Erfahrung verbessert die Schätzung der reinen Code-Arbeit. Aber das Drumherum — eindenken, Kontext herstellen, testen, deployen — wird unabhängig von der Erfahrung unterschätzt, weil es als „nicht zur Aufgabe gehörend" wahrgenommen wird. Das ist ein Rahmen-Problem.
Wie wirkt sich systematisches Unterschätzen auf die Kundenbeziehung aus?
Kunden gewöhnen sich an die zu niedrigen Preise. Wenn Du später realistisch kalkulierst, fühlt sich das für den Kunden wie eine Preiserhöhung an. Das erzeugt Widerstand, obwohl Du nur korrigierst, was von Anfang an falsch berechnet war.
Reicht es, einen Puffer auf die Schätzung draufzuschlagen?
Ein pauschaler Puffer kaschiert das Problem, löst es aber nicht. Dein Team versteht weiterhin nicht, wohin die Zeit geht. Besser: den echten Aufwand einmal sichtbar machen und dann die Schätzlogik anpassen — von „wie lange sitze ich am Code" zu „wie lange dauert es vom Ticket bis zum Deployment".