Software-Aufwände präzise schätzen

Wir freuen uns, wertvolle Einblicke aus unserem letzten Cudos Trail Workshop zu teilen: Gemeinsam mit Christian Ewald (Senior Software Architekt bei der TEQABLE AG und geschätzter Ex-Kollege) sowie unserem CEO Reto Bättig haben unsere Junior Software Engineers die Kunst der präzisen Aufwandsschätzung vertieft. Jesper hat die wichtigsten Erkenntnisse für uns zusammengefasst und teilt diese nun hier mit euch.

Aufwandsschätzung in Softwareprojekten

Böse Zungen behaupten, dass Aufwandsschätzungen in IT-Projekten der Vergangenheit angehören. Doch das Schätzen bleibt ein zentraler Bestandteil von SCRUM und gehört zum bewährten Vorgehen in modernen Softwareprojekten.

Bei einem Fixpreis-Projekt mit entsprechendem Werkvertrag ist sofort klar, wofür wir die Schätzung benötigen: Sie wirkt sich direkt auf den Preis aus. Fällt die Schätzung zu hoch aus, sind wir nicht marktfähig. Fällt sie zu tief aus, sinkt die Wirtschaftlichkeit.

Gilt das auch für agile Projekte?

Warum wir Aufwandsschätzungen auch in agilen Projekten brauchen

Auch in agilen Projekten spielen Schätzungen eine zentrale Rolle. Sie bieten der Kundschaft und dem Entwicklungsteam wertvolle Orientierung.

Für Auftraggebende ist es wichtig zu wissen, wie teuer ein Projekt ungefähr wird, um über die Durchführung zu entscheiden. Weiterhin hilft es, einzelne Features zu priorisieren oder wegzulassen. Schätzungen zeigen zudem den Fortschritt: Gibt es Probleme? Können wichtige Termine eingehalten werden (Estimated Time of Arrival)?

Zudem bieten Schätzungen Transparenz und die Möglichkeit, Verzögerungen frühzeitig zu identifizieren. Damit dienen sie als fundierte Diskussionsgrundlage. Ein weiterer Vorteil: Wir erkennen Risiken oft schon während der Aufwandsschätzung. Die meisten Gründe für Schätzungen lassen sich sowohl auf Fixpreis- als auch auf agile Projekte beziehen.

Die fünf Schätzgrundsätze

1. Schätzen ist ein Muskel, der trainiert werden kann.
2. Schätzungen sind falsch.
3. Schätze nie alleine.
4. Schätze nie spontan.
5. Denke in Bereichen.

Die  Schätzaufgaben von codinghorror zeigen einige der 5 Schätz-Grundsätze sehr gut.

Schätzverfahren für Fixpreis-Projekte

Bottom-up-Verfahren

Hierbei zerlegen wir grosse Aufgaben in kleinere Teilaufgaben, bis Vergleichswerte vorliegen. Anschliessend summieren wir die Werte auf. Bei Unklarheiten treffen wir Annahmen, die wir vertraglich festhalten.

Top-down-Verfahren

Für dieses Verfahren nutzen wir die Erfahrung aus ähnlichen Aufgaben. Mehrere Referenzprojekte sind dabei besser als ein einzelnes. Wir ordnen das Projekt hinsichtlich Aufwand und Komplexität zwischen den Referenzen ein. Ein Vorteil: Wir können bei den Referenzen nicht nur den tatsächlichen, sondern auch den geschätzten Aufwand sowie den Projektverlauf einsehen.

Function Points

Bei dieser Methode ordnen wir verschiedene Standard-Eigenschaften der Aufgabe nach Komplexität ein und multiplizieren sie mit einer Matrix aus Erfahrungswerten.

Auflistung der Eigenschaften: Wie viele Schnittstellen und GUI-Seiten werden für das Projekt benötigt? Wie lässt sich der jeweilige Realisierungsaufwand einordnen – einfach, mittel oder komplex?

Datenbank mit Erfahrungswerten: Wie viele Stunden beispielsweise für die Implementierung einer einfachen Schnittstelle veranschlagt werden. 

Schätzung: Die Schätzung ergibt sich aus der Multiplikation der Anzahl und Komplexität der Anforderungen mit den entsprechenden Erfahrungswerten in Stunden.

Verhandeln mit Kunden

Ist die Kundschaft mit der Preis- oder Terminschätzung unzufrieden, bedeutet das nicht, dass der Auftrag verloren ist. Wichtig ist, dass wir erklären, wie die Schätzung zustande kommt.

Wenn ein fixes Kostendach oder ein fixer Release-Termin besteht:

• Besprechen, ob wir die Kosten erhöhen oder den Termin schieben können.
• Den Lieferumfang reduzieren.
• Eine Teillieferung (MVP) umsetzen, welche die Grundfunktionalität abdeckt.
• Mehr Leute auf das Projekt setzen (führt zu Mehrkosten und Koordinationsaufwand).

