Verlässliche Aufwandschätzungen für Softwareprojekte: So kommen Sie zu Zahlen, denen Sie trauen können

Eine gute Aufwandschätzung für Software ist keine einzelne Zahl, die am Ende auf den Franken genau der Schlussrechnung entspricht. Sie ist eine Bandbreite, die auf klaren Informationen und ausgesprochenen Annahmen beruht und die Sie anpassen, sobald das Projekt Neues zeigt. Die Genauigkeit steigt, wenn Sie zuerst die Grundlagen in Ordnung bringen (Umfang, Anforderungen, Erfahrungswerte) und erst danach an der Rechenmethode feilen. Dieser Artikel erklärt, warum Schätzungen danebenliegen, welche Methoden sich lohnen und was Sie beim nächsten Projekt konkret tun können.

Kurz zusammengefasst

• Die meisten Schätzfehler beginnen mit schlechten Informationen: unklare, instabile oder falsche Anforderungen, nicht falsche Rechnerei.
• Keine einzelne Methode ist die beste. Wer mehrere unabhängige Schätzungen kombiniert, sie auf den eigenen Kontext zuschneidet und eigene Erfahrungswerte nutzt, liegt verlässlicher.
• Nennen Sie Bandbreiten, machen Sie Annahmen sichtbar und schätzen Sie neu, sobald die Anforderungen klarer werden.
• Halten Sie nach jedem Projekt den tatsächlichen Aufwand fest. Die eigene Projekthistorie ist die günstigste Verbesserung, die es gibt.
• Eine erfahrene Person, die vom ersten Gespräch bis zur Übergabe am Projekt bleibt, beseitigt eine häufige Fehlerquelle.

Was «genau» bei einer Softwareschätzung wirklich bedeutet

Viele Gründer:innen wollen früh eine fixe Zahl und verstehen sie als Versprechen. Steve McConnell, Autor eines viel gelesenen Buchs über Aufwandschätzung in der Softwareentwicklung, sieht das anders: Schätzen ist für ihn primarily a test of whether project targets are realistic and controllable, also in erster Linie eine Prüfung, ob die Projektziele realistisch und steuerbar sind, und keine Garantie, dass das Ergebnis einer frühen Zahl entspricht.

Er macht noch einen Punkt, den die meisten Auftraggebenden übersehen. Präzision auf dem Papier bringt wenig, wenn sich die Annahmen darunter verschieben. In seinen Worten ist eine auf ±5 % genaue Schätzung nutzlos, wenn sich die primarily a test of whether project targets are realistic and controllable. Eine saubere Tabelle rettet kein vages Briefing.

Wenn Sie die Qualität einer Schätzung beurteilen, stellen Sie deshalb drei Fragen:

1. Ist der Umfang so festgehalten, dass zwei Personen ihn gleich verstehen?
2. Zeigt die Schätzung eine Bandbreite und die Annahmen dahinter?
3. Gibt es einen Plan, sie laufend anzupassen?

Wenn Sie alle drei Fragen mit Ja beantworten, ist die Zahl vermutlich vertrauenswürdiger als ein selbstbewusster Betrag ohne jede Begründung.

Warum verlässliche Schätzungen zählen

Für ein Startup bestimmt die Schätzung die Reichweite der Finanzierung, das Zeitfenster für den Start und das Gespräch mit Investor:innen. Für ein etabliertes Unternehmen entscheidet sie, ob ein Projekt überhaupt bewilligt wird. Die Planungsliteratur für agile Teams zählt auf, was verlässliche Schätzungen ermöglichen: reliable delivery, sensible prioritization and trade-offs, trust, a sustainable pace for developers, and fewer quality problems, also verlässliche Lieferung, sinnvolle Priorisierung und Abwägungen, Vertrauen, ein nachhaltiges Tempo für Entwickler:innen und weniger Qualitätsprobleme.

