Seminar. Scrum. Author: Crina-Maria Iliadis Matrikel-Nr Betreuender Professor: Roland Dietrich

Transkript

1 Seminar Scrum Author: Crina-Maria Iliadis Matrikel-Nr Betreuender Professor: Roland Dietrich 11. Januar 2015

2 Inhaltsverzeichnis 1 Einleitung Motivation Was ist Scrum? Wo ist Scrum Sinnvoll? Die Rollen, Verantwortlichkeiten Interne Rollen Der Product Owner Das Entwicklungsteam Der Scrum Master Externe Rollen Das Management Customer User Artefakte Impendiment Backlog Product Backlog Selected Product Backog Potentially Shippable Product Increment Sprint Backlog Visualisierungstechniken Taskboard Burn-Down-Chart Aktivitäten Estimation Meeting Das erste Sprint Planning Das zweite Sprint Planning Daily Scrum Sprint Review Sprint Retrospektive Scrum of Scrums Meeting Vorgehensweise 10 7 Schluÿwort 14 1

3 1 Einleitung 1.1 Motivation In meiner früheren Anstellung als Softwaretesterin war mein direkter Vorgesetzte ein Scrum Master. Dieser hat das Daily Scrum und das Taskboard in unserer Abteilung eingeführt. Meine persönlichen Erfahrungen mit dem Taskboard waren sehr positiv. Durch das Taskboard konnte ich meine täglichen unterschiedlichen Arbeiten und Fortschritte visualisieren für mich und für die internen Anwender und Entwickler. Das ersparte mir oft lange Diskussionen mit einzelnen Entwicklern über die Dringlichkeit der Fehleraufbereitung oder Nachtests. Die Entwickler durften mir Aufgaben auf Karten schreiben und die Dringlichkeit mit mir abklären. Ich kann nicht behaupten dass sich unsere Zusammenarbeit dadurch gebessert hat denn sie war stets einwandfrei aber ich bekam das Gefühl dass meine Arbeit höher geschätzt wurde. Dadurch wurde mein Interesse an Scrum geweckt. In dieser Ausarbeitung werde ich nicht zu sehr auf die Hindernisse die bei der Scrum Einführung auftreten können oder welche Methoden geeigneter wären um Scrum erfolgreich einzuführen eingehen sondern die Funktionsweise von Scrum erläutern. Wer sich intensiver mit Scrum beschäftigen möchte empfehle ich die im Literaturverzeichnis erwähnte Literatur auf die diese Ausarbeitung basiert. 1.2 Was ist Scrum? Der Begri Scrum stammt aus dem Rugby und wird auf Deutsch mit Gedränge übersetzt. Zwei Mannschaften stehen sich nach einen kleineren Regelverstoÿ gegenüber und versuchen gemeinschaftlich die gegnerische Mannschaft daran zu hindern Raum zu gewinnen. Die Mannschaft die den Regelverstoÿ nicht verursacht hat erhält den Ball. Die Verwendung des Begris soll auf den Zusammenhalt der Mannschaft und das Rugby ein sehr diszipliniertes Spiel ist verweisen. Scrum ist ein Framework für das Projektmanagement mit der Timebox als die wichtigste und stärkste Rahmenbedingung. Es wurde in der Softwareentwicklung konzipiert, ist aber davon unabhängig und kann in allen anderen Bereiche angewendet werden. Scrum basiert auf den Grundsätzen der agilen Softwareentwicklung, auÿerdem ist Scrum empirisch, inkrementell und iterativ. Empirisch baut auf drei Punkte auf: Transparenz: Das Projekt ist für jeden sichtbar Überprüfung: Nach jedem Sprint wird das Projekt und das gelieferte Produkt überprüft und beurteilt Anpassung: Pläne und Vorgehensweise werden immer wieder überprüft und neu erarbeitet. Kein starres Vorgehen. Nicht nur das Produkt sondern auch die Planung werden in Scrum inkrementell und iterativ entwickelt. Der Aufbau besteht aus fünf Artefakten, sechs Aktivitäten und sechs Rollen. 2

