Scrum

• Zunächst werden alle bekannten Anforderungen erfasst und geschätzt.

• Dann werden die Anforderungen für die nächste Iteration identifiziert (z.B. wichtigste, kritischste, einfachste) und geplant.

• Die Iteration ist time boxed. Sie wird nicht unterbrochen und auch nicht verlängert. Die Iteration heißt auch Sprint. Er ist üblicherweise 30 Tage lang.

• Am Ende der Iteration steht dem Kunden ein „fertiges“ Produkt zur Verfügung, das er sich anschauen und zu dem er Feedback geben kann.

• Der Fortschritt der Arbeit wird täglich in einem kurzen Meeting im gesamten Team besprochen.

• Die wichtigste Zahl bei Scrum ist die Drei: Es gibt jeweils drei Rollen, Artefakte und Meetings

Bei Scrum gibt es drei verschiedene Rollen: Team, Product Owner und Scrum Master.

Das Team führt die Arbeit aus und entscheidet wie viele Anforderungen es in einem Sprint umsetzen kann. Seine Arbeitsweise ist völlig frei durch das Team selbst bestimmbar, es gibt keine Vorgaben („selbstorganisierendes Team“).

Der Product Owner repräsentiert die Kundenbedürfnisse. Ihm „gehört“ das Produkt und er trifft die nötigen Entscheidungen (in Abstimmung mit dem Kunden). Er entscheidet, welche Anforderungen für eine Version umgesetzt werden und wann die Software ausgeliefert wird. Er arbeitet eng mit dem Team zusammen und ist weit mehr als ein einfacher Produktmanager oder Projektleiter, hat aber keine Weisungsfunktion.

Der Scrum Master hilft allen Beteiligten, Scrum korrekt anzuwenden und unterstützt das Team, indem er z.B. „Impediments“ (Hindernisse) beseitigt. Der Scrum Master ist kein Projektleiter, sondern sollte eher als „Consultant“ oder „Coach“ verstanden werden, der penibel prüft, ob die Regeln von Scrum eingehalten werden. Er hat daher auch keine Weisungsbefugnis.

Im Rahmen von Scrum werden drei verschiedene Artefakte erzeugt und bearbeitet: Das Product Backlog, die Sprint Backlogs und das (End-)Produkt. Die obige Darstellung zeigt die Zuordnung der einzelnen Artefakte zu den Phasen von Scrum.

Das Product Backlog ist das zentrale Instrument zum Erfassen und Managen von Anforderungen. Aus ihm werden die in den einzelnen Sprints umzusetzenden Aufgaben oder Tasks abgeleitet. Vereinfacht gesagt ist das Product Backlog eine absteigend nach Priorität sortierte Liste aller bereits geschätzten (!) Anforderungen an das Produkt.

Aus dem Poduct Backlog werden im Rahmen des Sprint Plannings die wichtigsten Anforderungen herausgenommen und für den nächsten Sprint in das Sprint Backlog übertragen. Dort werden alle nötigen Aktivitäten zum Erreichen des Sprint-Ziels aufgelistet und detailliert beschrieben. Das Team schwört sich auf das Sprint Backlog ein und verpflichtet sich zur Umsetzung der dort definierten Punkte („commitment“). Das Sprint Backlog wird täglich aktualisiert.

Das Produkt(-inkrement) ist das wichtigste Artefakt, da letztlich nur die erstellte Software dem Kunden einen Mehrwert bietet und kein Product Backlog oder Sprint Backlog. Um den Kundenanforderungen bestmöglich zu entsprechen wird es in Iterationen entwickelt, um sich nicht von den Vorstellungen des Kunden wegzuentwickeln. Das Produkt beinhaltet: Das Programm, die Dokumentation und die nötigen Tests („definition of done“).

Bei Scrum werden drei Meetings abgehalten: Das Sprint Planning, der Daily Scrum und der Sprint Review. Die obige Darstellung zeigt auch die Zuordnung der Meetings zu den Phasen von Scrum.

Beim Sprint Planning werden die im nächsten Sprint umzusetzenden Anforderungen vom Team realistisch geschätzt (z.B. muss die verfügbare Entwicklungszeit realistisch definiert werden, etwa mit 2 Tagen/Woche) und das Team legt sich verbindlich auf das Ziel des Sprints fest. Die Aufgaben werden an die Teammitglieder verteilt. Für die Schätzung kann z.B. Planning Poker gespielt werden.

Das Daily Scrum ist ein „time-boxed Standup-Meeting“, das max. 15 Minuten dauern sollte und am besten direkt vor dem Sprint Backlog durchgeführt wird. Ziel ist, das Sprint Backlog auf den neusten Stand zu bringen und drei Fragen durch jedes einzelne Teammitglied beantworten zu lassen:

1. Was habe ich seit dem letzten Daily Scrum gemacht?

2. Was werde ich bis zum nächsten Daily Scrum tun?

3. Was hat mich bei meiner Arbeit behindert? (das sind die Impediments, die der Scrum Master beheben muss)

Beim Sprint Review am Ende eines Sprints wird das Produkt dem Kunden vorgeführt, damit dieser Feedback geben kann. Im besten Fall wird immer eine lauffähige Software präsentiert und keine theoretischen Überlegungen oder UML-Diagramme. Auf Basis des Kundenfeedbacks können im nächsten Sprint dann gezielt die Probleme behoben oder die nächstwichtigen Anforderungen umgesetzt werden.

Optional wird von Zeit zu Zeit eine Sprint Retrospective am Ende eines Sprints durchgeführt, um sicherzustellen, dass die Arbeit im Projekt regelmäßig verbessert wird. Der Scrum-Prozess soll ständig optimiert werden und somit ein noch besseres Ergebnis geliefert werden.

Die Velocity des Teams sagt aus, wie schnell dieses Aufgaben abarbeiten kann. Sie pendelt sich im Laufe des Projekts auf einen stabilen Wert ein, da zu Beginn des Projekts die Schätzungen häufig ungenauer sind, weil z.B. die Domäne nicht bekannt ist, Technologien evaluiert werden müssen usw.

Auf dem Burndown Chart kann zu jedem Zeitpunkt der aktuelle Fortschritt des Projekts abgelesen werden. Hier werden im Daily Scrum die Schätzungen der aktuellen Aufgaben aktualisiert, wobei sich diese nach unten (erfolgreich bearbeitet) oder oben (Probleme aufgetreten) entwickeln können. Es geht nicht darum, die aufgewendete (vergangene) Arbeitszeit zu protokollieren, sondern darum, die Schätzung der zukünftigen Aufwände an die aktuellen Erkenntnisse anzupassen.