ScrumSo läuft ein Projekt mit Scrum ab

Warum wird ein Scrum-Projekt begonnen?

Am Anfang steht eine Produkt-Vision. Das ist eine grobe Vorstellung vom Produkt oder Projektergebnis, die die Geschäftsleitung oder der Product Owner als Auftraggeber hat. Für eine solche Produkt-Vision und Vorstellung gibt es meist einen konkreten Anlass oder Auslöser.

Beispiele dafür sind:

• Anwender oder Kunden sind mit einem bestehenden Produkt nicht mehr zufrieden, sie haben andere Anforderungen und Wünsche, weil Wettbewerber das auch bieten.
• Es gibt neue, bessere technische Möglichkeiten für ein bestehendes oder ganz neues Produkt, die man nutzen will.
• Technik ist fehleranfällig, Prozesse sind schwerfällig und teuer; das soll verbessert werden.
• Es gibt eine gesetzliche Anforderung oder andere Rahmenbedingungen, die es notwendig machen, dass etwas umgesetzt oder geändert wird.

Letztlich wollen Geschäftsleitung und Product Owner ein Produkt oder ein Projektergebnis, das einen größeren Nutzen bringt oder Schaden für das Unternehmen abwendet. Mit solchen Auslösern und Anlässen startet ein Scrum-Projekt.

Das läuft dann aber anders ab als ein klassisches Projekt; es gelten die Regeln des agilen Projektmanagements. Der Scrum-Prozess ist darauf ausgerichtet, die Anforderungen der Auftraggeber, der Nutzer, der Kunden und des Product Owners, möglichst korrekt zu erfassen, dann ohne großen Planungsaufwand zu bearbeiten und am Ende funktionierende Ergebnisse zu liefern. Im Einzelnen werden dazu folgende Schritte durchgeführt.

1. Anforderungen für das Scrum-Projekt ermitteln und in User Storys und Story Cards festhalten

Aus der ersten, aber möglichst schon anschaulichen und verständlichen Produkt-Vision und der groben Produkt-Vorstellung lassen sich einzelne Funktionen und Merkmale des Produkts oder der Lösung ableiten, die im Projekt zu entwickeln sind. Die Kunden und Nutzer beschreiben ihre Anforderungen und Erwartungen dazu als User Story aus ihrer Anwenderperspektive und in ihren Worten – nicht im Jargon der Techniker.

Daraus werden die Funktionen und Merkmale abgleitet, die das Produkt haben soll. Sie werden auf einer Story Card formuliert. Die Story Card ist das Medium, auf dem die User Story möglichst exakt erfasst und dargestellt wird. Die User Storys und Story Cards können im Gespräch oder in einem Workshop mit dem Product Owner und gegebenenfalls mit ausgewählten Nutzern oder Kunden ermittelt und formuliert werden.

Mit diesen Anforderungen wird bereits deutlich, welche Ressourcen das Projekt braucht. Das betrifft zum einen die Art der Qualifikationen und des Know-hows im Projektteam und zum anderen eine grobe Schätzung des Aufwands für die Entwicklung des Produkts oder der Lösung.

2. Product Backlog und Backlog-Items erarbeiten

Aus den Anforderungen des Product Owners und der Nutzer oder Kunden und aus den User Storys wird ein Product Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt oder die Lösung für das Projekt haben soll.

Im Product Backlog können außer Merkmalen und Funktionen auch Aufgaben oder Arbeitspakete für das Scrum-Projekt zusammengestellt sein. Eine einzelne Aufgabe, eine Funktion oder ein Merkmal wird als Backlog-Item bezeichnet.

Am Anfang ist die Beschreibung der einzelnen Backlog-Items noch grob. Denn im Projektteam ist noch nicht genau geklärt, welche Teilaufgaben mit einer Lösung verknüpft sind oder welche Eigenschaften die Funktion im Detail haben soll. Das ergibt sich, wenn das jeweilige Backlog-Item entwickelt oder ausgearbeitet wird.

Dazu müssen gegebenenfalls weitere Gespräche mit dem Nutzer, Kunden oder Project Owner geführt werden. Im Projektverlauf werden die einzelnen Aufgaben, Funktionen und Merkmale deshalb immer detaillierter formuliert und entsprechend beschrieben.

3. Definition of Done festlegen