4 1.3 Wo ist Scrum Sinnvoll? Scrum ist für Projekte die klare Start und Endzeiten haben, auÿerdem sollte ein Scrum Team aus mindestens drei und höchstens neun Mitglieder bestehen. Ist ein Team gröÿer als neun Mitglieder sollte es aufgeteilt werden da der Verwaltungsaufwand zu groÿ und unübersichtlich wird, dadurch wird das Gelingen des Scrum Teams gefährdet. Es ist von groÿen Vorteil wenn das Management voll und ganz dahinter steht und alle externen Anforderungen vom Scrum Team fern hält und die notwendigen Räumlichkeiten und Materialien zur Verfügung stellt. Für das Gelingen braucht man einen zertizierten Scrum Master. Sollte das Unternehmen keinen Scrum Master haben kann ein Mitarbeiter geschult werden oder ein externen Scrum Master beauftragt werden. 2 Die Rollen, Verantwortlichkeiten 2.1 Interne Rollen [Glo13] Abbildung 1: Interne Rollen Die Internen Rollen arbeiten kontinuierlich zusammen an dem Projekt und ergeben das Scrum Team Der Product Owner Der Product Owner ist eine Person die den Kunden repräsentiert und eine klare Vision des Produkts hat. Er weiÿ wie die Software später funktionieren soll und ganz genau was der Kunde möchte. Er beschreibt die Funktionsweise und legt die Eigenschaften des Produkts fest. Ihm alleine obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. Er muss kontinuierlich die Product Backlogs priorisieren, wodurch die Protabilität des Projekts gesteigert wird. Er geht nie ohne Product Backlog in ein Sprint Planing und bewertet am Ende jedes Sprints die Ergebnisse des Entwicklungsteams. Er muss jedes Mal die Produktvision dem Entwicklungsteams neu erklären. 3

5 2.1.2 Das Entwicklungsteam Das Entwicklungsteam besteht im Idealfall aus mindestens drei und höchstens neun Personen. Sollte das Team gröÿer sein, wird dieses in mehrere Teams eingeteilt und Scrum of Scrums angewendet. Das Entwicklungsteam analysiert die Anforderungen, erarbeitet die Stories und entwickelt das Design. Auÿerdem ist das Entwicklungsteam verantwortlich für die Implementierung, den Test und die Auslieferung des Produkts. Es arbeitet mit dem Product Owner und den Kunden zusammen um die Product Backlog Items zu gestalten, abzuschätzen und zu qualizieren. Das Entwicklungsteam teilt sich die Arbeit mit Hilfe des Product Backog selbst ein, genauso wie die Aufgabenzuständigkeiten. Im Entwicklungsteam sind alle gleichgestellt Der Scrum Master Der Scrum Master ist ein Moderator der für die Durchführung von Scrum verantwortlich ist. Zu seinen Verantwortlichkeiten zählt auch die Änderung von Strukturen in der Organisation. Er ist auch für das Gelingen verantwortlich. Er ist die Schnittstelle zwischen dem Entwicklungsteam, dem Product Owner und anderen Abteilungen. Er sorgt dafür dass das Entwicklungsteam vor äuÿeren Einüsse geschützt wird und kümmert sich um Behebung von Störungen und Hindernissen wie z.b. mangelhafte Kommunikation, Zusammenarbeit oder persönliche Konikte. Er sorgt für das Abarbeiten von Impendiments (Hindernissen) die auf das Impendiment Backlog beziehen. Der Scrum Master moderiert die Aktivitäten und achtet auf das Einhalten von Regeln und Termine. In Scrum ist die Einhaltung der Termine die wichtigste Regel. Obwohl der Scrum Master mit dem Entwicklungsteam zusammen arbeitet gehört er nicht dazu und ist auch nicht höher gestellt als das Team. Der Scrum Master darf einzelnen Mitgliedern des Teams keine direkten Arbeitsanweisungen geben. 2.2 Externe Rollen [Glo13] Abbildung 2: Externe Rollen 4

