RE-Metriken in SCRUM

Transkript

1 RE-Metriken in SCRUM Michael Mainik Abstract. In dieser Ausarbeitung werden die gängigsten Metriken zur Unterstützung einer SCRUM-Projektentwicklung vorgestellt und diskutiert. Da Metriken in agilen Entwicklungsmethoden sehr viel mit Aufwandsschätzungen zu tun haben, werden außerdem zwei Schätzungstechniken Story Points und Ideal Days vorgestellt und mit den beschriebenen Metriken in Zusammenhang gebracht. 1. Einleitung Der Prozess der Software-Entwicklung wurde bis vor wenigen Jahren als ein transparenter Ablauf aufgefasst, den man planen und einschätzen konnte. Man behandelte diesen wie einen industriellen Prozess, bei dem mit gleichem Input derselbe Output resultierte. Das bedeutete für Manager von Software-Projekten, dass sie versuchten jeden Schritt im Entwicklungsprozess vorherzusehen, vom Aufwand, Kosten und Risiken her einzuschätzen und dementsprechend die Entwicklungszeit festzulegen. Jedoch lassen sich nicht alle Systeme von Anfang an vollständig planen. Kunden wissen oft nicht genau wie das Produkt aussehen soll und ihre Anforderungen an das Produkt können während der Entwicklung sehr schwanken. Dies hatte zur Folge, dass viele Projekte aufgrund von unvorhergesehenen Problemen deutlich länger dauerten und kosteten, falls sie überhaupt abgeschlossen wurden. Da man mittlerweile weiß, dass Software-Entwicklung ein höchst komplexer Prozess ist, der sich nicht immer in allen Einzelheiten vor dem Projektbeginn planen lässt, waren andere Entwicklungstechniken nötig. Agile Techniken beruhen auf dem Prinzip der iterativen Softwareentwicklung und eignen sich ganz besonders für Projekte mit sich oft ändernden Anforderungen. Traditionelle Techniken wie das Wasserfall- Modell machten die Entwicklung solch unberechenbarer Systeme sehr teuer und zeitaufwendig. Eine von diesen agilen Techniken ist SCRUM. Sie basiert auf Aufwandsschätzungen für einzelne Features und iterativer Begutachtung des aktuellen Standes des Produkts. Auf den folgenden Seiten möchte ich diese Technik in 2. Prinzipien von SCRUM kurz vorstellen und in 3. Wie schätzt man richtig? / Wieso ist schätzen gut? zwei interessante Aufwandschätztechniken beschreiben. Im vierten und fünften Teil der Ausarbeitung werden zwei Metriken vorgestellt und diskutiert. Die Ausarbeitung wird dann schließlich mit einer Zusammenfassung und einem kurzem Vergleich mit anderen Ausarbeitungen abgerundet.