Die letzten beiden Punkte gehen leicht vergessen. Sind Schätzungen zu tief, nimmt das Team Abkürzungen, um den Termin zu halten, und Sie bezahlen später mit Fehlern und Nacharbeit. Sind sie zu hoch, starten gute Projekte gar nie. In beiden Fällen zeigen sich die Kosten einer schlechten Schätzung selten an dem Tag, an dem sie entsteht.

Warum Softwareschätzungen danebenliegen

Eine systematische Literaturübersicht von 2024 in ACM Computing Surveys ordnet die Gründe für ungenaue agile Aufwandschätzungen fünf Kategorien zu: information quality, the team, estimation practice, project management, and business influences, also Informationsqualität, Team, Schätzpraxis, Projektleitung und geschäftliche Einflüsse. Dieselbe Übersicht nennt eine besonders häufige Einzelursache: schlechte Informationen, also unklare, instabile oder fehlerhafte Grundlagen.

So sieht das in der Praxis aus.

Unklare oder wechselnde Informationen

«Ein Marktplatz mit Zahlungen» kann drei Wochen Arbeit bedeuten oder sechs Monate, je nachdem, wie viele Verkäufertypen, Auszahlungsregeln und Währungen es gibt. Ist das Briefing zum Zeitpunkt der Schätzung vage, ist die Schätzung eine Vermutung im Kleid einer Zahl. Verschieben sich die Anforderungen mitten im Projekt, hat die ursprüngliche Zahl ein anderes Produkt gemessen.

Das Team und seine Erfahrung

Eine Studie von 2007 zu 43 internen Softwareprojekten zeigte, dass higher project uncertainty went with larger effort-estimation errors: Je höher die Unsicherheit im Projekt, desto grösser die Fehler bei der Aufwandschätzung. Dieselbe Studie brachte stärkere Schätz- und Entwicklungsprozesse, eine bessere Steuerung der Schätzung und erfahrenere Schätzende mit kleineren Fehlern bei der Dauer in Verbindung. Es zählt also, wer schätzt, und wie oft diese Person es schon getan hat.

Die Schätzpraxis

Aus dem Gedächtnis schätzen, allein schätzen oder einmal schätzen und nie mehr hinschauen: All das senkt die Genauigkeit. Vergessene Tätigkeiten sind ein Klassiker: Testing, Deployment, Datenmigration, Barrierefreiheit, Inhaltspflege, Übergabedokumentation. Sie sind niemandem präsent, wenn die Zahl entsteht.

Projektleitung und geschäftlicher Druck

Ein Zieltermin, der durch einen Launch-Anlass oder ein Investorentreffen gesetzt ist, macht aus einer Schätzung still und leise eine Verhandlung. Die Zahl schrumpft auf den Termin, die Arbeit aber nicht.

Wessen Erklärung glauben Sie?

Eine Studie von 2004 in IEEE Transactions on Software Engineering fand, dass die wahrgenommenen Ursachen von Schätzfehlern depend on the respondent’s role, how information is collected, and how it is analyzed, also von der Rolle der befragten Person, von der Art der Erhebung und von der Auswertung abhängen. Eine Darstellung allein aus Sicht der Projektleitung ist deshalb einseitig. Die praktische Lehre: Hören Sie bei einer Nachbetrachtung Entwickler:innen, Product Owner und die Kundenseite an, nicht nur die Person, die den Zeitplan geführt hat.

Schätzmethoden für Softwareprojekte

Softwareteams nutzen eine Handvoll Methodenfamilien. Eine catalog of estimation approaches beschreibt sie ungefähr so.

Methode	So funktioniert sie	Am besten geeignet, wenn
Expertenurteil (inklusive Planning Poker)	Erfahrene Personen denken die Arbeit durch und nennen Zahlen	Der Umfang klein oder vertraut ist und Sie Leute haben, die Ähnliches gebaut haben
Bottom-up (Arbeitsstrukturplan)	Das Projekt in Aufgaben zerlegen, jede schätzen, alles addieren	Die Anforderungen detailliert genug sind, um Aufgaben aufzulisten
Top-down	Von einem Gesamtbudget oder einer Gesamtgrösse ausgehen und aufteilen	Sehr früh, wenn Sie nur eine Grössenordnung brauchen
Analogie	Vergleich mit abgeschlossenen Projekten	Sie vergleichbare frühere Projekte mit erfassten Ist-Werten haben
Gewichtete Funktionszählung	Funktionen zählen und nach Komplexität gewichten	Sie ein wiederholbares Mass für die Grösse brauchen
Parametrische Modelle (zum Beispiel COCOMO)	Eine Kostenbeziehung an Erfahrungsdaten anpassen	Sie über einen soliden Datenbestand und einen stabilen Prozess verfügen

