Softwareentwicklung mit Scrum

Transkript

1 Seminararbeit Softwareentwicklung mit Scrum von Stephan Kugelmann Matrikel-Nr.: Betreuer: Prof. Dr.-Ing. Andreas Terstegge 2. Betreuer: Dipl. Phys. Michael Benden

2 Inhaltsverzeichnis 1 Einleitung Motivation Ursprung Grundprinzip von Scrum Die Rollen Das Team Der Product-Owner Der Scrum-Master Das Product-Backlog Anforderungsermittlung Priorisieren Schätzen Der Sprint Die Sprint-Planungssitzung Das Sprint-Backlog Der Sprint-Burndown-Bericht Die Daily-Scrum-Besprechung Die Hindernis-Liste Das Sprint-Review Der Sprint-Endebericht Die Sprint-Retrospektive Releaseplanung Entwicklungsgeschwindigkeit Der Release-Burndown-Bericht Der Entwicklungsgeschwindigkeitsbericht Der Themenpark Optimierung des Projektfortschritts Große und verteilte Projekte Fazit Literaturnachweise

3 1 Einleitung 1.1 Motivation Scrum ist ein agiles Vorgehensmodell, das zur Softwareentwicklung eingesetzt wird. Es wird agil oder schlank genannt, da nur wenige Rollen, Artefakte und Regeln existieren. Somit steht es im Kontrast zur traditionellen Softwareentwicklung, die als schwergewichtig und bürokratisch angesehen wird. Bei Scrum liegt der Schwerpunkt auf der Kommunikation sowohl zwischen den Teammitgliedern als auch mit den Interessensvertretern. Des Weiteren wird davon ausgegangen, dass sich im Verlauf eines Projektes die Anforderungen ändern werden. Darum wird nicht das Wasserfallmodell, das in der traditionellen Softwareentwicklung üblich ist, angewendet. Bei diesem Modell wird zu erst versucht ein Plan des kompletten Projekts in einer langen Planungsphase zu erstellen, an den sich bei der Implementierung strikt gehalten werden muss. Stattdessen wird das Projekt in mehreren Iterationen realisiert. In jeder Iteration, die Sprint genannt wird, wird ein voll funktionsfähiges Produkt-Inkrement entwickelt. Dadurch ist es zu Beginn jeder Iteration möglich neue Anforderungen bzw. Änderungen zu berücksichtigen ohne, dass ein kompliziertes Änderungsmanagement betrieben werden muss. Damit die Anforderungen innerhalb eines Sprints durch das Team optimal umgesetzt werden können, verwaltet das Team sich selbst. Es gibt somit keinen Manager, der Aufgaben zuweist. Es gibt keine Beschränkung welche Art von Projekten mit Scrum durchgeführt werden können. Es ist also eine Neuentwicklung als auch eine Erweiterung eines bestehenden Systems möglich. Richtig angewendet kann Scrum die Kundenzufriedenheit, die Produktivität und Qualität einer Software steigern. Dies kann in kommerziellen Projekten zu höheren Gewinnen führen. Außerdem kommt es nicht zur Überlastung der Mitarbeiter. Das Projekt ist transparent und der Projektfortschritt läst sich leicht verfolgen. 1.2 Ursprung Schon Mitte der 1980er Jahre wurden die traditionellen Methoden der Softwareentwicklung in Frage gestellt wurde Scrum erstmals von Peter DeGrace und Leslie Hulet Stah in Wicked Problems, Righteous Solutions erwähnt führte Jeff Sutherland das erste Projekt mit Scrum durch. Er erstellte im Jahr 1996 zusammen mit Ken Schwaber eine erste Definition von Scrum. In den folgenden Jahren wurde Scrum immer beliebter, so dass es immer häufiger angewandt wurde und Projekte zum Erfolg führte. Der Begriff Scrum beschreibt einen Spielzug im Rugby. Ins Deutsche übersetzt bedeutet er Gedränge. Dabei stehen sich die Spieler beider Mannschaften eng umschlungen gegenüber und versuchen den Ball mit den Füßen aus dem Gedränge zu schieben. Dabei handelt es sich um einen komplizierten Spielzug der gut einstudiert werden muss und eine disziplinierte Teamarbeit verlangt. Auch beim Projektmanagement mit Scrum ist gute Teamarbeit erforderlich. Ebenfalls müssen bei Scrum die neuen Rollen und Regeln gut einstudiert werden - 3 -

4 um es erfolgreich einsetzten zu können, da es einen komplett anderen Ansatz als die traditionellen Methoden verfolgt. 1.3 Grundprinzip von Scrum Scrum ist ein iterativ inkrementelles Verfahren. Dies bedeutet, dass Anforderungen in Iterationen gleicher Länge von maximal 30 Tagen in ein Produktinkrement umgesetzt werden. Alle Anforderungen werden im Product-Backlog gesammelt. Die Anforderungen, die in einem Sprint umgesetzt werden, kommen in ein extra Sprint-Backlog. Während eines Sprints trifft sich das Team an jedem Tag zu einer maximal 15-minütigen Besprechung, die Daily Scrum genannt wird. Diese dient zur Synchronisation der Arbeit der Teammitglieder und dazu Hindernisse aufzudecken. Das Resultat eines Sprints ist ein lauffähiges, getestetes, dokumentiertes und auslieferbares Produktinkrement. Dies veranschaulicht folgende Abbildung: Abb. 1: Der Scrum Prozess im Überblick (Quelle: wikipedia.de [7]) Bevor ein Scrum-Projekt beginnen kann muss das Product-Backlog vom Product-Owner gefüllt und priorisiert werden. In einem Sprint-Planning-Meeting wählt das Team die Anforderungen aus, die es im Sprint umsetzen wird und erstellt damit das Sprint Backlog. Am Ende jedes Sprints wird die Arbeit vom Product-Owner in einem Sprint-Review abgenommen. Dabei dürfen nur Anforderungen abgenommen werden, die zu 100% fertig gestellt sind. Dies schließt Tests und Dokumentation mit ein. Im Anschluss wird noch eine Sprint-Retrospektive gehalten, in der über den Sprint reflektiert wird und Verbesserungen abgeleitet werden