2 2 2. Prinzipien von SCRUM Diese Technik der Software-Entwicklung wurde erstmals von Takeuchi und Nonaka 1986 vorgestellt. Sie beschreibt eine iterative Entwicklung von Software bei der nach jedem Iterationsschritt laufende Software entstehen soll, welche getestet, ausgewertet und erweitert wird. Die Hauptidee ist, dass ein Team von fünf bis neun Entwicklern 30 Tage lang eine Liste von Anforderungen abarbeitet damit am Ende dieses Sprints eine lauffähige Software entsteht, die vom Kunden begutachtet werden kann. Bevor solch ein 30- tägiger Sprint beginnen kann muss eine priorisierte Liste, Product Backlog, von Anforderungen von dem Product Owner, vorzugsweise eine einzige Person, die Anforderungen sammelt und ordnet, erstellt werden. Aus dieser Liste nimmt sich ein Scrum-Team gemeinsam die Anzahl der Anforderungen mit höchster Priorität raus, die sie ihrer Schätzung nach in 30 Tagen umsetzen können, das Scrum Backlog. Hat das Team mit der Umsetzung des Scrum Backlogs begonnen, darf es nicht mit zusätzlichen Anforderungen belästigt werden. Sie sind für die Dauer eines Sprints praktisch isoliert, damit sie sich auf ihre Aufgaben komplett konzentrieren können. Damit die Entwickler ungestört und ungehindert arbeiten können, wird eine Person, der Scrum Master, mit der Aufgabe betraut, das Team abzuschirmen, zu beraten und Hindernisse aus dem Weg zu räumen. Er greift nicht in die Entwicklung ein, da sich ein Scrum-Team komplett selbst organisiert. Tägliche Besprechungen, Daily Scrums, von maximal 15 Minuten Dauer sorgen für einen effektiven Informationsaustausch zwischen den Entwicklern und dem Scrum Master. Hier lassen sich mögliche Hindernisse und Probleme aufdecken, damit der Scrum Master und das Management rechtzeitig reagieren können. Die Besprechungen sollten immer zur selben Zeit und am gleichen Ort stattfinden, damit alle mit Sicherheit wissen wo und wann das wichtige Treffen stattfindet. Es sind zwar Personen, die nicht zu einem Team gehören zugelassen, jedoch dürfen sie zu keinem Zeitpunkt der Besprechung daran aktiv teilnehmen. Der Scrum Master ist der Leiter der Besprechungen und lässt jedes Sprint-Team-Mitglied sprechen. Er stellt jedem Entwickler drei folgende Fragen: "Bist Du gestern mit dem fertig geworden, was Du Dir vorgenommen hast?" "Welche Aufgaben wirst Du bis zum nächsten Meeting bearbeiten?" "Gibt es ein Problem, das dich blockiert?" So erfährt jeder Entwickler was der andere leistet und demnächst macht und der Scrum Master deckt Probleme und Hindernisse auf. Nach 30 Tagen Sprint entsteht eine lauffähige Version, das Increment, mit den implementierten Anforderungen des Scrum Backlogs. Natürlich kommt es öfters vor, dass ein Team sich verschätzt und zu viele oder zu wenige Anforderungen in einen Sprint aufnimmt. Der Scrum Master hat die Aufgabe in solch einem Fall die Anzahl der Arbeit zu verringern oder zu erhöhen, so dass das Team stetig bis zum Ende des Sprints arbeitet und eine lauffähige Software liefert. Nach jedem Sprint wird das Increment von interessierten Personen begutachtet, getestet und diskutiert. Das ist der wichtigste Schritt dieser Entwicklungstechnik, weil er den am Produkt interessierten

3 3 Personen erlaubt spätestens nach 30 Tagen die wichtigsten gewünschten Features zu testen und Verbesserungsvorschläge oder neue Ideen zu äußern. Sie müssen nicht Monate auf die erste Version warten, sondern erhalten handfeste Ergebnisse bereits nach 30 Tagen. Im nächsten Sprint werden die Verbesserungen und Erfahrungen des vorherigen Sprints einbezogen. Jeder Sprint fügt dem Produkt die wichtigsten Features hinzu und bietet Kontrolle über den Entwicklungsprozess. 3. Wie schätzt man richtig? / Wieso ist schätzen gut? Wie oben schon angesprochen, ist Softwareentwicklung mit einem sehr hohen Aufwand an Anforderungssammlung und Dokumentation verbunden. Man hat versucht, jeden Schritt des Entwicklungsprozesses so genau wie möglich zu planen und seine Dauer und Kosten zu schätzen. Aufbauend auf diesen Informationen wurde ein Zeit- und Kostenplan für die Entwicklung eines Systems festgelegt. Man weiß heute, dass das nicht bei allen Projekten möglich und deshalb eine andere, flexiblere (agile) Herangehensweise notwendig ist. Damit ein Projekt agil ist und bleibt sind Schätzungen von Aufwand und Dauer einer Entwicklung notwendig. Das bedeutet keinesfalls, dass diese Schätzungen immer zutreffen müssen. Vielmehr geben sie einen groben Rahmen, in dem ungeplante Anforderungen enthalten sind. Es ist und war allgemein bekannt, das die Einschätzung von Aufwand und Entwicklungsdauer eines Systems stets unpräzise bleibt, ungeachtet des Aufwandes welchen man für die Einschätzung aufbringt. Das Ergebnis einer Schätzung kann sich in manchem Fällen sogar mit steigendem Planungsaufwand verschlechtern, da ein Projektplan immer festere Form annimmt und nicht auf unvorhergesehene Probleme reagieren kann. Abbildung 1. Beziehung zwischen Aufwand und Genauigkeit [Coh07] Auf der Abbildung 1 ist diese Problematik dargestellt. Die ersten 10% des Aufwandes resultieren bereits in einer mehr als 50% genauen Schätzung. Das bedeutet mit relativ