Planning Poker und warum Unabhängigkeit hilft

Der Forscher Magne Jørgensen hält Delphi-artige Verfahren wie Planning Poker für nützlich, weil people reveal independently formed estimates at the same moment, alle also ihre unabhängig gebildete Schätzung im selben Moment aufdecken und sich niemand an der lautesten Stimme orientiert. Die anschliessende Diskussion bringt dann Tätigkeiten ans Licht, die Einzelne vergessen haben. Wenn zwei Entwickler:innen drei Tage sagen und eine dritte Person zehn, hat diese dritte Person wahrscheinlich etwas gesehen, das den anderen entgangen ist. Diese Uneinigkeit ist das wertvollste Ergebnis der Runde.

Bottom-up gegen Top-down

Bottom-up liefert mehr Detail, braucht aber einen stabilen Umfang. Top-down ist schnell, aber grob. Eine sinnvolle Reihenfolge: Top-down im allerersten Gespräch («das ist ein sechsstelliges CHF-Projekt, kein fünfstelliges»), dann Bottom-up, sobald aus der Analysephase ein echtes Backlog entstanden ist.

Analogie und parametrische Modelle

Beide hängen von Erfahrungswerten ab. Wenn Ihre letzten vier Webanwendungen zwischen 11 und 16 Wochen gedauert haben, ist das ein besserer Anker für die fünfte als jede allgemeine Formel. Parametrische Modelle formalisieren dieselbe Idee, brauchen aber Daten, die Sie vielleicht noch nicht haben.

Welche Methode ist die verlässlichste?

Keine, für sich allein. Jørgensen hält fest, dass es keine universell beste Methode zur Aufwandschätzung gibt, weil die Zusammenhänge zwischen Grösse, Aufwand und Kostentreibern people reveal independently formed estimates at the same moment, also je nach Kontext variieren und die Methoden auf Organisation und Projekt zugeschnitten werden sollten. Verlässlicher wird es in der Regel, wenn Sie passende Erfahrungsdaten, firmeneigene Checklisten und mehrere unabhängige, kombinierte Schätzungen nutzen.

Dieselbe Übersicht zu Schätzansätzen empfiehlt, catalog of estimation approaches: nach Möglichkeit mehrere Methoden kombinieren, die Streuung ausweisen statt im Mittelwert verstecken, eine Bandbreite angeben, neu schätzen, sobald die Anforderungen klarer werden, und die Ist-Werte erfassen.

Ein praktisches Rezept für ein kleines Team:

1. Lassen Sie zwei oder drei Personen unabhängig schätzen.
2. Vergleichen Sie die Zahlen und besprechen Sie die grössten Abweichungen.
3. Prüfen Sie gegen ein früheres Projekt ähnlichen Zuschnitts.
4. Weisen Sie einen tiefen, einen wahrscheinlichen und einen hohen Wert aus, nicht einen einzigen.
5. Halten Sie fest, welche Annahmen die Bandbreite verschieben würden.

Der tiefe, wahrscheinliche und hohe Wert funktioniert zugleich als einfache Form der Drei-Punkt-Schätzung, einer verbreiteten Methode, die optimistische, pessimistische und wahrscheinlichste Ergebnisse gewichtet.

Schritt für Schritt zu genaueren Schätzungen

1. Verbessern Sie die Informationen, bevor Sie schätzen