5 2 Die Rollen In Scrum sind unterschiedliche Rollen definiert. Es gibt das Team, das die Anforderungen umsetzt. Diese werden vom Product-Owner definiert, der einen Überblick über die Interessen der Interessensvertreter, den so genanten Stakeholdern, hat. Der Scrum-Master hilft allen Beteiligten den Scrum-Prozess richtig anzuwenden. 2.1 Das Team Das Team setzt in jedem Sprint die Anforderungen aus dem Sprint-Backlog um. Dies sollte gemeinschaftlich und in enger Zusammenarbeit geschehen. Ein Team ist somit mehr als nur eine Ansammlung von Personen, die innerhalb einer Firma zufällig am gleichen Projekt arbeiten. Es ist nicht erwünscht, dass einzelne Personen Helden-Taten verrichten. Scrum setzt auf Synergie, also dass das Team mehr ist als nur die Summe der einzelnen Teammitglieder. Ein Team muss also aus den richtigen Mitarbeitern zusammengesetzt sein, damit es produktiv arbeiten kann. Zum einen muss es interdisziplinär besetzt sein, damit alle Rollen, die für die Umsetzung notwendig sind, im Team vertreten sind. Dazu zählen zum Beispiel Architekten, Entwickler, Tester und Dokumentationsexperten. Zum anderen müssen die einzelnen Teammitglieder das notwendige Wissen als auch die Fähigkeiten mitbringen und ein gemeinsames Wissen über Softwareentwicklung haben. Auch wenn es die unterschiedlichen Rollen im Team gibt, dürfen sich die Mitglieder nicht auf ihr Spezialgebiet beschränken. Sie müssen die Arbeit anderer Teammitglieder übernehmen können, da sich das Team kollektiv zur Umsetzung verpflichtet hat. Aus diesem Grund spricht man auch von generalistischen Spezialisten (engl. generalist-specialist) oder auch cross-skilling. Damit das Team die Anforderungen, zu denen es sich zu Beginn verpflichtet hat, umsetzen kann, muss es autonom sein. Externe Abhängigkeiten erschweren es, Verpflichtungen einzugehen und gefährden somit, dass Anforderungen nicht umgesetzt werden können. Das Team ist, wie die beiden anderen Rollen auch, eine Managerrolle. Es gibt somit keinen Manager, der Aufgaben, die vom Team zu erledigen sind, delegiert. Stattdessen organisiert sich das Team selbst. Es entscheidet eigenständig, welche und wie viele Aufgaben es aus dem priorisierten Product-Backlog in einem Sprint umsetzen kann. Außerdem entscheidet es auch darüber, wie die Anforderungen umgesetzt werden und welche Schritte dafür notwendig sind. Damit das Team dies machen kann, muss es vom Management bevollmächtigt sein. Dies ist eine gravierende Änderung zur traditionellen Softwareentwicklung und erfordert vom Management Vertrauen in das Team und dessen Fähigkeiten. Ein Vorteil ist, dass durch die Verantwortung für das Produktinkrement das Team alles unternehmen wird, die Anforderungen optimal umzusetzen. Mit der Zeit wird das Team lernen seine Verpflichtungen besser zu erfüllen. Bei diesem Lern-Prozess wird das Team durch den Scrum-Master unterstützt. Das Team sollte zwischen fünf und neun Mitglieder umfassen. Sind Teams zu groß, so steigen die Kommunikationskosten und eine effektive Zusammenarbeit ist nicht möglich. Außerdem kann es passieren, dass sich kleinere Gruppen bilden. Kleine Teams sind zwar - 5 -

6 möglich, aber es muss sichergestellt werden, dass genügend Wissen zum Erstellen der Produktinkremente vorhanden ist. Um die Kommunikation im Team zu fördern, sodass diese enger abläuft und spontan zustande kommen kann, sollte das komplette Team räumlich nah beieinander arbeiten. Am besten wäre ein eigenes Büro für das ganze Team. In Großraumbüros könnte man durch Stellwände eine eigene Teamzone einrichten. Sollte es nicht die Möglichkeit geben, dass das Team in einem Raum arbeiten kann, so sollte für das Daily-Scrum ein Besprechungszimmer reserviert werden. In dem Team-Raum sollte es möglich sein Informationen zum Projekt wie das Sprint-Ziel, den Sprint-Backlog, das Sprint-Burndown-Chart, die Hindernissliste und den Releaseplan an einer Wand oder einem Flipchart aufzuhängen. Diese Art des sichtbar Machens der wichtigen Informationen macht den Fortschritt transparenter und fördert das Bewusstsein des Teams für deren Verantwortung besser, als wenn die gleichen Informationen nur in elektronischer Form vorgehalten werden. Die Zusammensetzung des Teams sollte sich während der Dauer des Projektes nicht ändern. Die einzelnen Mitglieder sollten in der Regel Vollzeitkräfte und nur einem Team zugeordnet sein. Dies reduziert unter anderem die Einarbeitungszeit. Wird ein Mitarbeiter in mehreren Teams benötigt, so deutet dies darauf hin, dass das Wissen nicht breit genug gestreut ist. Das Wissen könnte man mit Hilfe von Paararbeiten - auch wenn dies kurzfristig die Entwicklungsgeschwindigkeit reduziert, aber langfristig steigern wird - in die Breite tragen. Sind im Team Teilzeitkräfte, so sollten diese an den Sprint-Planungssitzungen und -Reviews teilnehmen, damit diese mit planen können und stärker eingebunden sind. Damit sie während des Sprints auch immer auf dem Laufenden bleiben, bietet sich auch hier Paararbeit an. Ein gutes Team entsteht nicht von alleine. Nach Bruce Tuckman durchläuft ein Team vier Phasen bis es sich zu einem echten Team entwickelt hat und produktiv arbeiten kann. Zuerst wird in der Formierungsphase (forming) das Team gebildet. Daran schließt sich eine Phase der Auseinandersetzung (storming) an, in der Konflikte auftauchen, da jedes Individuum eine eigene Vorstellung über die Vorgehensweisen entworfen hat. Diese Konflikte müssen gelöst werden. Hierbei kann das Team durch den Scrum-Master unterstützt werden. Die Lösungen und Arbeitsweisen werden dann als Normen in der norming-phase festgehalten. Erst anschließend kann das Team produktiv in der performing-phase arbeiten. Die Übergänge zwischen den einzelnen Phasen sind fließend und der komplette Prozess zieht sich über eine längere Zeit hin. So braucht nach Roman Pichlers Erfahrungen das Team zwei bis drei Sprints bis es in der Norming-Phase angekommen ist. Anschließend benötigt es noch weitere Sprints bis es dann produktiv arbeitet. Nach einer geänderten Team-Zusammensetzung müssen alle Phasen wieder von neuem durchlaufen werden. Darum gilt hier der Spruch never change a winning team. Es sollte versucht werden ein Team möglichst lange beizubehalten, da durch häufige Änderungen ein Team eventuell nie in die Performing-Phase kommt

