Aufwände im Team schätzen - eine Anleitung

Wie viel Arbeit kann ein Team realistisch schaffen? Ohne eine gemeinsame Schätzung ist das schwierig zu bewerten. Aber wie geht man genau vor? Hier ein Blick über die Schultern der CST-Kolleginnen und Kollegen.

Schätzungen auf Zeitbasis funktionieren nicht

Wir haben eine Zeitlang versucht, Aufwände auf der Basis von Zeiten zu schätzen. Jeder von uns hat seine eigene Zeitaufschreibung und sein eigenes System /1/. Für viele Dinge kenne ich die Aufwandstreiber und ich kann ziemlich zuverlässig sagen, wie lange ich für bestimmte Aufgaben brauche. (Bei anderen Dingen liege ich aber hoffnungslos daneben.)

Die persönliche Zeitaufschreibung hat aber mit einer Abschätzung im Team nichts zu tun. Jeder hat seinen eigenen Arbeitsstil. Jeder hat unterschiedliche Aufgaben und muss auch unterschiedliche Kontexte berücksichtigen. Die lassen sich nicht vergleichen. Zudem treibt einem die - wenn auch wohlgemeinte - Frage danach, was man denn den ganzen Tag mache, schnell die Zornesröte ins Gesicht.

Steve McConnell weist in seinem Buch über Aufwandsschätzungen darauf hin, dass eine zeitliche Abschätzung nicht automatisch mit einer Zusage gleichzusetzen sei. Das schwingt leider oft in der Frage nach der Dauer einer Aufgabe mit.

Was können wir statt Zeiteinheiten für die Schätzungen nehmen?

Wir brauchen ein Maß für Arbeit

Aber um realistisch einzuschätzen, was wir als Team in den nächsten Wochen leisten können, brauchen wir etwas.

Es ist gut, wenn wir zählbare Dinge haben. Nehmen wir an, ich möchte ein längeres Dokument ins Englische übersetzen. Ich sehe mir nach einer Stunde an, wie viele Seiten ich geschafft habe. Dann zähle ich, wie viele Seiten noch zu übersetzen sind. Jede Stunde überprüfe ich, ob der Aufwand noch hinkommt. Zählbare Dinge sind immer praktisch. Das ist der wichtigste Tipp, den Steve McConnell in seinem Buch gibt.

Was machen wir aber, wenn wir kein vergleichbares Maß haben? In diesem Fall können wir Story Points nutzen, die wir aus Scrum-Projekten kennen. Story Points geben den relativen Aufwand wieder, der in verschiedenen Aufgaben steckt. Dabei wird nicht die einzelne Aufgabe, sondern eine größere Menge an Aufgaben insgesamt betrachtet. Eine leichte Aufgabe hat weniger Aufwandspunkte als eine schwierige. Vergeben werden die Punkte 1, 2, 3, 5, 8, 13, 21, 34 usw.. Einer ganz leichten Aufgabe wird ein Story Point zugeordnet. Eine Aufgabe mit 3 Story Points entspricht ungefähr so viel Aufwand wie eine Aufgabe mit einem und zwei Story Points zusammen.

Während wir uns mit absoluten Zeitschätzungen sehr schwer tun und oft gewaltig daneben liegen, fällt uns die relative Abschätzung viel leichter. Wie kann man das nun konkret im Team machen?

Beispiel für einen Schätzworkshop für ein Team (Dauer ca. 2-4 Stunden)

Bei Scrum-Teams wird der relative Aufwand von Anforderungen geschätzt. Der Ausdruck "Story Point" bezieht sich auf das Format der Anforderungen, weil die Anforderungen in agilen Softwareprojekten oft in der Form von sog. User Storys beschrieben werden. Das heißt aber nicht, dass andere Teams nicht auch Story Points nutzen dürfen. Die Art der Aufgaben ist aber etwas anders:

• In unserem Team machen wir Trainings. 
• Wir beraten Kunden. 
• Die Buchhaltung muss gemacht werden. Es werden Rechnungen gestellt, Angebote geschrieben usw. 
• Wir schreiben Blogbeiträge und Buchkapitel. 
• Anfragen und Termine sind zu koordinieren. Hotels, Zugfahrten und Flüge müssen gebucht werden. 
• Das Wechseln des Telefonanbieters macht man nicht eben zwischen Tür und Angel. 

Kurz: es gibt eine Vielzahl an unterschiedlichen Aufgaben.Wir haben die Erfahrung gemacht, dass wir unseren Zeitaufwand nicht vergleichen können. Aber interessanterweise schätzen wir alle den relativen Aufwand ähnlich ein. Und so geht es.

• Zunächst wird ein Scrum Master festgelegt, der durch den Workshop führt.
• Jeder geht im Geiste die letzten 2-3 Wochen durch und schreibt alle wesentlichen Aufgaben auf Post-Its auf. Eine Aufgabe pro Zettel.
• Jeder bringt die Aufgaben für sich in eine Reihenfolge: ganz leichte nach unten, ganz schwere nach oben. Alle anderen werden dazwischen eingeteilt.
• Die Aufgaben werden zusammengetragen. Entweder fängt man bei 1 (kleinste Aufgaben) oder bei 5 (mittlerer Aufwand) an. Jeder hängt seine Aufgabenzettel hin, ohne dies mit den anderen zu diskutieren.

Abb. 1: Typische Aufgaben in einem Team nach relativem Aufwand sortiert

• Das Team diskutiert nacheinander jede Größenklasse. Jeder stellt dazu nacheinander seine Karten in der Größenklasse vor und beschreibt, was für ihn den hohen oder geringen Aufwand ausmacht.

In der Diskussion merken einzelne (aber nicht alle) Teammitglieder, dass sie ähnliche Aufgaben haben. Entweder merken sie, dass sie den relativen Aufwand gleich einschätzen oder sie entdecken unterschiedliche Aufwandstreiber. Oder sie merken, dass für sie unterschiedliche Aktivitäten zur Aufgaben gehören. So gleichen sie ihr Verständnis an.

• Der wichtige Schritt ist nun, für jede Größenklasse eine oder mehrere Referenzen festzulegen.

Damit ist die Basis für die weitere Zusammenarbeit gelegt. Neue Aufgaben mit Hilfe der Referenzen eingeschätzt. Für die Wochen- oder Sprintplanung werden die Aufwandspunkte zusammengerechnet. Im Review wird geprüft, ob das Team die Leistung gebracht hat.

Anmerkungen:

• /1/ Für meine Projekte benutze ich übrigens Toogl. Dieser Dienst einer estnischen Firma bietet eine kostenfreie Variante an. Er  funktioniert plattformübergreifend und ist online und offline verfügbar: www.toggl.com
• /2/ McConnell, Steve: Software Estimation : Demystifying the Black Art. 1. Aufl.. München: Microsoft Press, 2006.