6 Externe Rollen sind Personen die am Scrum Projekt mitwirken und das Scrum Team unterstützen aber nicht aktiv daran arbeiten Das Management Das Management stellt die personelle Besetzung des Teams und des Scrum Masters bereit und sorgt für die Personalentwicklung und Weiterbildung. Zudem stellt es die Arbeitsmittel und die Räume bereit. Sorgt dafür dass die Rahmenbedingungen stimmen. Auÿerdem sorgt das Management dafür dass das Entwicklungsteam nicht durch externe Arbeitsanforderungen gestört wird. Das Management arbeitet mit dem Scrum Master zusammen und hilft ihm Hindernisse aus dem Weg zu räumen damit das Entwicklungsteam ungestört arbeiten kann Customer Die Rolle Customer (Kunde) ist die Person die die Entwicklungskosten des Produkts übernimmt, dessen Ziel ist es die Anwender des Produkts zufrieden zu stellen. Bei interner Anforderung ist der Kunde die Person die für die Freigabe des Budgets verantwortlich ist. Der Kunde arbeitet sehr eng mit dem Product Owner zusammen und sollte nach den ersten Sprints die Möglichkeit bekommen die ersten Funktionalitäten zu begutachten und zu bewerten. Nur so kann die kundennahe Entwicklung gewährleistet werden. Jedoch sollte weder der Kunde noch der Product Owner im laufenden Sprint eingreifen können User Der User (Anwender) ist die Person die später das Produkt anwendet. Der Anwender kann muss aber nicht der Kunde sein. Er weiÿ genau welche Funktionalitäten das Produkt haben muss und wie das Produkt später angewendet werden wird. Der Anwender sollte beim Sprint Review und Product Backlog unbedingt dabei sein, um das Produkt testen zu können und Feedback zu geben. 3 Artefakte Artefakte sind Dokumente unterschiedlicher Arten die für die Realisierung von Scrum Notwendig sind. 3.1 Impendiment Backlog Impendiment Backog ist die Aufgabenliste des Scrum Masters, es ist eine Liste mit all den Hindernissen die für das Entwicklungsteam während oder vor der Entwicklungsarbeit entstehen. Sollte ein Hindernis während des Sprints festgestellt werden kann dieser in Daily Scrum angesprochen und vom Scrum Master in der Liste eingetragen. Diese Hindernisse müssen vom Scrum Master beseitigt werden. 5

7 Diese Liste muss vom Scrum Master abgearbeitet und sehr genau verwaltet werden, denn durch diese Liste können später Prozessverbesserungen vorgenommen werden. 3.2 Product Backlog Das Product Backog wird vor jeden Sprint vom Product Owner zusammengefasst und besteht aus einer sehr langen Liste von Product Backog Items (Funktionalitäten oder Anforderungen in Scrum auch Stories genannt). Das Product Backlog ist dynamisch und unvollständig, es wird immer vor jedem Sprintplanning neu aktualisiert und noch nicht realisierte Items werden priorisiert. Die Priorisierung der Stories erfolgt nach wirtschaftlichen Nutzen und Notwendigkeit. Die Anforderungen werden Anwender orientiert und fachlich beschrieben. 3.3 Selected Product Backog Die in Estimation und in Sprint Meeting erarbeiteten Stories aus dem Product Backog werden in Selected Product Backog eingetragen. Es handelt sich um eine priorisierte Liste von User Stories die das Entwicklungsteam in einem Sprint umsetzen muss. 3.4 Potentially Shippable Product Increment Hierbei handelt es sich um eine Liste aller Produktteile (Stories) die jederzeit geliefert werden können da diese keine Entwicklung oder Verwaltung mehr benötigen. 3.5 Sprint Backlog Besteht aus Product Backog Einträgen die für den aktuellen Sprint ausgewählt wurden. Ist immer der aktuelle Plan des Entwicklungsteams und für alle berechtigten Personen im Unternehmen sichtbar. Hierfür wird häug ein Taskboard benutzt. 4 Visualisierungstechniken In Scrum werden das Taskboard und das Burn-Down-Chart als Visualisierungstechniken benutzt. Diese können auf weiÿes Papier, White-Boards oder mithilfe von Flip-Charts dargestellt werden. Die Visualisierung ist nicht nur für das Entwicklungsteam das somit seine Aufgaben und Fortschritte visuell erfassen kann sondern auch für den Rest des Unternehmens oder andere betroene Abteilungen da. Hiermit stellt man die Wichtigkeit der Aufgaben dar. Aus eigener Erfahrung weiÿ ich dass auch Menschen die sich gegen die Einführung von Scrum aussprechen sehr gerne das Taskboard in ihrer täglichen Arbeit anwenden. 6