7 2.2 Der Product-Owner Der Product-Owner ist verantwortlich für den Erfolg des Projekts und somit auch für die Rendite bzw. den Return on Investment (kurz ROI). Er sammelt die Bedürfnisse der Kunden und weiterer Interessensvertretern, den Stakeholdern, und muss für die Kunden einen Mehrwert schaffen. Um die Entwicklung zu steuern beschreibt der Product-Owner die Anforderungen in User Stories. Im Gegensatz zum traditionellem Projektmanagement werden nicht zu Beginn des Projekts alle Anforderungen aufgeschrieben, festgehalten und der Entwicklung übergeben. Stattdessen werden die Anforderungen zuerst grob erfasst und mit der Zeit immer weiter verfeinert. So ist es auch Möglich, dass im Laufe des Projekts neue Anforderungen hinzukommen oder andere gestrichen werden. Der Product-Owner trägt nun fortlaufend, in der Regel mit Fokus auf den nächsten Sprint, neue Anforderungen in das Product-Backlog ein oder aktualisiert bestehende. Dabei versieht er die Anforderungen mit Prioritäten um zu steuern, welche Anforderungen als nächstes entwickelt werden sollen. Außerdem müssen Abnahmebedingungen definiert werden, anhand derer der Product-Owner die umgesetzten Anforderungen am Ende des Sprints abnimmt und entscheidet ob die Qualität aus Kundensicht akzeptabel ist. Damit der Product-Owner die Anforderungen gut erstellen und dem Team wiedergeben kann, ist eine enge und regelmäßige Zusammenarbeit mit den Kunden, den Anwendern und den Interessensvertretern erforderlich. So können die Anforderungen zum Beispiel in Workshops gemeinsam erarbeitet werden. Es ist auch möglich die Gruppen zum Sprint-Review einzuladen, damit diese direkt den Teammitgliedern ein Feedback geben und Wünsche äußern können. Die gesammelten Anforderungen werden dann vom Product-Owner gebündelt und gefiltert in das Product-Backlog eingetragen. Ebenso wichtig wie die Zusammenarbeit mit dem Kunden ist die Zusammenarbeit mit dem Team. Der Product-Owner muss dem Team helfen die Anforderungen und Visionen zu verstehen, damit es diese in Produktinkremente umwandeln kann. Neben detaillierten Anforderungen ist es sinnvoll, wenn der Product-Owner jeden Tag eine gewisse Zeit mit dem Team verbringt und arbeitet. Dadurch kann er aufkommende Fragen schnell beantworten und bekommt während des Sprints ein Feedback. Der Product-Owner ist keine einfache Rolle. Er hat die Interessen der einzelnen Parteien zu gewichten und zwischen den Parteien zu vermitteln, damit diese ein wechselseitiges Verständnis bekommen. Darüber hinaus muss er über genügend Domänen-Wissen verfügen, um die Anforderungen definieren und deren Nutzen abwägen zu können und einzuschätzen, wie viel der Kunde bereit ist dafür zu zahlen. Der Product-Owner vereint Aufgaben des Produkt- und Projektmanagers. Um diese Aufgaben wahrnehmen zu können, muss der Product-Owner bevollmächtigt sein und genügend Zeit haben. 2.3 Der Scrum-Master Der Scum-Master wacht über die Einhaltung der Scrum-Regeln und sorgt dafür, dass Scrum richtig eingesetzt und angewandt wird. Dies macht er nicht, indem er Aufgaben zuteilt - 7 -

8 sondern indem er Fehler im System aufzeigt, Hindernisse beseitigt und die Beteiligten trainiert. Jedes Team hat einen Scrum-Master, der das Team unterstützt und als Vorbild dient. Die neuen Denk- und Verhaltensweisen referiert er nicht nur, sondern lebt sie vor. Kehrt das Team zu alten Gewohnheiten zurück, macht er den Rückschritt deutlich und veranschaulicht dem Team, welche Vorteile und Nutzen alle durch die neuen Vorgehensweisen haben. Nicht nur das Team, sondern auch der Product-Owner profitiert durch den Scrum-Master. So hilft er ihm beim Erstellen des Product-Backlogs. Der Scrum-Master soll die Kommunikation verbessern, indem er zum Beispiel die Meetings moderiert. Dafür sollte er die entsprechenden Techniken beherrschen um dem Team zu helfen kollaborative und tragfähige Entscheidungen zu treffen oder Konflikte zu lösen. Kenntnisse über Teamentscheidungs- und Teambildungsprozesse sind dabei ebenfalls wichtig. Der Scrum-Master ist auch dazu da auftauchende Hindernisse zu beseitigen. Jedoch soll er bei Hindernissen, die das Team selber beseitigen kann, nur auf diese Aufmerksam machen. Zum Beispiel wenn jemand eine Aufgabe nicht alleine lösen kann und ein Teammitglied für Pairprogramming benötigt. Sind es Hindernisse, die durch die Organisationsstruktur oder strategische Entscheidungen bedingt sind, ist es Aufgabe des Scrum-Masters sich dieser anzunehmen. Gleiches gilt auch für anderweitige, durch das Team nicht lösbare Probleme, wie zum Beispiel das Fehlen von Ressourcen. Eine weitere Aufgabe ist es, das Team vor externen Einflüssen zu schützen. So dürfen dem Team oder einzelnen Mitgliedern keine Aufgaben von außen zugewiesen werden. Auch das Abziehen von Personen im laufenden Sprint ist nicht erlaubt. Beides bringt das Sprint-Ziel in Gefahr. Um das Team zu schützen und bei Problemen zu helfen benötigt der Scrum-Master Durchsetzungsvermögen und Rückgrat. Der Scrum-Master ist ein Servant-Leader. Das bedeutet, dass er dem Team, das sich selbst organisiert, dient und es unterstützt, ohne dabei selber Autorität oder Personalverantwortung zu besitzen. Würde er über Personalverantwortung verfügen oder die Leistungen der Mitarbeiter beurteilen, so wäre die Kommunikation zwischen Team und Scrum-Master nicht offen

9 3 Das Product-Backlog Das Product-Backlog ist ein Dokument in dem tabellarisch alle Anforderungen für ein Projekt verwaltet werden. Jedes Projekt, bei dem Scrum eingesetzt wird, besitzt ein eigenes Product- Backlog. Dieses wird vom Product-Owner verwaltet und mit funktionalen und nicht funktionalen Anforderungen, als auch mit Benutzergeschichten (User Stories) oder den komplexeren Anwendungsfällen (use cases) gefüllt. Dabei ist man nicht auf ein Format beschränkt. Das Product-Backlog wird nicht zu Beginn des Projekts komplett mit allen Anforderungen gefüllt. Viel mehr handelt es sich um ein lebendiges Dokument, das mit der Zeit immer weiter gefüllt und verfeinert wird oder auch Einträge daraus entfernt werden. Es wächst wie das Produkt iterativ-inkrementell. Die einzelnen Einträge können unterschiedlich detailliert sein. Üblicher Weise sind Einträge mit hoher Priorität, die in einem der nächsten Sprints umgesetzt werden sollen, genauer beschrieben als die mit einer niedrigeren Priorität. Diese werden aber durch den Product-Owner auch noch weiter verfeinert. Dadurch wird der initiale Aufwand zum Erstellen des Product-Backlogs verringert. Um zu einem späteren Zeitpunkt feststellen zu können, wie sich das Product-Backlog entwickelt hat, ist es sinnvoll dieses zu versionisieren. Der Product-Owner ist dafür verantwortlich, dass jedes Element im Product-Backlog priorisiert ist. Dabei kann er frei entscheiden, welche Faktoren, wie zum Beispiel Kosten, Nutzen und Risiko, einfließen und wie stark diese gewichtet werden. Ziel sollte es jedoch sein die Anforderungen höher zu priorisieren, die einen Mehrwert für den Kunden generieren. Diese können in Form von mit der Software erzielten Gewinnen, Kosteneinsparungen oder Automatisierungen sein. Das Team kann bei der Priorisierung helfen, indem es den Product- Owner über technische Risiken aufklärt. Die Einträge im Product-Backlog werden alle durch das Team abgeschätzt. Zur Abschätzung der Einträge können unterschiedliche Methoden verwendet werden. So können die Aufwände in Punkten (story Points) oder idealen Tagen geschätzt werden. Mit Hilfe dieser Daten kann der Product-Owner über Kosten und Nutzen abwägen und dies in die Priorisierung einfließen lassen. Des Weiteren können damit Release-Planungen durchgeführt werden. 3.1 Anforderungsermittlung Vor Beginn des ersten Sprints muss das Product-Backlog initial gefüllt werden. Dabei werden nicht alle Anforderungen bis ins kleinste Detail erfasst und aufgeschrieben. Dies würde das Product-Backlog, das immer so einfach wie möglich gehalten werden soll, sprengen und unübersichtlich machen. Es müssen aber mindestens so viele Anforderungen erfasst werden, dass diese für die ersten paar Sprints reichen, damit einerseits das Team eine Auswahl in der Sprintplanungssitzung hat und andererseits einen Ausblick auf die nächsten Sprints bekommt. Es gilt also der Spruch: So wenig wie möglich, so viel wie nötig