Dann ist es notwendig, bei der Beschreibung des Backlog-Items genau zu klären und festzulegen, was zeigt, dass das Item fertig ist. Dies wird mit der Beschreibung einer „Definition of Done“ erfüllt. Dazu werden Indikatoren, Funktionen oder Tests benannt, die nach der Entwicklung des Ergebnisses durchgeführt werden und bestätigen, dass die Lösung funktioniert oder ein Produktmerkmal vorhanden ist.

4. Entwicklungsaufwand mit Story Points darstellen

Wenn die Anforderungen der Nutzer, Kunden oder des Product Owners geklärt sind, muss das Projektteam abschätzen, wie komplex eine Aufgabe, Funktion oder Merkmal, also das einzelne Backlog-Item, ist. Die Komplexität ist meistens ein Indikator für den (zeitlichen) Aufwand für die Realisierung. Diese Schätzung wird bei Scrum in Story Points ausgedrückt.

Ein Backlog-Item mit 10 Story Points ist doppelt so komplex und aufwendig wie ein Backlog-Item mit 5 Story Points. Wie viele Stunden Entwicklungsaufwand mit einem Story Point verbunden sind, ergibt sich aus der Erfahrung oder aus dem Projektverlauf. Für eine Zeit- und Kostenkalkulation kann ein Story Point mit einem Zeit- oder Geldfaktor verknüpft werden.

5. Prioritäten für Backlog-Items vergeben

Im nächsten Schritt werden Prioritäten vergeben. Eine hohe Priorität erhalten die Aufgaben, Merkmale und Funktionen, die zur Zufriedenheit der Anwender besonders viel beitragen, indem sie deren besonders wichtigen Anforderungen erfüllen. Maßgeblich ist auch, dass das Produkt und das Projektergebnis insgesamt am Ende des Projekts „funktionieren“ und eine Lösung sind, die für den Anwender brauchbar ist und einen Vorteil bringt.

Eine geringere Priorität erhalten solche Aufgaben, Merkmale und Funktionen, die mit Anforderungen verbunden sind, die für den Anwender nicht so wichtig sind. Sie werden mit anderen zusammengelegt, werden verschoben, zurückgestellt oder gar nicht entwickelt, weil sie nicht in den Zeitrahmen und ins Budget passen.

Möglich ist, dass diese weniger wichtigen Aufgaben, Merkmale und Funktionen bei einer Überarbeitung oder bei der Erweiterung des Produkts oder der Lösung entwickelt werden. Im Bereich der Software-Entwicklung spricht man von einem Release-Wechsel.

6. Ablauf des Projekts besprechen

In einer ersten Besprechung des Scrum-Masters mit seinem Projektteam zum Projektablauf werden die Rahmenbedingungen abgesteckt und ein gemeinsames Verständnis vom Produkt und den wichtigen Aufgaben sowie vom zeitlichen Ablauf entwickelt. Diese Fragen werden dazu besprochen:

• Wie soll der allgemeine Aufbau des Produkts oder der Lösung aussehen?
• Was sind die Meilensteine?
• Welche Funktionen und Aufgaben müssen bis zu welchem Zeitpunkt in jedem Fall erledigt sein?
• Was sind die Teilziele für eine einzelne Funktion oder Aufgabe?
• In welche Teilschritte, Sprints, lässt sich das Projekt untergliedern?
• Auf welche Details oder Besonderheiten ist zu achten?
• Welche Konventionen und Schnittstellen sind einzuhalten?
• Wo und wann kann sich das Team regelmäßig für den Daily Scrum (täglich!) treffen?

Ein wesentliches Merkmal von Scrum-Projekten ist, dass die Ablaufplanung nur grob ist und kein großer Aufwand in die Detailplanung investiert wird; denn im Laufe des Projekts wird sich ohnehin vieles wieder ändern. Wichtiger ist, dass ein gemeinsames Verständnis im Projektteam dazu entsteht, was die K.-o.-Kriterien sind, welche Ziele besonders wichtig sind und welche Meilensteine beachtet werden müssen.

7. Sprint Planning: Einzelne Aufgaben bestimmen

Wenn die Ziele und Rahmenbedingungen geklärt sind, erfolgt das Sprint Planning. Dazu bespricht das Projektteam, wie die Backlog-Items aus dem Product Backlog in Einzel- oder Teilaufgaben zerlegt werden. Diese werden dann innerhalb sogenannter Sprints geplant und bearbeitet.