8 [Glo13] Abbildung 3: Taskboard mit Stories 4.1 Taskboard Das Taskboard wird vom Entwicklungsteam bearbeitet und aktualisiert. Es enthält alle Aufgaben die das Entwicklungsteam für den aktuellen Sprint bearbeiten muss. Das Taskboard ist in vier Spalten eingeteilt. 1. Stories beinhaltet alle Aufgaben die in diesen Sprint bearbeitet werden müssen in priorisierter Reihenfolge. 2. Tasks to do beinhaltet alle Aufgaben die für die einzelnen Stories realisiert werden müssen. Diese Aufgaben können sich auch während des Sprints entwickeln, die meisten wurden jedoch während des Sprint Planning Nr.2 entwickelt. 3. Work in progress beinhaltet alle Aufgaben an denen einzelne Team Mitglieder arbeiten. Eine Aufgabe sollte nicht länger als einen Tag dauern. Falls eine Aufgabe länger als einen Tag dauert muss diese in mehrere Tagesaufgaben eingeteilt werden. 4. Done wurde für jede Aufgabe am Anfang des Sprints oder des Projekts deniert. Es deniert ob zu einer Story Unittests, Dokumente oder Kommentare gehören. Erst wenn diese vollständig erstellt wurden kann das Team Mitglied die Karte von Work in progress auf Done setzen. Jetzt kann das Team Mitglied eine neue Aufgabe beginnen. Am Ende jedes Sprints müssen alle Stories auf done sein. Sollten Stories wegen Hindernissen nicht realisiert werden können müssen diese gekennzeichnet werden und im nächsten Daily Scrum diskutiert. Der Scrum Master muss diese Hindernisse in Impendiment Backlog eintragen und beheben. 7

9 4.2 Burn-Down-Chart [Glo13] Abbildung 4: Burndown Chart Das Burn-Down-Chart zeigt den Fortschritt des Teams in einem Sprint gemessen an den realisierten Stories und nicht an ihre Aufgaben. Die Aktualisierung des Burn-Down-Charts ist Aufgabe des Teams und es sollte sehr schnell möglich sein. Es ist von Vorteil wenn das Burn-Down-Chart neben dem Taskboard aufgehängt wird. 5 Aktivitäten In Scrum werden Meetings als Aktivitäten oder Ereignisse bezeichnet. So will man zeigen dass in diese Meetings alle Mitglieder arbeiten müssen. Alle Meetings sind zeitlich begrenzt und öentlich (d.h. jeder berechtigte Mitarbeiter kann daran teilnehmen) auÿerdem beginnen und enden sie pünktlich. Alle Teilnehmer müssen vorbereitet in das Meeting gehen und die Agenda muss bekannt sein. Der Moderator (Scrum Master) ist jederzeit anwesend und aktiv, auÿerdem beendet er jedes Meeting mit einer Zusammenfassung. 5.1 Estimation Meeting Das Estimation Meeting dauert fünfunddreizig Minuten und ndet jede Woche statt. Der Zweck des Estimation Meetings ist die Einschätzung der Stories durch das Entwicklungsteam. Der Product Owner präsentiert dem Team die priorisierten Product Backlog Items (Stories). Groÿe Stories werden in kleinere aufgeteilt und neu abgeschätzt. 8