10 Die Anforderungen sollten dabei sowohl funktional als auch nicht funktional sein und können in Form von Benutzergeschichten (User Stories) sein. Auch Anforderungen an das User- Interface sollten mit aufgenommen werden. Um dies umsetzen zu können müssen die Anforderungen unterschiedlich detailliert sein. Die hoch priorisierten Anforderungen sind detailliert und bei den niedrig priorisierten reicht es diese nur grob zu skizzieren oder nur das Thema zu erfassen. Mit Hilfe von Themen können mehrere Anforderungen zusammengefasst werden, die thematisch zusammen gehören oder nur in Kombination einen Mehrwert für den Kunden darstellen. Dies erhöht die Übersicht im Product-Backlog, auch wenn dieses mit der Zeit immer weiter verfeinert wird und somit die Anzahl der Einträge wächst. Des Weiteren kann dies den Product-Owner beim priorisieren unterstützen. Damit das Team die Anforderungen gut umsetzen kann, sollten diese verständlich und gut sein. Die von William Wake beschriebenen INVEST-Merkmale guter Benutzergeschichten lassen sich dafür auf Anforderungen übertragen. Als erstes sollten Anforderungen, die diese Merkmale aufweisen, möglichst zu anderen unabhängig (independent) und somit einzeln und in frei wählbarer Reihenfolge umsetzbar sein. Abhängigkeiten können zu Schwierigkeiten beim abschätzen, priorisieren oder entwickeln führen, da unter anderem auf andere Ergebnisse gewartet werden muss. In der Realität können aber nicht alle Abhängigkeiten aufgelöst werden. Als zweites sollten die Product-Backlog-Einträge verhandelbar (negotiable) sein, damit das Team und der Product-Owner über diese im gewissen Maße während der Sprintplanungssitzung verhandeln können. Als drittes sollten die Anforderungen nützlich (valuable) sein. Es sollte bei jeder Anforderung ein Nutzen klar erkennbar sein. Dies sollte auch für nicht wertschöpfende aber notwendige Einträge, wie das Errichten einer Testumgebung, gelten. Als viertes sollten die Einträge im Product-Backlog vom Team abgeschätzt werden können (estimatable). Damit das Team die Einträge optimal abschätzen kann, müssen diese klar und verständlich geschrieben sein. Außerdem sollten sie nicht zu wage oder groß sein, damit der Fehler der Schätzung nicht zu groß wird. Als fünftes sollten die Anforderungen klein (small) sein. Die groben und niedrig priorisierten Anforderungen sollten kurz gehalten werden. Wenn diese weiter verfeinert und höher priorisiert werden, so müssen diese in mehrere kleine aufgebrochen werden. Am Ende sollten die Anforderungen ungefähr die gleiche Größe besitzen. Das letzte Merkmal einer guten Anforderung ist, dass diese testbar (testable) sein sollten. Darum sollten in das Product-Backlog Akzeptanzkriterien aufgenommen werden, an denen die Einträge im Sprint Review abgenommen werden. Zu Beginn des Projektes sammelt und gruppiert der Product-Owner eine Grundmenge an Anforderungen, die er durch Befragung und Beobachtung der Anwender bei der Arbeit oder Anforderungsworkshops herausfindet. Diese Anforderungen werden nun priorisiert. Dabei kann er für einzelne Anforderungen die Unterstützung des Teams anfordern. Anschließend ist ein weiterer Anforderungsworkshop möglich, um die Anforderungen noch einmal vor dem ersten Sprint zu verfeinern. Nachdem dann der erste Sprint gestartet wurde, werden in

11 folgenden Anforderungsworkshops die bestehenden Anforderungen aktualisiert und verfeinert. Der Product-Owner lädt für einen Anforderungsworkshop das Team, die Anwender und weitere Interessenvertreter ein. Zusammen werden dann Anforderungen herausgearbeitet. Dabei ist es hilfreich, wenn die Anforderungen zuerst auf Karteikarten erfasst werden, damit diese zwischen den Teilnehmern weiter gereicht werden können oder diese gruppiert werden können. Diese enge Zusammenarbeit aller Beteiligten stellt sicher, dass alle das gleiche Verständnis haben und die gleiche Sprache sprechen. 3.2 Priorisieren Durch die Priorisierung der Anforderungen wird der Fokus auf die wichtigsten Anforderungen gesetzt. Dadurch werden diese detaillierter beschrieben und als erstes umgesetzt. Welche Faktoren in die Priorisierung einfließen, kann der Product-Owner selber entscheiden, aber es gibt Methoden, die ihm dabei unterstützen. Das Kano-Modell hilft dabei den Nutzen von Anforderungen zu bestimmen. Dabei werden die Anforderungen in die Kategorien Basis-, Leistungs- und Begeisterungsmerkmale eingeteilt, die eine unterschiedliche Kundenzufriedenheit hervorrufen. 1. Basismerkmale sind zwar für die Software notwendig, aber dieses Modell besagt, dass die Kundenzufriedenheit stagniert, je mehr von diesen umgesetzt werden. Am Beispiel eines Autos wären dies Elemente wie Reifen, Motor, Bremsen, etc. 2. Leistungsmerkmale lassen die Kundenzufriedenheit linear steigen. Am Auto wären dies zum Beispiel der Kraftstoffverbrauch oder die Motorleistung. 3. Begeisterungsmerkmale verursachen eine hohe Kundenzufriedenheit. Im Beispiel wäre dies ein Navigationssystem oder die Lackierung. Anforderungen aus allen drei Kategorien müssen für eine hohe Kundenzufriedenheit kombiniert werden. Mit Hilfe einer Wert-Risiko-Matrix lassen sich Anforderungen ebenfalls priorisieren. Ein Risiko schadet dem Projektverlauf dadurch, dass ein bestimmtes Ereignis eintritt oder ausbleibt. Dabei ist nicht sicher, ob das Ereignis tatsächlich eintritt. Somit liegt ein Risiko in der Zukunft. Ist ein Risiko eingetreten handelt es sich um ein konkretes Problem. Stellt man nun die Risiken den Werten der Anforderungen gegenüber, so erhält man die Wert- Risiko-Matrix. Dabei sollten zuerst die Anforderungen umgesetzt werden, die einen hohen Wert und ein hohes Risiko haben, um zügig die Risiken zu beseitigen. Sollten die Risiken zu Problemen führen, die das Projekt scheitern lassen, so passiert dies meistens früh. Dadurch ist der Schaden geringer, als wenn das Projekt zu einem späteren Zeitpunkt scheitert. Als Zweites sollten Anforderungen umgesetzt werden, die einen hohen Wert, aber geringes Risiko besitzen. Zu letzt sollten Anforderungen mit geringen Wert und Risiko ausgeführt werden. Anforderungen, die einen geringen Wert aber ein hohes Risiko haben sollten ganz vermieden werden, da bei diesen das Risiko in keinem Verhältnis zu dem Mehrwert steht. Eine weitere Technik zum Priorisiren der Anforderungen ist die MuSCoW-Priorisierung. Dabei werden die Anforderungen lediglich in die vier Gruppen Must have, Should have, Could have und Won t have aufgeteilt. Anforderungen aus den ersten drei Gruppen sollten während des geplanten Sprints und Anforderungen aus der letzten Gruppe können