4 4 wenig Aufwand erreicht man einen Großteil an Genauigkeit einer Schätzung. Auf diesem Prinzip basiert auch die Planung in agilen Entwicklungsmethoden wie z.b. Scrum. Vor einem Sprint versucht man erst gar nicht große Analysen und Planungen bezüglich Aufwand und Dauer für eine bestimmte Anforderungsmenge zu betreiben, denn sie kosten Zeit, Geld und liefern relativ weniger genaue Schätzungen als mit weniger Planung. Was Entwickler aber tun, ist Anforderungen, die sie umsetzen möchten aufbauend auf eigenen Erfahrungen und Informationen aus früheren Sprints/Projekten auf den Aufwand und Dauer zu schätzen. Hierbei spielt natürlich der Scrum Master eine entscheidende Rolle, indem dieser seine umfassendere Sicht der früheren Sprints und Projekte mit einbringt und die Schätzung enorm verbessern kann. Doch wie schätzt man richtig? Gibt es Techniken oder Metriken, um das Schätzen zu verbessern? In seinem Buch Agile Estimating and Planning beschreibt M. Cohn [Coh07] zwei interessante Maßeinheiten und Vorgehensweisen, Schätzungen eine solide Grundlage zu geben, die bis zu einem gewissen Grad mit Fehleinschätzungen gültig bleibt. Eine der Maßeinheiten ist Story Points. Dies ist eine abstrakte Einheit, welche den geschätzten Aufwand eines Features in einem System quantifiziert. Man wählt zuerst eine Menge an Story Points aus, die man Features zuordnen möchte, z.b. 1 bis 10, und sucht das Feature mit vermutlich geringstem Entwicklungsaufwand aus. Dieses Feature erhält den Story-Points-Wert 1. Nun sucht man sich ein Feature aus, was vermutlich den mittleren Aufwand verglichen mit allen anderen Features beansprucht und ordnet diesem den Wert 5 zu. Die restlichen Features werden relativ zu den zwei ersten und allen bereits gewerteten geschätzt und gewertet. Der Vorteil dieser Vorgehensweise und Metrik ist, dass alle Features relativ zueinander gewertet werden. Das bedeutet, wenn sich ein Entwickler bei einem Feature mit dem konkreten Aufwand verschätzt hat, gilt immer noch die Relation zu allen anderen. Daraus ergibt sich ein weiterer Vorteil. Die Dauer eines Projektes lässt sich mit Hilfe der Story Points und der geschätzten Umsetzung von Story Points pro Zeiteinheit herleiten. Dabei wird keine neue Schätzung nötig sein, wenn sich jemand im konkreten Aufwand eines oder mehrer Features verschätzt hat. Denn wenn die relativen Größen noch stimmen, lässt sich die Dauer einfach herleiten. Die Schätzung des Aufwandes ist somit unabhängig von der Dauer. Die zweite Maßeinheit beschreibt die geschätzte Anzahl von Ideal Days, also reinen Arbeitstagen, in denen nur an dem Feature was geschätzt wird gearbeitet wird. Ideal Days beinhalten weder Wochenenden, Besprechungen noch Telefonate, die nichts mit dem Feature zu tun haben. Das bedeutet, ein Entwickler wird gefragt wie viele Tage reiner Arbeitszeit er für ein bestimmtes Feature voraussichtlich brauchen wird. Diese Maßeinheit bringt jedoch einige Nachteile mit sich, denn ihre Aussage muss über die Zeit nicht einheitlich bleiben. Ein unerfahrener Entwickler wird für ein Feature anfangs 5 Ideal Days schätzen und nachdem er Erfahrung gesammelt hat womöglich nur 1 Ideal Day. Das würde bedeuten, dass er im ersten Fall ein Feature innerhalb von 5 Ideal Days umsetzen würde und im zweiten fünf Features in derselben Zeit. Würde man die Geschwindigkeit (Velocity) = Ideal Days umgesetzt messen wollen, so ergäbe sich für beide Fälle die Geschwindigkeit von 5 obwohl im zweiten Fall mehr geleistet wurde.