Ein Sprint ist ein Arbeitszyklus (Teilschritt oder Phase) im Projekt, in dem jeder Projektmitarbeiter die von ihm ausgewählte Teilaufgabe (Sprint-Task) bearbeitet und eine fertige Teillösung dafür liefert. Die Zeit für einen Sprint hängt vom Umfang und von der Komplexität der jeweils bearbeiteten Aufgaben ab. Sie wird als sogenannte Time Box festgelegt und kann ein bis vier Wochen umfassen.

Abbildung 1 zeigt im Überblick, wie dieser Kernprozess im Scrum-Projekt, der Sprint, funktioniert.

Das Ergebnis des Sprint Planning sind die Sprint-Tasks oder Tickets. Diese Teilaufgaben werden im Sprint Backlog (Maßnahmenplan) aufgeführt und am Sprint-Taskboard visualisiert. Das Sprint Backlog und das Taskboard sind gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwicklerteam für den nächsten Arbeitszyklus (Sprint). Jedes Teammitglied übernimmt eigenverantwortlich eine Teilaufgabe beziehungsweise ein Ticket und verpflichtet sich damit, dafür eine Lösung zu entwickeln oder zu finden.

8. Aufgabendurchlauf mit dem Sprint Taskboard oder Kanban-Board steuern

Die Planung und der Durchlauf der einzelnen Aufgaben (Sprint-Tasks) wird mit einem Sprint-Taskboard für alle Projektmitglieder sichtbar. Das Taskboard kann in Form eines Kanban-Boards stärker untergliedert und verbessert werden. Das Kanban-Board macht anschaulich, in welcher Phase sich eine Sprint-Task oder ein Ticket gerade befindet. Es bildet die Wertschöpfungskette des Projekts ab.

Wichtig ist: Es werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können beispielsweise vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.

Abbildung 2 zeigt den Aufbau eines Kanban-Boards im Scrum-Projekt. An einer Wandtafel sind alle einzelnen Aufgaben bis zum nächsten Meilenstein auf Karten formuliert. Engpässe oder eilige Tickets können farblich markiert werden. So sind der Arbeitsablauf, der Stand der Arbeiten und die Engpässe für alle immer sichtbar.

9. Aufgaben erledigen

Im Sprint arbeiten die Teammitglieder an ihren Aufgaben (Sprint-Tasks). Die Projektmitarbeiter und Entwickler orientieren sich dabei an den Story Cards, mit deren Hilfe sie prüfen und testen können, ob sie eine gute Lösung entwickelt haben. Sie haben dafür den mit der Time Box definierten Zeitrahmen.

Die Teammitglieder haben deshalb den Zeitplan, den Aufwand und die Meilensteine im Blick, um im vereinbarten Zeitrahmen und Kostenrahmen zu bleiben. Die Story Points zeigen, wie viel Budget zur Verfügung steht.

10. Daily Scrum: Lösungen regelmäßig besprechen

Während eines täglichen, 15-minütigen Treffens, dem eigentlichen Daily Scrum (Gedränge), berichtet jeder der Reihe nach:

• Was wurde seit dem letzten Scrum gemacht?
• Was ist bis zum nächsten Scrum zu tun?
• Was behindert bei der Arbeit oder was verhindert die weitere Bearbeitung?

Die Probleme werden im Impediment Backlog festgehalten. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. Die Projektmitglieder können mit dem Arbeitsfortschritt erkennen, ob der geplante Zeitaufwand, wie er in den Story Points dargestellt ist, dem tatsächlichen Aufwand entspricht. Ungeplanter Aufwand und seine Ursachen werden beim Daily Scrum besprochen.

11. Plan- und Ist-Aufwand im Burn-Down-Chart darstellen

In einem Sprint-Burn-Down-Chart wird sichtbar gemacht, wie das Projekt voranschreitet. Dazu wird festgehalten, welche Ressourcen oder Arbeitszeiten bereits verbraucht wurden. Dieser Ist-Aufwand wird mit dem Plan-Aufwand verglichen und in einem Diagramm, dem Burn-Down-Chart bei Scrum, dargestellt.

Das Burn-Down-Chart ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt. Oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können diese sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden. Abbildung 3 zeigt, wie ein Burn-Down-Chart für einen Sprint aussehen kann.