10 Das Ergebnis des Estimation Meetings ist ein geschätztes Product Backlog, kleine Stories und eine Liste von Funktionen die bearbeitet werden müssen. 5.2 Das erste Sprint Planning Das erste Sprint Planning Meeting dauert sechzig Minuten und es wäre vom Vorteil wenn es Vormittags statt ndet damit das zweite Nachmittags statt nden kann. In dieser Aktivität wird analysiert was der Kunde funktional wirklich will, auÿerdem werden hier die Done Kriterien besprochen, bestimmt und festgehalten. Stories deren Umfang nicht denierbar sind werden vom Product Owner bis zum nächsten Estimation Meeting geklärt. Zuerst gibt es eine gemeinsame Überlegung mit dem Team, End User, Customer und dem Product Owner wieviele und welche Stories in diesem Sprint realisierbar sein könnten. Dann verlassen alle bis auf das Entwicklungsteam und der Scrum Master den Raum und diese entscheiden welche Stories in diesem Sprint realisiert werden. Die Ergebnisse des Entwicklungsteams dürfen bei der Vorstellung nicht in Frage gestellt werden und es sollte darüber auch keine Diskussion geführt werden. Die Entscheidungen des Entwicklungsteams dürfen nicht in Frage gestellt oder untergraben werden. Das Ergebnis des ersten Sprint Planning ist das Selected Product Backlog, die Anforderungen und die Abnahmekriterien (Done) für jede Story 5.3 Das zweite Sprint Planning Das zweite Sprint Planning Meeting dauert sechzig Minuten und es ist am Sinnvollsten wenn es am Nachmittag nach dem ersten statt ndet. Hier werden alle Stories die in diesem Sprint realisiert werden genauer besprochen. Es wird festgelegt welche Schnittstellen, Datenbanken, Architekturen oder Komponenten für jede einzelne Story notwendig sind. Am Ende der Aktivität weiÿ das Team welche Stories im aktuellen Sprint realisiert werden und wie sie umgesetzt werden müssen. 5.4 Daily Scrum Der Daily Scrum ndet täglich zur gleichen Uhrzeit statt, dauert fünfzehn Minuten und gibt Auskunft über die aktuellen Tätigkeiten jedes einzelnen Teammitglied. Das Entwicklungsteam und der Scrum Master müssen ausnahmslos vollzählig anwesend sein. Jedes Teammitglied berichtet was es aktuell realisiert hat, was es realisieren wird, aktualisiert das Taskboard und das Burn-Down- Chart und spricht Hindernisse auf die er zugestoÿen ist an. Der Scrum Master trägt alle Hindernisse in das Impendiment Backlog und versucht diese so schnell wie möglich zu beseitigen. Das Entwicklungsteam berichtet nicht an den Scrum Master und dieser darf die Teammitglieder nicht abfragen. Der Zweck dieses Meetings ist es Hindernisse sofort zu erkennen und zu beheben, auÿerdem weiÿ das gesamte Team an welchem Thema jedes einzelne Teammitglied gerade arbeitet. 9

11 5.5 Sprint Review Das Sprint Review Meeting dauert Neunzig Minuten und ndet am Ende jedes Sprints statt. Das Entwicklerteam stellt dem User, dem Product Owner und dem Manager das Sprint Ergebnis vor. Der User bekommt die Gelegenheit die neuen Funktionalitäten selbst auszuprobieren. Anschlieÿend ndet eine gemeinsame Analyse statt in der eventuelle Verbesserungen oder neue Stories entstehen können. Alle Anregungen werden vom Product Owner und Scrum Master dokumentiert. Das Ziel dieses Meetings ist die Erkenntnis ob das bisher Geleistete dem entspricht was der Kunde sich vorstellt und ob die Software anwendbar ist. Auÿerdem kann das Entwicklungsteam Anregungen und neue Ideen für Funktionen sammeln um eine ezientere und mehr zufriedenstellende Software realisieren zu können. 5.6 Sprint Retrospektive Das Sprint Retrospektive Meeting dauert neunzig Minuten und ndet anschlieÿend am Sprint Review statt. An diesem Meeting nehmen das Entwicklungsteam, der Scrum Master und der Manager teil. Das Entwicklungsteam identi- ziert interne Verbesserungsmöglichkeiten am Arbeitsprozess und überlegt sich Methoden oder Lösungen um ezienter zu werden. Auch Hindernisse die das Team alleine nicht beheben kann werden angesprochen und in das Impediment Backlog eingetragen. Diese Hindernisse müssen jedoch der Scrum Master und der Manager beheben damit sie im nächsten Sprint nicht mehr vorhanden sind. Das Ziel dieses Meetings ist für das Entwicklungsteam Verbesserungen im Arbeitsablauf zu erkennen und einen Plan für die Durchführung zu erstellen. Für das Management und den Scrum Master ist das Ziel der Besprechung Hindernisse für das Entwicklungsteam zu erkennen und zu beheben. 5.7 Scrum of Scrums Meeting Das Scrum of Scrum Meeting ndet nur statt wenn eine Abteilung in mehrere Teams aufgeteilt wurde damit diese nicht zu groÿ sind. Es ist ein Meeting das genau an denselben Regeln gebunden ist wie das Daily Scrum mit dem einzigen Unterschied das die Teilnehmer aus je einem Mitglied eines jeden Teams besteht. Der Team Repräsentant wird von jedem Entwicklungsteam selbst gewählt, genauso wie ein Vertreter. 6 Vorgehensweise Um Scrum in ein Unternehmen einzuführen muss ein Kunden, ein Auftrag vom Product Owner betreut, ein Scrum Master, die Unterstützung des Managements und das Entwicklungsteam mit all den Fähigkeiten die es für die Umsetzung der Aufgabe braucht vorhanden sein. Erst wenn die Strukturen vorhanden sind kann die Scrum Einführung beginnen. 10

