<?page no="0"?> Jörg Brüggenkamp / Peter Preuss / Tobias Renk Schätzen in agilen Projekten <?page no="1"?> Schätzen in agilen Projekten <?page no="2"?> Dipl. Inf. Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC - ProjektManagement- und Controlling GmbH in der Schweiz. Er ist als Spezialist mit über 20 Jahren Erfahrung in den Bereichen Turnaround-/ In‐ terims-Management im klassischen und agilen Umfeld tätig. Prof. Dr. Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Parallel zu seiner Lehrtätigkeit ist Peter Preuss geschäftsführender Gesell‐ schafter der Unternehmensberatung People Consolidated GmbH. Dr. Tobias Renk ist Chief Information Officer (CIO) der Trafineo GmbH & Co. KG. Er ist als Experte und Keynote Speaker zu den Themen Künstliche Intelligenz, Innovation, kultureller Wandel und Digitale Transformation unterwegs. Außerdem ist er als Dozent für Digitale Wirtschaft & Geschäfts‐ modelle an der Dualen Hochschule Baden-Württemberg in Stuttgart tätig. In der Lehre immer am Zahn der Zeit zu sein, wird in unserer schnelllebigen Zeit immer mehr zur Herausforderung. Mit unserer neuen fachübergreifenden Reihe nuggets präsentieren wir Ihnen die aktuellen Trends, die Forschung, Lehre und Gesellschaft beschäftigen - wissenschaftlich fundiert und kompakt dargestellt. Ein besonderes Augenmerk legt die Reihe auf den didaktischen Anspruch, denn die Bände sind vor allem konzipiert als kleine Bausteine, die Sie für Ihre Lehrveranstaltung ganz unkompliziert einsetzen können. Mit unseren nuggets bekommen Sie prägnante und kompakt dar‐ gestellte Themen im handlichen Buchformat, verfasst von Expert: innen, die gezielte Information mit fundierter Analyse verbinden und damit aktuelles Wissen vermitteln, ohne den Fokus auf das Wesentliche zu verlieren. Damit sind sie für Lehre und Studium vor allem eines: Gold wert! So gezielt die Themen in den Bänden bearbeitet werden, so breit ist auch das Fachspektrum, das die nuggets abdecken: von den Wirtschaftswissenschaf‐ ten über die Geisteswissenschaften und die Naturwissenschaften bis hin zur Sozialwissenschaft - Leser: innen aller Fachbereiche können in dieser Reihe fündig werden. <?page no="3"?> Jörg Brüggenkamp / Peter Preuss / Tobias Renk Schätzen in agilen Projekten <?page no="4"?> DOI: https: / / doi.org/ 10.24053/ 9783381125128 © UVK Verlag 2024 ‒ Ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG Dischingerweg 5 · D-72070 Tübingen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikro‐ verfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Informationen in diesem Buch wurden mit großer Sorgfalt erstellt. Fehler können dennoch nicht völlig ausgeschlossen werden. Weder Verlag noch Autor: innen oder Heraus‐ geber: innen übernehmen deshalb eine Gewährleistung für die Korrektheit des Inhaltes und haften nicht für fehlerhafte Angaben und deren Folgen. Diese Publikation enthält gegebenenfalls Links zu externen Inhalten Dritter, auf die weder Verlag noch Autor: innen oder Herausgeber: innen Einfluss haben. Für die Inhalte der verlinkten Seiten sind stets die jeweiligen Anbieter oder Betreibenden der Seiten verantwortlich. Internet: www.narr.de eMail: info@narr.de CPI books GmbH, Leck ISSN 2941-2730 ISBN 978-3-381-12511-1 (Print) ISBN 978-3-381-12512-8 (ePDF) ISBN 978-3-381-12513-5 (ePub) Umschlagabbildung: © wanderluster iStockphoto Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbi‐ bliografie; detaillierte bibliografische Daten sind im Internet über http: / / dnb.dnb.de abrufbar. www.fsc.org MIX Papier aus verantwortungsvollen Quellen FSC ® C083411 ® <?page no="5"?> 7 11 1 13 1.1 13 1.2 15 1.3 17 2 19 2.1 19 2.2 22 3 33 4 35 4.1 35 4.2 42 5 47 5.1 47 5.2 49 5.3 51 5.4 54 6 59 6.1 60 6.2 68 7 71 Inhalt Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hinweise zur Lektüre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Story Points und agile Schätzmethoden . . . . . . . . . . . . . . . . . . . . . Definition von Story Points . . . . . . . . . . . . . . . . . . . . . . . . . . Schätzmethoden für Story Points . . . . . . . . . . . . . . . . . . . . . Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ursachen und Folgen von Fehleinschätzungen . . . . . . . . . . . . . . . . Verschätzen leichtgemacht . . . . . . . . . . . . . . . . . . . . . . . . . . . Top 5 Gründe für Fehleinschätzungen . . . . . . . . . . . . . . . . . Verlässliche Schätzungen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kalibrierung und Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kalibierung der Teammitglieder . . . . . . . . . . . . . . . . . . . . . . Optimierung der Information . . . . . . . . . . . . . . . . . . . . . . . . . Konfidenzintervalle, Wahrscheinlichkeiten und mehr . . . . . . . . . Berechnung von Konfidenzintervallen . . . . . . . . . . . . . . . . . Wahrscheinlichkeiten schätzen . . . . . . . . . . . . . . . . . . . . . . . Schwarmintelligenz - die Vermittlung der Extreme . . . . . . Pre Mortem Analyse vor Post Mortem Analyse . . . . . . . . . Prediction Interval Game---die integrierte Schätzmethode . . . . . PIG-Schätzverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hinweise für die praktische Anwendung . . . . . . . . . . . . . . . Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . <?page no="6"?> 73 74 75 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Inhalt <?page no="7"?> Vorwort „Plans are useless, but planning is essential.“ Dwight D. Eisenhower, ehemaliger US-Präsident Wir mögen es kaum glauben, aber Schätzen - ob nun bewusst oder unbe‐ wusst - spielt eine große Rolle in unserem Leben. Es beginnt schon am frühen Morgen, wenn der Wecker klingelt. Wir stehen auf und gehen ins Bad. Die Zeit im Bad will gut geschätzt sein. Danach wird gefrühstückt - den Blick immer wieder auf die Uhr richtend, um zu sehen, wie viel Zeit noch bleibt, bevor wir das Haus verlassen müssen, um rechtzeitig den Bus oder die Bahn zu erreichen. Oder aber wir fahren mit dem Auto. Bei längerer Strecke wird nicht selten noch einmal kurz die Strecke abgecheckt auf mögliche Staus. Auch während der Fahrt im Auto kommt es immer wieder zu Situationen, in denen wir schätzen müssen. Ist die Geschwindigkeit angemessen, sodass wir rechtzeitig an der Ampel zum Stehen kommen? Oder ist die Entfernung zur eben auf Orange umgeschalteten Ampel so kurz, dass es sich lohnt, noch einmal kurz auf das Gaspedal zu treten? Ein weiteres Beispiel ist die Einladung von Gästen am Abend. Es müssen Getränke und Essen besorgt werden, damit der Abend auch gut gelingen kann. Hier wird es aber unter Umständen schon etwas komplizierter als beim vorherigen Beispiel, weil dieses Mal mehrere Menschen in die Abschätzung der richtigen Mengen mit einbezogen werden müssen. Und Menschen verhalten sich eben nicht jeden Tag gleich. Manchmal haben sie mehr Durst als sonst, manchmal Essen sie deutlich weniger als erwartet. Schätzen ist also überall, und wir sind mehrmals am Tag dazu gezwungen, Schätzungen vorzunehmen. Dabei muss man zwischen zwei grundlegenden Arten der Schätzung un‐ terscheiden, und zwar zwischen bewussten und unbewussten Schätzungen. Beim Heranfahren an eine Ampel denken wir üblicherweise nicht mehr viel darüber nach, was zu tun ist. Hier läuft die Abschätzung von Geschwindig‐ keit und Entfernung in Bezug auf den Zustand der Ampel unbewusst, ja fast schon automatisiert ab. Bei der Einladung von Gästen sieht das Ganze schon ein wenig anders aus. Hier werden bewusste Schätzungen durchgeführt, in denen gerne auch Erfahrungen aus vorherigen Einladungen mit in Betracht gezogen werden. Häufig liegen wir, ob nun unbewusst oder bewusst, mit Schätzungen im Alltag gar nicht so verkehrt, und das ist auch gut so. <?page no="8"?> Anders verhält es sich allerdings, wenn man die Thematik Schätzen auf die Projektwelt überträgt. Wer kennt sie nicht, die großen Bauprojekte, die meist deutlich teurer werden und länger dauern als geschätzt. Egal ob es sich um die Elbphilharmonie handelt, den Berliner Flughafen oder Stuttgart 21; die Liste ist beliebig erweiterbar. Verschiebungen im Projektplan sind, vor allem bei der klassischen Wasserfallmethode, an der Tagesordnung. Aber warum ist das so? Wieso können wir in Projekten häufig nicht gut schätzen? Und wieso tun wir es dann trotzdem tagein tagaus? Ein Grund liegt sicher in der Tatsache, dass wir häufig gezwungen werden, zu weit in die Zukunft zu schauen. Das ist einerseits natürlich nachvollziehbar, weil man eben gerne wüsste, wann das Projekt abgeschlos‐ sen sein wird (zumal die Definition eines Projektes unter anderem ja eben durch ein festes Start- und Enddatum begründet ist) und wie viel es dann gekostet haben wird. Zum anderen ist der Wunsch aber eben häufig nichts anderes als genau das, ein Wunsch bzw. das Denken, Projekte könnten vor Beginn bereits belastbar durchgeplant werden. Ein weiterer Grund liegt in der Tatsache begründet, dass die heutige Welt so komplex geworden ist, dass nicht alle Abhängigkeiten, die im Laufe eines Projektes auftreten werden, berücksichtigt werden können. Und dann gilt es auch noch, den Faktor Mensch einzubeziehen. Meist überschätzen wir uns und das, was wir in einem bestimmten Zeitraum zu leisten imstande sind. So entstand das in Projektkreisen bekannte Gesetz von Hofstadter, nach dem ein Projekt immer länger dauert als erwarten - und das auch, wenn man bei der Planung Hofstadters Gesetz mit einbezieht! In der agilen Projektwelt verspricht man sich deutlich bessere Schätzun‐ gen als bei den klassischen Verfahren. Aber warum ist das so? ■ Zum einen findet der klassische Projektplan im agilen Kontext keine Anwendung. Damit ist eine Quelle ständiger Fehleinschätzungen nicht mehr vorhanden, die überdies häufig zu intensiven Diskussionen führt. ■ Zum anderen sind die Planungszyklen deutlich kürzer. Ein Sprint, der detailliert geplant wird, besteht meist nur aus zwei oder vier Wochen. Zwar findet auch im agilen Kontext ein Blick in die weitere Zukunft statt, dieser ist aber deutlich weniger konkret (was bei agilen Projekten auch von allen so akzeptiert wird). Weiterhin werden Anforderungen erst dann geschätzt, wenn sie klar und verstanden sind. Sollte das nämlich nicht der Fall sein, so wäre es die Aufgabe des Product Owners, diese nicht in die Sprintplanung aufzunehmen. Im agilen Kontext besteht darüber hinaus die 8 Vorwort <?page no="9"?> Möglichkeit, andere Schätzverfahren wie beispielsweise Planning Poker zu verwenden. Zu guter Letzt können Anpassungen von Schätzungen basierend auf echten Performancedaten des Projektteams vorgenommen werden. Oder anders ausgedrückt: Wenn man weiß, was das Team zu leisten imstande ist, dann kann man auch deutlich belastbarere Schätzungen darüber abgeben, was das Team in einem gewissen Zeitraum erreichen kann. Der vorliegende Text konzentriert sich darauf, die Hauptursachen für Fehleinschätzungen zu beleuchten und Möglichkeiten zur Verbesserung der Qualität von Abschätzungen aufzuzeigen. Er ist mitnichten als ein Plädoyer gegen Abschätzungen zu verstehen, sondern steht ganz im Sinne Dwight D. Eisenhowers Aussage: „Plans are useless, but planning is essential.“ München, im Juni 2024 Jörg Brüggekamp Peter Preuss Tobias Renk Vorwort 9 <?page no="11"?> Hinweise zur Lektüre Bevor wir uns dem eigentlichen Kern des Sprach- und Bedeutungswandels zuwenden können, möchte wir noch einige Informationen zur Lektüre und zum richtigen Umgang mit diesem Buch voranschicken. Dieses Lehrbuch versteht sich als Arbeitsbuch und ist in erster Linie für das Selbststudium geschrieben. Wir haben versucht, Komplexes einfach darzustellen. Das bleibt nicht ohne Folgen. Wissenschaftliche Unschärfe hier und da mögen uns unsere Fachkolleginnen und -kollegen nachsehen. Denn: Für diese Leserschaft ist dieses Buch nicht geschrieben worden. Der Anspruch an dieses Buch lautet: Es kann weitestgehend ohne Vorwissen gelesen werden. Dass eine diesem Anspruch verpflichtete Einführung nicht möglich ist, ohne das ein oder andere zu verkürzen und zu simplifizieren, ist klar-- und eher eine Stärke als eine Schwäche dieses Buches. Der besseren Lesbarkeit halber werden Personenbezeichnungen in die‐ sem Buch in der maskulinen Form genannt. Verstehen Sie dies bitte einzig unter dem Aspekt der sprachlichen Ökonomie - die im Übrigen eine wichtige Bedingung für Sprachwandel ist. Auf einer Waage, die zwischen sprachlicher political correctness einerseits und guter Lesbarkeit von Texten andererseits pendelt, bevorzugen wir stets den Ausschlag zugunsten der Prägnanz. <?page no="13"?> 1 Vgl. Schwaber, Ken und Sutherland, Jeff (2020): o.S. 2 Vgl. Jeffreys, Ron (2019): o.S. 1 Story Points und agile Schätzmethoden Kaum ein Projekt scheint in der Vergangenheit mit klassischen Schätz- und Planungsmethoden erfolgreich gewesen zu sein. Fehleinschätzungen scheinen an der Tagesordnung zu sein. Als Lösung bietet sich zumindest im agilen Umfeld der Einsatz von Story Points an, um einfach, schnell und qualitativ hochwertig schätzen zu können. Warum Schätzungen mit Story Points aber angeblich so gut funktionieren, scheint oft ein Rätsel zu sein. Im Folgenden werden daher kurz die Grundlagen agiler Schätzansätze am Beispiel von Scrum dargestellt und kritisch hinterfragt, bevor auf die eigentlichen Ursachen von Schätzfehlern näher eingegangen wird. 1.1 Definition von Story Points Bereits bei der ersten Recherche zu Story Points fällt auf, dass diese im Scrum Guide nicht erwähnt werden, die Meinungen dazu weit auseinandergehen und die Beschreibungen sehr uneinheitlich sind. 1 Schon bei der Definition von Story Points und der Frage, ob es sich um eine Maßeinheit handelt, also messbar ist, wird es schwierig. Um es vorwegzunehmen: Ron Jeffries, der in erster Linie als möglicher Erfinder der Story Points genannt wird, meinte mit Story Points den Aufwand - mehr nicht. Im Mai 2019 erzählte er die Geschichte hinter den Story Points und bedauerte ein wenig, sie erfunden zu haben. 2 Im Grunde waren Story Points für ihn nichts anderes als ein anderer Name für den klassischen Aufwand in Stunden oder Tagen. Multipliziert mit einem bestimmten Faktor („load factor“) wurde aus dem Aufwand die Dauer errechnet - in seiner Geschichte war es der Faktor 3. Insgesamt ging es ihm bei seiner Methode eher darum, die ständigen Rechtfertigungen zu vermeiden, warum beispielsweise ein Tag Aufwand drei Tage Umsetzung erfordert. Also hat er den Aufwand einfach in Punkte <?page no="14"?> umdefiniert. Danach wurde nur noch angegeben, wie viele Punkte im Durchschnitt in einer Iteration umgesetzt werden konnten. Von Aufwand oder Dauer war nicht mehr die Rede. Nun ist auch hier im Laufe der Zeit in Vergessenheit geraten, was Story Points eigentlich sind und es haben sich sehr unterschiedliche Definitionen von Story Points entwickelt, die über die ursprüngliche Aufwandsschätzung hinausgehen. Eine heute weit verbreitete Definition beschreibt Story Points als Kom‐ plexität(sgrad) einer Aufgabe (User Story), ohne zu spezifizieren, was die Komplexität bestimmt. Andere Definitionen beschreiben Story Points als Gesamtaufwand, der durch Parameter wie ■ Arbeitsvolumen, ■ thematisches Wissen/ Unsicherheit und ■ Risiken bestimmt wird. Weniger gebräuchlich sind Definitionen, die auf Komplexi‐ tätselementen wie der ■ Anzahl der betroffenen Komponenten (z. B. User Interface, Datenbank- Backend), ■ Features, ■ Modulen, ■ Schnittstellen, ■ Micro-/ Macro-Services, ■ Funktionspunkten etc. basieren. Schwierig wird es schon bei der Bedeutung von Komplexität, die in fast allen auffindbaren Definitionen von Story Points enthalten ist. Je nach Fachgebiet wird Komplexität bereits sehr unterschiedlich definiert und Komplexität selbst ist zunächst einmal keine Maßeinheit. Es scheint, dass der Begriff Komplexität selbst schon komplex ist. Vermischungen und Verwechslungen von kompli‐ ziert und komplex erschweren die Definition zusätzlich. Am Ende wird gerne darauf hingewiesen, dass es eigentlich nicht darauf ankommt, was Story Points sind, sondern was mit Story Points ausgedrückt 14 1 Story Points und agile Schätzmethoden <?page no="15"?> werden soll, nämlich die Bewertung einer Aufgabe im Vergleich zu anderen Aufgaben. Aber auch dafür sollten Story Points klar definiert und in irgendeiner Form messbar sein, sonst wird es schwierig, Story Points für Relationen zwischen Elementen zu verwenden, oder ihre Bewertung wird reine Inter‐ pretationssache und ähnelt eher einer Kategorisierung als einer Bewertung. Daher ist es für die Verbesserung der Schätzungen unerlässlich, dass sich das Team vorab auf eine Definition der Story Points einigt. Vergleichbar mit den Story Point Schätzungen anderer Teams wäre es nicht und zumindest im Scrum-Umfeld auch nicht das Ziel, aber User Stories zum eigenen Produkt könnten für das zugehörige Team in Relation zueinander gesetzt werden. Story Points werden in der Regel als Zahlenwerte dargestellt, d. h. „eine Zahl für alles“. Die häufig verwendete Zahlenfolge für Story Points stammt aus der Fibonacci-Reihe mit den Zahlenwerten 1, 2, 3, 5, 8, 13, 21 usw. (die nächste Zahl ergibt sich immer aus der Summe der beiden vorhergehenden Zahlen) - häufig nach oben gerundet und gedeckelt. Damit soll eine relative Bewertung zwischen den Aufgabenbewertungen erfolgen, d. h. eine User Story mit zwei Story Points ist „doppelt so groß“ (Aufwand, Dauer, Komplexität, Risiko, Umfang etc.) wie eine User Story, die mit einem Story Point bewertet wurde bzw. der prozentuale Aufschlag beträgt 100 %. Zwischen den Zahlen zwei und drei der Fibonacci-Reihe beträgt der Aufschlag ca. 67 % und zwischen drei und fünf ca. 60-%. Bei allen anderen Zahlen der Fibonacci-Reihe beträgt der prozentuale Aufschlag zur nächsten Zahl ca. 62 % und soll damit dem höheren Schätzrisiko bei umfangreicheren Aufgaben Rechnung tragen. 1.2 Schätzmethoden für Story Points Die drei gebräuchlichsten Schätzmethoden für Story Points im Scrum- Umfeld sind ■ Story Point Poker, ■ Magic Story Points und ■ Story Point Game. 1.2 Schätzmethoden für Story Points 15 <?page no="16"?> Die Methoden basieren auf der Schätzung von Aufgaben (User Stories) in Gruppen oder Einzelschätzungen mit vorheriger Erläuterung durch den Product Owner, der auch für Rückfragen zur Verfügung steht. Die Moderation übernimmt in der Regel der Scrum Master. Die Schätzungen erfolgen durch die Teammitglieder, wobei Product Owner und Scrum Master in der Regel keine Schätzung abgeben. Der Zahlenraum (z. B. Fibonacci-Folge) bzw. die Verwendungsdefinition der Story Points ist vorab vom Team festzulegen. Bevor auf die grund‐ sätzlichen Risiken von Schätzungen eingegangen wird, folgt eine kurze Beschreibung der Methoden. Story Point Poker Die bekannteste Methode, Story Point Poker, ist eine konsensbasierte Schätz‐ methode. In einem ersten Schritt ermittelt jedes Teammitglied für sich eine Schätzung auf der Grundlage der Story Point Definition im Vergleich zu bekann‐ ten Referenz User Stories. Nach gleichzeitiger Offenlegung der Schätzungen der Teammitglieder erfolgt eine Diskussion in der Gruppe, zumindest zwischen den Teilnehmern mit der höchsten und der niedrigsten Schätzung, um einen Informationsaustausch zu gewährleisten, Informationslücken zu schließen und anschließend die Schätzung zu hinterfragen bzw. anzupassen. Dieser Prozess wird für die User Story so lange wiederholt, bis ein Gruppenkonsens erreicht ist oder der Scrum Master die Schätzungen für die User Story beendet, bevor die nächste User Story bewertet wird. Magic Story Points Diese Methode wird oft als die schnellste Schätzmethode für eine große Anzahl zu schätzender User Stories angepriesen. Sie basiert auf Einzelschät‐ zungen der Teammitglieder, idealerweise auf Basis von Referenz User Stories, mit anschließender Gruppenschätzung und Konsensfindung bei abweichenden Einschätzungen. Dazu werden die zu schätzenden User Stories gleichmäßig auf die Teammitglieder verteilt. In einem definierten Zeitraum schätzt jeder seine User Stories ohne Diskus‐ sion im Team und legt jede Schätzung direkt offen. In einem weiteren definierten Zeitraum schätzt jeder für sich, ohne Diskussion im Team, die Schätzungen der anderen und gibt ggf. seine Schätzung dazu ab, wodurch User Stories mit unterschiedlichen Einschätzungen erkennbar werden. Alle User Stories, bei 16 1 Story Points und agile Schätzmethoden <?page no="17"?> denen sich die Einschätzungen der anderen geändert haben, werden in der Gruppe diskutiert, bis ein Konsens über die Einschätzung erreicht ist. Story Point Game Bei dieser Methode geht es darum, die User Stories miteinander in Beziehung zu setzen und dann die Story Points zu definieren. Im ersten Schritt setzen die einzelnen Teammitglieder die User Stories ohne Gruppendiskussion zueinander in Beziehung. Dazu wird ausgehend von der ersten User Story jede weitere User Story abwechselnd von jeweils einem Teammitglied z. B. darübergelegt, wenn es sich um eine „größere“ User Story handelt. Ist sie gleich groß, wird sie entsprechend auf der gleichen Ebene platziert, ist sie kleiner, wird sie darunter angeordnet. Liegt sie zwischen zwei bestehenden User Stories, müssen die Elemente entsprechend verschoben werden. Dies ist auch horizontal möglich. Ist dieser Vorgang abgeschlossen, werden die Story Points von der kleinsten bis zur größten User Story zugeordnet, wobei die vorhergehende User Story jeweils die Referenz zur nächsten darstellt. Bei bestehenden Zuordnungsschwierigkeiten einzelner User Stories werden sogenannte „Spikes“ oder die Konsensfindung im Team empfohlen. 1.3 Zwischenfazit Die meisten Kritikpunkte an den Story Points und ihren Schätzmethoden beziehen sich auf ihre Vor- und Nachteile und weniger auf die Qualität der Schätzungen - insbesondere nicht auf die Berücksichtigung der mensch‐ lichen Komponente. So wird neben den Story Points selbst vor allem der Aufwand für die Schätzungen in der Gruppe (z. B. beim Story Point Poker) oder die Tatsache, dass nicht alle User Stories ausführlich diskutiert wurden, aufgrund von Einzelschätzungen der Teammitglieder mit wenig Gruppendiskussion (z. B. bei Magic Story Points) kritisiert. In der sogenannten #NoEstimate-Initiative wird sogar davon ausge‐ gangen, dass alle Schätzungen von User Stories nur an der Implemen‐ tierungszeit „nagen“ und daher als „Wombat“ (australisches Nagetier - abgeleitet von „Waste of Money, Budget and Time“) bezeichnet. 1.3 Zwischenfazit 17 <?page no="18"?> Obwohl vieles dafürspricht, sich im agilen Umfeld intensiver mit diesem Ansatz zu beschäftigen, gibt es in der Praxis einige Hürden. Zudem ist es kaum möglich, gänzlich auf Schätzungen zu verzichten, zumal es auch um den Kosten-Nutzen-Faktor von Aufgaben geht. Es ist auch wichtig zu erwähnen, dass der größte Vorteil der agilen Schätzmethoden nicht unbedingt in der Verbesserung der Schätzgenauigkeit liegt, sondern vielmehr in der Gruppendynamik. Vor allem das Verständnis für die anstehenden Aufgaben wird durch die intensive Auseinandersetzung mit den Themen gefördert. Insbesondere durch die Konsensfindung im Team entsteht schnell ein Gemeinschaftsgefühl - auch wenn sich eine Aufgaben‐ abschätzung im Nachhinein als sehr ungenau oder falsch herausstellen sollte. Offenheit wird gefördert und die Bereitschaft, eventuelle Unzulänglich‐ keiten zu zeigen, stärkt das Teamgefühl bzw. den Zusammenhalt. Dies sind alles sehr wichtige Aspekte und somit klare Vorteile. Leider sind diese Vorteile manchmal mit gewissen Nachteilen in anderen Bereichen verbunden. Ob Story Points allein zur Bewertung einer User Story oder zur Planung von Aufgaben funktionieren oder nicht, bleibt meist der Interpretation des Teams überlassen. Solange die Ergebnisse in Bezug auf Zeit, Inhalt, Qualität, Budget und Wertschöpfung stimmen, wird wahrscheinlich kein Verantwort‐ licher das Vorgehen in Frage stellen. Inwieweit die Story Points jedoch zur Transparenz, Vereinfachung und Verbesserung der Schätzqualität beitragen, ist eine andere Frage. Im Folgenden wird daher zunächst auf die Ursachen und Auswirkungen von Schätzfehlern eingegangen, bevor Ansätze zur Verbesserung der Schät‐ zung näher beleuchtet werden. 18 1 Story Points und agile Schätzmethoden <?page no="19"?> 2 Ursachen und Folgen von Fehleinschätzungen Getreu dem Motto von Donald J. Trump „nobody knows it better than me“ gibt es auch bei der Schätzung von Aufgaben menschliche Verhaltens‐ weisen, die von den meisten agilen Schätzmethoden nicht berücksichtigt werden. Es wird viel über technische Details, Story Points und das richtige agile Vorgehen im Zusammenhang mit der Spezifikation von User Stories gesprochen, aber weniger über die Ursachen von Fehleinschätzungen, deren Konsequenzen und wie man diesen entgegenwirken kann. In diesem Sinne hier zwei weitere Zitate von Donald J. Trump ■ „nobody knows what it means, I know what it means“ und ■ „which is why I alone can fix it“ als Einstieg in die Ursachen und Folgen von Fehleinschätzungen. 2.1 Verschätzen leichtgemacht Es kommt immer wieder zu Fehleinschätzungen und manche Methoden oder Definitionen zur Aufgabenschätzung machen es uns leicht. Ein Beispiel aus dem agilen Bereich sind leider auch die Story Points. Im agilen Umfeld wird Transparenz groß geschrieben und leider tragen die Story Points sehr oft zu einer gewissen Intransparenz bei. Wie bereits beschrieben, haben nur wenige Teams eine Definition, was Story Points sind bzw. können diese genau beschreiben, sodass sie „messbar“ werden. Gerne wird dann darauf verwiesen, dass die Sprint Velocity (hier die Summe der abgeschlossenen Story Points eines Sprints) nach einer bestimm‐ ten Anzahl von Sprints anzeigt, was das Team in einem Sprint erledigen kann. Abgesehen davon, dass hier die Schätzung der Aufgabe mit der Schät‐ zung des Sprintinhalts vermischt wird, stellt sich die Frage, wie eine Velocity dies mit einer meist undefinierten Einheit „Story Points“ dieser anzeigen soll oder ob hier eine gewisse Korrelation mit Kausalität verwechselt wird. Grundsätzlich sollte es aber jedem Team selbst überlassen bleiben, wie der Prozess der Aufgabenbewertung aussieht und messbar gemacht wird, um sich bei zukünftigen Schätzungen verbessern zu können. <?page no="20"?> Wichtig bei Schätzungen ist jedoch immer eine klare Benennung der Schätzparameter. Damit ist gemeint, was geschätzt werden soll, also so etwas wie Story Points, Aufwand, Dauer oder Kosten. Schätzen darf nicht mit Planen verwechselt werden. Ein Beispiel für die Vermischung von Schätzung und Planung ist die Annahme, dass die Sprint Velocity mit Story Points zeigen würde, was das Team im Sprint gemäß der User Story Schätzung in Zukunft umsetzen kann. Die Schätzung der Story Points erfolgt in der gängigsten Definition auf Basis einer „Komplexität“, wie oben beschrieben, oder entspricht in seiner Form eher einem Aufwand und die Velocity bezieht sich auf die Dauer. Wer kennt nicht den Satz „Aufwand ist nicht Dauer“. Die Aussage muss ergänzt werden um „Komplexität ist weder Aufwand noch Dauer“ und bei Story Points ist keine Umrechnung in Aufwand oder Dauer möglich. Story Points als „Maß der Komplexität“ können also nicht in Geld umgerechnet werden. Deutlich wird dies daran, dass eine User Story mit zwei Story Points nicht doppelt so lange dauern oder doppelt so viel Aufwand erfordern muss wie eine User Story mit einem Story Point. Noch deutlicher wird dies daran, dass selbst wenn beispielsweise ein Team durchschnittlich 60 Story Points pro Sprint abarbeiten kann, nicht zwingend zwei User Stories mit je 21 Story Points in einem Sprint abgearbeitet werden können. Die Gründe hierfür können vielfältig sein. Für die Planung ist die Dauer von elementarer Bedeutung. Schätzungen der Dauer können nicht hinreichend genau sein, da zu viele Parameter die Dauer beeinflussen. Im agilen Umfeld schätzen Teams daher in der Regel den Aufwand von User Stories oder verwenden Story Points, um im Idealfall eine Aussage über die entwicklerunabhängige Komplexität der User Story in Relation zu anderen User Stories treffen zu können. Im ersten Fall sagt der Aufwand noch nichts über die Dauer aus. Die Dauer ergibt sich zwar nicht allein aus der Kapazität der Entwickler, aber zumindest ist der Zusammenhang zwischen Aufwand und Dauer auf der Basis der Kapazität zunächst nachvollziehbar. 20 2 Ursachen und Folgen von Fehleinschätzungen <?page no="21"?> Bei der Story Point Schätzung auf Basis der Komplexität wird zunächst davon ausgegangen, dass eine zum Beispiel doppelt so komplexe Aufgabe auch doppelt so viel Aufwand bedeuten kann. Dies ist nachvollziehbar, aber nicht automatisch richtig. Ansonsten wäre der Idealfall der „entwick‐ lerunabhängigen Komplexität“ nicht mehr unabhängig vom Entwickler bzw. der Anzahl der Entwickler. Es verhält sich ähnlich wie bei Aufwand zu Dauer auf Basis der Entwicklerkapazität - eine User Story mit einem geschätzten Aufwand von z. B. acht Stunden könnte zwar theoretisch von einem Entwickler mit einer Kapazität von acht Stunden pro Tag in acht Stunden Dauer erledigt werden, das heißt aber nicht, dass zwei Entwickler mit ausreichender Kapazität die Aufgabe in vier Stunden Dauer erledigen können. Es ist auch nicht sicher, dass zwei Entwickler mit einer Kapazität von jeweils vier Stunden pro Tag sich die Aufgabe teilen und in acht Stunden erledigen können. Es ist nicht einmal sicher, dass ein anderer Entwickler ebenfalls acht Stunden Aufwand für die Aufgabe benötigt, es könnte sogar weniger Aufwand sein, also die Dauer verkürzen, oder auch mit weniger Aufwand die Dauer verlängern, wenn z. B. die Kapazität des Entwicklers pro Tag nicht ausreicht. Der erforderliche Aufwand hängt also letztlich immer von den jeweils ausführenden Entwicklern ab. Die Dauer hängt von vielen zusätzlichen Parametern der Entwickler (wie Kapazität, Verfüg‐ barkeit, Performance, Wissensstand u. a.) und weiteren Einflüssen (z. B. Systemverfügbarkeit/ Performance, Abhängigkeiten im Team u. a.) ab. Die Annahme, dass alle Entwickler die gleiche Leistung bei gleicher Kapazität haben, führt daher in die Irre. Nicht nur die Schätzungen sind von einzelnen Entwicklern abhängig, sondern auch die Umsetzung. Das bedeutet leider auch, dass die Schätzung und die Leistung des oder der umsetzenden Teammitglieder erheblich voneinander abweichen können und sich zudem über die Zeit verändern. Die Verwendung von Komplexitätsschätzungen als Planungsgrundlage für einen Sprint ist daher riskant. Die Annahme, dass die Velocity der Story Points über einen bestimmten Zeitraum zeigt, was das Team im Sprint umsetzen kann, hat, auch wenn es so aussieht, keinen kausalen Zusammenhang. Spätestens bei der Sprintplanung wird es also eine neue Zeitschätzung der Entwickler geben müssen, ob etwas halbwegs realistisch im Sprint umsetzbar ist. Im Umkehrschluss bedeutet dies aber auch, dass zu frühe Aufwandsschät‐ zungen ebenfalls nur eine Orientierung sein können. Das haben Generatio‐ 2.1 Verschätzen leichtgemacht 21 <?page no="22"?> nen von klassischen Projektmanagern schmerzhaft lernen müssen. Eine Planung ist nur für einen kurzen Zeitraum verlässlich und auch dann nur mit einem gewissen, wenn auch geringen Risiko. Agile Methoden nutzen genau diesen Ansatz unter anderem mit Sprints. Unabhängig davon, was geschätzt werden soll, ist es wichtig, die Schätz‐ parameter klar zu benennen. Nur wenn diese klar definiert und messbar sind, kann an einer Verbesserung der Schätzungen gearbeitet werden. 2.2 Top 5 Gründe für Fehleinschätzungen Fehleinschätzungen haben viele Ursachen und wirken sich in agilen Projek‐ ten in den meisten Fällen weniger stark aus als in klassischen Projekten. Allein die Tatsache, dass Korrekturen in der nächsten Iteration vorgenom‐ men werden können, erleichtert den Umgang mit Fehleinschätzungen. Dies ist sicherlich ein Vorteil agiler Methoden. Er führt aber auch zu einem gewissen zeitlichen oder finanziellen Verlust im Projekt. Das Verständnis der primären Ursachen von Fehleinschätzungen hilft, die Auswirkungen zu minimieren. Diese sind: ■ Fehlende Informationen und Fehlinterpretation von Informationen ■ Selbstüberschätzung ■ Ungerechtfertigter Glaube an die Zuverlässigkeit der Schätzung ■ Unzureichende Kenntnisse über und Einflüsse auf die Schätzungen ■ Vermeidung von Risikoanalysen Fehlende Informationen und Fehlinterpretation von Informationen Unabhängig davon, dass sich nicht jeder Entwickler in allen Themengebie‐ ten auskennt und daher keine Bewertung zu einer Aufgabe abgeben möchte, die nicht in seinem Wissensgebiet liegt, sollte eine Aufgabe (User Story) den gewünschten Zielzustand so beschreiben, dass diese für den interessierten Entwickler nachvollziehbar ist. Bei der Erstellung einer User Story wird daher häufig davon ausgegan‐ gen, dass alle notwendigen Informationen zur Beurteilung der User Story vorhanden sind. Schließlich beschreibt eine User Story nicht nur den angestrebten Zielzustand, sondern enthält wichtige Zusatzinformationen wie „wer was und wofür braucht“. Die Lösung muss im Team gefunden 22 2 Ursachen und Folgen von Fehleinschätzungen <?page no="23"?> 3 Vgl. Oskamp, Stuart (1965): S.-261-265. werden. Gleichzeitig definiert die User Story die Akzeptanzkriterien, und gerade dieser Bereich wird allzu oft vernachlässigt. Diese Informationsgewinnung ist ein kontinuierlicher Prozess, zu dem auch die Schätzung gehört. Bevor jedoch eine User Story geschätzt werden kann, ist ein gewisser Informationsstand erforderlich. Die Annahme, dass eine Schätzung nahezu 100 % genau wäre, wenn nahezu 100 % der Informa‐ tionen über die Aufgabe verfügbar wären, ist nicht korrekt. Eine Fallstudie von Stuart Oskamp zeigte, dass das Vertrauen einer Gruppe, richtig zu liegen, von 33 % auf 53 % anstieg, nachdem die Gruppe mehr Informationen erhalten hatte. Die Genauigkeit verbes‐ serte sich jedoch nicht wesentlich und blieb unter 30-%. 3 Nicht nur diese Fallstudie, sondern auch die Praxis zeigt, dass mehr Infor‐ mation nicht unbedingt zu einer besseren Einschätzung führt. Es stellt sich auch die Frage, wie viele Informationen noch benötigt werden, um eine genauere Schätzung abgeben zu können und welchen Wert es hat, wenn mehr Informationen zur Verfügung stehen. Es geht also auch um die Kosten der Informationsbeschaffung und damit um die Zeit, die das Entwicklungsteam durch die Informationsbeschaffung verliert. Als Lösung werden gerne sogenannte Spike Stories (oder einfach nur Spike) genannt, ganz grob gesagt versteht man darunter User Stories zur Analyse und Informationsbeschaffung. Diese generieren jedoch zunächst keinen sogenannten Business Value, können aber helfen, Kosten zu sparen. Insbesondere dann, wenn durch kurze Analysen bessere Einschätzungen oder qualitativ bessere Ergebnisse generiert werden können, die letztlich einen Wert generieren. Dennoch sollten auch Spike Stories unter dem Kosten-Nutzen-Aspekt betrachtet werden. Jede oder fast jede Aufgabe mit einem Spike zu evaluieren, würde über das Ziel hinausschießen. Außerdem werden die gleichen Informationen, so umfangreich sie auch sein mögen, sehr unterschiedlich interpretiert. Jeder Entwickler kann die Anforderung je nach Kenntnisstand, Erfahrung, Umfeld etc. anders inter‐ pretieren. Gleichzeitig wird es immer einen mehr oder weniger unterschied‐ lichen Informations- und Wissensstand im Team geben. Dementsprechend unterschiedlich werden die Bewertungen einer Aufgabe durch die einzelnen Entwickler ausfallen. Entscheidend ist, dass keine „Extreme“ der Einschät‐ 2.2 Top 5 Gründe für Fehleinschätzungen 23 <?page no="24"?> 4 Vgl. Svenson, Ola (1981): S.-143-148, zung entstehen. Gleichzeitig ist es ein Ziel, zu erkennen, wer möglicherweise über wichtige Informationen verfügt, die die Gruppe nicht hat und die für die Bewertung relevant sein könnten. Ein weiterer wichtiger Punkt ist, dass bereits die Formulierung der Aufgabenstellung die Bewertung beeinflusst. Eine der bekanntesten Un‐ tersuchungen zur illusorischen Überlegenheit basierte auf der Frage, ob sich Autofahrer für besser als den Median halten. In dieser Studie hielten sich 93 % der Befragten für besser als der Durchschnitt. Das hier darge‐ stellte Problem der Informationsinterpretation liegt jedoch nicht in der erwarteten Selbstüberlegenheitseinschätzung der Befragten, sondern in der Fragestellung selbst. Die Interpretation der Frage kann sehr unterschiedlich ausfallen. Der eine hält sich für einen guten Autofahrer, weil er jung und reaktionsschnell ist, der andere, weil er jahrelange Erfahrung hat, während ein Dritter seine Einschätzung auf seine Unfallstatistik zurückführt. 4 Auch die Präsentation der User Story beeinflusst die Bewertung. Allzu oft ist zu beobachten, dass der Product Owner seine Einschätzung unterschwel‐ lig in die Anforderungsformulierung oder in die mündliche Diskussion einbringt. Die Sensibilisierung des Product Owners für eine möglichst neutrale Darstellung der User Stories ist daher ebenfalls ein Aspekt zur Verbesserung der Schätzungen. Selbstüberschätzung Eine Erkenntnis der Psychologie über das Urteilsvermögen ist, dass Men‐ schen sich ihrer selbst übermäßig sicher sind. Dies ist auch in Teams fast überall anzutreffen. Die Folgen sind typische Unterschätzungen von Auf‐ wand und Dauer von Aufgaben. Dieser Effekt tritt verstärkt bei vermeintlich „einfachen“ User Stories auf, bei denen sich die Entwickler kompetent fühlen und sicher sind, dass sie es „schaffen“ (bei schwierigen Aufgaben kehrt sich der Effekt eher um). Dies äußert sich dann in langen Durchlaufzeiten (cycle time) der User Stories; teilweise über mehrere Sprints mit Auswirkungen und Verzögerungen auf andere Produktteile. Im Extremfall wird das Team durch die häufigen Verschiebungen der User Stories und das Verfehlen des Sprintziels demotiviert. Die Folge ist eine Überschätzung von Aufwand/ Dauer - selbst bei einfachen Aufgaben. Es kommt zu immer mehr „Pufferbildung“, wodurch immer weniger pro Sprint 24 2 Ursachen und Folgen von Fehleinschätzungen <?page no="25"?> geplant wird. Zwar können so von den wenigen geplanten User Stories mehr im Sprint umgesetzt werden, aber immer noch nicht alles - trotz des „Puffers“. Selbst wenn die Entwickler nach kurzer Zeit feststellen, dass sie doch weniger Zeit benötigen, wird diese nicht genutzt, um andere Aufgaben in Angriff zu nehmen. Das liegt nicht an der Empfehlung, den Sprint nach dem Start möglichst nicht mehr zu verändern, das würde Scrum auch nicht vorgeben, sondern unter anderem an zwei Effekten des menschlichen Verhaltens. ■ Erstens das Parkinson’sche Gesetz in leichter Abwandlung: „Die Arbeit wird immer so weit ausgedehnt, wie Zeit für die Erledigung der Aufgabe zur Verfügung steht“ und ■ zweitens das Studentensyndrom: „Mit dem Beginn der Arbeit wird bis zum letzten Moment gewartet“. Aus dem ersten „Gesetz“ folgt, dass kaum etwas früher fertig wird, und in Kombination mit dem zweiten „Effekt“ besteht ein hohes Risiko, dass es am Ende doch nicht fertig wird. Fehleinschätzung der eigenen Leistung Die wohl stärkste Ausprägung der Selbstüberschätzung ist die Fehleinschät‐ zung der eigenen Leistungsfähigkeit. Wenn das Risiko negativer Konsequen‐ zen gering ist oder es sich nicht um wirklich wichtige Dinge im Leben handelt, verstärkt sich dieses Verhalten. Dies wirkt sich direkt auf die Einschätzung der Aufgaben aus, die dann in der Regel zu niedrig ausfällt. Die eigenen Fähigkeiten einschließlich des eigenen Fachwissens, die Kon‐ trolle über die Umsetzung und die Erfolgsaussichten werden überschätzt. Die Einschätzung der Aufgaben in der Gruppe scheint auch dann verstär‐ kend zu wirken, wenn die Zuordnung der Entwickler noch nicht feststeht. Die Überschätzung der eigenen Fähigkeiten in Verbindung mit fehlender Verantwortung führt zu einer noch optimistischeren Einschätzung. Bei eigener Verantwortung setzt das Erwartungsmanagement ein, das die Einschätzung pessimistischer werden lässt, aber immer noch zu optimis‐ tisch, um vor der Gruppe nicht zu schlecht dazustehen. 2.2 Top 5 Gründe für Fehleinschätzungen 25 <?page no="26"?> 5 Vgl. Kruger, Justin & Dunning, David (1999): S.-1121-1134. Überzeugung, besser als der Durchschnitt zu sein Neben der Fehleinschätzung der eigenen Leistung wirkt sich auch die Überzeugung, besser als der Durchschnitt zu sein, deutlich negativ auf die Schätzgenauigkeit aus. Wie bereits erwähnt, ist eine der bekanntesten Untersuchungen zur illusorischen Überlegenheit die Befragung amerikanischer Autofahrer, ob sie sich für besser als den Median halten. Das Ergebnis: 93 % der Befragten hielten sich für besser als der Durchschnitt. Auch wenn hier sicherlich die Fragestellung das Ergebnis beeinflusst hat, zeigt sich auch in vielen anderen Untersuchungen, dass sich die meisten Menschen anderen überlegen fühlen. Besonders häufig tritt dieser Effekt bei Entwicklern bei der Bewertung einfacher Aufgaben auf, von denen an‐ genommen wird, dass sie leicht und erfolgreich zu bewältigen sind. Verstärkt wird dies durch eine unbewusste Inkompetenz in den Themenbereichen der Aufgabe bei gleichzeitiger Ignoranz möglicher Unzulänglichkeiten bei bewusster Inkompetenz. In der Folge werden die eigenen Fähigkeiten überschätzt, was zu opti‐ mistischen Einschätzungen führt (sogenannter Dunning-Kruger-Effekt). 5 Umgekehrt werden bei hoher Kompetenz die eigenen Fähigkeiten eher unterschätzt, was zu pessimistischen Einschätzungen führt. Gleiches gilt, wenn eine Aufgabe als „sehr schwierig“ eingestuft wird. Insbesondere wenn es sich um eine Aufgabe handelt, die eine gewisse Aufmerksamkeit oder einen gewissen Erfolgsdruck erfordert, kommt im Rahmen des „Erwartungs‐ managements“ ein „Zweckpessimismus“ zum Tragen. Das heißt, es wird ein defensiver Pessimismus an den Tag gelegt, um die Enttäuschung zu verringern, die einer zu optimistischen Einschätzung folgen würde. Dies ändert jedoch nichts an der Überzeugung, überdurchschnittlich gut zu sein. Ein weiterer Aspekt des Überlegenheitsgefühls kann sich in der Unter‐ drückung anderer im Team zeigen. Dies ist zwar nicht so offensichtlich bzw. der erfahrene Scrum Master wird dies unterbinden, kann aber sehr unter‐ schwellig in Diskussionen über die Bewertung von Aufgaben auftauchen. Dies ist z. B. bei Gruppendiskussionen im Rahmen von Story Point Poker ein Risiko. Oft setzt sich eine Meinung durch, die dann als Konsens akzeptiert 26 2 Ursachen und Folgen von Fehleinschätzungen <?page no="27"?> wird. Andere Meinungen können dadurch nicht ausreichend berücksichtigt werden. Häufigere Fehleinschätzungen sind die Folge. Die Neigung zu genauen Schätzungen Aus der Fehleinschätzung der eigenen Fähigkeiten und dem Glauben, über‐ durchschnittlich gut zu sein, entsteht die Neigung, sehr genaue Schätzungen abzugeben. Überpräzision ist das übertriebene Vertrauen darauf, die Wahrheit zu kennen. Risiken und Ungewissheiten werden ausgeblendet. Es wird nicht mehr kommuniziert, dass es mit einer gewissen Wahrschein‐ lichkeit zwischen fünf und zehn Tagen Aufwand sein könnte, sondern es sind genau sechs, maximal sieben Tage und da ist man sich sehr sicher. Es wird also ein sehr enger Bereich als Schätzung angegeben, der aus Sicht des Schätzers mit hoher Wahrscheinlichkeit richtig sein soll. Dieses so genannte Konfidenzintervall gibt den Bereich „von bis“ mit einer vorgegebenen oder gewünschten Wahrscheinlichkeit an. Die Fibonacci-Folge kann auch zur Intervallbildung verwendet werden, indem nicht die Zahl der Fibonacci-Folge als Zielwert betrachtet wird, sondern der „Maximalwert“ eines Bereichs. Der „Minimalwert“ dieses Bereichs ist dann die vorhergehende Zahl der Fibonacci-Folge. Für das Intervall sind diese Werte dann mit größer (>) und klei‐ ner/ gleich (<=) zu kennzeichnen, so dass sich z. B. ein Intervall von > fünf bis <= acht oder von > acht bis <= 13 Story Points ergibt. Ein Konfidenzintervall liegt jedoch nur dann vor, wenn für die Intervalle Eintrittswahrscheinlichkeiten angegeben werden. Ungerechtfertigter Glaube an die Zuverlässikeit der Schätzung Es wird oft gesagt, dass man an den Erfolg glauben muss, dann wird er sich einstellen. Als Beispiel werden die erfolgreichen Menschen der Welt angeführt, die immer an ihren Erfolg geglaubt haben. Eine „Wenn man nur 2.2 Top 5 Gründe für Fehleinschätzungen 27 <?page no="28"?> fest genug an etwas glaubt, dann ist alles möglich“-Mentalität lässt sich jedoch weder im Leben noch im agilen Umfeld bestätigen. Der feste Glaube, selbst fliegen zu können, indem man wie ein Vogel mit den Armen auf und ab schlägt, hilft nicht wirklich beim Fliegen. Solange es nicht schadet, hilft der Glaube oft, alternative Wege zum Erfolg zu finden und andere zu inspirieren. Der Glaube an den Erfolg hilft, sich länger mit einer Sache zu beschäftigen und nicht aufzugeben, wenn sich der gewünschte Erfolg nicht sofort einstellt. Umgekehrt, wenn der Glaube an den Erfolg fehlt, wird wahrscheinlich weniger getan, um den Erfolg zu ermöglichen. Es ist jedoch nicht notwendig, an den Erfolg zu glauben, um erfolgreich zu sein. Der feste Glaube an sehr unwahrscheinliche oder unmögliche Dinge kann jedoch großen Schaden anrichten. Im agilen Umfeld gilt mehr „fail fast“. Es kostet das Unternehmen weniger, wenn früh genug erkannt wird, dass etwas nicht in der gewünschten Form umsetzbar ist. ■ Denn erstens ist „Glauben“ nicht „Wissen“ und ■ zweitens trägt Glauben nicht zur Verbesserung von Schätzungen bei. Schätzungen werden bis zu einem gewissen Grad durch mehr Wissen, also Information, verbessert. Der Fokus sollte also darauf liegen, den Informa‐ tionsgehalt so anzureichern, dass die Qualität der Schätzungen optimiert werden kann. Das Mittel der Wahl im agilen Umfeld ist der „Spike“. Der Effekt des „Wunschdenkens“ bzw. des übertriebenen Optimismus, bei dem die Erfolgswahrscheinlichkeit aufgrund der Wünschbarkeit über‐ schätzt wird, tritt glücklicherweise nicht so häufig auf. Dennoch sollte er nicht unterschätzt werden. Untersuchungen haben gezeigt, dass den Probanden Optimismus wich‐ tiger war als die Genauigkeit einer Schätzung, weil sich Optimismus besser anfühlt und gefühlt zu besseren Ergebnissen führt. Dass zumindest der zweite Punkt nicht unbedingt zutrifft, wurde oben beschrieben. Dennoch sind optimistische Aussagen an der Tagesordnung. Vor allem, wenn es um Zeitpläne oder Umsatzprognosen von Unternehmen geht. Beides relativiert sich dann im Laufe der Zeit, wenn sich herausstellt, dass die optimistischen Prognosen nicht eintreffen. Zusammenfassend kann 28 2 Ursachen und Folgen von Fehleinschätzungen <?page no="29"?> 6 Vgl. Merton, Robert K.und Zuckerman, Harriet (1988): S.-606-623. 7 Vgl. Peter, Laurence J.und Hull, Raymond (1969). also gesagt werden, dass ein hoher Optimismus die Probleme erst später erkennen lässt. Dies wäre jedoch nicht im Sinne der agilen Methoden. Glücklicherweise neigen die Entwickler, insbesondere bei wichtigen The‐ men mit hoher Öffentlichkeitswirkung, eher zu einem defensiven Pessimis‐ mus, um die Enttäuschung über zu optimistische Vorhersagen zu reduzieren. Realistische Schätzungen, die weder zu optimistisch noch zu pessimistisch sind, sollten jedoch das erstrebenswerte Ziel sein. Natürlich ist immer wieder der Effekt zu beobachten, dass Menschen, die als erfolgreich gelten und ihren Erfolgsglauben offen zeigen, in der Regel auch später erfolgreicher sind als andere. Nicht kausal, weil sie an ihren Erfolg geglaubt haben, sondern weil ihnen aufgrund früherer Erfolge in der Regel andere Mittel zur Verfügung stehen, um erfolgreich zu sein. Meist im Sinne von mehr Aufmerksamkeit, Unterstützung von Stakeholdern, besserem Netzwerk/ Kontakten zum Top-Management etc. Das Ganze nennt sich Matthäus-Effekt 6 oder besser bekannt aus Volks‐ weisheiten wie „Wer hat, dem wird gegeben“ oder „Der Teufel macht immer auf den größten Haufen“. Der Glaube an den Erfolg und das Vertrauen auf die Erfolge der Vergangenheit führen jedoch oft dazu, dass neue Erkenntnisse, die z. B. für Bewertungen notwendig sind, ignoriert werden. Das Festhalten an dem, was einmal erfolgreich war, muss nicht zum erneuten Erfolg führen. Fähigkeiten, die in früheren Projekten oder Positionen erworben wurden, sind nicht unbedingt auf neue Umgebungen übertragbar. Ein klassisches Beispiel ist die Beobachtung, dass Menschen in einer Hierarchie dazu neigen, immer auf der Ebene ihrer jeweiligen Inkom‐ petenz aufzusteigen (Peter-Prinzip) 7 . So kann es durchaus sein, dass man auch in einem Projekt oder Vorhaben eine Ebene erreicht, auf der man nicht mehr kompetent ist. Insbesondere ehemals erfolgreiche und damit anerkannte Entwickler, also Experten auf ihrem Gebiet, neigen zudem dazu, sich für etwas Besseres zu halten und daher auch bessere Schätzungen abzugeben. Ihr Glaube an den 2.2 Top 5 Gründe für Fehleinschätzungen 29 <?page no="30"?> Erfolg bzw. die Richtigkeit ihrer Aussagen verleitet viele andere Teammit‐ glieder dazu, diese Aussagen zu glauben, ohne sie zu hinterfragen oder sich eine eigene Meinung zu bilden. Die Auswirkungen auf die Schätzungen sind entsprechend negativ. Jedes Team muss daher auch einen geeigneten Weg finden, besser mit Schätzungen umzugehen, um am Ende die eigenen Vorhersagen erfüllen zu können. Der feste Glaube oder das starre Festhalten an vorgegebenen Methoden und Vorgehensweisen führt nicht zum Erfolg. Nicht umsonst findet in einem agilen Umfeld immer wieder eine Anpassung an neue Erkenntnisse statt. Leider geschieht dies bei der Bewertung von Aufgaben viel zu selten. Nur mit nachvollziehbaren Metriken zur Bewertung der Bewertungsergebnisse können Erkenntnisse für zukünftige Schätzungen abgeleitet werden. Diese bilden die Grundlage für die Kalibrierung der Teammitglieder für realistischere Schätzungen, die nicht nur auf Glauben basieren und somit mit höherer Wahrscheinlichkeit zum Erfolg führen. Unzureichende Kenntnisse über und Einflüsse auf die Schätzungen Im Allgemeinen sind Menschen, einschließlich der Teammitglieder, entwe‐ der übermäßig zuversichtlich oder sehr unsicher, wenn es darum geht, Dinge zu beurteilen. Ersteres ist typischer. Wenn ein Entwickler wenig oder gar nichts über eine Aufgabe weiß oder unsicher ist, wird er sich nur zu 50 % oder weniger sicher sein, mit seiner Einschätzung richtig zu liegen. Wenn er absolut sicher ist, dass er richtig liegt, wird er 100 % angeben. Die meisten werden jedoch irgendwo dazwischen liegen. Die Einschätzung der Wahrscheinlichkeit, richtig zu liegen, ist ein zentra‐ ler Punkt jeder Schätzmethode. Am Ende einer Story Point Poker Runde wird wahrscheinlich jeder denken, dass er zwischen 90 % und 100 % richtig liegt, obwohl die tatsächliche Wahrscheinlichkeit, richtig zu liegen, viel geringer sein wird. Je mehr Erfahrung im Laufe des Projekts gesammelt wird, desto sicherer fühlen sich die Schätzenden. So entsteht schnell der Glaube, dass Erfahrung die besten Schätzungen hervorbringt. Reine Erfahrungswerte allein helfen aber meist nicht weiter, da sie sich nicht ohne weiteres auf neue Anforderungen übertragen lassen. Zudem bestehen diese „Erfahrungen“ meist nur aus der gefühlten Dauer ohne initiale Aufwandsschätzungen und beeinflussende Parameter wurden ver‐ gessen oder ignoriert. Gleichzeitig neigen nicht nur Entwickler dazu, ihr 30 2 Ursachen und Folgen von Fehleinschätzungen <?page no="31"?> persönliches Wissen zu überschätzen oder unbewusst davon auszugehen, nahezu alle Fakten und Risiken zu kennen. Vielmehr ist es weit verbrei‐ tet, die Einflussfaktoren von Abschätzungen nicht zu kennen oder nicht zu berücksichtigen. Die Methodenkompetenz für Schätzungen beschränkt sich zudem auf die Grundlagen agiler Schätzmethoden. Darüber hinaus stehen in der Regel keine verwertbaren Daten zur Analyse vergleichbarer Elemente zur Verfügung oder es werden keine Metriken zur Verbesserung der Schätzungen eingesetzt. Letztlich stellen „Schätzungen auf Basis von Erfahrungen“ ein Risiko für agile Schätzmethoden dar. Da es leider keine objektiven und immer richtigen Schätzungen geben wird, bleibt nur die Möglichkeit, subjektive Wahrscheinlichkeitsschätzun‐ gen zu verbessern. Dies wird auch als Kalibrierung bezeichnet. Sie löst natürlich nicht alle Schätzprobleme, kann aber wesentlich dazu beitragen, die Qualität der Schätzungen zu verbessern. Vermeidung von Risikoanalysen Die „Illusion der Kontrolle“, ein Unterpunkt der Fehleinschätzung der eigenen Leistungsfähigkeit, beschreibt die Tendenz von Entwicklern, sich so zu verhalten, als hätten sie eine gewisse Kontrolle über den Verlauf der Entwicklung, obwohl sie diese in Wirklichkeit nicht haben. Externe Einflüsse stellen lediglich ein Risiko dar. Auf der anderen Seite neigen Scrum Master oder Product Owner dazu, zu unterschätzen, wie viel Kontrolle sie über den Entwicklungsverlauf haben. Denn gerade durch die Scrum- Routinen können sie sehr viel Kontrolle und Einfluss ausüben. Der Punkt dahinter ist, dass es viele Aspekte gibt, die den Aufwand oder die reibungslose Durchführung der Aufgabe beeinflussen. Diese zu identifizieren, aufgabenspezifisch zu benennen und ihre Auswirkungen darzustellen, ist Inhalt der Risikoanalyse. Viele Risiken sind allgemeiner Natur und ergeben sich nicht direkt aus der zu bewertenden Aufgabe, können diese aber beeinflussen. Diese allgemeinen Risiken werden bei klassischen Projekten in der Regel im Rahmen des Risikomanagements und der Lessons Learned Diskussionen erfasst. Ziel der Lessons Learned ist es, Erfahrungswissen festzuhalten und zur Vermeidung von Fehlern wiederzuverwenden. Obwohl diese Veranstaltung fester Bestandteil jedes klassischen Projekts ist, werden die Ergebnisse nur selten für das nächste Projekt genutzt. 2.2 Top 5 Gründe für Fehleinschätzungen 31 <?page no="32"?> Der Ordner mit den Lessons Learned Ergebnissen landet in der un‐ tersten Schublade im Rollcontainer des Projektleiters und die Fehler werden im nächsten Projekt einfach wiederholt. Lessons Learned Diskussionen sind sinnvoll, wenn sie direkt in das Projekt integriert, also ein kontinuierlicher Prozess sind. Sie beginnen jedoch meist erst, wenn das Projekt an sich schon „tot“ ist. Es handelt sich also, wie bei anderen Katastrophen auch, eher um eine Post Mortem Analyse. Im agilen Umfeld kann eine Post Mortem Analyse nach Abschluss einer Iteration, eines Sprints oder einer einzelnen Aufgabe erfolgen oder wenn ein einzelnes Thema wie z. B. eine User Story einfach gescheitert ist. Bei Scrum geschieht dies in der Retrospektive. Die Erkenntnisse aus dieser Analyse können dann im weiteren Verlauf bzw. in weiteren Iterationen bzw. Sprints des Projekts sehr nützlich sein. Eine weitere gute Methode bei der agilen Schätzung wichtiger Tasks ist es, sich im Vorfeld zu überlegen, woran diese Tasks „sterben“ (schei‐ tern) könnten. Es handelt sich also um eine Pre Mortem Analyse. So wünschenswert es theoretisch sein mag, diese für jede Aufgabe im Voraus durchzuführen, so gering ist ihr praktischer Wert. Eine Pre Mortem Analyse ist nur dann sinnvoll, wenn eine zu bewertende Aufgabe einen gewissen Unsicherheitsfaktor mit entsprechend hohem Geschäftswert aufweist. Die Pre Mortem Analyse ist nicht mit der Spike Story zu verwechseln. Die Spike Story dient dazu, mehr Informationen zu einem Thema zu erhalten. Es kann jedoch sinnvoll sein, eine Pre Mortem Analyse in eine Spike Story zu integrieren, so dass die Ergebnisse bei der Bewertung berücksichtigt werden können. In der Praxis findet eine echte Risikobewertung bei Assessments eher selten statt und auch bei agilen Assessmentmethoden ist es bestenfalls nur ein Parameter im Assessment, ohne dass die Informationen ausrei‐ chend berücksichtigt werden. Die Kenntnis und Berücksichtigung von Risiken im Vorfeld helfen wesentlich bei der Bewertung von Aufgaben. 32 2 Ursachen und Folgen von Fehleinschätzungen <?page no="33"?> 3 Verlässliche Schätzungen? Im vorangegangenen Abschnitt wurden die Ursachen und Auswirkun‐ gen von Schätzfehlern untersucht. In den folgenden Kapiteln geht es um das Ziel, zu möglichst zuverlässigen Schätzungen zu gelangen, die weder deutlich zu hoch noch deutlich zu niedrig sind. So klar und einfach das klingt, so schwierig ist es umzusetzen. Am einfachs‐ ten wäre es wohl, im agilen Umfeld auf Schätzungen verzichten zu können. Gute Ansätze dazu finden sich unter #NoEstimate. Natürlich haben diese Ansätze nicht nur Vorteile, aber einige Punkte daraus würden Schätzungen sogar vereinfachen, wenn aus verschiedenen Gründen nicht auf Schätzun‐ gen verzichtet werden kann. Der Verzicht auf Schätzungen auf der Ebene der User Stories bedeutet jedoch nicht, dass keine Vorhersagen über die Entwicklung gemacht werden. Der Glaube, in der agilen Welt ganz ohne Schätzungen auskommen zu können, führt in der Regel schnell in eine Sackgasse. Die beiden Extreme „keine Schätzungen“ und „alles schätzen“ als einzige Optionen zu betrach‐ ten, wäre jedoch nicht zielführend. Geeignete Kombinationen helfen weiter. Dazu gehören sicherlich einerseits „kleine User Stories“ (z. B. mit nur einem Akzeptanzkriterium oder mit einem Aufwand von deutlich unter einem Tag) und andererseits Schätzungen auf höherer Ebene (z. B. nur auf Feature und/ oder Epic Ebene). Wie diese Kombination aussehen kann, muss (leider) jedes Team für sich selbst herausfinden. Zu vermeiden sind jedoch Schätzungen mit undefinierten und damit nicht messbaren Einheiten. Solche Schätzungen können nicht verbessert werden bzw. es entsteht allenfalls eine Scheinsicherheit und es sollte nicht versucht werden, die Schätzungen damit zu optimieren. Vielmehr sollte der Informationsgehalt, d. h. die Auseinandersetzung mit der Anforderung im Vordergrund stehen und ggf. der #NoEstimate-Ansatz in Betracht gezogen werden. <?page no="34"?> Unter der Voraussetzung, dass klar definierte Einheiten für die Schätzun‐ gen verwendet werden, sind die folgenden fünf Schritte hilfreich, um einen Mittelweg zwischen Über- und Unterschätzung zu finden: 1. Sensibilisierung des Teams für die verschiedenen Faktoren, die die Schätzungen beeinflussen, insbesondere bei Gruppendiskussionen und Konsensentscheidungen. 2. Kalibrieren des Teams anhand der Abweichungen zwischen den zuvor abgegebenen Schätzungen und den tatsächlich benötigten Werten. 3. Verwenden von Intervallen, um Aufgaben zu schätzen, und diese bewer‐ ten im Team anhand von Wahrscheinlichkeitsschätzungen. 4. Schätzungen in einen Wettbewerb umwandeln, um das Vertrauen in die Schätzungen zu erhöhen und festzustellen, ob weitere Maßnahmen oder Analysen erforderlich sind. 5. Ab einem bestimmten Punkt eine „Fehleranalyse“ der Schätzungen durchführen, um das „Erwartungsmanagement“ zu berücksichtigen. 34 3 Verlässliche Schätzungen? <?page no="35"?> 4 Kalibrierung und Optimierung Ein zentraler Ansatzpunkt zur Optimierung der Schätzungen ist die Bereit‐ stellung ausreichender Informationen und die Verbesserung der subjektiven Schätzungen. Wie bereits beschrieben, ist es selbst bei Verfügbarkeit aller Informationen zu den Aufgaben nicht möglich, 100 %-genaue Schätzungen abzugeben. Darüber hinaus ist es in der Regel schwierig, eine Schätzung abzugeben, z. B. wie viel Aufwand eine Aufgabe voraussichtlich erfordern wird. Einfacher ist es dagegen, eine bestimmte Wahrscheinlichkeit für das Eintreten eines Ereignisses anzugeben, z. B. die Wahrscheinlichkeit, dass es mit einem Aufwand von x Tagen erreicht werden kann, liegt irgendwo zwischen 50 und 70-%. Daher ist neben der Verfeinerung der Fähigkeiten zur Schätzung von Wahrscheinlichkeiten auch die richtige Menge an Informationen für eine verbesserte Schätzung relevant. 4.1 Kalibierung der Teammitglieder Die Kalibrierung von Teammitgliedern klingt wie ein Messgerät, das im Idealfall zu fast 100 % korrekte Schätzungen liefert. Glücklicherweise sind Teammitglieder keine Maschinen und die Kalibrierung von Teammitglie‐ dern ist kein mechanischer Prozess. Vielmehr geht es darum, eine Wahr‐ scheinlichkeitsschätzung so zu verbessern, dass sie weder zu optimistisch noch zu pessimistisch ist. Insbesondere eine übertriebene Zuversicht der Teammitglieder führt immer wieder zu späteren Problemen bei der Umset‐ zung. Bei der Kalibrierung geht es also auch darum, sich zu „erinnern“, wie die Fakten aussehen, um bessere Schätzungen abgeben zu können. Das Hauptziel besteht darin, die subjektiven Schätzungen zu verbessern, indem man sich der Einflüsse auf die Schätzungen bewusst wird und die Fähigkeit, Wahrscheinlichkeiten abzuschätzen, ständig verfeinert. Der Kalibrierungsprozess selbst besteht im Wesentlichen aus wenigen Schritten: 1. Einmalige Schulung zum Thema Kalibrierung 2. Entwicklung einer eigenen Kalibrierungs-/ Schätzmethodik im Team <?page no="36"?> 3. Anwendung der Methodik 4. Analyse der Daten (Schätzung vs. tatsächlicher Wert) 5. Anpassung/ Verbesserung der Methodik 6. Iterative Wiederholung der Anwendung, Analyse und Optimierung der Methodik Im ersten Schritt werden die Teammitglieder geschult und für Schätzungen sensibilisiert. Im Rahmen der Schulung wird das Team mit den Schätz- und Kalibrierungsmethoden vertraut gemacht. Es wird über die Bedeutung der Kalibrierung und die Auswirkungen von Verzerrungen bei Schätzungen informiert. Die Teilnehmer sollen dadurch in die Lage versetzt werden, sich bewusster zu werden, was für ihre Schätzungen relevant ist und welche Einflüsse es gibt. Neben dem theoretischen Teil sind praktische Übungen zur Anwendung besonders wichtig. Nach dem Training sollte das Team über einen ersten abgestimmten Entwurf der eigenen Methodik verfügen. Dieser Methodenentwurf entwickelt sich im Laufe der Zeit und ori‐ entiert sich typischerweise an folgendem Ablauf: Identifizierung der Schätzparameter: Zunächst muss klar definiert werden, was geschätzt werden soll. Werden also für User Stories die populären Story Points, der Aufwand, die Dauer oder vielleicht die Kosten geschätzt? Wenn der Parameter eine Einheit hat, sollte diese auch benannt werden, z. B. Kosten in Euro oder Aufwand in Stunden. Entwicklung von Schätzmethoden: Es werden die Techniken ent‐ wickelt oder ausgewählt, die das Team später für die Schätzungen verwenden wird. Dies können z. B. Ankertechniken, Skalierungsme‐ thoden oder statistische Modellierung sein. Typischerweise werden Referenzpunkte festgelegt. Dies können z. B. User Story Referenzen sein, für die z. B. genaue Ergebnisse aus der Vergangenheit vorliegen. Wahrscheinlich sind mehrere User Stories je nach Entwicklungsbe‐ reich notwendig, z. B. ein Referenzpunkt für Datenbankanforderun‐ gen und ein Referenzpunkt für UI-Anforderungen. Anhand dieses genau bekannten Referenzpunktes können alle Schätzungen für die Bereiche kalibriert werden. Natürlich sind die Entwicklungen nicht so eindimensional wie oben dargestellt, aber dies ist ein Ausgangspunkt. Daher müssen diese Referenzpunkte klar definiert, objektiv messbar und repräsentativ für die zu schätzenden Parameter sein. 36 4 Kalibrierung und Optimierung <?page no="37"?> Durchführung der Schätzungen: Das Team führt die Schätzungen anhand der erarbeiteten Methodik durch. Um spätere Auswertungen der Schätzungen zu ermöglichen, wird der Einsatz von Tools empfoh‐ len. In den meisten Fällen verwenden agile Teams bereits umfangrei‐ che Tools für das Backlog- und Sprint-Management. Diese können in der Regel genutzt werden, um die Datenerhebung zu erleichtern. Ziel ist der regelmäßige Vergleich mit Referenzpunkten. Basierend auf diesem Vergleich erhält das Team Feedback über die Genauigkeit seiner Schätzungen und wird dadurch ermutigt, seine Schätztechniken anzupassen. Analyse der Daten: Die gesammelten Daten über die Schätzungen der User Stories und des tatsächlichen Bedarfs werden analysiert, um Muster oder Trends in den Schätzungen zu identifizieren, jedoch nicht, um einzelne Teammitglieder in ihrer „Schätzleistung“ zu bewerten. Ziel ist es vielmehr, systematische Fehler in der Schätzgenauigkeit zu identifizieren, um daraus Maßnahmen ableiten zu können. Optimierung und Validierung der Methodik: Basierend auf den Ergebnissen der Datenanalyse können Anpassungen am gesamten Kalibrierungsprozess vorgenommen werden, um die Genauigkeit und Zuverlässigkeit der Schätzungen weiter zu verbessern. Dies könnte eine Änderung der Schätzmethode, zusätzliches Training, regelmä‐ ßige Schätzübungen oder die Einrichtung kürzerer Feedbackschleifen beinhalten. Eine Kalibrierung ist also keine einmalige Schulung oder Lessons Learned Veranstaltung, sondern ein kontinuierlicher Prozess zur Verbesserung der Schätzungen in allen Bereichen. Untersuchungen haben gezeigt, dass „unkalibrierte“ Probanden mit ihren Wahrscheinlichkeitsschätzungen zu 90 % richtig liegen, aber zu weniger als 50 % tatsächlich richtig liegen. Wenn ein kalibrierter Entwickler eine große Anzahl von Schätzungen vornimmt, wird er im Idealfall ungefähr so viele richtig eingeschätzt haben, wie er vorher erwartet hat. Wenn die Teammitglieder also theoretisch „perfekt kali‐ briert“ wären, würden ihre Schätzungen für Aufgaben, die beispiels‐ weise zu 90 % richtig sind, auch in 90 % der Fälle richtig sein. Ein nicht kalibriertes Teammitglied ist entweder übermäßig zuversichtlich und 4.1 Kalibierung der Teammitglieder 37 <?page no="38"?> glaubt z. B. zu 80 % richtig zu liegen, obwohl es vielleicht nur 50 % sind, oder ist eher wenig zuversichtlich und glaubt zu 50 % richtig zu liegen, obwohl es vielleicht 80-% sind. Hier das Verständnis für Sicherheit und Zuversicht zu schärfen, ist ein erster Schritt. Einiges davon kann sogar schon im Rahmen des Scrum- Events Retrospektive geschehen. Die Kalibrierung lässt sich daher sehr gut in die Retrospektive integrieren und erweitert die Veranstaltung z. B. um Quizfragen, die es dem Team ermöglichen, seine Fähigkeit zur Einschätzung von Wahrscheinlichkeiten anhand allgemeiner Themenbereiche und spezi‐ fischer Auswertungen aus den letzten Sprints zu verfeinern. Das Spiel kann so gestaltet werden, dass zunächst zwei oder drei allgemeine Fragen aus der realen Welt gestellt werden, z. B. die Frage nach dem Gewicht eines Dackels. Wenn die erste Frage beantwortet wurde und das tatsächliche Gewicht des Hundes bekannt ist, kann dieses Ergebnis als Bezugspunkt für die Schätzung des Gewichts anderer Hunde verwendet werden. Die zweite Frage könnte z. B. lauten: „Wie viel wiegt ein Rüde der Hunderasse Deutsche Dogge“. (Das Gewicht liegt hier zwischen 80 und 95 kg.) Da Doggen sehr große Hunde sind, könnte dieses Gewicht als zweiter Referenzpunkt für große Hunde verwendet werden. Als dritte Frage könnte nach dem Gewicht einer mittelgroßen Hunderasse gefragt werden, um einen weiteren Referenzpunkt zu erhalten. Durch die Einteilung in Gewichtsklassen kann abgeschätzt werden, dass die meisten anderen Hunderassen eine ähnliche Gewichtsverteilung aufweisen. Die Genauigkeit der Schätzung steigt mit der Anzahl der berücksichtigten Hunderassen. Die Kenntnis der Hunderassen und weiterer Informationen wie Größe oder Statur ist dabei von Vorteil. Auch der Inhalt der Frage spielt eine Rolle. Im Gegensatz zur ersten Frage, bei der es um das Gewicht eines Dackels geht, enthält die zweite Frage mehr Spezifikationen über den Hund. Die Dogge ist ein Rüde und die Rasse ist genauer definiert als beim Dackel. Dackel gibt es in vielen Varianten und das Gewicht variiert je nach Geschlecht erheblich. Die kleinsten Teckelrassen wiegen kaum mehr als 2,5 bis 3,5 kg. Auf diese Weise können Wahrscheinlichkeitsintervalle für das Gewicht von Hunden festgelegt werden, die für eine erste Einstufung von Hunden verwendet werden können. 38 4 Kalibrierung und Optimierung <?page no="39"?> Wichtig für die Bewertung ist immer der zugrunde liegende Informations‐ gehalt. Auf die Frage „Wieviel wiegt ein Auto? “ wird vermutlich jeder etwas anderes schätzen oder im Idealfall bereits nach einer Präzisierung der Frage fragen. Angaben zur Fahrzeugklassifizierung wie Kleinwagen, Mittelklasse usw. und/ oder zur Karosserie wie Cabrio, Kombi, SUV usw. können hilfreich sein. Der Felgendurchmesser wird eher keine große Rolle spielen. Bei der Frage „Wieviel wiegt eine Scheibe Salami? “ sind Durchmesser und Dicke wahrscheinlich wichtige Informationen. Die Zusammenset‐ zung sicherlich auch, aber sie könnte eine untergeordnete Rolle spielen. Je mehr Fragen zu Gewichten aus verschiedenen Bereichen gestellt werden, desto mehr wird sich das Wissen über die Klassifizierung von Gewichten verbessern. Allerdings nur in geringem Maße, wenn die Fragen zu unspezifisch sind. Dies ist daher auch Teil der Kalibrierung - die Fragestellung zu hinterfragen bzw. herauszufinden, welche Einflussfaktoren die Schätzungen beeinflussen und welcher Informationsgehalt notwendig ist, um etwas besser einschätzen zu können. Je klarer und verständlicher die Fragestellung ist, desto wahr‐ scheinlicher ist eine bessere Schätzung. Es ist auch zu berücksichtigen, dass Daten, Beweise und Erinnerungen, die es ermöglichen, eine Frage positiv, d. h. immer mit „ja“ zu beantworten, standardmäßig berücksichtigt werden. Dies liegt zum Teil daran, dass es einfacher ist, das Vorhandensein von etwas festzustellen als das Fehlen von etwas. Es macht also einen Unterschied, ob man fragt: „Ist die Annahme richtig, dass […]“ oder „Ist die Annahme falsch, dass […]“. In beiden Fällen wird alles in Betracht gezogen, um die Frage mit „Ja“ beantworten zu können. Aus diesem Grund werden Fragen oft so formuliert, dass sie mit größerer Wahrscheinlichkeit zu einer positiven Antwort führen. Der zweite Gesichtspunkt wird nicht mehr berücksichtigt. Es sollte daher auch vermit‐ telt werden, dass bei Wahrscheinlichkeitsabschätzungen im Zweifelsfall auch gegenteilige Fragen formuliert werden sollten. Nachdem die allgemeinen Fragen der realen Welt durchgespielt wurden, sollten die Bewertungen der Vergangenheit analysiert werden, bei denen es die größten Abweichungen zwischen den Schätzungen und den tatsäch‐ lichen Ergebnissen gab. Es wird also eine „Post Mortem Analyse“ durchge‐ 4.1 Kalibierung der Teammitglieder 39 <?page no="40"?> 8 Vgl. Mitroff, Ian I. (1998). führt. Wenn für die Aufgabe auch eine Pre Mortem Analyse durchgeführt wurde, kann der Vergleich sehr viele und wertvolle Informationen für die nächste Schätzung liefern. Dazu gehört auch, dass der Product Owner dazu beiträgt, die Informationsaufbereitung für die Schätzung zu verbessern, indem er erkennt, welche Informationen einen besonderen Einfluss auf die Schätzung hatten oder haben könnten. Die typischen Fragen, warum etwas im Sprint nicht fertiggestellt wurde, sind dagegen für die Schätzung wenig relevant - insbesondere, wenn die Wahrscheinlichkeit der Fertigstellung im Sprint bereits gering war. Wichtiger ist es daher, dem Team zu vermitteln, dass bereits Wunschden‐ ken oder zu großer Optimismus die Einschätzung der Wahrscheinlichkeit verzerren kann. Reiner Optimismus, etwas erreichen zu können, verbessert die Er‐ folgsaussichten in der Regel nicht. Im Gegenteil, Wunschdenken ist ein Haupthindernis für eine angemessene Vorbereitung, wodurch Probleme erst später auftreten oder erkannt werden. 8 Um dies zu verdeutlichen, ist es notwendig, die bisherigen Einschätzungen mit den tatsächlichen Werten zu vergleichen. Nur so kann aufgezeigt wer‐ den, an welchen Stellen es zu signifikanten Abweichungen gekommen ist. Dies sind dann gute Voraussetzungen, um die Genauigkeit der Schätzungen im Laufe der Zeit zu verbessern. Damit verringert sich automatisch auch die Gefahr der Selbstüberschätzung. Ganz wichtig ist, dass die verwendeten Metriken bzw. die Ergebnisse der Bewertung „Schätzung vs. tatsächliche Ergebnisse“ nicht zu Zielvorgaben im Sinne von „wir müssen unter 20 % Abweichung bleiben“ werden. Sonst gilt das leicht abgewandelte Goodhart’sche Gesetz: „Wenn eine Metrik zum Ziel wird, ist sie keine gute Metrik mehr“. Das bedeutet, dass das Team anfangen wird, die Metriken zu manipulieren, wodurch sie unbrauchbar werden. Natürlich können Schätzungen aus der Vergangenheit nicht immer auf zukünftige Schätzungen übertragen werden, aber es wird klarer, was wahr‐ scheinlicher ist. Ohne Schätztraining in den erforderlichen Bereichen auf Basis klar definierter und evaluierter User Stories ist eine qualitativ hoch‐ 40 4 Kalibrierung und Optimierung <?page no="41"?> wertige Schätzung kaum möglich. Dies spricht auf den ersten Blick für den Ansatz mit Referenz User Stories, nur können sich auch hier die Schätzungen und Parameter im Laufe der Zeit ändern. Am deutlichsten wird dies beim „Wissen“ über die einzelnen Bereiche, die am häufigsten bearbeitet werden. Wenn also bisher im Projekt 100 User Stories zu Datenbankthemen geschätzt wurden, aber nur drei zum User Interface, dann wird sich das auf die Qualität der Schätzungen pro Themenbereich auswirken. Eine Referenz User Story aus den Anfängen der Datenbankentwicklung im Projekt wird wahrscheinlich nicht mehr so relevant sein, aber für das User Interface schon. Ein weiterer Effekt ist die Beeinflussung durch falsch gewählte Referenz User Stories. Wird hier vor der Schätzung einer neuen User Story der Wert einer nicht passenden Referenzstory gezeigt, so beeinflusst dies bereits die Schätzung. Dieser sogenannte Ankereffekt tritt auch dann auf, wenn der Wert der falschen Referenzstory nichts mit der zu schätzenden User Story zu tun hat. Die Teammitglieder können dadurch in ihrer Schätzung so beeinflusst werden, dass ihre Schätzung in Richtung des gezeigten Ankers verzerrt wird. Der Glaube, dass die Schätzungen im Laufe des Projekts automatisch sehr genau werden, d. h. dass praktisch jeder im Team automatisch „kalibriert“ ist und daher nahezu perfekte Schätzungen abgibt, entspricht leider nicht der Realität. Nicht nur Entwickler neigen dazu, ihr persönliches Wissen zu überschätzen oder unbewusst davon auszugehen, nahezu alle Fakten und Risiken zu kennen. Vielmehr ist es weit verbreitet, die Einflussfaktoren von Abschätzungen nicht zu kennen oder nicht zu berücksichtigen. Die Methodenkompetenz für Schätzungen beschränkt sich auf die Grundlagen der agilen Schätzmethoden. Darüber hinaus stehen in der Regel keine ver‐ wertbaren Daten zur Analyse vergleichbarer Elemente zur Verfügung oder es werden keine Metriken zur Verbesserung der Schätzungen verwendet. Daher ist es wichtig, eine kontinuierliche Neukalibrierung auf der Grund‐ lage aktueller Informationen vorzunehmen. Obwohl ein Teil davon bereits im Rahmen des Scrum-Events Retrospektive angegangen werden kann, ist in der Regel eine umfassendere Maßnahme erforderlich, um das Team für die Prozesse und Einflüsse auf die Schätzungen zu sensibilisieren. Dabei geht es nicht darum, alle Teammitglieder in Wahrscheinlichkeitstheorie zu schulen. Außerdem hat auch die beste Kalibrierung ihre Grenzen und es geht eher darum, ein geeignetes Werkzeug für die tägliche Arbeit zur Verfügung zu haben. 4.1 Kalibierung der Teammitglieder 41 <?page no="42"?> 4.2 Optimierung der Information Die Entwickler gehen oft unbewusst davon aus, dass sie fast alle Fakten kennen, die sie eigentlich erst durch Rückfragen bei anderen Entwicklern oder durch Nachschlagen erfahren müssten, bevor sie eine genauere Ein‐ schätzung abgeben können. Gerade in einem neuen Team ist es daher wichtig, den Wissensstand der Entwickler im Team zu überprüfen. Am einfachsten kann dies im Team geschehen, indem der Entwickler anhand eines Themas erklärt, wie es funktioniert oder umgesetzt werden kann. Auf diese Weise werden Wissenslücken aufgedeckt und die Überschätzung des Wissens zu diesem Thema reduziert. Ein weiterer sehr wichtiger Teil ist die Frage, welche Informationen für die Aufwandsschätzung benötigt werden. Im Rahmen der Kalibrierung sollte der Product Owner zunehmend erkennen, welche Informationsaufbe‐ reitung zu einer Verbesserung der Schätzung beiträgt. Mittlerweile gibt es umfangreiche Beschreibungen, wie eine User Story aufgebaut sein sollte. Der INVEST-Ansatz zeigt alle notwendigen Voraussetzungen für eine User Story auf (siehe Abb. 1). Abb. 1: INVEST User Story In der Praxis zeigt sich jedoch, dass viele Product Owner wenig Erfahrung oder Ausbildung in diesem Bereich haben. Zudem fehlen oft weitere Informationen, um eine Abschätzung vornehmen zu können. Ein wichtiger Punkt ist zu klären, wie viele Informationen benötigt 42 4 Kalibrierung und Optimierung <?page no="43"?> werden, welchen Nutzen sie bringen und mit welchem Aufwand sie beschafft werden können. Es darf nicht vergessen werden, dass mehr Informationen über ein bestimmtes Maß hinaus die Genauigkeit der Schätzungen nicht verbessern. Die Verwendung von Spikes kann helfen, bessere Schätzungen zu erhalten. Dies vor jeder User Story zu tun, würde einem klassischen Projekt mit „Machbarkeitsstudie“ oder „Spezifikation“ ähneln. Der agile Gedanke würde verloren gehen. Stattdessen sollten Spikes sparsam und gezielt eingesetzt werden. Es wird daher empfohlen, Spikes nur bei Schätzungen einzusetzen, bei denen ein zu hohes Risiko besteht, dass die Schätzung nicht eingehalten wird und die Informationsbeschaffung einen signifikanten Mehrwert liefern kann. Ob ein Mehrwert erzielt werden kann, hängt davon ab, welchen Wert die Aufgabe durch die Implementierung erzeugt. Wenn der Product Owner keinen Wert für eine Aufgabe angibt oder der Wert nur so hoch ist wie die geschätzten Kosten einer mittleren Aufwandsschätzung, dann stehen Spikes nicht in einem Kosten-Nutzen-Verhältnis. In diesem Fall sollte kein Spike durchgeführt werden, da kein Mehrwert zu erwarten ist. Ob sich ein Spike lohnt, kann also grob bestimmt werden, indem man die Wahrscheinlichkeit einer Durchführung in beispielsweise x Tagen ermittelt und zunächst die Kosten bis zu dieser Schätzung bestimmt. Abb. 2: Berechnungsgrundlage zur Beurteilung einer Spike Story In dem in Abb. 2 gezeigten Beispiel wurde nach der Vorstellung der User Story geschätzt, dass der Aufwand sicher nicht mehr als 18 Tage betragen würde. Weniger als drei Tage wurden nur mit einer Wahrscheinlichkeit von 15 % geschätzt, bis zu 6 Tage mit ca. 50 %-iger Wahrscheinlicheit. Bis zu neun Aufwandstage wurden mit 4.2 Optimierung der Information 43 <?page no="44"?> 25 % eingeschätzt und es verbleibt ein Restrisiko von 10 %, dass es bis zu 18 Aufwandstage werden könnten. Kumuliert bedeutet dies, dass das Team zu 90 % sicher ist, dass es nicht mehr als neun Aufwandstage werden. Unter der Annahme, dass der Product Owner die Aufgabe mit einem Business Value von 10.000 € bewertet, sollte der Aufwand bei einem Tagessatz von 1.000 € nicht mehr als neun Tage betragen. Andernfalls würde die Aufgabe keinen Wertzuwachs generieren. Sollte die Aufgabe tatsächlich 18 Tage in Anspruch nehmen, würde dies einen Verlust von 8.000 € bedeuten. Wenn es möglich wäre, die Schätzung durch mehr Informationen zu verbessern und damit die Schätzung des Restrisikos von 10 % auf 0 % zu reduzieren, d. h. sicher zu sein, dass es keinen Verlust von 8.000€ geben wird, könnte es theoretisch sinnvoll sein, einen Spike für die Informationsbeschaffung einzuplanen. Die Wahrscheinlichkeit, dass der Aufwand mehr als neun Tage beträgt, liegt nur bei 10 %. Angenommen, der Product Owner betrachtet dies als eine Wette, bei der er mit einer Wahrscheinlichkeit von 10 % 8.000 € gewinnen könnte. Um den Erwartungswert dieser Wette zu berechnen, wird die Gewinnsumme mit der Wahrscheinlichkeit multipliziert - also 8.000 € * 10 % = 800 €. Daraus lässt sich ableiten, dass es sinnvoll sein könnte, bis zu 800 € in einen Spike zu investieren. Leider ist die Wahrscheinlichkeit, dass dadurch das Restrisiko von ursprünglich 10 % auf 0 % reduziert werden kann, deutlich geringer als 100 %. Im besten Fall sind es 50 % (= 5 % Restrisiko), eher noch deutlich weniger. Ausgehend vom besten Szenario mit 50 % würde sich der Erwartungswert auf 400 € reduzieren (8.000 € * 10% - 8.000 € * 5 % = 400 €). Ein Spike sollte in diesem Beispiel also nicht mehr als 400 € kosten. Dies würde auch bedeuten, dass der Aufwand für diesen Spike nicht mehr als vier Stunden betragen sollte, wenn wir der Einfachheit halber von einem Zehn-Stunden-Tag als Basis für die 1.000 € pro Tag (bei einem Stundensatz von 100 € pro Stunde) ausgehen. In diesem Beispiel wird es wahrscheinlich keinen Spike geben. Der Grund dafür ist, dass Entscheidungen leider nicht automatisch auf Basis eines erwarteten Nutzens getroffen werden. Um dies zu verdeutlichen, wird gerne die Geschichte des Wirtschaftsnobelpreisträgers Paul Samuelson herangezogen. Er hatte einem Kollegen eine Wette auf einen Münzwurf mit Kopf oder Zahl angeboten. Sollte der Kollege gewinnen, würde er ihm 200 Dollar zahlen, sollte er verlieren, müsste der Kollege 100 Dollar 44 4 Kalibrierung und Optimierung <?page no="45"?> 9 Samuelson, Paul A. (1963): S.-108-113. an Paul Samuelson zahlen. Er berechnet eine akzeptable Wette mit einer 50: 50-Wahrscheinlichkeit (die dritte Option „Münze bleibt auf dem Rand“ wird nicht berücksichtigt). Er hätte also einen positiven Erwartungswert von 50 Dollar. Der Kollege lehnt die Wette mit der Be‐ gründung ab, dass für ihn der mögliche Verlust von 100 Dollar schwerer wiegt als die kurzfristige Freude über den Gewinn von 200 Dollar. Dies ist auch das Prinzip der Prospect Theory, dass Verluste schwerer wiegen als Gewinne. Mit anderen Worten, Entscheidungen werden nicht automatisch auf der Grundlage des erwarteten wirtschaftlichen Nutzens getroffen. 9 Das Restrisiko von 10 % aus dem obigen Beispiel entspricht einem möglichen Verlust von 8.000 €. Es wäre also ein negatives Ereignis für den Product Owner, wenn es einträte. Die Prospect Theory besagt, dass Menschen bei vorhersehbaren negativen Ereignissen risikofreudiger sind und einen unsicheren, hohen Verlust einem sicheren, aber geringeren Verlust vorziehen. Bezogen auf das Restrisiko von 10 % bedeutet dies, dass wahrscheinlich keine Spikes eingesetzt werden und das Risiko akzeptiert wird. Hier muss ein Kompromiss zwischen vollständiger Risikovermeidung und Akzeptanz aller Risiken gefunden werden. Daher ist ab einem gewissen Unsicherheitsgrad der Schätzungen zu überlegen, ob eine kurze Risikoabschätzung ausreicht oder ob ein Spike verwendet wird, um den Informationsgehalt der abzu‐ schätzenden Aufgabe zu verbessern. Wenn Intervalle mit Wahrscheinlich‐ keiten wie im obigen Beispiel verwendet werden, wäre eine Entscheidung auf der Grundlage eines ökonomischen Erwartungsnutzens möglich, aber es bleibt dem Team überlassen, ob es diesen nutzen will. Darüber hinaus ist zu berücksichtigen, dass mehr Informationen die Schätzungen nicht in gleichem Maße verbessern, wie die Fallstudie von Stuart Oskamp gezeigt hat. Ein weiteres Muster ist, dass, wenn das Team noch nicht lange an dem Produkt arbeitet, die Spikes zu Beginn in der Regel mehr Informationen liefern als in späteren Phasen der Produktentwicklung. 4.2 Optimierung der Information 45 <?page no="46"?> Darüber hinaus werden dieselben Informationen, so umfangreich sie auch sein mögen, unterschiedlich interpretiert. Jeder Entwickler kann die Anforderung anders interpretieren, abhängig von seinem Wissen, seiner Erfahrung, seinem Umfeld usw. Gleichzeitig wird es im Team immer einen mehr oder weniger unterschiedlichen Informati‐ ons- und Wissensstand geben. Entsprechend unterschiedlich werden die Einschätzungen der einzelnen Entwickler zu einer Aufgabe sein. Entschei‐ dend ist, dass keine „Extreme“ der Einschätzung entstehen. Gleichzeitig ist es ein Ziel zu erkennen, wer möglicherweise über wichtige Informationen verfügt, die die Gruppe nicht hat und die für die Bewertung relevant sein könnten. 46 4 Kalibrierung und Optimierung <?page no="47"?> 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr Es hat sich nicht bewährt, Schätzungen auf eine „exakte Zahl“ zu reduzieren. In der Praxis wird es kaum vorkommen, dass eine Aufgabe, für die ein Aufwand von acht Stunden geschätzt wird, auch genau acht Stunden Aufwand erfordert. Also nicht mehr, aber auch nicht weniger. Einfacher ist es zu sagen, es wird wahrscheinlich zwischen sechs und zehn Stunden Aufwand erfordern und auf Nachfrage das „wahrscheinlich“ mit einem Wahrscheinlichkeitswert zu konkretisieren. Nun ist es unvermeidlich, dass die Meinungen der Entwickler über den beispielhaften Aufwand von sechs bis zehn Stunden weit auseinander gehen. Dies gilt sowohl für die Stunden als auch für die Einschätzung der Wahr‐ scheinlichkeit. Hier ist es wichtig, „extreme“ Einschätzungen zu vermeiden. Jeder im Team hat viele Gründe, auf denen die jeweiligen Einschätzungen beruhen. Im Team kommen diese Informationen zusammen und können helfen, ein vollständigeres Bild zu erhalten. Die Nutzung dieser Schwarmintelligenz ist daher ein klassischer Ansatz, der auch in vielen agilen Schätzmethoden verwendet wird. Schätzungen können daher erheblich verbessert werden, wenn zusätz‐ liche Risikoinformationen bereitgestellt werden. 5.1 Berechnung von Konfidenzintervallen Anstelle von exakten Werten sollten Intervalle verwendet werden. Auch die Story Points können als Intervall betrachtet werden, denn obwohl es sich nur um eine Zahl handelt, kennt jeder die vorhergehende Zahl aus der Fibonacci- Reihe. Die Intervallgrenzen reichen von „größer als die vorherige Zahl“ bis „aktuelle Zahl“ - also z. B. ein Intervall von >5 bis <=8 Story Points. Die Angabe eines Intervalls ist auch sehr hilfreich für Schätzungen, die auf dem Aufwand in Zeiteinheiten basieren. So könnte ein Intervall von >5 Stunden bis <=10 Stunden gebildet werden. <?page no="48"?> Zu kleine und zu große Intervalle sollte man nicht verwenden. Die richtige Spanne hängt sicherlich von Größenordnung und dem Kontext ab. Bei der Fibonacci-Folge beträgt der Abstand zwischen den höheren Zahlen etwa 62-%. Bei Zeiteinheiten werden häufiger Intervalle mit 50 % bis 100 % Abstand genutzt. Wenn z. B. zehn Stunden als erstes Schätzergebnis ermittelt wurde, könnte das Intervall zehn Stunden +/ - 50 % (d. h. fünf bis 15 Stunden) verwendet werden. Dies ist immer noch eine ausreichend große Spanne. Wenn das Team dann in einer weiteren Runde die Wahrscheinlichkeit schätzen würde, wäre dies ein Konfidenzintervall. Das Team könnte, ähnlich wie beim Story Point Poker, diskutieren, zu wie viel Prozent (z. B. 80 %) es sicher ist, dass der Aufwand in diesem Intervall liegt. Wenn es sich nicht um eine sehr kleine Aufgabe handelt, sollte die Wahrscheinlichkeit nicht bei 100 % liegen. Wenn dies der Fall ist, könnte das Intervall zu groß sein oder das Team könnte zu sehr glauben, alles zu wissen und in die Gewohnheit verfallen, sehr genaue Schätzungen abgeben zu wollen. In der Regel liegt die Wahrscheinlichkeit, das Intervall zu treffen, zwischen 50 und 80 %. Liegt sie darunter, ist das Intervall zu klein oder passt nicht zur Schätzung. Es stellt sich dann die Frage, in welche Richtung die verbleibenden Prozentsätze tendieren. Aus diesem Grund werden bei Konfidenzintervallen immer meh‐ rere Intervalle verwendet. Abb. 3: Beispiel für die Verwendung von Konfidenzintervallen In dem Beispiel in Abb. 3 wird ein geschätzter Aufwand von zehn Stunden als Mittelwert angenommen. Davon wird ein Intervall bis zum Mittelwert und ein Intervall darüber mit jeweils +/ - 50 % des Mittelwer‐ tes gebildet, um die Tendenz „unter oder über dem Mittelwert“ besser erkennen zu können. Unterhalb und oberhalb sind wiederum die Inter‐ valle „kleiner und größer“ (hier <5 und >15) des unteren und oberen Mittelwertintervalls. Für jedes Intervall kann so die Wahrscheinlichkeit 48 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr <?page no="49"?> bestimmt werden, mit der der Aufwand in diesem Intervall liegt. Die Summe sollte 100 % ergeben. Wenn sie nicht auf 100 % normiert ist, wird sie wahrscheinlich größer als 100 % sein. Sie können jedoch die Tendenz anzeigen und später auf eine 100 %-Skalierung gebracht werden. Zu viele Intervalle helfen nicht automatisch. In der Regel werden drei bis fünf Intervalle gebildet, je nach Definition der zu verwendenden Intervalle. Aus den Wahrscheinlichkeiten lässt sich ableiten, welche Maßnahmen noch erforderlich sein könnten, um die Schätzung zu optimieren bzw. Risiken frühzeitig zu erkennen. Eine Maßnahme bei einem sehr niedrigen Konfidenzniveau könnte die Durchführung eines Spikes sein, um mehr Informationen über das Thema zu sammeln. Eine andere Maßnahme bei niedrigem Konfidenzniveau könnte darin bestehen, die Risiken zu identifi‐ zieren, die zu einem „Scheitern“ der Aufgabe führen könnten. 5.2 Wahrscheinlichkeiten schätzen Für die Entwickler ist es in der Regel einfacher, die Wahrscheinlichkeit eines Intervalls abzuschätzen, als die Intervalle selbst festzulegen. Das bedeutet nicht, dass diese Wahrscheinlichkeiten richtig sind, ebenso wenig wie die Intervalle. Es zeigt nur, dass eine gewisse Vorgabe die Schätzung erleichtert. Inter‐ essanterweise ist sehr oft zu beobachten, dass bei einer Auswahl von z. B. vier Intervallen für den Aufwand einer Aufgabe (siehe vorheriges Beispiel) diese nach der Wahrscheinlichkeitsschätzung zusammen über 100 % liegen. Häufig werden mehrere Intervalle mit ähnlichen Wahrscheinlichkeiten bewertet, wobei die Summe schnell über 150-% liegt. Zum Beispiel wird das zweitniedrigste Intervall als das wahrschein‐ lichste angesehen und mit 70 % bewertet. Das Intervall darüber viel‐ leicht mit 50 % und das Intervall darüber mit 40 %. Das unterste Intervall wird als eher unwahrscheinlich angesehen und mit 10 % bewertet. Am Ende sind es 170 %, aber die Aussage ist klar, dass es wahrscheinlicher ist, dass es länger dauert als im zweiten mit 70 % bewerteten Intervall, weil die beiden Intervalle darüber zusammen eine Wahrscheinlichkeit von 90 % erreichen. Es ist also nicht zwingend notwendig, dass die Summe aller Wahrscheinlichkeiten 100 % ergibt, sondern dass die Tendenz deutlich wird. 5.2 Wahrscheinlichkeiten schätzen 49 <?page no="50"?> Um dies zu vermeiden, sollten die Methoden im Rahmen der Kalibrierung vermittelt und verbessert werden. Insbesondere bei der Wahrscheinlich‐ keitsabschätzung ist es auch wichtig, die reine Ich-Perspektive zu verlassen und die „Außensicht“ einzunehmen. Wie sollten die Trefferquoten der anderen im Team berücksichtigt werden und was würde ein „objektiver Beobachter“ bei der Entscheidung empfehlen? Man sollte immer beide Seiten einer Wahrscheinlichkeitseinschätzung betrachten, also nicht nur „warum könnte meine Einschätzung richtig sein“, sondern auch „warum könnte meine Einschätzung falsch sein“. Ein weiterer guter Ansatz ist zu überlegen, ob und zu welchem Preis Sie bereit wären, auf Ihre Einschätzung zu wetten. Unter der Annahme, dass alle Teammitglieder rationale und gut informierte Experten sind, sollte jeder den Erwartungswert einer Wette auf Basis der eigenen Einschätzung kennen. Wenn jemand im Team dennoch bereit ist, die andere Seite der Wette zu akzeptieren, sollte man sich fragen, was diese Person weiß, was man selbst nicht weiß. Die Intervallwette kann also auch als letzte Instanz bei der Bewertung von Schätzungen dienen. Auch wenn alle Schätzungen mit Hilfe von Konfidenzintervallen gemacht wurden, bleibt die Frage, wie sicher sich das Team sein sollte, um ein Intervall als Schätzung zu wählen, um es später für eine Sprintplanung auf Basis der Entwicklerkapazitäten zu verwenden. Bereits in der klassischen Critical Chain Methode wird eine absolute Wahrscheinlichkeit von 50 % als ausreichende Basis für eine Schätzung angesehen. Die verbleibenden 50-% werden zu Gesamtpuffern vor einem Meilenstein oder Projekt addiert und als Steuerungselement verwendet. Ziel dieser Methode ist es, den Gesamtpuffer durch weitere Maßnahmen auf 50 % zu reduzieren. Dies könnte in ähnlicher Form auch für die Planung und Steuerung von Sprints verwendet werden. Häufig verwendete Werte sind Konfidenzintervalle mit einer kumulativen Wahrscheinlichkeit von 60 % bis 90 %. Welche Werte akzeptabel sind, hängt jedoch von der Risikobereitschaft und dem Kosten-Nutzen-Verhältnis ab. Für das Beispiel in Abb. 3 würde dies bedeuten, dass entweder fünf bis zehn Stunden oder nur zehn Stunden, wenn es ein Wert sein muss, oder elf bis 15 Stunden oder nur 15 Stunden als Schätzwert eingetragen werden. 50 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr <?page no="51"?> 10 Vgl. Galton, Francis (1907): 450-1. Die Reihenfolge der Intervalle vom niedrigsten bis zum höchsten Aufwand in Verbindung mit der Wahrscheinlichkeit kann auch als Anhaltspunkt für die Einleitung von Maßnahmen dienen. Eine Vorgabe könnte sein, dass bis zum zweiten Intervall ein kumulatives Konfidenzniveau von mindestens 75 % erreicht werden muss. Bis zu 5-% darunter ist eine Pre Mortem Analyse oder Risikoanalyse durchzu‐ führen. Liegt das Konfidenzniveau >5 % bis <=15 % darunter, ist eine Kosten-Nutzen-Analyse erforderlich und die Aufgabenschätzung wird zurückgestellt. Bei weniger als 60 % im zweiten Intervall ist die Intervall‐ schätzung zu wiederholen, um zunächst besser geeignete Intervalle zu ermitteln. Bezogen auf das obige Beispiel der Konfidenzintervalle wäre die kumulierte Wahrscheinlichkeit im zweiten Intervall (>=5 bis <=15) 65 % (15 % aus dem unteren Intervall plus 50 % aus dem oberen Intervall). Dies würde bedeuten, dass die Schätzung zurückgestellt und ein Spike durchgeführt wird. Die Entscheidung, wie mit den Ergebnissen am besten umzugehen ist, bleibt dem Team überlassen. 5.3 Schwarmintelligenz - die Vermittlung der Extreme Die klassische Aussage „Eine Gruppe kann als Ganzes klüger sein als der Einzelne“ wird gerne mit der Geschichte von Sir Francis Galton untermauert: Mehr als 700 Gäste wurden gebeten, das Gewicht eines Ochsen zu schätzen. Das Ergebnis war, dass der Mittelwert aller Schätzungen genauer war als alle Einzelschätzungen. 10 Die Lehre daraus ist, dass sich die Fehler der Einzelnen im Durchschnitt aufheben. Leider hängt die Schwarmintelligenz von der Unabhängigkeit der Mitglieder voneinander ab. Das bedeutet, dass die einzelnen Personen zumindest teilweise über korrekte Informationen verfügen müssen und ihre Fehleinschätzungen nicht miteinander korrelieren oder aufeinander aufbauen dürfen. Unabhängig davon, wie viele Experten zusammenkommen, wird es im‐ mer unterschiedliche Informationsstände zu einer Aufgabe oder einem Thema geben. Das ist auch gut so, denn so kommen unterschiedliche 5.3 Schwarmintelligenz - die Vermittlung der Extreme 51 <?page no="52"?> Informationen und Interpretationsaspekte zusammen. Diese auszutauschen hilft in der Regel, eine Aufgabe besser zu verstehen. Daher ist es wichtig, die unterschiedlichen Informationsstände bei agilen Schätzmethoden zu erkennen, um die Schwarmintelligenz richtig nutzen zu können. Wenn ein Team eine Aufgabe schätzt, wird es immer sehr unterschiedli‐ che Bewertungen geben. Besonders auffällig sind die teilweise extremen Unterschiede. Methoden wie Story Point Poker nutzen daher das Mittel der Diskussion zwischen dem Teammitglied mit der höchsten und dem Teammitglied mit der niedrigsten Schätzung. Ziel ist es, die Extreme zu vermeiden und über mehrere Runden eine Annäherung der Schätzungen zu erreichen, bis sich ein Konsens über die Schätzung einstellt. Viele Runden bis zum Konsens sind jedoch nicht ohne Risiko. Eine andere einfache und bewährte Methode, Extreme zu erkennen ist, wie bereits beschrieben, die Verwendung des Mittelwertes. Dieser wird gerne um die Standardabweichung ergänzt. Der Einfachheit halber sollte der Mittelwert völlig ausreichen, um zu erkennen, in welchem Bereich sich die Schätzung bewegen wird. Interessanter ist es herauszufinden, warum es bei einigen Schätzungen erhebliche Abweichungen gibt. Hier kommt die aus dem Story Point Poker bekannte „Diskussion“ ins Spiel. Dabei geht es bekanntlich darum, sich die Argumente der anderen anzuhören und darüber zu diskutieren. Die Hauptgefahr besteht hier eher darin, dass durch die Diskussion eine gegenseitige Beeinflussung stattfindet und alle weiteren Einschätzungen nur noch auf einen Konsens hinarbeiten - aus Zeitdruck dann gerne auch mal mit einer „Basta“-Entscheidung. Unterschiedliche Perspektiven sind jedoch immer hilfreich bei der Bewer‐ tung. Sie verringern das Risiko, dass alle Teammitglieder die gleiche Vor‐ eingenommenheit haben, dass individuelle Fehler miteinander korrelieren und dass das Team sich gegenseitig in seiner Voreingenommenheit bestärkt. Leider reduziert die Diskussion innerhalb eines vorurteilsbehafteten Teams die Voreingenommenheit der Teammitglieder nicht zuverlässig. Stattdessen neigen die Teammitglieder dazu, die Diskussion noch vor‐ eingenommener zu verlassen, als sie sie begonnen haben („Gruppenpo‐ larisierung“). Viele gruppendynamische Studien legen sogar nahe, dass Diskussionen der Qualität einer Entscheidung sogar abträglich sein können. Andererseits ist es für eine Schätzung hilfreich, mehr Informationen über die Bewertung zu erhalten. Bei Schätzungen spiegeln sich die Informationsun‐ terschiede in den Abweichungen zwischen den Schätzungen wider. Diese können sehr groß sein. Daher ist es wichtig zu wissen, ob es sich um eine 52 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr <?page no="53"?> bewusste Schätzung eines Entwicklers auf der Grundlage von Informationen handelt, die dem Rest des Teams möglicherweise nicht zur Verfügung stehen, oder ob die Schätzung einfach auf der Interpretation von Informationen beruht. Die Frage ist also eher, ob jemand über Informationen verfügt, die dem Rest des Teams nicht zur Verfügung stehen. Wenn dies der Fall ist, kann es hilfreich sein, diese Informationen mit allen Teammitgliedern zu teilen, um die Schätzung zu verbessern. Am einfachsten ist es, das Team zu fragen, ob jemand glaubt, Informationen zu haben, die der Rest des Teams wahrscheinlich nicht berücksichtigt hat. Diese Frage allen zu stellen, kann jedoch schnell zu einem Problem für den Zeitplan der Bewertung werden. Daher ist es wichtig, herauszufinden, wer glaubt, dass der Rest des Teams eine andere Sichtweise auf das Thema haben könnte. Aus diesem Grund ist es hilfreich, bei jeder Schätzung zu fragen, was jeder denkt, wie der Rest des Teams das Thema bewerten würde. Abb. 4: Eigene Einschätzung und Teameinschätzung Die zwei bis drei Teammitglieder mit der größten Diskrepanz zwischen ihrer eigenen Einschätzung und der des Teams werden gefragt, welche Informationen für das Team relevant sein könnten. Diese müssen nicht unbedingt relevant sein, sondern können auch auf einer unterschiedlichen Interpretation der Aufgabe beruhen, aber bei größeren Abweichungen kann davon ausgegangen werden, dass der betreffende Entwickler zumindest annimmt, mehr relevante Informationen zu haben als der Rest des Teams. In dem Beispiel in Abb. 4 würden die Entwickler 5 und 6 gefragt werden, welche Informationen sie haben, um zu dieser Einschätzung zu gelangen. Dies sollte jedoch eher ein Informationsaustausch als eine Diskussion sein. Es ist auch nicht das Ziel, einen Konsens zu finden, da sonst die Gefahr besteht, dass andere Meinungen in der Bewertung nicht mehr ausreichend repräsentiert sind. 5.3 Schwarmintelligenz - die Vermittlung der Extreme 53 <?page no="54"?> Vorsicht ist geboten, wenn bei einem umfangreichen Thema zu viele gleiche Bewertungen vorliegen. In diesem Fall sollte mindestens ein Teammitglied eine andere Position einnehmen und die Bewertung in Frage stellen. Diese Rolle, die man auch „Schätzförderer“ nennt (früher besser bekannt als „Teu‐ felsadmiral“), sollte die Schätzung in Frage stellen, indem sie Gegenfragen formuliert, Risiken und Daten aus der Vergangenheit ähnlicher Schätzungen aufzeigt und versucht, mehr negative Aspekte aufzuzeigen, wenn es sich um eine sehr positive oder zu zuversichtliche Schätzung handelt. Wenn es sich um eine sehr negative Schätzung handelt, sollte sie auch die Gegenseite mit positiven Aspekten aufzeigen. In diesem Fall hat die Rolle die Aufgabe zu verhindern, dass alle einer Meinung sind, aber auch alle falsch liegen können. Die Rolle des „Schätzförderers“ ist jedoch aus gruppendynamischer Sicht nicht immer einfach. Die Mitglieder eines Teams entwickeln im Laufe der Zeit eine gemeinsame Identität und eine Gruppenkultur, die ihr Verhalten direkt beeinflussen. In der Folge kann dies zu einem gewissen „Gruppen‐ zwang“ führen, in dem kritische Haltungen eher unterdrückt werden. Un‐ terschiedliche Perspektiven werden dann nicht mehr ausreichend vertreten oder akzeptiert. Darüber hinaus bringt jedes Teammitglied seine eigenen Persönlichkeitsmerkmale, Präferenzen und Erfahrungen ein, wodurch auch Spannungen zwischen Individualität und Teamgemeinschaft entstehen. Teammitglieder, die in erster Linie darauf bedacht sind, Harmonie und Einheit im Team aufrechtzuerhalten, sind in der Regel nicht optimal für diese Rolle geeignet, da sie dazu neigen, ihre eigenen Meinungen oder Ideen zurückzuhalten. Auf der anderen Seite sind Teammitglieder, die eher eine gegenteilige Einstellung haben, auch nicht ideal für die Rolle. Zu Beginn ist es daher denkbar, dass die Rolle eher vom Scrum Master übernommen wird, bis sich die Rolle etabliert hat und zunehmend im Team wechseln kann. 5.4 Pre Mortem Analyse vor Post Mortem Analyse Sich bei jeder Abschätzung zu fragen, warum man falsch liegen könnte, ist ein guter Einstieg in die Risikobetrachtung. Nur sollte dies nicht ins Negative umschlagen und alles als hohes Risiko angesehen werden, so dass es letztlich zu einer Methode der Risikovermeidung wird und damit Chancen verpasst werden. 54 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr <?page no="55"?> Auch hier gilt es, einen Mittelweg zwischen Risikoscheu und übertriebe‐ ner Risikobereitschaft zu finden. Für die Abschätzung von Aufgaben ist es notwendig, sich ab einem bestimmten Konfidenzniveau zu überlegen, aus welchen Gründen eine Aufgabe scheitern oder sich deutlich verzö‐ gern könnte. Eine Schätzung erfolgt typischerweise unter der positiven Annahme, dass keine Probleme auftreten werden. Daher ist es wichtig, das Gegenteil dieser Annahmen zu betrachten, indem man auflistet, was am wahrscheinlichsten schief gehen könnte. Allein durch die Nennung der wichtigsten drei bis fünf Punkte ist es möglich, die Erwartungen zu dämpfen und sich auf wahrscheinliche Ergebnisse vorzubereiten. Unterstüt‐ zend wirkt im agilen Umfeld die Post Mortem Analyse nach Abschluss eines Sprints. Hier werden die Probleme des einzelnen Tasks aufgegriffen, die in der vorgegebenen Zeit nicht umgesetzt werden konnten und einen deutlichen Mehraufwand erforderten. Im Fokus der Post Mortem Analyse am Sprintende stehen nicht die Tasks, deren Dauer sich deutlich verändert hat, sondern nur die Tasks mit deutlichen Abweichungen im Aufwand. (Für die Pre und Post Mortem Analyse bei der Sprintplanung ist dagegen die Dauer relevanter.) Interessant ist zum einen die Auswertung, ob der Mehraufwand innerhalb der Konfidenzintervalle liegt und zum anderen, ob dieser Mehraufwand auf zuvor identifizierte Risiken zurückzuführen ist, wenn es sich um eine Aufgabe mit „niedrigem Konfidenzniveau“ handelt. Wenn eine Aufgabe von einer Schätzung mit niedrigem Konfidenzniveau betroffen ist, ist zu prüfen, ob die Pre Mortem Analyse das Risiko identifiziert hat oder ob ein Spike das Risiko bereits berücksichtigt hat. Wurden keine Pre Mortem Analysen oder Spikes durchgeführt, ist zu prüfen, ab welchem Konfidenzniveau typische Maßnahmen wie Spikes oder Pre Mortem Analy‐ sen sinnvoll wären. Ist das Konfidenzniveau hoch, zeigt die Auswertung, dass die Konfidenz nicht ausreichend war oder Parameter nicht ausreichend berücksichtigt wurden. Dies kann für den „Schätzer“ ein gutes Beispiel für eine weniger gute Schätzung sein. Wie bereits aus den Auswertungen der Post Mortem Analyse hervorgeht, wird nicht für jede Aufgabe eine Pre Mortem Analyse durchgeführt. Dies mag theoretisch sinnvoll erscheinen, um die Risiken für jede Aufgabe zu identifizieren, ist aber in der Praxis mit einem nicht unerheblichen Aufwand verbunden. Bereits der Prozess der Abschätzung erfordert einen gewissen Zeitaufwand und daher ist das Instrument der Pre Mortem Analyse ähnlich 5.4 Pre Mortem Analyse vor Post Mortem Analyse 55 <?page no="56"?> zu bewerten wie die Spike Stories. Das Kosten-Nutzen-Verhältnis muss stimmen. Es wird daher empfohlen, eine Pre Mortem Analyse immer in einen Spike zu integrieren. Eine Kurzfassung davon ist eine Art Brainstorming im Rahmen der Abschät‐ zung, sollte aber nicht viel länger als fünf Minuten dauern. Um Lücken aufzudecken, sollte sich zumindest der jeweilige „Schätzer“ von einem Experten des Fachgebietes erklären lassen, wie er sich die Umsetzung vorstellt. Während der Erläuterungen kann dann nachgefragt werden, was bei dem jeweiligen Schritt schief gehen könnte. Die Aufzählung von Standardrisiken wie „der Umfang der Aufgabe könnte sich ändern“ sollte man vermeiden. Standardrisiken sind für die erweiterte Bewertung der Aufgabe wenig hilfreich und werden in der Regel durch den agilen Ansatz sowieso berücksichtigt. Auch Informationen über Änderungen an der Aufgabe oder Risiken im Rahmen von Work in Progress gehören grundsätzlich nicht zur Aufwands‐ schätzung, sondern eher zur Dauer der Aufgabe für eine Sprintplanung. Aufwand ist, wie bereits erwähnt, die ideale Zeit ohne Unterbrechungen. Wichtig sind aufgabenspezifische Punkte wie „eine Umstrukturierung der Datenbankindizes könnte mehr Aufwand bedeuten“ oder „ein Überlauf der größenbeschränkten Protokolldateien könnte eine signifikante Änderung der Prozesslogik erfordern, die einen zusätzlichen Aufwand von x erfordert“. Je mehr Punkte in der Voranalyse identifiziert und berücksichtigt wurden, desto besser können Aufwand und Konfidenz abgeschätzt werden. Die Post Mortem Analyse kann insbesondere bei größeren Aufgaben mit der weniger bekannten Methode des „Backcastings“ kombiniert werden. Bekannter als das Backcasting ist das Forecasting. Beim Forecasting geht es darum, die wahrscheinlichsten Zukunftsaussichten zu prognostizieren, also Annahmen über die zukünftige Entwicklung zu treffen. Ausgehend von der Gegenwart wird also der Weg in die Zukunft geplant. Beim Backcasting geht es darum, einen Weg in eine wünschenswerte Zukunft zu finden, obwohl dieser Weg nicht unbedingt der wahrscheinlichste sein muss. Backcasting beginnt also mit einem gewünschten Ziel in der Zukunft und arbeitet sich dann Schritt für Schritt zurück in die Gegenwart, um Wege zu finden, 56 5 Konfidenzintervalle, Wahrscheinlichkeiten und mehr <?page no="57"?> wie dieses Ziel erreicht werden kann. Dabei werden auch verschiedene Szenarien bzw. Wege beschrieben, wie das Ziel erreicht werden könnte. Die Ergebnisse der Pre Mortem Analyse können hierbei unterstützend genutzt werden, indem auch alternative Wege identifiziert werden, um mögliche Probleme, die sich aus der Pre Mortem Analyse ergeben haben, umgehen zu können. Das Risiko des Backcasting besteht darin, dass es zu sehr auf Wunschdenken bzw. übertriebenem Optimismus und unplausiblen Annahmen beruht. Backcasting ist am ehesten dann nützlich, wenn bereits eine umfas‐ sende Bewertung der Risiken vorliegt oder, einfacher ausgedrückt, wenn die meisten Dinge, die zum Scheitern der Maßnahme führen können, bereits bekannt sind. Auf der Grundlage dieser Informationen können dann im Rahmen der Rückwärtsplanung die Schritte und Maßnahmen festgelegt werden, die erforderlich sind, um die verschiedenen Szenarien zu erreichen. Obwohl das Backcasting nicht im Mittelpunkt der reinen Schätzung steht und daher hier nicht weiter behandelt wird, kann die Pre Mortem Analyse den Prozess im Rahmen der Überprüfung und Anpassung der Backcast-Planung unterstützen. 5.4 Pre Mortem Analyse vor Post Mortem Analyse 57 <?page no="59"?> 6 Prediction Interval Game---die integrierte Schätzmethode Um die Schätzung in agilen Projekten zu verbessern, wird eine Methode benötigt, die den wissenschaftlichen Ansatz mit den praktischen Möglich‐ keiten mit Augenmaß verbindet. Ziel ist ein Verfahren, das sich so in agile Methoden integrieren lässt, dass kein oder nur ein geringer Mehrauf‐ wand entsteht. Im Folgenden wird ein möglicher Ansatz vorgestellt, der sich beispielhaft in Scrum integrieren lässt, auf dessen bekannten agilen Schätzmethoden aufbaut und gleichzeitig eine deutliche Verbesserung der Schätzergebnisse ermöglicht. Der Einfachheit halber wird er hier als PIG- Ansatz (Prediction Intervall Game) bezeichnet. Das PIG wird in die normalen Scrum-Events und in die laufenden Aktivitäten integriert. Es basiert auf folgenden drei Säulen: 1. Sensibilisierung des Teams für die verschiedenen Einflussfaktoren bei der Schätzung durch kontinuierliche Kalibrierung des Teams anhand geeigneter Bewertungsdaten und gegebenenfalls Anpassung der Schätz‐ methodik. 2. Verwendung von Intervallen für die Schätzung von Aufgaben und deren Bewertung auf der Grundlage von Wahrscheinlichkeitsschätzungen. 3. Berücksichtigung von zusätzlichem Informationsbedarf und Risikoana‐ lysen im Rahmen des Schätz-, Planungs- und Entwicklungsprozesses. Die erste Säule lässt sich am einfachsten in die Retrospektive integrieren, die eine permanente Rekalibrierung des Teams sicherstellt. Natürlich können Teile davon auch vorher im Rahmen des Teamtrainings und der Teament‐ wicklung durchgeführt werden, ggf. in Kombination mit agilen Methoden. Die erste Säule bildet auch die Grundlage für die zweite Säule. Diese ist das Kernelement der Schätzungen und wird in den kontinuier‐ lichen Prozess der „Backlog Refinements“ einfließen. Die dritte Säule ist sowohl in den „Backlog Refinements“ als auch im „Sprint Planning“ verankert und unterstützt die ersten beiden Säulen mit Informationen aus der operativen Durchführung der Sprints. Durch diesen ganzheitlichen Ansatz soll vermieden werden, dass die Bewertung der Aufgaben auf den Schätzprozess selbst reduziert wird. Auch wenn das Schätzverfahren der Säule zwei unabhängig von den anderen <?page no="60"?> Säulen eingesetzt werden kann, ergeben sich signifikante Verbesserungen nur im Gesamtkontext. Wie die erste und die dritte Säule in ihren Grund‐ zügen aufgebaut sind, wurde bereits in den vorangegangenen Abschnitten diskutiert. Im Folgenden wird daher die zweite Säule im Detail vorgestellt und das eigentliche Schätzverfahren diskutiert. 6.1 PIG-Schätzverfahren Ähnlich wie beim Story Point Poker erfolgt zunächst eine Erläuterung der User Story durch den Product Owner, der auch für Rückfragen zur Verfügung steht. Die Moderation übernimmt in der Regel der Scrum Master. Die Schätzung erfolgt durch die Teammitglieder, wobei Product Owner und Scrum Master in der Regel keine Schätzung abgeben. Ob Aufwand oder die bekannten Story Points verwendet werden, bleibt dem Team überlassen. Die Methode kann nicht nur für User Stories, sondern auch auf der Ebene von Epics oder Features angewendet werden. Unabhängig von Scrum wird die Qualität der Schätzung im Bereich der Budgetplanung oft vernachlässigt. Sofern nicht eine „Top-Down-Budgetplanung“ ohne Einbeziehung der Fachexperten erfolgt, kann durch den Einsatz geeigneter Schätzmethoden hier ebenfalls eine Verbesserung der Budgetplanung erreicht werden. Kurzbeschreibung Das PIG-Schätzverfahren ist das Kernelement der PIG-Methode. Es verwen‐ det anonyme Einzelschätzungen der Teammitglieder mit Schätzintervallen und nachgeschalteten Wahrscheinlichkeits-/ Zuverlässigkeitswetten auf Ba‐ sis des Informationsaustausches. Zusätzlich werden bei entsprechend hohen Risiken aus den Wahrscheinlichkeitswetten eine Pre Mortem Kurzanalyse und bei entsprechend sehr hohen Risiken die Verwendung von Spike Sto‐ ries zur zusätzlichen Informationsbeschaffung durchgeführt, um genauere Schätzungen zu ermöglichen. Vor Beginn der Schätzungen wird ein Schätzförderer für die Runde bestimmt. Dieser wird im Laufe des Prozesses gewisse abgegebenen Schät‐ zungen hinterfragen. In der ersten Runde bewertet jeder Entwickler jede User Story mit zwei Meinungen. Die erste Meinung ist die Einschätzung der User Story aus Sicht des Entwicklers selbst und die zweite Meinung ist die Meinung des 60 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="61"?> Entwicklers, was das Team schätzen würde. Die einzelnen Bewertungen werden nicht veröffentlicht. Der Mittelwert aller Schätzungen bildet die Grundlage für mindestens vier zu definierende Intervalle. Bevor diese Intervalle in der zweiten Runde offengelegt und mit dem „Developer’s Confidence“ bewertet werden, sollen die zwei bis drei Teammitglieder mit der größten Abweichung zwischen ihrer ersten und zweiten Meinung das Team darüber informieren, warum sie glauben, dass der Rest des Teams anders schätzen würde - also nicht wie beim Story Point Poker, wo nur die beiden Entwickler mit der größten Abweichung in ihrer Schätzung befragt werden. Eine Gruppendiskussion, Lösungs- oder Konsensfindung sollte jedoch nicht stattfinden. Rückfragen an den Product Owner sind jederzeit möglich. Optional kann eine zweite Bewertungsrunde stattfinden, um die ausge‐ tauschten Informationen zu berücksichtigen. In der nächsten Runde geht es um ein Wettspiel. Dazu hat jedes Teammit‐ glied ein symbolisches Wettbudget von 100 Story-Dollar (SD) pro User Story. Diese 100 SD sollen von jedem Teammitglied als Wette auf die nun offen zu legenden Intervalle verteilt werden, die es für am wahrscheinlichsten hält. Optional kann auch hier eine zweite Wettrunde stattfinden, wenn die Wetten einzelner Entwickler extreme Abweichungen aufweisen. Anschließend werden die Mittelwerte aller Entwicklertipps als „Wahr‐ scheinlichkeit“ bzw. „Konfidenzintervall“ pro Intervall dargestellt, woraus sich auch die Wettquote ergibt. Der Maximalwert des Intervalls mit einer kumulierten „Konfidenz“ zwischen beispielsweise 70-80% (vom Team zu definieren) wird als Schätzung in der User Story hinterlegt. Zusätzlich wird anhand der „Konfidenz“ bestimmt, ob eine kurze Pre Mortem Analyse oder eine Spike Story mit vollständiger Pre Mortem Analyse erforderlich ist. Das Wettspiel sollte am besten einen zusätzlichen Anreiz bieten, z. B. durch das Sammeln von symbolischen Story-Dollar-Gewinnen mit Umwandlung durch das Unternehmen in echtes Geld für gemeinnützige Organisationen oder die Ermittlung des Team-Wettexperten als „Estimation Expert“ des Quartals oder Jahres, ggf. mit Preisen oder Auszeichnungen für die ersten drei Plätze. 6.1 PIG-Schätzverfahren 61 <?page no="62"?> Abb. 5: Ablauf beim PIG-Schätzverfahren 62 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="63"?> Der Ablauf des PIG-Schätzverfahrens kann bei Bedarf angepasst werden. Ziel sollte es sein, die Methodik als Ganzes beizubehalten. Ein „Heraus‐ brechen“ aus dem Bewertungsprozess oder der zweiten Säule wird nicht die volle Wirkung entfalten. Welche Anpassungen jedoch sinnvoll und notwendig sind, muss team- und kontextspezifisch entschieden werden. Hier ist das Augenmaß der Scrum Master gefragt. Das PIG-Assessment selbst besteht aus einer anoynmen Bewertungs‐ runde und einer Wettrunde. Anonyme Bewertungsrunde (max. mit einer optionalen Zusatz‐ runde) ■ Informationsaustausch auf Basis der Assessments ■ Intervallbildung bestehend aus vier Intervallen um den Mittelwert (+/ - 50-% bei Zeiteinheiten) Wettrunde ■ Entscheidungsfindung zur Intervallwahl, ggf. mit Pre Mortem Analyse oder Verschiebung der Schätzung aufgrund einer notwen‐ digen Spike Story Selbstverständlich kann das Team auch hier Anpassungen vornehmen, wie z. B. eine zweite Auswertungsrunde, Informationsaustausch nach der ersten Auswertungsrunde, mehr Intervalle um den Mittelwert, eine weitere Auswertungsrunde nach der Quotensichtung oder „Gegenwetten“ nach der ersten Auswertungsrunde. Anonyme Bewertungsrunde In der anonymen Bewertungsrunde erhält jeder Entwickler für die zu be‐ wertende Aufgabe einen grünen Notizzettel für seine Bewertung und einen blauen Notizzettel für die Meinung des Entwicklers, was das Team schätzen würde. Natürlich sind auch andere Farben möglich - bei der Verwendung von Story Poker-Karten wird einfach ein entsprechend farbiger Notizzettel auf die Rückseite geklebt. Diese werden an den Scrum Master übergeben, der daraus ableitet, welche Developer nach Informationen befragt werden sollen, die das Team möglicherweise nicht hat. Dazu werden die zwei bis 6.1 PIG-Schätzverfahren 63 <?page no="64"?> drei Entwickler angehört, die die größte Abweichung bei den negativen und positiven Werten haben, d. h. die Differenz zwischen der eigenen Schätzung und dem, was das Team schätzen würde. Im Beispiel in Abb. 4 sind es die Entwickler 5 und 6, die, ohne ihre Bewertung zu nennen, das Team darüber informieren müssen, warum sie glauben, dass der Rest des Teams eine andere Bewertung abge‐ ben würde. Gruppendiskussionen, Lösungssuche oder Konsensfindung sind zu vermeiden. Es geht lediglich darum, dem Team Informationen zur Verfügung zu stellen, damit es diese in der Abstimmung berück‐ sichtigen kann. Bei virtuellen Teams können direkte Chats mit dem Scrum Master o.ä. genutzt werden. Auch eine gemeinsam genutztes Spreadsheet ist möglich, allerdings sind hier die Schätzungen der ande‐ ren Entwickler sichtbar. In diesem Fall sollten zumindest die Namen der Entwickler anonym bleiben, indem der Scrum Master jedem Entwickler vorab im Einzelchat ein Pseudonym oder eine Nummer zuweist. Leider werden die Entwickler spätestens beim Informationsaustausch nach und nach bekannt, was aus Gründen der Teambeeinflussung vermieden werden sollte. Wenn die Unterschiede zwischen den Schätzungen nur gering sind, d. h. wenn alle Entwickler mehr oder weniger der gleichen Meinung sind, dann sollte der Schätzförderer eingreifen und die Schätzungen in Frage stellen, bevor die Wettrunde beginnt. Auf diese Weise hat das Team die Möglichkeit, seine Schätzung zu überdenken, bevor die Wahrscheinlichkeit auf der Basis von Intervallen geschätzt wird. Sollten die Argumente des Schätzförderers so gut sein, dass das Team offensichtlich verunsichert ist, kann auf Wunsch des Scrum Masters eine zweite anonyme Bewertungsrunde inkl. einer weiteren Infor‐ mationspräsentation stattfinden, jedoch keine dritte. Wenn die Schätzungen signifikant weit auseinander liegen, ist in jedem Fall eine zweite Runde erforderlich. Nach der zweiten Schätzung schaut sich der Schätzförderer die Entwicklung der Ergebnisse an. Hat sich das Ergebnis mehr in Richtung einer niedrigeren Schätzung verändert, greift der Schätzförderer die Bemer‐ kungen des Entwicklers aus der ersten Runde auf, warum möglicherweise ein höherer Wert richtig sein könnte. 64 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="65"?> In dem in Abb. 4 gezeigten Beispiel liegt Entwickler 5 mit 20 deutlich über den anderen Schätzungen. Am besten in Kombination mit Ergeb‐ nissen aus früheren, vergleichbaren Aufgaben, die die Argumentation unterstützen könnten. Im Folgenden werden die Intervalle vom Scrum Master durch Mittel‐ wertbildung aus den Schätzungen der Entwickler gebildet. Im einfachs‐ ten Fall wird vom Mittelwert mit +/ - 50 % gerechnet, um zwei Intervalle zu bilden (z. B. bei 10 als Mittelwert also von >5 bis 10 und von >10 bis 15). Dazu kommt ein Intervall unterhalb des -50%-Intervalls (also <=5) und ein Intervall oberhalb des + 50 % -Intervalls (also >15). Daraus ergibt sich die in Abb. 6 gezeigte Intervalltabelle für die Wetten der Entwickler. Abb. 6: Intervalltabelle für die Wettrunde Bei der Fibonacci-Folge wird die Zahl gewählt, die dem Mittelwert am nächsten kommt und mindestens zwei ist. Die Intervalle darunter und darüber werden durch die entsprechenden Fibonacci-Zahlen dargestellt. Der Mittelwert liegt immer im zweiten Intervall von oben. Der Grund für die Wetten, wie hoch die Entwickler die Wahrscheinlichkeit einschätzen, ist, dass der Aufwand höher sein wird, als es der Mittelwert aussagt. Wenn der Mittelwert im dritten Intervall von oben läge, gäbe es nur ein Intervall über dem Mittelwert, was die Einschätzung, wie weit man über den Mittelwert hinausgehen könnte, verringern würde. Darüber hinaus würde die Beurteilung der Notwendigkeit einer kurzen Voranalyse oder einer Spike Story eingeschränkt. Es ist grundsätzlich positiv, wenn weniger Zeit benötigt wird, um einen Trend zu erkennen. Deshalb ist ein Intervall unter dem Mittelwert ausreichend, um einen Trend abzuleiten. 6.1 PIG-Schätzverfahren 65 <?page no="66"?> Wettrunde Nach Bekanntgabe der Intervalltabelle muss jeder Entwickler anonym seine Wette abgeben. Dazu hat jedes Teammitglied ein symbolisches Wettbudget von 100 SD für die Aufgabe. Diese 100 SD sollten von jedem Teammitglied als Wette auf die Intervalle verteilt werden, die nach dem Informationsaus‐ tausch am wahrscheinlichsten sind. Abb. 7: Wetten der Developer je Intervall Im Grunde handelt es sich um eine Schätzung der Wahrscheinlichkeit auf 100 %. Die Story-Dollars reduzieren das Risiko, dass die Summe pro Entwick‐ ler sonst mehr als 100 % beträgt. Die 100 SD müssen vollständig für die User Story verwendet werden. Es ist nicht möglich, Story-Dollars einzubehalten, d. h. nicht zu wetten oder bei Enthaltung keine Wette abzugeben. Eine mehr oder weniger gleichmäßige Verteilung der Wetten auf alle Intervalle ist nicht sinnvoll. Das jeweilige Teammitglied hat dann keine wirkliche Meinung zum Thema. Das Team sollte daher darauf hingewiesen werden, dass in diesem Fall die Tippverteilung des Entwicklers für ungültig erklärt wird. Dies würde sonst zu einer Verzerrung der Auswertung führen. Nach der Tippabgabe wird der Mittelwert pro Intervall berechnet, woraus sich die Konfidenzintervalle ergeben. Abb. 8: Konfidenzintervalle 66 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="67"?> Das Team legt im Voraus für alle Schätzungen fest, welche kumulative Wahrscheinlichkeit erforderlich ist, damit dieses Intervall als Schätzwert für die Aufgabe verwendet wird. Zum Beispiel könnte das Intervall als Schätzwert verwendet werden, das mindestens eine kumulative Wahrscheinlichkeit von 70 % aufweist (in dem Beispiel aus Abb. 8 wäre das das zweite Intervall „>5-10“ mit 77 %). Weiterhin kann anhand der kumulativen Wahrscheinlich‐ keit im „zweiten Intervall“ entschieden werden, ob eine Pre Mortem Kurzanalyse, ein Spike oder eine Wiederholung der Intervallmessung durchgeführt werden soll. Dazu sollte bis zum zweiten Intervall der gewünschte Wahrscheinlichkeitswert (hier zuvor als 70 % festgelegt) erreicht werden. Bis z. B. 5 % darunter (d. h. >=65% bis < 70 %) ist eine Pre Mortem Kurzanalyse durchzuführen, um zu beurteilen, ob das darüber liegende Intervall als Schätzung in der Aufgabe hinterlegt werden soll. Liegt das Konfidenzintervall z. B. >5% bis <=15% darunter (d. h. >=55% bis <65%), so ist eine Spike Story auf Basis von Kosten/ Nutzen erfor‐ derlich (siehe Informationsoptimierung). Die Schätzung der Aufgabe wird dann auf den nächsten Termin oder bis zum Ende des Spikes verschoben. Wenn z. B. im zweiten Intervall weniger als 55 % erreicht werden, ist die gesamte Schätzung zu wiederholen, um geeignetere Intervalle zu ermitteln. Im Beispiel in Abb. 8 wurden 77 % im zweiten Intervall geschätzt. Damit liegt die Schätzung sogar über dem definierten Grenzwert und es besteht kein weiterer Handlungsbedarf. Für die Aufgabe ist daher das Intervall >5 bis 10 zu hinterlegen oder, wenn nur eine Zahl hinterlegt werden soll, der jeweilige Maximalwert des Intervalls---in diesem Fall zehn. Das Team definiert alle Werte selbst und die akzeptablen Wahr‐ scheinlichkeitswerte hängen von der Risikobereitschaft des Teams ab. Zusätzlich wird empfohlen, die Einsätze der Entwickler für die spätere Auswertung und Gewinnausschüttung zu erfassen. Es wird immer die Summe ausbezahlt, die in dem Intervall von den Entwicklern gesetzt wurde. Die in den anderen Intervallen gesetzten SD verfallen. Würde sich im obigen Beispiel herausstellen, dass das zweite Intervall richtig war, würden insgesamt 340 SD bzw. pro Entwickler die eingesetzte Summe ausgezahlt. Die gewonnenen SD könnten in echtes Geld um‐ gewandelt werden (z. B. 1 SD = 0,01 Cent) und vom Unternehmen an eine gemeinnützige Organisation gespendet werden. Möglichst etwas 6.1 PIG-Schätzverfahren 67 <?page no="68"?> mit lokalem Bezug, um die Verbundenheit des Teams zu stärken. Daher sollte das Team auch die Auswahl treffen. Ein Nebeneffekt ist die Motivation für das Team, mehr kleine User Stories zu erstellen, um mehr Geld einsetzen zu können. Dies geht in Richtung #NoEstimates und kann den Schätzprozess ggf. deutlich beschleunigen. Außerdem zeigt das Unternehmen soziales Engagement und vor allem wird einfach etwas Gutes getan. 6.2 Hinweise für die praktische Anwendung Keine agile Methode sollte als starres Konzept verstanden werden, daher kann eine Anpassung des Vorgehens je nach Team/ Teamgröße, zu bewer‐ tenden Objekten und Umfeld durchaus sinnvoll sein. So können die Schät‐ zungen auch zu einem Wettkampf zwischen zwei Teamteilen gegeneinander werden. Dabei stellt ein Teamteil sein Ergebnis mit einer Quote vor und fragt das andere Team, ob es dafür oder dagegen wetten möchte. Dies kann das Vertrauen in die Schätzung stärken oder dabei helfen festzustellen, ob eine Wette, die nicht eingetroffen ist, analysiert werden muss. Bei dieser Methode kann es auch gewöhnungsbedürftig sein, dass kein Konsens im Mittelpunkt steht und scheinbar kein umfassender Informati‐ onsaustausch stattfindet. Hier sollte der Informationsaustausch möglichst schon vor der Schätzphase bei der Definition der User Story erfolgen, um die Schätzphase zu verkürzen. Sofern eine User Story im Rahmen des Backlog Refinements einen definierten Status „DoR“ (Definition of Ready) verwendet, sollten im Prinzip kaum noch inhaltliche Fragen auftauchen. Selbstverständlich kann bei der Vorstellung einer User Story ein Informati‐ onsaustausch in der Gruppe stattfinden und ist ab einem gewissen Grad der Unsicherheit über die User Story auch ausdrücklich erwünscht. Wichtig ist, dass nicht bereits eine Gruppendiskussion zur Konsensfindung oder eine Meinungsbildung zur Abschätzung stattfindet, da dies bereits Auswirkun‐ gen auf die folgenden Abschätzungen hätte. Denn auch wenn am Ende alle einer Meinung sind, kann sich jeder irren. Zwar ist es gruppendynamisch gut, einen Konsens zu haben und das Wir-Gefühl wird auch bei Misserfolg geteilt, aber die Vielfalt der Meinungen führt in der Regel zu besseren Ergebnissen bei den Abschätzungen. 68 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="69"?> Ein Punkt darf hier nicht unterschlagen werden. Neben den Schätzungen geht es immer auch um die Erfassung von Daten, um die Schätzungen mit den tatsächlichen Werten vergleichen zu können. Nur so können Verbesserungen erzielt werden. Ob nun für jede User Story alle notwendigen Daten erfasst werden oder nur für ausgewählte Objekte, bleibt dem Team überlassen. Hinzu kommt, welche Daten erfasst werden. Auch wenn es nicht explizit beschrieben ist, ist die Schätzung des Aufwands für eine Aufgabe unkritisch, nicht aber der Aufwand, der bei der Umsetzung der Aufgabe durch die Entwickler entsteht. Die Ermittlung des Aufwands kann sich aus arbeitsrechtlichen Gründen als schwierig erweisen, insbesondere bei interner Zusammenarbeit. Eine Umrechnung von Dauer in Aufwand ist wenig empfehlenswert bzw. mit zu vielen Einflussfaktoren belastet, so dass kein Nutzen daraus gezogen werden kann. Hilfreicher ist es zu klären, ob die Entwickler zumindest gefragt werden können, in welchem Aufwandsintervall der Schätzungen der tatsächliche Aufwand liegt. Das Risiko des „Selbstbetrugs“, um besser dazustehen, ist kalkulierbar und akzeptabel. Die Ermittlung des Aufwandes aus der Dauer (Cycle Time) als Notlösung erfolgte früher in seltenen Fällen nach einer typischen Faustformel wie Aufwand = Dauer / (Tageskapazität - 25-%). Beispiel: Dauer = 24 Stunden Kapazität pro Tag = 4 Stunden Aufwand = 24 Stunden / (4 Stunden - 1 Stunde) = 8 Stunden Dieser Aufwandswert kann allenfalls als unzuverlässiger Richtwert angese‐ hen werden und wird zudem von zu vielen Faktoren beeinflusst. Insbeson‐ dere durch die Kapazität pro Tag, die ihrerseits nur ein Richtwert ist. Es ist durchaus möglich, dass ein Entwickler zwei Stunden pro Tag als Kapazität angibt, aber an einem Tag 4 Stunden arbeitet und den nächsten Tag frei nimmt oder andere Aufgaben hat. Die Annahme, dass bei gleichbleibender Kapazität eines Entwicklers die Dauer ca. 20 bis 30 % über dem tatsächlichen Aufwand liegt, kann grob zutreffen, wenn nur ein Entwickler die User Story umsetzt. Bei mehreren Entwicklern, die gemeinsam eine User Story umsetzen, kann nicht davon ausgegangen werden, dass Dauer und Aufwand in einem ähnlichen Verhältnis stehen. 6.2 Hinweise für die praktische Anwendung 69 <?page no="70"?> Selbst wenn die durchschnittliche Kapazität pro Tag für alle Entwickler konstant wäre und sich somit zur Gesamtkapazität addiert, gibt es einen notwendigen Koordinations- und Abstimmungsaufwand, der mit der An‐ zahl der beteiligten Entwickler steigt. Es ist daher eher von einem Abschlag von 30 bis 50 % auf die Tageskapazität auszugehen. Um dieses Vorgehen ins‐ gesamt zu vermeiden, wäre eine Aufwandermittlung sicherlich die genauere und bessere Wahl, gefolgt von der Frage, in welchem Schätzintervall der Aufwand liegt. Sicherlich ist der Ansatz einer adäquaten Erfassung von Zeiten im Sinne von Aufwänden nicht optimal mit dem agilen Vorgehen vereinbar, bei dem es mehr um kreative Entwicklungsprozesse und weniger um formale Abläufe geht. Es ist jedoch immer zu bedenken, dass ein nicht unerhebli‐ cher Einfluss auf das Projekt entsteht, wenn unzureichende Schätzungen den Projekterfolg gefährden. Insbesondere im Budgetumfeld können sich genauere Schätzungen sogar positiv auf das Unternehmensergebnis auswir‐ ken, wodurch wiederum weitere wertschöpfende Maßnahmen umgesetzt werden können. Insofern ist die Erhebung von Daten zur Schätzverbesse‐ rung in einem maßvollen und legalen Rahmen, idealerweise toolunterstützt, auch im agilen Umfeld durchaus sinnvoll. 70 6 Prediction Interval Game---die integrierte Schätzmethode <?page no="71"?> 7 Resümee Es zeigt sich, dass das Verständnis von Schätzungen weit über die bloße Anwendung mathematischer Modelle hinausgeht. Es erfordert eine inter‐ disziplinäre Kompetenz, die ein tiefes Verständnis für die menschlichen Aspekte der Teamarbeit, einen sensiblen Umgang mit Informationen und eine geschickte Balance zwischen Optimismus und pragmatischer Realität beinhaltet. Die vorgestellten Methoden und Perspektiven regen hoffentlich dazu an, bestehende Praktiken zu überdenken, und öffnen den Blick für innovative Wege, die nicht nur die Genauigkeit von Schätzungen erhöhen, sondern auch den Teamgeist fördern. Die reine Fokussierung auf Zahlen und das Streben nach übergenauen Schätzungen wird der Dynamik agiler Projekte nicht gerecht. Stattdessen ist ein flexibler und offener Ansatz erforderlich, der die Unvorhersehbarkeiten und Unsicherheiten des Projektverlaufs ak‐ zeptiert und konstruktiv in die Planung einbezieht. Es zeigt sich auch, dass die Kunst des Schätzens in agilen Projekten eine kontinuierliche Disziplin ist, die sich nicht in starren Metho‐ den manifestiert, sondern eine Haltung und Praxis des ständigen Anpassens und Lernens erfordert. Durch die intensive Auseinandersetzung mit strukturierten Schätz- und Ka‐ librierungsmethoden wird sich die Sicht auf den Ablauf von Schätzprozessen sehr schnell verändern und die Qualität der Schätzungen wird sich über die Zeit nachweisbar verbessern. Dies wird für agile Teams in der schnelllebigen und komplexen Welt der Softwareentwicklung ein wichtiger Faktor sein, um ihre Projekte zum Erfolg zu führen. Wir hoffen, mit diesem Buch einen Beitrag zum Verständnis und zur Verbesserung der Schätzpraxis in agilen Umgebungen geleistet und den Grundstein für weitere Diskussionen und Untersuchungen in diesem wich‐ tigen Bereich des Projektmanagements gelegt zu haben. <?page no="73"?> Literaturverzeichnis G A L T O N , Francis (1907): Vox Populi (The Wisdom of Crowds). Nature 75, no. 7 (1907): 450-1. J E F F R I E S , Ron (2019): Story Points Revisited. https: / / ronjeffries.com/ articles/ 019-01ff/ story-points/ Index.html. K R U G E R , Justin und D U N N I N G , David (1999): Unskilled and Unaware of It: How Diffi‐ culties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments. Journal of Personality and Social Psychology, December 1999, Volume 77, Issue 6, Pages 1121-1134. M E R T O N , Robert K. und Z U C K E R M A N , Harriet (1988): The Matthew Effect. Science, II: Cumulative Advantage and the Symbolism of Intellectual Property Journal Isis, Vol. 79, No. 4, Pages 606-623. M I T R O F F , Ian I. (1998): Smart Thinking for Crazy Times: The Art of Solving the Right Problems. O S K A M P , Stuart (1965): Overconfidence in Case-Study Judgments. Journal of Consul‐ ting Psychology, 1965, Volume 29, Issue 3, Pages 261-265. P E T E R , Laurence J. und H U L L , Raymond (1969): The Peter Principle: Why Things Always Go Wrong. S A M U E L S O N , Paul A. (1963): Risk and Uncertainty: A Fallacy of Large Numbers. Scientia 98 (1963): 108-113 S C H W A B E R , Ken und S U T H E R L A N D , Jeff (2020): The 2020 Scrum Guide. https: / / scrumgu ides.org/ scrum-guide.html. S V E N S O N , Ola (1981): Are We All Less Risky and More Skillful than Our Fellow Drivers? . Acta Psychologica, Volume 47, Issue 2, October 1981, Pages 143-148. <?page no="74"?> Register Ankertechniken-36 Backcasting-56 Backlog Refinement-59 Bewertungsrunde-63 Brainstorming-56 Critical Chain Methode-50 Definition of Ready-68 Diskussion-52 Epics-60 Erfahrung-30 Features-60 Fehleinschätzungen-19 Fibonacci-Folge-16, 48 Goodhart’sches Gesetz-40 Gruppendiskussionen-34 Kalibrierung-35 Kalibrierungsprozess-35 Komplexitätsschätzungen-21 Konfidenzintervall-48 Konfidenzniveau-55 Konsensentscheidungen-34 Kontrolle-31 Magic Story Points-16 Matthäus-Effekt-29 Mittelwert-52 Modellierung-36 Optimismus-40 PIG-Ansatz-59 PIG-Assessment-63 PIG-Schätzverfahren-60 Post Mortem Analyse-32, 55 Prediction Intervall Game-59 Pre Mortem Analyse-32, 55 Prospect Theory-45 Schätzförderer-54 Schätzparameter-20 Schwarmintelligenz-47, 51 Selbstüberschätzung-24 Skalierungsmethoden-36 soziales Engagement-68 Spike-23, 56 Sprint Velocity-19 Story Point Game-17 Story Point Poker-16, 26, 52 Story Points-13 Überpräzision-27 User Story-18 Wahrscheinlichkeit-49 Wettspiel-61 Wombat-17 Wunschdenken-28 <?page no="75"?> Abbildungsverzeichnis Abb. 1: INVEST User Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Abb. 2: Berechnungsgrundlage zur Beurteilung einer Spike Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Abb. 3: Beispiel für die Verwendung von Konfidenzintervallen . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Abb. 4: Eigene Einschätzung und Teameinschätzung . . . . . . 53 Abb. 5: Ablauf beim PIG-Schätzverfahren . . . . . . . . . . . . . . . . 62 Abb. 6: Intervalltabelle für die Wettrunde . . . . . . . . . . . . . . . . 65 Abb. 7: Wetten der Developer je Intervall . . . . . . . . . . . . . . . . 66 Abb. 8: Konfidenzintervalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 <?page no="76"?> Bisher sind erschienen: Ulrich Sailer Digitalisierung im Controlling Transformation der Unternehmenssteuerung durch die Digitalisierung 2023, 104 Seiten €[D] 17,90 ISBN 978-3-381-10301-0 Michael von Hauff Wald und Klima Aus der Perspektive nachhaltiger Entwicklung 2023, 85 Seiten €[D] 17,90 ISBN 978-3-381-10311-9 Ralf Hafner Unternehmensbewertung 2024, 133 Seiten €[D] 19,90 ISBN 978-3-381-11351-4 Irene E. Rath / Wilhelm Schmeisser Internationale Unternehmenstätigkeit Grundlagen, Führung, Organisation 2024, 175 Seiten €[D] 19,90 ISBN 978-3-381-11231-9 Reinhard Hünerberg / Matthias Hartmann Technologische Innovationen Steuerung und Vermarktung 2024, 152 Seiten €[D] 19,90 ISBN 978-3-381-11291-3 Ulrich Sailer Klimaneutrale Unternehmen Management, Steuerung, Technologien 2024, 130 Seiten €[D] 19,90 ISBN 978-3-381-11341-5 Oˇ guz Alaku¸ s Basiswissen Kryptowährungen 2024, 79 Seiten €[D] 17,90 ISBN 978-3-381-11381-1 Uta Kirschten Personalmanagement: Gezielte Maßnahmen zur langfristigen Personalbindung 2024, 159 Seiten €[D] 19,90 ISBN 978-3-381-12151-9 nuggets Die Reihe nuggets behandelt anspruchsvolle Themen und Trends, die nicht nur Studierende beschäftigen. Expert: innen erklären und vertiefen kompakt und gleichzeitig tiefgehend Zusammenhänge und Wissenswertes zu brandneuen und speziellen Themen. Dabei spielt die richtige Balance zwischen gezielter Information und fundierter Analyse die wichtigste Rolle. Das Besondere an dieser Reihe ist, dass sie fachgebiets- und verlagsübergreifend konzipiert ist. Sowohl der Narr-Verlag als auch expert- und UVK-Autor: innen bereichern nuggets. <?page no="77"?> Kariem Soliman Leitfaden Onlineumfragen Zielsetzung, Fragenauswahl, Auswertung und Dissemination der Ergebnisse 2024, 102 Seiten €[D] 19,90 ISBN 978-3-381-11961-5 Oˇ guz Alaku¸ s Das Prinzip von Kryptowährungen und Blockchain 2024, 133 Seiten €[D] 19,90 ISBN 978-3-381-12211-0 Eckart Koch Interkulturelles Management Managementkompetenzen für multikulturelle Herausforderungen 2024, 118 Seiten €[D] 19,90 ISBN 978-3-381-11801-4 Margareta Kulessa Die Konzeption der Sozialen Marktwirtschaft Ziele, Prinzipien und Herausforderungen 2024, 113 Seiten €[D] 19,90 ISBN 978-3-381-11411-5 Jörg Brüggenkamp / Peter Preuss / Tobias Renk Schätzen in agilen Projekten 2024, 75 Seiten €[D] 17,90 ISBN 978-3-381-12511-1 <?page no="78"?> ISBN 978-3-381-12511-1 In diesem Buch wird die Thematik Schätzen auf die Projektwelt angewandt. Wer kennt sie nicht, die großen Bauprojekte, die meist deutlich teurer werden und länger dauern als geschätzt. Egal ob es sich um die Elbphilharmonie handelt, den Berliner Flughafen oder Stuttgart 21. Verschiebungen und Kostensteigerungen sind an der Tagesordnung. In der agilen Projektwelt verspricht man sich deutlich bessere Schätzungen als bei den klassischen Verfahren. Zum einen findet der klassische Projektplan im agilen Kontext keine Anwendung, zum anderen sind die Planungszyklen deutlich kürzer. Dieser Band konzentriert sich darauf, die Hauptursachen für Fehleinschätzungen zu beleuchten und Möglichkeiten zur Verbesserung der Qualität von Abschätzungen aufzuzeigen. Er ist mitnichten als ein Plädoyer gegen Abschätzungen zu verstehen, sondern steht ganz im Sinne Dwight D. Eisenhowers Aussage: Plans are useless, but planning is essential.