Sie stehen vor der Herausforderung Ihre Produkte agil zu entwickeln? Vielleicht freiwillig, da Sie an die Vorteile von agilen Methoden glauben. Vielleicht wurde Ihnen die agile Entwicklung aber auch aufgezwungen. Oder Sie stehen der Transition von klassischer Arbeitsweise hin zu einem agilen Vorgehen à la Scrum gleichgültig gegenüber. Die Herausforderungen bleiben grundsätzlich dieselben! Wie in der klassischen Produktentwicklung wird auch in der agilen Produktentwicklung nach Scrum versucht, Anforderungen an ein Produkt pünktlich und kostengünstig zu realisieren. So weit so gut. Die Beschreibungen dieser neuen Produktfunktionalitäten werden in sogenannten User Stories vorgenommen. Die darin formulierten Funktionalitäten sollten dabei entweder für einen Käufer oder Anwender einen Nutzen stiftenden Mehrwert liefern. Eine User Story versteht sich also im Prinzip als ein Kommunikationsmittel, das Anforderer, Entwickler und Kunden laufend mit einbezieht. Die Stories sollen auf diesem Wege dabei helfen, ein Produkt zu entwickeln, welches der Kunde zum Zeitpunkt der endgültigen Fertigstellung wirklich will oder braucht. Auch bis hier hin könnten Sie zu Recht einwerfen, dass es im Wesentlichen noch nach dem Gleichen in Grün klingt. User Stories erheben keinesfalls den Anspruch auf Vollständigkeit. Sie lassen vielmehr Raum für Anpassungen. Dieser Grad an Veränderungsmöglichkeit schafft Räume zur Kommunikation und Kooperation. Was User Stories nämlich definitiv schaffen, sie prägen die alltägliche Zusammenarbeit. Damit stellen sie ein schlagendes Argument, um klassische Entwicklungsprozesse immer weiter zu agilisieren.
Eine der vielen Herausforderungen vor die Scrum eine Organisation oder ein Team stellt, ist, dass den so genannten INVEST-Kriterien[1] folgend, User Stories unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar sein sollten. Nüchtern bewertet mögen Ihnen diese Kriterien leicht erfüllbar scheinen, erfahrungsgemäß ist jedoch besonders das Thema „Agiles Schätzen“ ein großes Problem! Denn bei aller Euphorie, tun sich die meisten Scrum Teams hierbei trotzdem schwer und das scheint sich wie ein roter Faden durch unerfahrene wie erfahrene Teams zu ziehen. Freunde werden plötzlich zu Widersachern und die Bereitschaft, sich neuen, unbekannten Wegen in Richtung Agilität zu öffnen, sinkt beim Schätzen nicht selten gegen Null. Interessanterweise werden fast durchweg die gleichen Fragen und Befürchtungen geäußert. Deshalb möchte ich im Folgenden auf genau dieses Thema mit Hilfe einiger konkreter Fragen, die mir im Rahmen meiner Tätigkeit als agiler Coach von Mitgliedern agiler Teams gestellt wurden, eingehen.
Teammitglied: Warum schätzen wir nicht mehr den Arbeitsaufwand in Personentagen, sondern die Komplexität einer Anforderung in Story Points? Und warum verwenden wir zur Schätzung diese ungewöhnliche Zahlenfolge?
TEAMWILLE Berater: Hierzu habe ich schon eine Vielzahl an verschiedenen Erklärungsansätzen gehört und gelesen, mal mehr, mal weniger überzeugend. Zu Beginn zur Frage warum überhaupt etwas geändert wird: Die Schätzung des Arbeitsaufwandes in Personentagen täuscht oftmals eine Genauigkeit vor, die es zum Zeitpunkt der Schätzung in der Regel nicht gibt. Zur Verifizierung dieser Behauptung bitte ich Sie sich selber die Frage zu stellen, wie viele Projekte Sie kennen, in denen sich die initiale Aufwandsschätzung in Personentagen spätestens zum Projektende als falsch herausgestellt hat. Um dieser vorgetäuschten oder vielmehr sehnsüchtig erhofften Genauigkeit vorzubeugen, bietet sich eine (agile) Schätzung der Komplexität in Story Points an.
Dabei nutzt man die unreine Fibonaccci-Reihe nach Mike Cohn (1, 2, 3, 5, 8, 13, 20, 40, 100). Die Abkehr von der klassischen Bandbreite (1, 2, 3…100) liegt in der einfacheren Schätzbarkeit: Ob eine Story 5 oder 8 Punkte Komplexität aufweist, ist nicht nur leichter zu beurteilen, als die Unterscheidung zwischen 5, 6, 7 oder 8 Tage Aufwand, sondern ermöglicht immer auch einen Vergleich der zu schätzenden Funktionalitäten in Relation zueinander.
Ein weiterer Grund, der für die Schätzung in Punkten spricht, ist, dass Story Points in einem Atemzug mit Velocity (Geschwindigkeit) genannt werden. Die Velocity gibt Auskunft darüber, wie viele Punkte ein Scrum Team pro Sprint umsetzen kann. Je mehr Sprints bereits in der Vergangenheit liegen, desto besser die Bestimmung der eigenen Geschwindigkeit. Eine Planung mit Story Points und Velocity berücksichtigt sämtliche beeinflussende Faktoren (z. B. nicht geplante Meetings), während bei einer Planung in Personentagen lediglich die verfügbaren Personen berücksichtigt werden. Die vergangene Leistung sowie die Einflussfaktoren während dieser Zeit bleiben außen vor.
Nicht zuletzt sind Personentage unmittelbar in Zeit messbar und können so bei Einzelnen Druck aufbauen auch in genau dieser Zeit fertig werden zu müssen. Das Denken in Komplexität und Punkten kann wiederum diesen Stress reduzieren und so zu einer rationaleren und dadurch besseren Schätzung führen.
Teammitglied: Ich weiß aus Erfahrung wie viele Personentage ich für die Aufgabe benötige. Warum soll ich nun Story Points schätzen?
TEAMWILLE Berater: Für mich persönlich eine sehr gut nachvollziehbare Frage, die insbesondere von erfahrenen Mitarbeitern gestellt wird, die nach jahrelanger Arbeit mit ähnlichen Aufgaben in verwandten Umfeldern durchaus in der Lage sind, den zu erwartenden Arbeitsaufwand relativ genau zu beurteilen. Dabei sprechen wir allerdings von einzelnen Teammitgliedern und einzelnen Aufgaben einer Anforderung, während das Ziel jedoch die plausible Schätzung einer ganzen Anforderung ist. Es scheint einfacher auf Erfahrungswerte in Personentage Einzelner zurückzugreifen – vergleichbare Erfahrungswerte werden aber auch im Rahmen der agilen Vorgehensweise schon nach den ersten Sprints entstehen und sich verfestigen (s. Velocity). Diese Erfahrungswerte gelten dann allerdings team- und nicht mehr personenbezogen!
Ein weiteres Argument für ein Schätzen mit Story Points liefert die Definition der User Story. User Stories sind vor allem ein Anlass zur Konversation. Anfangs noch im Nebel und grobgranular verwandelt der fachliche Austausch zwischen erfahrenen und weniger erfahrenen Teammitgliedern ein Fragezeichen in Klarheit sowie ein gemeinsames Verständnis einer zu entwickelnden Funktionalität. Sich dieser Gespräche zu berauben und „nur“ auf die Erfahrung der Silberrücken zu setzen, wäre naiv und führt zu sozialem Faulenzen und Flaschenhälsen – together everyone achieves more oder kurzum TEAM.
Teammitglied: Ich bin bisher ausschließlich für ein einzelnes Aufgabengebiet zuständig gewesen. Wie soll ich nun eine User Story hinsichtlich aller Aufgabengebiete schätzen?
TEAMWILLE Berater: Die Schätzung sollte, wie bereits erwähnt, vom gesamten Team getragen werden können. Voraussetzung dafür ist ein gemeinsames Grundverständnis vom Was, also aller zu erfüllenden Aufgaben, die sich hinter einer Story verbergen. Dieses erreicht man insbesondere durch kontinuierlichen Austausch und konstruktive Diskussion. Nachdem dieser Austausch im Refinement Meeting [2] stattgefunden hat, sollte theoretisch jeder in der Lage sein die gesamte Story und nicht nur Teilaufgaben zu schätzen. Sollten sich Einzelne immer noch unsicher fühlen, sollten sie sich ihres natürlichen Bauchgefühls bedienen und ihrer Intuition folgen. Das hilft – nicht nur beim agilen Schätzen. Bitte beachten Sie: Es handelt sich lediglich um eine Schätzung, keine Gewissheit. Diese erhebt nie den Anspruch der 100%igen Genauigkeit, sondern lediglich der Plausibilität!
Teammitglied: Woher weiß ich also wie viele Story Points die einzelnen Stories aufweisen müssen?
TEAMWILLE Berater: Die Schätzung ist bei Scrum notwendigerweise von Team zu Team unterschiedlich. Während Story X für Team A eine Punktzahl von 8 aufweist, kann dieselbe Story X für Team B lediglich 5 Punkte komplex sein: verschiedene Teams verfügen schließlich über unterschiedliches Know-How und Erfahrung. Beim Schätzen geht es nicht um falsch oder richtig!
Teammitglied: Was tun wir, wenn eine Schätzung stark voneinander abweichende Schätzwerte ergibt?
TEAMWILLE Berater: Zur Erläuterung ein vereinfachtes Beispiel: Bei einer Schätzrunde mit 5 Teammitgliedern ergeben sich die Punktzahlen 3, 8, 8, 8 und 20. In diesem Fall sollten die Teammitglieder mit dem niedrigsten und höchsten Wert ihre Gründe erläutern. Rückfragen und Kommentare sind ausdrücklich erlaubt! Sobald die Beweggründe erläutert und Rückfragen beantwortet sind, folgt eine erneute Schätzrunde.
Die Idee dahinter ist – und auch die Erfahrung zeigt – unterschiedliche Schätzungen beruhen auf heterogenem Wissensstand, das heißt, diese gleichen sich bei annäherndem Verständnis der Anforderung aneinander an. Das Verständnis wird durch den erneuten Austausch gefördert.
Dieses Vorgehen wird wiederholt bis die Werte sich angenähert haben (z. B. 5, 8, 8, 8 und 8). In einem solchen Fall kann sich guten Gewissens auf den höheren Wert geeinigt werden (Voraussetzung: Werte liegen direkt beieinander). Falls die Punktwerte nach drei Schätzrunden allerdings immer noch weit auseinander liegen, kann davon ausgegangen werden, dass die Analyse, die der Story zugrunde liegt, unzureichend ist. Die Story sollte im Zusammenwirken mit dem Product Owner überarbeitet und dann vom Entwicklungsteam erneut geschätzt werden!
Teammitglied: Muss zwingend das gesamte Team schätzen? Kann eine User Story, bei der zum Zeitpunkt der Schätzung klar ist, dass lediglich eine weitere Kollegin und ich Tasks dieser Story bearbeiten werden, auch nur von uns beiden geschätzt werden?
TEAMWILLE Berater: Scrum stellt lediglich ein Framework dar und dieses geht vom optimalen Fall aus, dass jedes Teammitglied nicht nur theoretisch, sondern auch praktisch, jeden Task bearbeiten kann. Die Realität sieht jedoch, zumindest zu Beginn, meistens anders aus: Ein Team besteht aus Personen, die zuvor für jeweils ein Aufgabengebiet (z. B. Analyse, Entwicklung, Test, etc.) zuständig waren. Als Kompromiss in eben dieser Transitionsphase ist es nicht unüblich, dass ein vorheriger Tester auch im Sprint vornehmlich die Test-Tasks übernimmt – in Einzelfällen auch die alleinige Schätzung.
Dasselbe gilt für folgende Konstellationen: Falls es sich um ein großes Team oder z. B. um ein zeitkritisches Thema handelt, muss es ausreichend sein, dass ein Teil des Teams schätzt. Wie groß der Teil sein muss, damit man es als ausreichend ansieht, ist schwer definierbar. Hinsichtlich des Ziels einer möglichst plausiblen Schätzung der Komplexität einer Story, muss allerdings grundsätzlich gelten: Je mehr Teammitglieder schätzen, desto plausibler das Ergebnis!
Dabei sollte zusätzlich der ureigene Scrum-Gedanke „Abschaffung des Rollendenkens“ parallel und laufend durch selbstorganisierte Wissensweitergabe weiter verfolgt werden. Mit Blick auf diesen Zielzustand ist es auch empfehlenswert die Diskussion und die nachfolgende Schätzung trotzdem im Beisein des gesamten Teams durchzuführen.
Ein gemeinsamer Schätzprozess in Punkten wird von vielen nicht zuletzt auch deswegen positiv gesehen, da er ein gemeinsames Grundverständnis aller Aufgaben einer Story voraussetzt. Um dieses zu erreichen ist eine Diskussion der Storyinhalte unabdingbar. Diese beiden Punkte können Teambildung und funktionsübergreifende Denkweise fördern und führen definitiv zu einem besseren Verständnis des Produktes!
Lassen Sie mich zum Schluss sagen, dass agiles Schätzen einen viel zu schlechten Ruf hat. Es gibt Zweifler, die immer wieder bemerken, dass es anders ist. Das ist richtig. Allerdings muss anders nicht schlechter sein. Es braucht eben ein wenig Mut, sich darauf einzulassen. Ich bin ein großer Fan dieses Vorgehens geworden. Es kann durchaus auch Spaß machen! Es führt Menschen zusammen, die ein Problem diskutieren, ihre Erfahrungen austauschen und dann zu einem Kompromiss gelangen, der als Basis für die weitere Zusammenarbeit gesehen wird. Am Ende hat man sich im Team geeinigt. Ohne Schätzung kein Commitment! Und den Product Owner macht man damit auch noch glücklich. Ich kann jedes Scrum Team nur ermutigen, sich dem agilen Schätzen und der damit verbundenen Weisheit der Vielen zu öffnen. Es funktioniert! Man wird besser und besser und rückt als Team immer näher zusammen.
Literatur