12 auch in einem späteren Sprint realisiert werden. Dadurch verfügt diese Priorisierung über zwei Puffer. Arbeitet das Team schneller als erwartet, so kann es zusätzliche Anforderungen aus der Won t have -Gruppe umsetzten. Ist es langsamer als erwartet, so kann es Anforderungen aus der Could have -Gruppe streichen. Beides natürlich nur nach Rücksprache mit dem Product-Owner. Nach welchen Kriterien der Product-Owner die Anforderungen verteilt, ist ihm überlassen. So kann er zum Beispiel Basismerkmale in die Must have -Gruppe aufnehmen. 3.3 Schätzen Anforderungen werden abgeschätzt damit die Kosten mit dem Nutzen verglichen und dies in die Priorisierung einfließen kann. Außerdem lässt sich auf Grund der abgeschätzten Anforderungen planen, wie viele Anforderungen ca. in einem Sprint umgesetzt werden können, oder wie viele Sprints für die Entwicklung des kompletten Product-Backlogs notwendig sind. Häufig werden Punkte (Story Points) als Schätzgröße verwendet. Dabei handelt es sich um eine relative Aufwandsschätzung. Dies bedeutet, dass der Aufwand einer Anforderung mit einer anderen verglichen wird und Anforderungen nicht einzeln abgeschätzt werden können. Dafür muss zuerst eine Punktreihe eingeführt werden, die in einem Projekt verwendet wird. Somit sind Anforderungen aus unterschiedlichen Projekten oder von unterschiedlichen Teams nur dann vergleichbar, wenn sowohl die gleiche Punktreihe verwendet worden ist, als auch der Aufwand für die einzelnen Punkte auf beiden Skalen übereinstimmt. Als mögliche Punktereihe eignet sich die Fibonacci-Folge (0, 1, (1,) 2, 3, 5, 8, 13, ). Eine Anforderung mit null Punkten bedeutet keinen Aufwand. Ein Punkt bedeutet, einen sehr kleinen Aufwand. Zwei Punkte bekommen Anforderungen mit kleinem, aber doppelt so großen Aufwand wie die mit sehr kleinem Aufwand. Anforderungen mit drei Punkten haben einen mittleren Aufwand, der die Summe der beiden nächst kleineren, also von kleinem und sehr kleinem Aufwand, entspricht. Die Weiteren Punkte 5, 8 und 13 mit großem, sehr großem und riesigem Aufwand verhalten sich genau so. Dadurch, dass die Zahlen nicht alle den gleichen Abstand haben, werden Diskussionen ob eine Anforderung einen Aufwand von 7, 8 oder 9 Punkten hat, vermieden. Die Punkte werden dann nach folgendem Schema zugewiesen: Zuerst wird eine relativ kleine Anforderung ausgewählt, von der man den Aufwand gut einschätzen kann. Dieser Anforderung gibt man einen der Punkte auf der Skala. Somit ist die Skala fixiert. Der nächste Eintrag wird dann im Verhältnis zum ersten Eintrag geschätzt. Alle weiteren Schätzungen werden mit den vorherigen verglichen, damit die Relationen untereinander richtig sind. Durch gruppieren der Anforderungen mit gleicher Punktzahl kann überprüft werden, ob die Gruppen in sich konsistent sind. Dies kann dadurch erleichtert werden, dass die Anforderungen auf Karteikarten geschrieben werden. Anforderungen werden in Scrum vom Team in Schätzklausuren geschätzt. Diese finden regelmäßig statt um neue oder geänderte Anforderungen im Produkt-Backlog abzuschätzen. Der Scrum-Master moderiert die Schätzklausur und beendet diese sobald alle Anforderungen geschätzt sind oder die Zeit abgelaufen ist. Der Product-Owner erklärt dem Team die Anforderungen, die es dann abschätzen soll. Da das Team die Anforderungen umsetzt, darf

13 auch nur das Team diese abschätzen. In die Schätzungen müssen alle notwendigen Aktivitäten von Design über Programmierung und Integration bis Test und Dokumentation einfließen. Des Weiteren ist die Schätzung über Teamaufwände und muss deshalb die Aufwände aller Teammitglieder berücksichtigen. Als Methode zur Durchführung der Schätzungsklausur eignet sich Planungspoker. Dabei erhält jedes Teammitglied einen Kartenstapel mit allen Punkten. Nachdem der Product-Owner eine Anforderung vorgetragen hat, stimmt das Team sich über die wesentlichen Schritte zur Umsetzung ab. Haben sich die Teammitglieder beraten, wählt jeder die Karte mit der Punktzahl aus, die er persönlich schätzt und legt sie verdeckt vor sich ab. Sieht sich ein Teammitglied nicht in der Lage eine Anforderung abzuschätzen, so kann er sich enthalten. Anschließend drehen alle zusammen die Karten um. Stimmen die Punktzahlen überein und gibt es keine Ausreißer, so wird der Wert übernommen. Ansonsten müssen die beiden Teammitglieder, deren Schätzung am weitesten auseinander liegen, ihre Schätzung begründen. Anschließend wird wieder neu abgeschätzt. Kommen die Teammitglieder nach wiederholtem Schätzen nicht auf einen Konsens, so muss der Product-Owner die Anforderung noch einmal erklären. Reicht dies nicht aus, muss die Anforderung erst genauer beschrieben oder unterteilt werden oder Explorationsaktivitäten ausgeführt werden. Bei der Schätzung müssen sich alle im Klaren sein, dass es nur eine Schätzung ist, die einer Ungenauigkeit unterliegt. Die Schätzungen sind nicht für den restlichen Projektverlauf fest sondern können in folgenden Schätzklausuren korrigiert werden

14 4 Der Sprint In Scrum werden alle Anforderungen in Sprints umgesetzt. Am Ende jedes Sprints gibt es dann ein voll funktionsfähiges Produkt-Inkrement. Sprints sind Iterationen, die in der Regel alle die gleiche Länge haben und zwischen 1 und 4 Wochen dauern. Auch wenn der Name an einen Kurzstreckenlauf erinnert sollten die Teammitglieder nach einem Sprint nicht erschöpft sein. Zu Beginn jeden Sprints wird eine Sprint-Planungssitzung gehalten. In dieser Sitzung wählt das Team die Anforderungen aus, die es im Sprint umsetzen wird. Das Team erstellt anhand der Anforderungen die notwendigen Aktivitäten und füllt damit das Sprint-Backlog. Während des Sprints trifft sich das Team täglich zur gleichen Zeit, um im Daily-Scrum- Meeting die Arbeit untereinander zu synchronisieren. Am Ende des Sprints finden noch zwei weitere Besprechungen statt. Als erstes werden im Sprint-Review die Arbeitsergebnisse präsentiert und vom Product-Owner abgenommen. Danach wird in der Sprint-Retrospektive über den Sprint reflektiert und Verbesserungsmaßnahmen für den folgenden Sprint erarbeitet. Release 1. Inkrement 2. Inkrement Benutzerschnittstelle Geschäftslogik Infrastruktur Abb. 2: Inkremente eines Release Damit innerhalb eines Sprints ein Produkt-Inkrement entwickelt werden kann, das für den Kunden einen Mehrwert hat, müssen iterativ-inkrementelle Entwicklungstechniken eingesetzt werden. Besteht eine Software zum Beispiel aus den Schichten Benutzeroberfläche, Geschäftslogikschicht und Infrastrukturschicht, dann ist ein Inkrement ein Durchstich durch alle diese Schichten. In den nachfolgenden Sprints werden dann Inkremente erzeugt, die die vorherigen erweitern und somit ebenfalls Durchstiche sind. Ein Produkt-Inkrement besteht nicht nur aus der inkrementell wachsenden Software. Sie enthält sowohl auch noch Dokumentationen, wie zum Beispiel einer Benutzerdokumentation oder Entwicklerdokumentation, als auch unterschiedlichen Tests, wie Modul-, Integrations-, Funktionstests. Auch diese Teile wachsen mit der Software inkrementell mit und werden immer wieder erweitert. Dies ist ein Unterschied zum traditionellen Wasserfallmodell bei dem zuerst alle Schichten separat entwickelt und erst im Anschluss getestet bzw. dokumentiert werden. Sobald der Sprint gestartet ist und die Sprint-Planungssitzung beendet wurde kann der Sprint nicht mehr geändert werden. Das Team darf nicht in seiner Zusammensetzung geändert werden. Dies ist immer nur vor Beginn eines Sprints möglich. Auch dürfen keine neuen Anforderungen von außen hinzugefügt werden. Somit wird sichergestellt, dass das Team die