5 5 [Coh07] rät dazu, die Story Points als Maßeinheit zu verwenden, da sie aufgrund ihrer Relativität und der Fähigkeit des Menschen, Relationen gut einschätzen zu können mehr Aussagekraft besitzen als Ideal Days. Story Points beschreiben den nötigen Aufwand, um ein System zu entwickeln, wobei sich die Verhältnisse zwischen Features viel weniger ändern als die Einschätzung der Entwickler wie lange sie für ein Feature vermutlich brauchen würden. 4. Backlog Graph Wenn sich ein Scrum-Team auch selbst organisiert, braucht der Scrum Master und der Kunde Informationen über den Fortschritt einer Entwicklung, wann voraussichtlich mit dem Release zu rechnen ist und ob es Probleme gibt. Von den eingesetzten Metriken hängt viel ab. Eine der wichtigsten Funktionen des Scrum Masters ist es Hindernisse aus dem Weg zu räumen, damit die Entwicklung stetig fortschreitet. Durch Gespräche mit Entwicklern offenbaren sich nicht immer alle Probleme, da Entwickler grundsätzlich eine andere Sicht auf das Projekt haben als der Scrum Master. Hat sich der geschätzte Aufwand plötzlich erhöht, so verbreitet sich im Team Frustration, da man die aufgetauchten Schwierigkeiten nicht vorhersah. Als Folge sind alle gestresst, da sie davon ausgehen, dass das Sprint Backlog nicht mehr abgearbeitet werden kann. Nicht immer werden diese Gedanken sofort dem Scrum Master geschildert, sondern man versucht mehr zu leisten damit es doch noch klappt. Manchmal ist es jedoch viel hilfreicher, bei steigender verbleibender Arbeit einige Anforderungen erstmal für diesen Sprint zu verwerfen, damit am Ende des Sprints ein lauffähiges Increment entsteht (wenn auch nicht vollständig). Solche Änderungen sind normal, jedoch muss man sie früh genug erkennen können. Die wohl beliebteste Metrik, die in Scrum eingesetzt wird ist sowohl simpel als auch hilfreich beim Aufdecken von Problemen, beim Schätzen des Release-Termins und beim Beobachten der Arbeitsweise eines Teams: der Burn Down oder Backlog Graph. Abbildung 2: Release Burn Down Graph [Coc]