Wichtig: Wir korrigieren Schätzungen nie willkürlich nach unten. Das ist unprofessionell und gibt dem Kunden das Gefühl, dass wir unnötige Reserven eingerechnet haben. Dies ist aber gemäss unserem Prozess nicht der Fall, wir möchten bei den Schätzungen einen möglichst guten Erwartungswert erreichen. Um eine Schätzung greifbar zu machen, bilden wir möglichst kleine Pakete. So bieten die einzelnen Punkte weniger Angriffsfläche für Diskussionen.

Der Cudos-Schätzprozess für Fixpreisprojekte

Die Projektleitung erstellt ein Schätzteam aus mindestens zwei Personen, erklärt die Aufgabe und händigt alle Unterlagen (Anforderungs- und Konzeptdokumente) aus.

Das Schätzteam klärt offene Fragen. Jede Person erstellt für sich eine Task-Aufteilung und schätzt das Projekt ab (Bottom-up). Cudos nutzt hierfür ein einheitliches Formular. Zusätzlich führen wir ein Reasoning mit anderen Projekten durch (Top-down). Danach konsolidieren wir die Werte. Das Team muss sich einig sein.

Cudos-Schätzformular

Das Formular beinhaltet bereits die wichtigsten Annahmen und wird individuell ergänzt. Es enthält Reserven für Projektplanung und Garantie. Zudem berechnen wir eine "Elapsed-Time"-Schätzung: Geschätzte Tage / Anzahl Mitarbeitende * 1.4. Der Faktor 1.4 berücksichtigt Verzögerungen durch Ferien oder Krankheit. Eine Checkliste stellt sicher, dass keine Details vergessen werden.

Während des Projekts

Das Controlling zeigt monatlich den aktuellen Stand. Dies führt zu ständiger Anpassung der Schätzung, sodass wir schnell auf Schwierigkeiten reagieren können.

💡 Profitipp: In einem Projekt benötigten wir eine kundenspezifische Library zur Ansteuerung von Testhardware. Die Einbindung dauerte fünfmal länger als ursprünglich geschätzt, weil die Qualität der Library nicht gut genug war. Da wir dies im Vorfeld als Risiko identifiziert haben und die Schätzung explizit unter der Annahme einer guten Qualität gemacht haben, konnten wir den Mehraufwand unserem Kunden problemlos verrechnen. Gleichzeitig konnten wir durch frühes realisieren des Problemes gemeinsam mit dem Kunden gewisse Leistungen wegoptimieren, so dass die Mehrkosten für den Kunden trotzdem nur geringfügig gestiegen sind.

Agile Schätzverfahren

Für agile Projekte sind Schätzungen essenziell. Bei SCRUM ist das Schätzen fest integriert. Das Team schätzt regelmässig Aufgaben, wobei sich die Grundsätze widerspiegeln:

1. Wir schätzen mindestens einmal pro Sprint (Muskel-Training).
2. Wir nutzen virtuelle Einheiten (Story Points).
3. Wir schätzen immer im Team.
4. Wir nutzen Schätz-Meetings.
5. Wir nutzen die Fibonacci-Reihe (Denken in Bereichen).

Wir schätzen Produkt-Backlog und Sprint-Backlog getrennt. Im Produkt-Backlog nutzen wir Story Points, um die Velocity zu messen. Im Sprint-Backlog arbeiten wir mit konkreten Stunden für den Burndown-Chart. Der Produkt-Backlog sollte immer genug Stories enthalten, um neue Aufgaben relativ dazu schätzen zu können.

Schätzmethoden

Planning Poker

Für das Schätzen im Sprint-Backlog ist Planning Poker ideal. Jede Story wird diskutiert und anschliessend vom gesamten Team geschätzt.

Bucket-System

Muss das Team sehr viele Stories (z. B. 100) schätzen, bietet sich das Bucket-System an: Wir legen für jeden Wert der Fibonacci-Reihe einen "Bucket" (Eimer/Bereich) an. Alle Items werden auf die Beteiligten verteilt. Jede Person sortiert ihre Items unabhängig in die Buckets ein. Anschliessend prüfen alle Teammitglieder die Einordnung und markieren Unstimmigkeiten. Diese besprechen wir gemeinsam. So vermeiden wir langwierige Diskussionen für Items, die erst später relevant werden.

Fazit

Auch in agilen Projekten sind Aufwandsschätzungen unverzichtbar. Sie bieten Orientierung, schaffen Transparenz und helfen, Risiken frühzeitig zu erkennen. Regelmässiges, gemeinsames Schätzen fördert das Verständnis und sorgt für eine realistische Planung – egal ob klassisch oder agil.