15 ausgewählten Anforderungen in dem Sprint fertig stellen kann. Sollte es dennoch vorkommen, dass das Team schneller oder langsamer ist, als es in der Sprint-Planungssitzung geschätzt hat, so darf die Sprint Länge nicht geändert werden, denn diese unterliegt einer Time-Box. Stattdessen darf das Team unter Rücksprache mit dem Product-Owner neue Anforderungen, die vollständig umgesetzt werden können, in den Sprint aufnehmen oder Anforderungen streichen, damit diese erst in einem der nächsten Sprints umgesetzt werden. Sollten jedoch so massive Hindernisse auftauchen, dass das Team das Sprint-Ziel nicht erreichen kann oder das sich die Kundenanforderungen so stark geändert haben, dass der Sprint keinen Mehrwert mehr darstellt, so kann der Sprint entweder vom Team oder vom Product-Owner vorzeitig beendet werden. Dies sollte aber die allerletzte Lösung sein. Wurde der Sprint abgebrochen, so werden Sprint-Review und -Retrospektive vorgezogen und die Gründe für den Abbruch beseitigt. Im Anschluss wird dann ein neuer Sprint mit einer Sprint- Planungssitzung gestartet. Die Sprint-Länge sollte für die Dauer eines Projektes gleich bleiben. Nach Ken Schwaber dauert ein Sprint traditionell 30 Tage. Es sind aber auch kürzere Sprint-Längen, bis zu einer Woche, möglich. Je kürzer die Sprints sind, desto häufiger können die entstanden Produktinkremente inspiziert und angepasst werden. Dadurch kann schnell auf Änderungen reagiert werden, die häufig bei unsicheren oder risikoreichen Projekten auftreten können. Des Weiteren wirkt dies Sprint-Abbrüchen, die durch Änderungen der Anforderungen entstehen, entgegen. Kurze Sprints können zu einer höheren Produktivität des Teams führen, aber bedeuten gleichzeitig mehr Arbeit für den Product-Owner, da er die Anforderungen feingranularer erfassen muss, damit diese während des Sprints vom Team vollständig umgesetzt werden können. 4.1 Die Sprint-Planungssitzung Der Product-Owner muss bevor die Sprint-Planungssitzung stattfinden kann diese erst vorbereiten. Diese Aufgabe sollte er nicht unterschätzen und deshalb damit spätestens nach der Hälfte des laufenden Sprints beginnen. Eine Aufgabe ist es ein realistisches Sprint-Ziel zu definieren. Es dient dazu den Beteiligten einen Überblick über das geplante Ergebnis zu verschaffen. Anhand dieses Ziels werden nun Anforderungen aus dem Product-Backlog ausgewählt und weiter verfeinert. Dabei müssen so viele Anforderungen aufbereitet werden, dass das Team eine Auswahl hat. Der Product- Owner kann durch Teammitglieder bei der Aufbereitung der Anforderungen unterstützt werden. Die Teammitglieder, die ihm dabei helfen, sollten repräsentativ für das Team sein. Sollte dem Team Wissen für die Umsetzung fehlen, so können entsprechende Explorationsaktivitäten in das Product-Backlog aufgenommen werden. Tauchen viele solcher Aktivitäten auf, so kann auch ein Explorationssprint durchgeführt werden. Die verfeinerten Anforderungen müssen im Anschluss vom Team abgeschätzt werden. Mit Hilfe der Abschätzungen kann der Product-Owner über Kosten und Nutzen abwägen und dies in die anschließende Priorisierung einfließen lassen. Auch die Anzahl der umsetzbaren Anforderungen lässt sich damit abschätzen. Eine weitere Aufgabe des Product-Owners ist es die Teamverfügbarkeit zu ermitteln. Dies soll dem Team helfen einzuschätzen, wie viel es umsetzen kann. Dazu eignet sich eine

16 Tabelle, die die Verfügbarkeit jedes Teammitglieds an den einzelnen Tagen auflistet. Die Dauer der Sprint-Planungssitzung, Sprint-Review und Sprint-Restrospektive werden direkt an den entsprechenden Tagen abgezogen. Auch bekannte Fehlzeiten wie Urlaub und Feiertage werden sichtbar. Alle Einträge aufsummiert ergibt dies die Bruttokapazität des Teams. Um die Nettokapazität zu erhalten müssen alle zusätzlichen Aufwände erfasst und abgezogen werden, die nicht zum Erreichen des Sprint-Ziels dienen. Dazu zählen Aufgaben, die im Tagesgeschäft erledigt werden müssen, wie zum Beispiel Telefonate, s und Besprechungen. Der genaue Wert muss über mehrere Sprints hinweg ermittelt werden und kann zwischen 20-35% der Bruttokapazität liegen. Weitere 5% müssen abgezogen werden, damit das Team genügend Zeit hat den folgenden Sprint vorzubereiten. Letzte, eher triviale, Aufgabe ist es, einen Raum mit genügend Stühlen und sowohl Hilfsmittel zum moderieren, als auch Flipchart oder ähnliches zu reservieren. In der Sprint-Planungssitzung entscheidet das Team, welche Anforderungen es aus dem Product-Backlog umsetzen wird und erfasst die dafür notwendigen Aktivitäten im Sprint- Backlog. Die Sitzung sollte dabei maximal 10% der Gesamtzeit, bei einem 30-tägigen Sprint also 8 Stunden, betragen. Es muss sowohl der Product-Owner, das Team, als auch der Scrum- Master anwesend sein. Neben diesen drei Rollen können auch Interessensvertreter an der Sitzung teilnehmen, dürfen aber das Team nicht beeinflussen. Der Scrum-Master unterstützt das Team in dem er moderiert und dafür sorgt, dass das Team nicht beeinflusst wird und sich ausschließlich selbst organisiert. Nach der Eröffnung durch den Scrum-Master stellt der Product-Owner zuerst das Sprint-Ziel vor. Durch eine Diskussion zwischen Product-Owner und Team soll für ein gemeinsames Verständnis gesorgt werden. Sollten nicht alle Teammitglieder das Sprint-Ziel für realistisch und sinnvoll halten, so ist es möglich dieses noch zu ändern. Im weitern Verlauf wird das Team die Anforderungen durch gehen und Aktivitäten ableiten. Dazu gibt es zwei Möglichkeiten. Die erste ist, dass klassisch, wie es Ken Schwaber beschreibt, vorgegangen wird und die Sitzung in zwei gleich lange Teile geteilt wird. Im ersten Teil geht das Team alle Anforderungen durch und wählt die aus, die es glaubt während des Sprints umsetzen zu können. Dabei verpflichtet es sich diese umzusetzen. Während des zweiten Teils werden dann die für die Anforderungen notwenigen Aktivitäten ermittelt und im Sprint-Backlog erfasst. Die zweite Möglichkeit ist, dass Iterativ vorgegangen wird. Dabei werden die Anforderungen von der am höchsten priorisierten aus durchgegangen und für jede Anforderung werden sofort die zugehörigen Aktivitäten ermittelt und abgeschätzt. Wenn das Team noch über genügend Kapazitäten verfügt um alle Aktivitäten der Anforderung umzusetzen, so wird die Anforderung mit ihren Aktivitäten in das Sprint-Backlog übernommen und das Team verpflichtet sich diese umzusetzen. Bei beiden Varianten wird über die Anforderungen diskutiert, um ein gemeinsames Verständnis zu schaffen. Außerdem muss sich über Akzeptanzkriterien geeinigt werden, an denen die Ergebnisse im Sprint-Review abgenommen werden. Um für alle die Änderungen an den Anforderungen klar nachvollziehbar zu machen, eigenen sich Karteikarten, auf denen die Anforderungen aufgeschrieben sind. Diese lassen sich dann leicht erweitern, ändern oder umsortieren