6 6 Abbildung 2 zeigt den Verlauf von verbleibender Arbeit, in diesem Fall in Story Points gemessen, aufgetragen über die Zeit oder Iterationen (Sprints). Das ist die gröbste Darstellung, da auf der Zeitachse Iterationsendzeitpunkte eingetragen sind. Solch eine Darstellung dient z.b. zur Demonstration des Fortschritts vor dem Management, um dieses über die Veränderungen im Release-Termin aufzuzeigen und zu erklären. Auf der Grafik sind drei Punkte markiert, die typische Situationen in einem Entwicklungsprozess widerspiegeln. Die ersten zwei Stellen am Ende der zweiten und vierten Iteration zeigen einen Anstieg der verbleibenden Arbeit, was mehrere Gründe haben kann. Oft bedeutet ein starker Anstieg, dass unvorhergesehene Dinge auftauchen, die implementiert werden müssen. Die Entwickler schrauben also ihre Schätzungen hoch. Manchmal bedeutet es aber auch, dass einfach neue Anforderungen aufgetaucht sind, die der Kunde gerne implementiert haben möchte. Der dritte markante Punkt am Graphen zeigt einen senkrechten Abfall der verbleibenden Arbeit. Solch ein Verlauf bedeutet, dass einige Anforderungen aus dem Product Backlog entfernt wurden, da man merkte, dass das Projekt sonst nicht in der vorgesehenen Zeit fertig werden würde. Hier liegt auch der Vorteil dieser Metrik: sie erlaubt die Mitverfolgung der gesamten Entwicklung und natürlich auch Kontrolle über die nächsten Iterationen. Nach der siebten Iteration war offensichtlich, dass das Projekt nicht am Ende der achten Iteration wie gewünscht fertig wird, also wurden Anforderungen, die weniger kritisch sind entfernt, damit ein fertiges Produkt entsteht. Diese Entscheidung wäre nach den ersten zwei Anstiegen des Graphen nicht notwendig gewesen, da man aufgrund der Entwicklung nach der vierten Iteration davon ausgehen konnte, dass es ein Release am Ende der achten Iteration gibt. Nach dem Anstieg in der sechsten Iteration sah man sofort, dass es nicht mehr klappt, also wurde gehandelt. Der Kunde hat nach jeder Iteration dank dem Graphen die nötigen Informationen, um Entscheidungen treffen zu können. Gleichermaßen kann man den Graphen verwenden, um während eines Sprints Probleme aufzudecken und auf sie zu reagieren. Abbildung 3: Burn Down Graph mit Verringerung des Umfangs [SB02]

7 7 Dieser Burn Down Graph stellt einen typischen Verlauf verbleibender Arbeit für einen einzigen Sprint dar. Auf der y-achse sind die geschätzten Arbeitsstunden und auf der x-achse die Tage eines Sprints aufgetragen. Die Stunden beschreiben den reinen Arbeitsaufwand und könnten so in Ideal Days übersetzt werden. Die Schätzungen entstehen vor jedem Sprint in einer längeren Besprechung zusammen mit dem Scrum Master und den zuständigen Entwicklern. Hierbei dienen eigene Erfahrungen der Entwickler und Erfahrungen aus frühren Sprints / Projekten als Basis für die Aufwandschätzungen. Die Entwickler sind die eigentlichen Schätzer, da sie sich am besten in ihrem jeweiligen Umfeld auskennen. Der Scrum Master trägt auch seinen Teil zu Schätzungen bei, da er stets eine umfassende Sicht auf das Projekt und seine Entwicklung besitzt und so z.b. das Zusammenführen oder das Testen von einzelnen Features am besten einschätzen kann. Die x-achse enthält sowohl Arbeits- als auch Wochenendtage. Hier sind wieder einige interessante Punkte im Verlauf mit Kommentaren versehen. Der erste interessante Punkt zeigt ein sehr typisches Problem eines Sprints auf: das Aktualisieren der Schätzungen. Hier wurden die Schätzungen innerhalb von vier Tagen (zwei davon Wochenendtage) nicht nachgetragen weshalb sich der Verlauf auch nicht ändert und auch keine Aussagekraft über den Fortschritt bietet. Es ist wichtig, dass Schätzungen jeden Tag aktualisiert werden, damit solch ein Graph auch seine Aufgabe erfüllen kann. Die nächsten zwei Punkte zeigen ebenfalls ein Problem auf, was besonders bei unerfahrenen Teams vorkommt. Nach der ersten Woche merken die Entwickler, dass sie sich überschätzt haben und der Scrum Master muss eingreifen und den Umfang verringern, damit am Ende des Sprints ein Increment entsteht, welches begutachtet werden kann. Die letzten acht Tage des aufgezeigten Sprints stellen einen fast idealen Verlauf dar: jeden Tag wurde etwa die gleiche Menge an Arbeit bewältigt und der Sprint erfolgreich abgeschlossen. 5. Earned Business Value Mit Hilfe eines Burn Down Graphs kann man also die Entwicklung eines Software- Projektes in Bezug auf die verbleibende Arbeit mitverfolgen und Entscheidungen treffen. Da ein solches Projekt nicht ohne die nötigen finanziellen Mittel laufen kann, möchte man auch Einsicht in den wirtschaftlichen Wert und die Entwicklung des Wertes eines Produktes mitverfolgen können. Hierfür bietet sich die recht verbreitete Earned Business Value (EVB)-Metrik an. Bevor ich jedoch auf diese Metrik näher eingehe, möchte ich das Prinzip von der Work Breakdown Structure (WBS), welche zum Verständnis von EVB wichtig ist, erläutern.