Die ACM-Übersicht empfiehlt, die Qualität der verfügbaren Informationen zu erhöhen, die INVEST-Kriterien für User Storys anzuwenden, Storys aus Sicht der Entwicklung zu schreiben, Checklisten zu nutzen, die Auswirkung von Änderungen zu analysieren und Unsicherheit ausdrücklich zu benennen. INVEST steht für Storys, die unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar sind. Scheitert eine Story am «schätzbar», lautet die ehrliche Schätzung: «Wir brauchen einen kurzen Spike, um das herauszufinden.» Die Übersicht ist information quality, the team, estimation practice, project management, and business influences für alle, die es genauer wissen wollen.

Sie weist zudem auf ein Ungleichgewicht in der Forschung hin: Von 75 vorgeschlagenen Ansätzen zielen 66 auf die Aufwandschätzung selbst, und nur neun nehmen sich der Informationsqualität an. Die meisten Werkzeuge bekämpfen das Symptom. Ihr grösster Hebel liegt bei der Ursache.

2. Halten Sie den Umfang fest und steuern Sie Änderungen

Die internationale Norm zur Planung von Softwareprojekten, ISO/IEC/IEEE 16326:2019, versteht Planung als fortlaufend: Pläne legen Umfang, Tätigkeiten, Termine, Ressourcen, Zuständigkeiten und Kriterien fest und werden regularly revised, also regelmässig überarbeitet. Ihre Leitlinien verlangen ausserdem, dass Anspruchsgruppen bei der Definition der Anforderungen einbezogen werden, dass eine Anforderungsbasis besteht, dass die Arbeitsabfolge den ganzen Umfang abdeckt und dass Änderungen an Umfang und Anforderungen dokumentiert bewertet werden.

Im Klartext: Einigen Sie sich darauf, was dazugehört, halten Sie es schriftlich fest, und wenn sich etwas ändert, sagen Sie vor Arbeitsbeginn, was das für Kosten und Termine bedeutet. Diese eine Gewohnheit verhindert die meisten Diskussionen über ausufernden Projektumfang.

3. Nutzen Sie eine Checkliste aus Ihren eigenen Projekten

Jørgensen berichtet, dass passende Erfahrungsdaten und firmeneigene Checklisten die Genauigkeit verbessern, indem sie people reveal independently formed estimates at the same moment, also vergessene Tätigkeiten reduzieren, Erfahrung wiederverwendbar machen und realistische Reserven stützen. Eine Startcheckliste für ein Webprojekt könnte enthalten:

• Anmeldung, Rollen und Berechtigungen
• E-Mail- und Benachrichtigungsabläufe
• Sonderfälle bei Zahlung und Rechnungsstellung
• Anbindungen an CRM, ERP oder Shopsysteme
• Datenübernahme aus dem Altsystem
• Hosting, Überwachung und Sicherungen
• Barrierefreiheit und Browsertests
• Inhaltspflege und Übersetzung (in der Schweiz relevant, wo deutsche, französische, italienische und englische Versionen üblich sind)
• Dokumentation und Übergabe

Jedes Mal, wenn Sie eine Aufgabe überrascht, ergänzen Sie die Liste.

4. Erfassen Sie Ist-Werte und führen Sie ehrliche Retrospektiven

Schätzkompetenz wächst nur mit Rückmeldung. Vergleichen Sie nach jedem Projekt Schätzung und Ist-Wert nach Aufgabentyp, nicht nur in der Summe. Ein Projekt, das im Budget liegt, kann eine Überschreitung von 60 % bei den Schnittstellen verbergen, ausgeglichen durch einen Überschuss beim Design. Folgen Sie für die Nachbetrachtung dem Rat der Studie von 2004 und kombinieren Sie depend on the respondent’s role, how information is collected, and how it is analyzed, also Gespräche mit Beteiligten aus allen relevanten Rollen, Erfahrungsberichte aus abgeschlossenen Projekten und die statistische Auswertung von Projektmerkmalen.

5. Wählen Sie Schätzende nach Erfahrung aus