17 Bei der Ermittlung der Aktivitäten müssen die Teammitglieder alle Aktivitäten ermitteln die zur Umsetzung notwendig sind. Dazu gehören Design-, Implementierungs-, Test- und Dokumentationsaufgaben. Diese Aktivitäten sollten möglichst genau und detailliert beschrieben werden. Wenn die Zeit der Sprint-Planungssitzung nicht reicht die Anforderungen genau genug zu beschreiben so sollte dies während des Sprints fertig gestellt werden. Damit sowohl der Fertigstellungsgrad, als auch der Projektfortschritt gut verfolgt werden kann sollten die Aktivitäten nicht länger als einen Nettotag dauern. Nachdem die Aktivitäten erfasst worden sind, werden diese in Personenstunden abgeschätzt. Dabei sollte die Schätzung nicht gepuffert werden und der Aufwand von allen Teammitgliedern mitberücksichtigt werden. Damit alle Teammitglieder in den Prozess mit eingebunden werden und die Aktivitäten sich leicht gruppieren lassen, können diese, wie die Anforderungen auch, auf Karteikarten aufgeschrieben werden. Dabei werden ein Titel, eine kurze Beschreibung und der Aufwand notiert. Es können auch noch weitere Symbole vereinbart werden. So können Aktivitäten, die einer Time-Box unterliegen, da sie zum Beispiel der Exploration dienen, mit Hilfe eines Randes um die Karte gekennzeichnet werden. Auch Aktivitäten, die der Fortbildung dienen und deshalb vom Product-Owner erst freigegeben werden müssen, können durch andersfarbige Karten hervorgehoben werden. Eine aktive Mitarbeit von allen Teammitgliedern ist wichtig, damit sich alle mit dem Sprint- Backlog identifizieren können. Das Team kann zum Überprüfen, ob es eine Anforderung mit all ihren Aktivitäten umsetzen kann, unterschiedliche Techniken einsetzen. So kann die Kapazität des Teams mit einem Planungsglas symbolisiert werden. Dessen Inhalt entspricht der Bruttokapazität des Teams und wird als erstes mit den allgemeinen Aufwänden gefüllt. Der jetzt verbleibende Platz entspricht der Nettokapazität. Eine Anforderung wird aufgenommen, wenn in dem Planungsglas genügend Platz für die Aktivitäten der Anforderung ist. Alternativ lässt sich der Sprint-Ablauf simulieren. Dabei wird simuliert, von wem die einzelnen Aktivitäten ausgeführt werden könnten, in welcher Reihenfolge diese stattfinden könnten und welche parallelisiert werden könnten. Wenn das Team der Überzeugung ist, dass sie diese Anforderung umsetzen können, dann wird dieser Teil der Sprint-Verpflichtung. Auch wenn speziell bei der Ablaufsimulation überlegt wird, wer welche Aktivität ausführen könnte, so werden die Aktivitäten niemanden zugeordnet. Auch während des Sprints werden nicht die Aktivitäten den einzelnen Teammitgliedern zugeordnet. Ist ein Mitglied bereit für eine Aufgabe, so sucht er sich selber eine zu seinem Wissen passende aus. Dabei sollte er die hoch priorisierten bevorzugen. Die Kapazität des Sprints sollte nicht zu 100% ausgenutzt werden. Dies könnte zu Überlastungen führen, die sich negativ auf die Entwicklungsgeschwindigkeit auswirken. Des Weiteren würde Zeit für Verbesserungen durch Refaktorisierung fehlen. Die Sprint-Planungssitzung wird vom Scrum-Master beendet, sobald die Kapazität des Teams für den Sprint erschöpft ist, oder die Zeit der Sitzung abgelaufen ist. Das Ergebnis sollte ein realistisches Sprint-Ziel mit einem Sprint-Backlog sein zu dem sich das Team verpflichtet hat. Die wesentlichen Ergebnisse können noch einmal kurz zusammengefasst werden

18 4.2 Das Sprint-Backlog Das Sprint-Backlog enthält alle Anforderungen mit den dazu gehörigen Aktivitäten, zu denen sich das Team in der Sprint-Planungssitzung verpflichtet hat. Alle Einträge wurden in Personenstunden abgeschätzt. Wie das Product-Backlog ist es ein lebendiges Dokument, das während des Sprints fortlaufend aktualisiert wird. Mindestens einmal am Tag sollten die Teammitglieder die Aktivitäten, an denen sie zurzeit arbeiten, aktualisieren und den Restaufwand abschätzen. Dadurch ist für jeden der aktuelle Status und Fortschritt des Sprints sichtbar. Findet ein Teammitglied neue Aktivitäten, die zur Umsetzung einer Anforderung notwendig sind, so schätzt er diese ab und fügt sie in das Sprint-Backlog ein. Als Sprint-Backlog eignet sich eine Stellwand, an der die Karteikarten, die unter anderem während der Sprint-Planungssitzung erstellt worden sind, aufgehängt werden. Im Gegensatz zu einem elektronischen Sprint-Backlog haben die Teammitglieder, vorausgesetzt sie arbeiten wie empfohlen zusammen in einem Büro, die Stellwand immer im Blick und können diese auch immer ändern. Das Sprint-Backlog sollte eine tabellarische Struktur mit folgenden Spalten haben: Priorität, Anforderung, Zu erledigen, In Arbeit und Erledigt. Zu Beginn des Sprints werden alle Anforderungen nach Priorität sortiert in die Anforderung -Spalte eingefügt. In der Spalte Priorität werden die entsprechenden Prioritäten der Anforderungen festgehalten. Die zur Anforderung gehörigen Aktivitäten kommen in die Spalte Zu erledigen. Mit Hilfe von Linien kann man Anforderungen gleicher Priorität und Aktivitäten einer Anforderung gruppieren. Möchte ein Teammitglied mit der Bearbeitung einer der Aktivitäten beginnen, so nimmt er sich diese aus der Spalte Zu erledigen, versieht diese mit seinem Namen oder Kürzel und hängt sie in der Spalte In Arbeit. Sobald das Teammitglied mit der Aktivität fertig ist, wird die Karte in die Spalte Erledigt umgehängt und der Restaufwand auf null gesetzt. Mit der Zeit wandern die Karten von links nach rechts. Zuerst die oberen, dann die, die weiter unten sind. Diese Tabelle läst sich je nach Bedarf um weitere Spalten, wie bereit zum testen, erweitern. 4.3 Der Sprint-Burndown-Bericht Der Sprint-Burndown-Bericht visualisiert den Sprint-Fortschritt. Dieser basiert auf den Daten aus dem Sprint-Backlog. Aus dem Bericht wird auch ersichtlich, ob das Team im Zeitplan liegt oder nicht. Der Bericht ist ein Säulen-Diagram, in dem auf der x-achse die Anzahl der Tage und auf der y-achse der Restaufwand aller Aktivitäten eingetragen sind. Außerdem wird eine Gerade durch den aufsummierten Restaufwand zu Beginn und dem letzten Tag mit Restaufwand null gezogen. Dies gibt den idealen Fortschritt oder auch Burndown an. Der Begriff Burndown kommt daher, dass der Restaufwand im Verlauf des Sprints wie eine Kerze herunter brennt