12 [Glo13] Abbildung 5: Der Scrum Flow Der Kunde hat eine Idee oder Vorstellung von einem Produkt das er intern oder extern vertreiben möchte. Dieser setzt sich in Verbindung mit dem Management des Scrum Unternehmens. Das Management beauftragt den Product Owner als Verbindungsstelle zwischen das Entwicklungsteam und dem Kunden. Der Product Owner wird sich die Vorstellung des Kunden und die des Endusers ganz genau anhören und schriftlich festhalten. Das Festhalten der Funktionalitäten, in Scrum auch Stories genannt, ndet in dem Product Backlog statt. Der Product Owner priorisiert alle Stories nach wirtschaftlichem Nutzen. Ab diesen Zeitpunkt verläuft das Scrumprojekt wie in Abbildung 5. Der Scrum Flow iterativ und ist in Sprints eingeteilt bis zum Release der Software. Die Länge des Sprints kann zwischen einer Woche und einem Monat gewählt werden. Das Scrum Team sollte dies für sich entscheiden. Die Dauer sollten jedoch nicht kürzer oder länger dauern da sonst bei zu kurzer Zeit kaum noch Zeit für die eigentliche Arbeit ist und zu wenig geleistet wird und bei längerem Zeitraum als einem Monat kann leicht die Übersicht verloren gehen und die Motivation kann sinken durch das Fehlen der Ergebnisse. Auÿerdem besteht die Gefahr dass das 11

13 Entwicklungsteam nicht im Kundensinn entwickelt da das Kunden Feedback zu lange zurück liegt. Vor jedem Sprint ndet das Estimation Meeting statt. Abbildung 6: Estimation Meeting [Glo13] In dem Estimation Meeting Abbildung 6 stellt der Product Owner dem Entwicklungsteam die Liste mit den priorisierten Stories vor. Das Entwicklungsteam schätzt jede einzelne Story und falls notwendig werden diese in kleinere aufgeteilt und neu geschätzt. Es können hierbei neue Aufgaben oder Stories entstehen die priorisiert und geschätzt werden. Am Ende des Meetings entsteht eine Liste mit priorisierten und abgeschätzten Stories. Idealerweise dauert eine Aufgabe nicht länger als ein Arbeitstag. So können Hindernisse schnell erkannt und behoben werden. Das Entwicklungsteam hat nun eine Vorstellung über ihre zukünftigen Aufgaben. [Glo13] Abbildung 7: Das erste Sprint Planning Meeting Nun kann das erste Sprint Planning Meeting statt nden in dem die Stories aus dem Product Backlog (PB) genauer nach den Funktionalitäten analysiert werden. Es ist vom Vorteil wenn der Kunde und der User bei der funktionalen Analyse anwesend sind falls es ungeklärte Fragen gibt oder Stories noch unklar sind. Die Done Kriterien werden in dem Meeting festgelegt. Diese Kriterien beinhalten Festlegungen von Aufgaben die zusätzlich realisiert werden müssen damit eine Story als beendet gilt. Dies können zum Beispiel Kommentare, besondere Dokumentationen, Unittests oder andere Dinge sein. Das Entwicklungsteam entscheidet wie viele Stories sie in diesem Sprint realisieren werden. 12

