Aufwandsschätzung mit T-Shirt-Größen (T-shirt sizing)

Die Aufwandsschätzung in Softwareprojekten ist in mehrfacher Hinsicht ein problematisches Thema.

• Bei Festpreisprojekten hängt von der Qualität der Aufwandsschätzung der wirtschaftliche Erfolg und langfristig die Existenz des Auftragnehmers ab.
• Andererseits sind Änderungen an den Anforderungen in der agilen Softwareentwicklung ein zentraler Bestandteil von Projekten ("Embrace Change"), womit exakte Pläne meist nur eine sehr kurze Lebensdauer haben.
• Eine genaue Aufwandsschätzung erfordert unterschiedlichste Kompetenzen - zum einen Projektüberblick und Projektmanagement-Erfahrung, zum anderen Detailwissen in den zu schätzenden Tätigkeiten. Dadurch werden häufig Entwicklerkapazitäten in der Aufwandsschätzung gebunden und die Entwickler von ihrer eigentlichen Aufgabe abgelenkt.
• Es gibt keinen eindeutigen Zusammenhang zwischen Schätzaufwand und Vorhersagegenauigkeit – insbesondere bei agilen Projekten, in denen nicht auf Basis einer verbindlichen, vollständigen Spezifikation geschätzt wird. Mehr Schätzaufwand bedeutet also nicht unbedingt eine zutreffendere Schätzung.
• Wie kürzlich in unserem Beitrag Agile Softwareentwicklung in kleinen Projekten beschrieben, ist Schätzaufwand für später nicht beauftragte Features verschwendet. Schätzungen sind aber für den Auftraggeber unerlässlich, um über die Wirtschaftlichkeit eines Features zu entscheiden.

Unsere Anforderungen an ein Schätzverfahren

Auf Basis dieser Voraussetzungen haben wir ein Schätzverfahren gesucht, das

• dem Auftraggeber eine gute Einschätzung der Wirtschaftlichkeit zu einem sehr frühen Zeitpunkt ermöglicht und zugleich
• so wenig Schätzaufwand wie möglich verursacht und
• eine ausreichende Vorhersagegenauigkeit bietet.

Im Buch Software Estimation (McConnell 2006, S. 145) sind wir auf das T-Shirt-Sizing-Verfahren gestoßen, das genau dies zum Ziel hat. Die Kernidee: Features werden vom Entwicklungsteam mit einer T-Shirt-Größe versehen, die den Entwicklungsaufwand größenordnungsmäßig beschreibt (XS, S, M, L, ...). Parallel kann der Auftraggeber seinen erwarteten wirtschaftlichen Nutzen in T-Shirt-Größen beschreiben und dann anhand einer Matrix entscheiden, ob die Implementierung eines Features wirtschaftlich ist.

T-Shirt-Größen bei webfactory

Wir haben bei der webfactory den ersten Teil des T-Shirt-Sizing-Verfahrens, also die eigentliche Aufwandsschätzung, in den letzten Jahren für unsere Kunden operationalisiert und sukzessive verfeinert.

Zunächst haben wir die T-Shirt-Größen definiert und mit einer konkreten Aufwandsskala versehen. Dabei verdoppelt sich der Aufwand jeder T-Shirt-Größe gegenüber der vorherigen Stufe. Für den Aufwand einer einzelnen T-Shirt-Größe haben wir einen Nennwert definiert sowie eine Best Case-/Worst Case-Spanne. Die Spanne ist bewusst groß gewählt - den Best Case haben wir auf 50% des Nennwerts festgelegt, den Worst Case auf 200%.

Damit kommen wir zu folgender Größentabelle:

Nutzung der T-Shirt-Größen

Die T-Shirt-Größen können wir anwenden, wann immer wir über den Aufwand eines Features, Teilfeatures oder auch eines gesamten Projektes sprechen.

Ein großer Vorteil der Angabe einer T-Shirt-Größe gegenüber einem Schätzwert in Personentagen ist, dass die T-Shirt-Größe explizit Unschärfe beinhaltet – also klar ist, dass es sich nicht um eine präzise Aussage handelt. Während die Angaben "1 Personentag" oder "1000 €" als exakter Aufwand interpretiert werden könnten, ist bei "T-Shirt-Größe S" immer implizit klar, dass der Aufwand ungefähr bei einem Personentag liegt, aber im Worst Case auch 2 Personentage oder im Best Case einen halben Personentag betragen könnte.

Mit T-Shirt-Größen kann man einfach rechnen, da jeweils zwei Elemente einer Größe einem Element der nächsthöheren Größe entsprechen: 2x S = 1x M, 2x M = 1x L usf. Auch die Intervallgrenzen für Best Case und Worst Case bleiben bei der Addition erhalten.

Auf dieser Basis lässt sich sehr einfach eine Bottom-up-Schätzung durchführen. Bewährt hat sich bei uns unter anderem folgendes Verfahren:

• Zunächst definieren wir gemeinsam mit dem Auftraggeber Features. Ein Feature ist jeweils ein Teilaspekt der Software, der für sich genommen entwickelt und gelauncht werden kann und einen Wert für das System darstellt.
• Wenn das Feature hinreichend gut verstanden ist, erstellen wir eine Liste der Teilaufgaben für dieses Feature (z. B. Detailkonzeption; Datenbank, Objektmodell und CMS anpassen; Frontend umsetzen und gestalten; Businesslogik implementieren).
• Jede Teilaufgabe wird mit einer T-Shirt-Größe versehen.
• Die Summe der T-Shirt-Größen für die Teilaufgaben ergibt eine T-Shirt-Größe für das Feature (z. B. 2x XS, 1x S + 1x M = L)