12. Lösungen im Sprint-Review-Meeting als fertig abnehmen – nächste Schritte

Jeder Sprint wird durch ein Sprint-Review-Meeting abgeschlossen. Das Team stellt die Ergebnisse, das sogenannte Product Increment, dem Product Owner oder den Kunden und Anwendern vor. Sie müssen die Lösungen akzeptieren und abnehmen.

Dazu wird geprüft, ob das Teilergebnis aus diesem Sprint (Product Increment) der mit dem Product Backlog festgelegten Definition of Done entspricht. Falls der Product Owner nicht zufrieden ist, muss das Produkt verbessert werden. Es wird festgehalten, was nachbearbeitet werden muss.

Ist das Teilprodukt, das in diesem Sprint erstellt wurde, in Ordnung und vom Product Owner und den Anwendern oder Kunden abgenommen, werden die nächsten Aufgaben aus dem Product Backlog bearbeitet. Dabei wird wieder die grobe Beschreibung im Product Backlog geprüft und detailliert und für den nächsten Sprint eingeplant. Im Rahmen dieses Product-Backlog-Refinements kann sich auch herausstellen, dass einzelne Backlog-Items nicht mehr oder erst später gebraucht werden.

13. Scrum Velocity ermitteln

Mit jedem Sprint wird klar, wie schnell das Team im Projekt insgesamt vorankommt. Um diese Geschwindigkeit zu ermitteln, wird ein sogenanntes Velocity-Chart erstellt und nach jedem Sprint aktualisiert. Das hat zwei Zwecke:

• Das Team lernt, ob seine Einschätzungen zum Aufwand und zum Zeitablauf realistisch waren und ob Änderungen im Arbeitsablauf geholfen haben; damit wird das Sprint Planning (Schritt 7) genauer.
• Der Product Owner kann aus dem Velocity-Chart auch erkennen, bis wann er mit dem Projektabschluss und dem fertigen Produkt rechnen kann.

Im Velocity-Chart werden die Aufgaben aus dem Product Backlog, die komplett fertiggestellt sind, dem Sprint zugeordnet, in dem sie erledigt wurden. Die dazugehörenden Story Points werden addiert und kumuliert. So ergibt sich ein ähnliches Bild wie beim Burn-Down-Chart. Abbildung 4 zeigt ein Beispiel für ein Velocity-Chart.

14. Sprint-Retrospective durchführen

In gesonderten Treffen, der Sprint-Retrospective, können die Projektmitarbeiter ihre Zusammenarbeit im Team überprüfen. Sie besprechen und festhalten, was intern verbessert werden sollte, um die Projektziele gemäß Anforderung, Zeitplan und Kostenplan zu erreichen.

Anlässe für ein Sprint-Retrospective ergeben sich insbesondere dann, wenn Konflikte zwischen den Teammitgliedern oder auch zwischen Team und Product Owner entstanden sind oder wenn das Projekt nicht vorankommt. Im Rahmen dieser Meetings wird dann nach einer gemeinsamen und tragfähigen Lösung gesucht, sodass das Team weiterarbeiten kann und die Projektziele erreicht werden.

15. Projekt abschließen und Project-Review durchführen

Sind alle Sprints durchlaufen, wird das fertige Produkt an den Product Owner geliefert. Oder allgemein: Das Projekt kann abgeschlossen werden.

Der Product Owner prüft das Produkt und das Projektergebnis insgesamt vor dem Hintergrund der Anforderungen der Nutzer und der Kunden, wie sie mit den Story Cards formuliert wurden. Dabei werden Änderungen beachtet, die sich während der Projektlaufzeit ergeben haben. Außerdem wird berücksichtigt, welche Prioritäten zu Beginn das Projekts vereinbart und vergeben wurden.

Mit der Prüfung wird geklärt, welche Anforderungen, Merkmale und Funktionen des Produkts in diesem Projekt (doch nicht) bearbeitet wurden und welche Gründe das hatte. Sie werden gegebenenfalls erst in einem anschließenden Projekt bearbeitet.

Mit dem Projektabschluss kann ein Project-Review erfolgen. Hier werden alle Aspekte angesprochen, die die Zusammenarbeit erschwert oder den Prozess behindert haben. Daraus ergeben sich meistens Möglichkeiten, das nächste Scrum-Projekt besser zu machen.