8 8 Abbildung 4: Eine beispielhafte Work Breakdown Structure [BSR05] Abbildung 4 zeigt ein typisches Beispiel für ein WBS. Ein WBS dient dazu ein Projekt in all seine Zielelemente zu zerlegen und in einer Baumstruktur anzuordnen. Dabei ist zu beachten, dass es keinerlei Priorisierung oder Vorschläge zum Vorgehen beinhaltet, sondern nur die geplanten Features aufzeigt. Die zugeordnete Zahl eines Knotens beschreibt sein relatives Relevanzgewicht gegenüber dem Elternknoten. Das bedeutet das z.b. der Product -Knoten 3/4 der Relevanz gegenüber dem höchsten Knoten relativ zu den restlichen Knoten auf derselben Ebene besitzt. Ein Gewicht von 0 bedeutet zwar, dass ein Knoten keinen Wert gegenüber seinem Elternknoten besitzt, jedoch können die Gewichtungen seine Kindknoten durchaus voneinander unterscheiden. Abbildung 5: Zuwachs an Business Value nach zwei Sprints [BSR05] Die EVB-Metrik ist vom Aufbau her dem Burn Down Graphen sehr ähnlich. Auf den ersten Blick beschreibt sie in umgekehrter Reihenfolge nicht die Abnahme verbleibender Arbeit, sondern die Steigerung des wirtschaftlichen Wertes eines Produktes. Abbildung 5 beschreibt z.b. das Wachstum des Wertes eines Produktes mit jedem Sprint, dabei wird am Ende jedes Sprints der wirtschaftliche Wert jedes implementierten Features mit Hilfe von WBS ausgerechnet und aufaddiert. Der implementierte Mehrwert eines Sprints wird ebenfalls auf den letzten Sprint aufaddiert. Zum Vergleich dient stets die geschätzte Baseline (schwarz), die davon ausgeht, dass in der Start- und Endphase die Produktivität des Entwicklungsteams