Ermittlung eines Gesamtbudgets

Auf der Basis der T-Shirt-Größen für die einzelnen Features können wir ein Gesamtbudget für das Projekt empfehlen.

Hierbei gehen wir davon aus, dass Schätzfehler einzelner Features sich bis zu einem gewissen Grad ausmitteln, da der tatsächliche Aufwand für manche Features über, für andere unter dem Nennwert des Features liegen wird.

In der Praxis hat sich ein Sicherheitspuffer von 25% auf den Nennwert der T-Shirt-Größen bewährt, der zum Abfangen von Aufwandsüberschreitungen ebenso wie für ungeplante Aufwände dient. Dies entspricht übrigens genau dem Mittelwert aus Best Case- und Worst Case-Aufwand.

Erfahrungen mit dem Verfahren

Zwei Jahre T-Shirt-Sizing liegen hinter uns und wir können folgendes Zwischenfazit ziehen:

• T-Shirt-Größen lassen sich sehr schnell schätzen
• Der tatsächliche Aufwand für ein Feature liegt nur in den seltensten Fällen außerhalb der für die T-Shirt-Größe festgelegten Spanne
• Für die meisten Anwendungen ist die Angabe einer T-Shirt-Größe ausreichend und es wird keine exaktere Schätzung benötigt
• Erste Erfahrungen in der Durchführung von Festpreisprojekten mit einem Gesamtbudget, das nach der oben beschriebenen Regel gebildet wird, sind sehr positiv (bisherige Projektgrößen lagen zwischen 10 und 60 Personentagen)

Zunächst hatten wir das T-Shirt-Sizing als ersten Schritt eines mehrstufigen Schätzprozessen angedacht, in der Form

1. Der Auftraggeber wünscht sich ein Feature
2. webfactory nennt eine T-Shirt-Größe
3. Der Auftraggeber trifft eine Vorentscheidung, ob das Feature realisiert werden soll
4. Bei positiver Vorentscheidung nimmt webfactory eine detaillierte Schätzung vor und erstellt ein verbindliches Angebot
5. Auf dieser Basis erteilt der Auftraggeber den Auftrag.

Dieses Verfahren haben wir inzwischen aufgegeben, da es viele Probleme der Aufwandsschätzung nicht löst. Der positive Aspekt war, dass wir den Schätzaufwand für unwirtschaftliche Features einsparen – was durchaus eine große Verbesserung gegenüber einer sofortigen exakten Schätzung darstellt. Bei Features, die aufgrund ihrer T-Shirt-Größe beauftragt werden sollten, entstand dann allerdings unverändert der hohe und zum Teil wertlose Aufwand für die exakte Schätzung, ebenso wie das im letzten Beitrag beschriebene Problem der doppelten Einarbeitung.

Aufgrund dieser Erfahrungen sind wir dazu übergegangen, wie oben beschrieben direkt Festpreisbudgets und Angebote auf der Basis der T-Shirt-Größen mit Sicherheitspuffer zu kalkulieren.

Wer schätzt?

Die wichtigste Grundlage für eine zuverlässige Schätzung ist – wie bei jedem Schätzverfahren – die Erfahrung und der Überblick des Schätzers. Bei webfactory schätzen in den meisten Fällen langjährige Projektmanager auf der Basis der tatsächlichen Aufwände vergleichbarer Features aus früheren Projekten.

Eine sehr interessante alternative Methode, die sich gut mit der T-Shirt-Größen-Schätzung verbinden lassen müsste und das Entwicklungsteam einbezieht, ist Magic Estimation – hiermit haben wir allerdings noch keine eigenen Erfahrungen. Wir werden Magic Estimation für Projekte anwenden, bei denen es im Team niemanden gibt, der alleine genug Erfahrung mit den gefragten Kompetenzen mitbringt, um zuverlässig schätzen zu können.

Softwareprojekte als Innovationsprobleme

Die T-Shirt-Größen-Methode eignet sich nach unserer Erfahrung sehr gut für übersichtliche, gut verstandene Entwicklungsprobleme, bei denen nur eine relativ geringe Unsicherheit besteht. Gerade bei umfangreichen Softwareprojekten handelt es sich allerdings häufig um komplexe Innovationsprobleme. Michael Wolfe hat am Beispiel einer Wanderung von San Francisco nach Los Angeles sehr plastisch beschrieben, warum Schätzungen für Innovationsprojekte fast immer falsch sind: Zwar gibt die Landkarte einen guten Überblick und man kennt die Gesamtentfernung, doch die Geschwindigkeit hängt von Details des Weges ab, die man erst beim Wandern herausfindet. Die vollständige Geschichte ist sehr lesenswert.

Für umfangreiche und komplexe Projekte empfehlen wir ein schrittweises Vorgehen: Auf diese Weise plant man auf Sicht und kann den Aufwand zuverlässiger einschätzen – siehe hierzu unseren Beitrag Große Projekte Schritt für Schritt realisieren.

Sprechen Sie uns an

Wir sind eine Symfony Agentur mit Sitz in Bonn und arbeiten für Kunden aus ganz Deutschland. Wenn Sie ein Softwareprojekt umsetzen möchten und einen zuverlässigen, erfahrenen Partner suchen, dann sprechen Sie uns gerne an!