14 Das Entwicklungsteam sucht sich nicht die beliebtesten Stories sondern diese werden nach der Priorisierung gewählt. Das Entwicklungsteam weiÿ nun welche Aufgaben in diesem Sprint umgesetzt werden müssen. [Glo13] Abbildung 8: Das zweite Sprint Planning Meeting Es ist vom Vorteil beide Sprint Planning Meetings am selben Tag durchzuführen. Wenn das erste Sprint Planning Meeting Vormittags statt gefunden hat sollte das zweite Sprint Planning Meeting Nachmittags statt nden. An diesem Meeting sollten das Entwicklungsteam, der Scrum Master und der Manager teil nehmen. In dem zweiten Sprint Planning Meeting werden die Stories die in diesem Sprint umgesetzt werden genauer besprochen. Es werden Schnittstellen, Datenbanken, Architekturen oder zusätzlich notwendige Komponenten festgelegt. Am Ende des zweiten Sprint Planning Meetings weiÿ jedes Teammitglied ganz genau welche Aufgaben realisiert werden müssen und wie jede einzelne umgesetzt wird. Das Taskboard wird mit Stories und Aufgaben befüllt. Nach dem zweiten Sprint Planning Meeting kann sich jedes Teammitglied eine Aufgabe vom Taskboard wählen und diese in die Work in progress Spalte legen. Die Entwicklungsarbeit kann nun umgesetzt werden. Jeden Tag kann sich ein Teammitglied eine neue Aufgabe vom Taskboard auswählen und diese umsetzten. Für die Gewährleistung des täglichen Fortschritts ndet täglich ein Daily Scrum statt. Der Daily Scrum (Stand-Up-Meeting) dauert fünfzehn Minuten und das gesamte Entwicklungsteam wie auch der Scrum Master müssen anwesend sein. Jedes Teammitglied sagt welche Tätigkeit es seit dem letzten Daily Scrum erledigt hat. Falls es Hindernisse gab werden diese kurz erwähnt und dann wird noch kurz erläutert welche Aufgabe als nächstes bearbeitet wird. Sollte es bei der Erledigung einer Aufgabe vom Entwicklungsteam unüberwindbare Hindernisse geben muss der Scrum Master diese so schnell wie möglich beheben. Alle Hindernisse werden in das Impendiment Backlog eingetragen und gekennzeichnet wie diese behoben wurden oder wie sie behoben werden können. Für die Behebung von Hindernissen die das Entwicklungsteam nicht intern beheben kann sind der Scrum Master und das Management zuständig. 13

15 Abbildung 9: Daily Scrum [Glo13] Am Ende des Sprints ndet ein Sprint Review statt. Das Team stellt dem Product Owner, dem User und dem Management seine Arbeit vor. Diese bekommen die Gelegenheit die Funktionen anzuwenden. Anschlieÿend werden alle Funktionen analysiert und bewertet. Dabei können Verbesserungsvorschläge oder neue Stories entstehen. Alle Anregungen und eventuell neue Stories werden vom Product Owner und Scrum Master dokumentiert. Nach dieser Aktivität erlangt das Entwicklungsteam die Erkenntnis wie es die Software ezienter und kundenfreundlicher gestalten kann. Anschlieÿend an dem Sprint Review ndet die Sprint Retrospektive statt. Hier sind das Entwicklungsteam, der Scrum Master und der Manager anwesend und besprechen die angefallenen Hindernisse und wie diese für den nächsten Sprint behoben werden können. Das Entwicklungsteam identiziert die internen Verbesserungsmöglichkeiten am Arbeitsprozess und arbeitet gemeinsam an Lösungen. Die äuÿerlichen Hindernisse die in das Impendiment Backlog eingetragen sind werden jedoch vom Management und Scrum Master besprochen und für den nächsten Sprint behoben. Am Ende der Sprint Retrospektive endet der Sprint der mit dem ersten Sprint Planning angefangen hat. Die Estimation Meetings können wöchentlich gehalten werden, da die Teammitglieder jede Woche genauere Zeitangaben machen können durch die steigende Erfahrung in dem Projekt. Das Scrum Team besteht bis nach dem Release und Projektende. Danach kann das Team in der Zuteilung behalten oder aufgelöst werden und neue Teams gebildet werden. Ein Teamwechsel kann viele Vorteile bringen durch seine Vielfältigkeit. Ein funktionierendes Team aufzulösen kann aber auch nachteilig sein. 7 Schluÿwort Scrum sollte voller Überzeugung und mit viel Disziplin vom Management und Team umgesetzt werden. Dies sollte die eigene Arbeit sichtbarer machen um mit der Zeit ezienter zu werden. Hindernisse müssen visualisiert und von der zuständigen Person behoben werden. 14

16 Literatur [Glo13] Boris Gloger. Scrum. Carl Hanser Verlag München, [Max13] Dominik Maximini. Scrum Einführung in der Unternehmenspraxis. Springer-Verlag Berlin Heidelberg, [Pic08] [RD13] Roman Pichler. Scrum Agiles Projektmanagement erfolgreich einsetzen. dpunkt, Carsten Sahling Rolf Dräther, Holger Koschek. Scrum - kurz & gut. Springer-Verlag Berlin Heidelberg, [web14a] nov [web14b] nov