Die Studie von 2007 legt nahe, Schätzende danach auszuwählen, wie viele Projekte sie geleitet haben, in eine detaillierte Planung zu investieren und Unsicherheit einzubeziehen, wenn Erwartungen gesteuert werden. Wenn Sie ein Studio beauftragen, wird daraus eine einfache Frage: Wer erstellt die Schätzung, und ist dieselbe Person noch da, wenn die Arbeit erledigt wird?

Ein durchgerechnetes Beispiel: die Schätzung für ein Kundenportal

Stellen Sie sich vor, ein Schweizer KMU möchte ein Kundenportal, das an sein ERP angebunden ist. So sieht das beschriebene Vorgehen dann aus.

Woche 0, grobe Bandbreite. In Analogie zu ähnlichen Portalen sagt das Team, die Arbeit liege zwischen einem kleinen und einem mittelgrossen Vorhaben. Das ist eine Top-down-Grössenordnung und wird auch so bezeichnet.

Analysephase. In einer kurzen, bezahlten Analysephase listet das Team die Benutzerrollen, die Daten im ERP, die Freigabeabläufe und die Auswertungen auf. Jeder Punkt wird zu einer Story, und jede Story, die nicht schätzbar ist, erhält einen zeitlich begrenzten Spike.

Unabhängige Schätzungen. Drei Entwickler:innen schätzen getrennt. Anmeldung und Rollen: 4, 5 und 5 Tage, hier sind sie sich einig. ERP-Synchronisation: 6, 12 und 20 Tage. Die Abweichung ist der Befund. Nach der Diskussion zeigt sich: Das ERP hat keine stabile API für Rechnungen, und eine Person hatte eine Umgehungslösung eingerechnet. Die Bandbreite für diesen Punkt bleibt weit, und die Annahme wird festgehalten: «Der ERP-Anbieter stellt bis zu einem festgelegten Datum einen dokumentierten Endpunkt für Rechnungen bereit.»

Bandbreite und Annahmen. Die Offerte nennt tiefe, wahrscheinliche und hohe Gesamtwerte, die fünf Annahmen, die diese am ehesten verschieben, und das Datum, an dem die Schätzung überprüft wird.

Neu schätzen und erfassen. Nach der ersten Veröffentlichung aktualisiert das Team die Bandbreite, hält die tatsächlichen Tage pro Punkt fest und ergänzt die Checkliste um «Risiko Anbieter-API».

Nichts davon ist exotisch. Es ist die Disziplin, Unsicherheit früh sichtbar zu machen, solange sie günstig auszuräumen ist.

Was Sie einen Entwicklungspartner zu seinen Schätzungen fragen sollten

Wenn Sie Software bei einem externen Team einkaufen, hängt die Treffsicherheit der Schätzung auch von dessen Arbeitsweise ab. Diese Fragen lohnen sich:

• Wer erstellt die Schätzung, und wer baut das Produkt?
• Ist die Schätzung eine Bandbreite, und auf welchen Annahmen beruht sie?
• Was geschieht mit Preis und Zeitplan, wenn sich Anforderungen ändern?
• Wie gehen Sie mit Dingen um, die noch niemand schätzen kann, etwa einem undokumentierten Fremdsystem?
• Kann ich sehen, wie frühere Schätzungen im Vergleich zu den Ist-Werten ausgefallen sind?
• Was gehört mir bei der Übergabe, und könnte ein anderes Team übernehmen?

Vage Antworten darauf sind ein deutlicheres Warnzeichen als ein hoher Preis.

Wie wir das bei Ampersand handhaben

Ampersand ist ein kleines Zürcher Studio, und jedes Projekt wird von der ersten Beratung bis zur Übergabe von erfahrenen Entwickler:innen geführt. Genau diese Kontinuität hält eine Schätzung ehrlich: Wer den Umfang festgelegt hat, steht auch dafür gerade, Anforderungen werden nicht auf halbem Weg neu geschrieben, und das Team wechselt Ihnen nicht unter den Händen. Wir arbeiten für Kundschaft aus verschiedenen Branchen, darunter UBS und die Stadt Lugano, und setzen auf Transparenz und Unabhängigkeit statt auf Abhängigkeit vom Anbieter.