19 Summe der Aufwände Tage Abb. 3: Der Sprint-Burndown-Bericht Der Sprint-Burndown-Bericht wird in der Sprint-Planungssitzung angelegt und wird täglich anhand der aktuellen Daten aus dem Sprint-Backlog aktualisiert. Dazu werden alle Restaufwände aufsummiert und als Säule an die entsprechende Stelle in das Diagramm eingezeichnet. Liegen die Säulen oberhalb des idealen Burndowns, so ist das Team langsamer als in der Sprint-Planungssitzung angenommen. Liegen die Säulen unterhalb so ist es schneller. In der Regel ist der Fortschritt in den ersten Tagen langsamer als der ideale Fortschritt. Dies kann durch Hindernisse oder falsche Aufwandsschätzungen entstehen. Im Laufe des Sprints sollte sich die Entwicklungsgeschwindigkeit erhöhen, so dass dieser Rückstand wieder aufgeholt wird. Wenn das Team zu langsam sein sollte, so kann es diese Erkenntnisse aus dem Bericht dazu nutzen seine Selbstorganisation zu optimieren oder Anforderungen nach Rücksprache mit dem Product-Owner zu streichen. Der Bericht kann auch in der Sprint-Retrospektive heran gezogen werden um den Sprint-Verlauf nachvollziehen zu können. 4.4 Die Daily-Scrum-Besprechung Die Daily-Scrum-Besprechung ist eine 15 minütige Besprechung, die jeden Tag und immer am selben Ort stattfindet. An ihr nehmen das komplette Team und der Scrum-Master teil. Der Product-Owner kann mit dran teilnehmen, ist aber nicht dazu verpflichtet. Weitere Interessenvertreter können nach Rücksprache als Zuhörer teilnehmen. Die Besprechung dient dazu die Arbeit der Teammitglieder zu synchronisieren und Hindernisse aufzudecken. Die entdeckten Hindernisse werden aber nicht in der gleichen Besprechung, sondern von den betroffenen Teammitgliedern in einer weiteren Besprechung gelöst. Die Daily-Scrum-Besprechung wird meistens im Stehen und in der Nähe des Sprint Backlogs und des Sprint-Burndown-Berichts gehalten. Während der Besprechung beantworten alle Teammitglieder folgende Fragen ohne dabei weit auszuschweifen: Welche Aktivitäten habe ich seit der letzten Daily-Scrum abgeschlossen? Woran plane ich bis zur nächsten Daily-Scrum zu arbeiten? Werde ich in irgendeiner Form an der Ausführung einer Aktivität behindert? Der Scrum-Master schreibt die genannten Hindernisse zusammen mit dem Datum auf und aktualisiert schon vorhandene

20 4.5 Die Hindernis-Liste Hindernisse, die während der Daily-Scrum-Sitzung aufgedeckt werden, werden in die Hindernis-Liste mit dem Datum des Auftauchens eingetragen. Die Hindernisse, die gelöst worden sind, werden mit dem Datum der Beseitigung versehen. Anhand dieser Liste haben alle einen Überblick über alle zurzeit bekannten Hindernisse. Der Scrum-Master ist für die Beseitigung dieser Hindernisse zuständig. Durch analysieren der Hindernis-Liste, indem die Häufigkeit des Auftretens, die Art des Hindernisses und die Dauer bis zur Lösung untersucht wird, können Hindernissen in Zukunft entgegen gewirkt werden. 4.6 Das Sprint-Review Das Sprint-Review findet am Ende des Sprints statt und dient dazu die Arbeitsergebnisse vom Team abzunehmen. Die Besprechung sollte maximal 5% der Gesamtzeit betragen. Dies entspricht bei einem 30-tägigen Sprint 4 Stunden. Neben Product-Owner, Team und Scrum- Master, die an der Sitzung teilnehmen müssen, sind optional die Interessensvertreter wie Kunden, Endanwender oder Repräsentanten anderer Abteilungen eingeladen. In dieser Sitzung haben sie die Möglichkeit das Arbeitsergebnis des Sprints zu begutachten und den Entwicklern direkt ein Feedback zu geben. Aber der Product-Owner darf als einziger die Arbeitsergebnisse abnehmen. Nachdem der Product-Owner zu Beginn der Sitzung das aktuelle Sprint-Ziel und die Anforderungen, zu denen sich das Team verpflichtet hat, vorgetragen hat, beginnt das Team mit der Vorführung. Die Vorführung muss auf einem Testsystem stattfinden, das der Zielumgebung möglichst nahe kommt. Außerdem muss es sich um ein offizielles Build handeln. So wird sichergestellt, dass das Produkt-Inkrement auch wirklich potentiell auslieferbar ist und nicht nur auf dem Arbeitsplatz eines Entwicklers läuft. Nun geht das Team die umgesetzten Anforderungen durch und präsentiert diese. Dabei ist es erwünscht, dass der Product-Owner aktiv teilnimmt und die Ergebnisse selber ausprobiert. Des Weiteren kann er, und auch die Interessenvertreter, dem Team Fragen stellen bzw. Feedback geben. Sind alle Fragen zu der Anforderung beantwortet, so nimmt oder lehnt der Product-Owner die Anforderung ab. Dabei können nur vollständig umgesetzte Anforderungen abgenommen werden. Auch wenn eine Anforderung zu 99% fertig gestellt sein sollte oder auch nur kleine Bugs enthalten sind, so darf diese nicht abgenommen werden. Würden diese Anforderungen abgenommen werden, so würden diese die Entwicklungsgeschwindigkeit verfälschen. Die nicht abgenommen Anforderungen werden im Product-Backlog aktualisiert bzw. die Defekte neu aufgenommen. Diese sollten dann im nächsten Sprint als erstes fertig gestellt werden. Da das Team die Verpflichtungen zusammen in der Sprint-Planungssitzung eingegangen ist, ist es auch als ganzes für den Erfolg bzw. den Misserfolg des Sprints verantwortlich. Darum sollten auch nicht einzelne Personen gelobt oder kritisiert werden, da dies das Einheitsgefühl des Teams untergraben würde