9 9 nicht ideal sein kann, daher nicht-linearer Verlauf. In der Mitte wird eine lineare Steigerung des wirtschaftlichen Wertes erwartet. Wie die Berechnung vom Wert eines Features genau stattfindet möchte ich im Folgenden darstellen. Um den wirtschaftlichen Wert eines implementierten Features wie z.b. Deposit Check aus Abbildung 4 auszurechnen, benötigen wir zuerst den Business Value Index (BVI) des Deposit Check -Knotens. Der BVI beschreibt den Anteil eines Features am gesamten Produkt. So z.b. für Deposit Check würde der BVI 1 * 3/4 * 1 * 7/43 = 21/172 betragen. Die einzelnen Faktoren beschreiben die relativen Gewichte auf ihren Ebenen. Die Summe der Gewichte auf der Function - Kindebene z.b. beträgt 43 und Deposit Check ist 7 davon wert. Bei dem geschätzten Gesamtwert des Projektes von $ würde das Deposit Check - Feature also einen Wert von $ ($ * 21/172) haben. Anhand dieser Metrik könnte also der Kunde beobachten ob der Wert seines Produktes sich erwartungsgemäß entwickelt. Bei größeren Abweichungen von der Baseline kann, wie beim Burn Down Graphen, nach jedem Sprint eine Reaktion erfolgen, um mögliche Probleme zu lösen. Ein Nachteil dieser Metrik ist, dass es nur den Zusammenhang zwischen geschätztem Wert und implementierten Wert darstellt und nichts drüber aussagt, ob man wirklich die gewünschten Features implementiert. Es wird nur die Wertsteigerung aufgetragen, egal ob dieser Mehrwert nützlich ist oder nicht. Hier wäre es hilfreich eine Metrik zu haben, die zusammen mit EBV die Relevanz der implementierten Features sicherstellt. Eine interessante Idee hierfür hatte V. Szalvay [Sza04] indem er in die Berechnung des Wertes eines implementierten Features seine Priorität im Product Backlog mit einbezog. Dies geschieht indem man den Wert eines Product Backlog Elementes (wirtschaftlicher Wert oder geschätzter Aufwand) mit seiner relativen Priorität multipliziert. Um den relativen Wert der Priorität zu berechnen könnte man nach dem Prinzip der Story Points vorgehen. Da man die Prioritäten relativ zueinander bewertet so können diese Werte auch die relativen wirtschaftlichen Werte der Product Backlog Elemente repräsentieren. So würde durch die Kombination der beiden Metriken eine Metrik entstehen, die sowohl das wirtschaftlichen Wachstum eines Produktes als auch die tatsächliche Relevanz der implementierten Features widerspiegelt. 6. Zusammenfassung Scrum und mit ihm die agilen Entwicklungstechniken stellen einen interessanten Kontrast zu den traditionellen Methoden dar. Es gibt viel weniger Dokumentation, keine langen Planungen, sondern Schätzungen und iterative Auswertungen der fertigen Features zusammen mit dem Kunden. Regelmäßig kann dieser die Software begutachten und darauf basierend Entscheidungen treffen, damit am Ende das gewünschte Produkt entsteht. Auch Metriken für eine Scrum-Entwicklung basieren logischerweise auf den Iterationszyklen und sollen unter anderem dem Kunden den Entwicklungsfortschritt offenbaren. Globale Burn Down Graphen zeigen den Verlauf der geschätzten verbleibenden Arbeit über alle Iterationen und helfen bei Schätzungen des Release-Termins. Sprint Burn Down Graphen zeigen denselben Verlauf innerhalb

10 10 eines einzelnen Sprints und helfen dem Scrum Master Hindernisse aufzudecken und zu beseitigen. Business Value Graphen dienen dem Management bei der gegenwärtigen und zukünftigen Finanzplanung des Produktes. All diese Metriken basieren jedoch auf Aufwandschätzungen von Entwicklern. Es wurden zwei Vorgehensweisen für das Schätzen von Dauer und Aufwand, die Story Points und Ideal Days, vorgestellt. Die in anderen Ausarbeitungen vorgestellten Metriken unterscheiden sich meiner Meinung nach deutlich von den Metriken in Scrum. Die vorgestellten Metriken fokussieren sich auf die Sammlung oder Dokumentation von Anforderungen und den Anteil der korrekt umgesetzten oder interpretierten Anforderungen. In Scrum wird prinzipiell viel weniger Aufwand in die Sammlung und Dokumentation von Anforderungen gesteckt und deshalb arbeiten die Metriken in Scrum mit Aufwandschätzungen, um den Verlauf von Projekten zu verstehen und zu steuern. Aufgrund der kundennahen Entwicklung und der relativ kurzen Iterationen nach denen die Software begutachtet wird, ist der Schwerpunkt Anforderung hier eher in den Hintergrund gerückt. 7. Quellenverweis [SB02] Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, 2002 [Coh07] Agile Estimating and Planning, Mike Cohn, 2007 [Sza04] Business Value Added as a Scrum Metric, Victor Szalvay, 2004 [Coc] Dr. Alistair Cockburn, [BSR05] Reporting Scrum Project Progress to Executive Management through Metrics, B. Barton, K. Schwaber, D. Rowsthorne,