Wenn Sie ein Projekt haben und vor einer Zusage eine realistische Bandbreite möchten, sehen Sie auf der Preisseite, wie unsere Zusammenarbeit aufgebaut ist: von Websites, Apps, Plattformen und Schnittstellen über KI-Automatisierung bis zu Migrationen und Beratungspaketen. Zwei veröffentlichte Monatspreise geben ein Gefühl für die Grössenordnung laufender Arbeit: Das Beratungspaket Guidance kostet CHF 799 pro Monat, das Supportpaket Run & monitor CHF 750 pro Monat. Projekte werden einzeln kalkuliert, und genau darum beginnen wir mit den Fragen oben. Sie können sich auch unsere bisherigen Arbeiten ansehen, um zu beurteilen, welche Art von Projekten wir übernehmen.

Häufige Fehler, die Sie vermeiden sollten

• Eine Bandbreite als Schwäche sehen. Eine einzelne Zahl wirkt selbstsicher, verbirgt aber die Streuung. Die Streuung auszuweisen ist ehrlicher und nützlicher.
• Uneinigkeit wegmitteln. Wenn Schätzungen weit auseinanderliegen, fehlen Informationen. Klären Sie das, statt die Differenz zu halbieren.
• Nur einmal schätzen. Planung ist fortlaufend, also schätzen Sie neu, sobald die Anforderungen klarer werden.
• Die unscheinbare Arbeit auslassen. Deployment, Migration, Testing und Übergabe sind meist dort, wo die vergessenen Stunden stecken.
• Den Termin die Zahl bestimmen lassen. Steht das Startdatum fest, passen Sie den Umfang an, nicht die Schätzung.
• Den Kreis nie schliessen. Ohne erfasste Ist-Werte beginnt jedes Projekt bei null.

Häufige Fragen

Was ist ein häufiger Grund dafür, dass Schätzungen für Softwareprojekte danebenliegen?

Schlechte Informationen stehen weit vorne: Anforderungen, die zum Zeitpunkt der Schätzung unklar, instabil oder schlicht falsch sind. Eine systematische Übersicht von 2024 zur agilen Aufwandschätzung zählt die Informationsqualität zu fünf wiederkehrenden Ursachenkategorien. Das Briefing zu verbessern bringt meist mehr, als die Formel zu verbessern.

Welche Schätzmethode ist die verlässlichste?

Keine einzelne Methode gewinnt überall. Forschung von Simula spricht dafür, die Methoden auf den eigenen Kontext zuzuschneiden und unabhängige Schätzungen mit Erfahrungsdaten und Checklisten zu kombinieren. In der Praxis heisst das: zwei oder drei Personen schätzen getrennt, Abgleich mit einem ähnlichen früheren Projekt und eine ausgewiesene Bandbreite.

Wie genau sollte eine frühe Schätzung sein?

Frühe Schätzungen sollten weit gefasst sein, weil man noch wenig weiss. Werden die Anforderungen klarer, sollte sich die Bandbreite verengen, und Sie sollten in jeder Phase neu schätzen. Eine Schätzung, die eng bleibt, während sich die Annahmen ändern, ist ein Warnzeichen, kein Trost.

Wie wird ein kleines Team besser im Schätzen?

Halten Sie den tatsächlichen Aufwand für jedes Projekt nach Aufgabentyp fest und bauen Sie aus den Überraschungen eine Checkliste. Führen Sie kurze Retrospektiven mit Entwickler:innen, Product Ownern und der Kundenseite durch. Nach einer Handvoll Projekten schlägt Ihre eigene Historie jede allgemeine Faustregel.

Quellen

• primarily a test of whether project targets are realistic and controllable
• reliable delivery, sensible prioritization and trade-offs, trust, a sustainable pace for developers, and fewer quality problems
• information quality, the team, estimation practice, project management, and business influences
• higher project uncertainty went with larger effort-estimation errors
• depend on the respondent’s role, how information is collected, and how it is analyzed
• people reveal independently formed estimates at the same moment
• catalog of estimation approaches
• regularly revised