Premium
Scrum

So läuft der Scrum-Prozess ab

Scrum läuft nach einfachen Regeln ab: Wenn die Anforderungen und Aufgaben für das Projekt geklärt sind, verteilen die Projektmitarbeiter alle Aufgaben in eigener Verantwortung. Sie treffen sich täglich, um den Projektfortschritt zu besprechen. Ist eine Arbeitsphase (Sprint) abgeschlossen, wird das Ergebnis überprüft. Die Projektmitarbeiter reflektieren dann auch, was gut und was schlecht läuft im Projekt.

Bei einem Scrum-Projekt läuft der Prozess der Aufgabenbearbeitung anders ab als beim klassischen Projektmanagement: Der Scrum-Prozess ist darauf ausgerichtet, die Anforderungen der Auftraggeber, der Nutzer, der Kunden und des Product Owners, möglichst korrekt zu erfassen und dann ohne großen Planungsaufwand zu bearbeiten. Wichtig ist, dass sich alle Projektmitarbeiter und der Scrum-Master intensiv austauschen und die Aufgaben nach klaren Regeln verteilt und zuverlässig bearbeitet werden. Das ist die Stärke von Scrum im Rahmen des agilen Projektmanagements.

Auslöser für den Start des Scrum-Projekts

Am Anfang steht eine Produkt-Vision. Das ist eine grobe Vorstellung vom Produkt oder Projektergebnis, das die Geschäftsleitung oder der Product Owner als Auftraggeber vorantreiben will. Anlass oder Auslöser eines solchen Projekts kann sein, dass die Anwender oder Kunden andere Anforderungen haben, dass es neue technische Möglichkeiten gibt oder dass sich eine gesetzliche Rahmenbedingung geändert hat, die nun umgesetzt werden muss. Letztlich wollen Geschäftsleitung und Product Owner ein Produkt oder ein Ergebnis, dass einen größeren Nutzen bringt. Mit diesem Auslöser startet ein Scrum-Projekt, in dem sich der Scrum-Master mit seinem Projektteam zusammenfindet. Das Scrum-Projekt muss dann mit den folgenden Schritten bearbeitet werden.

(1) Anforderungen für das Scrum-Projekt ermitteln und in Story Cards festhalten

Aus der ersten, aber möglichst schon anschaulichen und verständlichen Produkt-Vision oder der groben Produkt-Vorstellung lassen sich einzelne Funktionen und Merkmale des Produkts oder der Lösung ableiten, die im Projekt zu entwickeln sind. Diese Funktionen und Merkmale müssen zu den Anforderungen aus Kundensicht oder Nutzersicht passen. Deshalb müssen sie genau erfasst und dargestellt werden. Mit Scrum werden die Kunden- und Nutzeranforderungen in der Form sogenannter Story Cards formuliert. In solchen Story Cards beschreiben die Anwender eine Funktion oder ein Merkmal aus ihrer Anwenderperspektive und in ihren Worten – nicht im Jargon der Techniker. Die Anforderungen können im Gespräch oder in einem Workshop mit dem Product Owner und gegebenenfalls mit ausgewählten Nutzern oder Kunden erhoben werden.

Mit diesen Anforderungen wird bereits deutlich, welche Ressourcen das Projekt braucht. Die Ressourcen betreffen 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 mit Backlog-Items erarbeiten

Aus den Anforderungen des Product-Owners und der Nutzer oder Kunden 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 dann, 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.

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 100 Story Points ist doppelt so komplex und aufwendig wie ein Backlog-Item mit 50 Story Points. Wie viele Stunden Entwicklungsaufwand mit einem Story Point verbunden sind, ergibt sich aus der Erfahrung oder aus dem Projektverlauf.

(3) Prioritäten 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.

(4) Ablauf des Projekts planen

In einer ersten Besprechung des Scrum-Masters mit seinem Projektteam zum Projektablauf werden die Rahmenbedingungen abgesteckt und ein gemeinsames Verständnis von der Aufgabe oder dem Produkt sowie vom zeitlichen Ablauf hergestellt. Diese Fragen werden dazu besprochen:

  • Wo und wann kann sich das Team regelmäßig (täglich!) treffen?
  • Was sind die Teilziele für eine einzelne Funktion oder Aufgabe?
  • 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?
  • In welche Teilschritte, Sprints, lässt sich das Projekt untergliedern?
  • Auf welche Details oder Besonderheiten ist zu achten?
  • Welche Konventionen und Schnittstellen sind einzuhalten?

Ein wesentliches Merkmal von Scrum-Projekten ist, dass diese Ablaufplanung nur grob ist und kein großer Aufwand in die Detailplanung investiert wird; denn im Laufe des Projekts wird sich sowieso 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.

Die Feinplanung – soweit notwendig – erfolgt durch die selbstverantwortlichen Projektmitarbeiter, wenn sie sich an eine Teilaufgabe machen. Diese werden dann innerhalb sogenannter Sprints geplant und direkt 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.

(5) Einzelne Aufgaben bestimmen

Die Backlog-Items aus dem Product-Backlog werden nun in solche Einzel- oder Teilaufgaben und Maßnahmen zerlegt, die für die Bearbeitung und die Lösung notwendig sind; das sind bei Scrum die Sprint-Tasks oder auch Tickets. Diese Teilaufgaben werden im Sprint-Backlog (Maßnahmenplan) aufgeführt und am Sprint-Taskboard visualisiert. Das ist gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwickler-Team 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.

(6) Aufgabendurchlauf mit dem Sprint-Taskboard oder Kanban-Board steuern

Die Planung und der Durchlauf der einzelnen Aufgaben (Sprint-Tasks) kann mit einem Sprint-Taskboard oder einem Kanban-Board, das stärker untergliedert ist, verbessert werden. Beide Boards machen 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 vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.

Abbildung 1 zeigt den Aufbau eines Kanban-Boards im Scrum-Projekt. An einer Wandtafel sind alle einzelnen Aufgaben bis zum nächsten Meilenstein auf Karten formuliert. So sind der Arbeitsablauf, der Stand der Arbeiten und Engpässe für alle immer sichtbar.

Abbildung 1: Kanban-Board als detailliertes Sprint-Task-Board
Abbildung 1: Kanban-Board als detailliertes Sprint-Task-Board

(7) Aufgaben erledigen

Im Sprint arbeiten die Teammitglieder an ihren Aufgaben (Sprint-Tasks). Die Projektmitarbeiter 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. Außerdem haben Sie den Zeitplan, den Aufwand und die Meilensteine im Blick, um im vereinbarten Zeitrahmen und Kostenrahmen zu bleiben. Die Story Points geben einen Hinweis darauf, wie viel Budget zur Verfügung steht.

(8) Lösungen regelmäßig besprechen

Während eines täglichen, 15-minütigen Treffens, dem eigentlichen 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. In einem Sprint-Burndown-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 Burndown-Chart bei Scrum, dargestellt.

Das Burndown-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 2 zeigt, wie ein Burndown-Chart aussehen kann.

Abbildung 2: Burndown-Chart in der einfachen Variante
Abbildung 2: Burndown-Chart in der einfachen Variante

(9) Lösungen im Sprint-Review-Meeting als fertig abnehmen

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. 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.

In gesonderten Treffen, der Sprint-Retrospective, können die Projektmitarbeiter ihre Zusammenarbeit im Team überprüfen 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, so dass das Team weiterarbeiten kann und die Projektziele erreicht werden.

(10) Projekt abschließen

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 des Projekts vereinbart und vergeben wurden. Möglicherweise werden einzelne Anforderungen, Merkmale und Funktionen des Produkts erst in einem anschließenden Projekt bearbeitet.

Mit dem Projektabschluss kann ein Projekt-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.

Praxis

Anforderungen ermitteln, Story Cards schreiben

Stellen Sie die Anforderungen des Produkteigners und der Anwender und Kunden zusammen.

  • Führen Sie Gespräche mit den Kunden und Anwendern, in denen diese ihre Anforderungen an das Produkt, das von Ihnen entwickelt werden soll, oder an das Projektergebnis, das Sie herbeiführen sollen, benennen und erläutern.
  • Lassen Sie die Anwender oder Kunden für Ihr Produkt oder Projekt Story Cards schreiben. Das sind kurze Beschreibungen dessen, was das Produkt oder Projekt – aus Sicht der Anwender – leisten und können soll.
  • Diskutieren und reflektieren Sie die Anforderungen auf den Story Cards. Fragen Sie nach.

Die Story Cards sind immer in den Worten der Anwender und in ihren Bildern formuliert. Nutzen Sie das folgende Formular, um Ihre Anwender-Anforderungen zu ermitteln und in der Story Card zu beschreiben.

Product-Backlog mit Backlog-Items erstellen

Leiten Sie aus den User Storys auf den Story Cards und den einzelnen Anforderungen die Aufgaben für das Projekt oder die Funktionen und Merkmale des Produkts oder der Lösung ab, die Sie entwickeln sollen.

  • Beschreiben Sie kurz die Backlog-Items.
  • Stellen Sie den Zusammenhang dar zwischen Backlog-Item (Aufgabe, Funktion, Merkmal) und Anforderung der Kunden oder Anwender (User Story).

Komplexität und Aufwand schätzen und Story Points vergeben

Weisen Sie jedem Backlog-Item eine Priorität zu und vergeben Sie Story Points. Schätzen Sie dazu grob den Aufwand, der mit der Realisierung einer Funktion oder eines Merkmals verbunden ist.

Prioritäten klären

Verschaffen Sie sich Klarheit darüber, welche Priorität eine Anforderung der Anwender oder Kunden sowie die damit verknüpften Aufgaben, Funktionen und Merkmale (Backlog-Items) haben soll. Diese Prioritäten haben Sie gegebenenfalls schon bei der Ermittlung der Anforderungen mit den Anwendern ermittelt und in der Story Card dokumentiert. Sie können diese Einschätzung nun im Projektteam überprüfen. Fassen Sie diese Informationen in der folgenden Vorlage zusammen.

Things-That-Matter-Matrix

Eine Things-That-Matter-Matrix kann bei der Einschätzung der Prioritäten hilfreich sein. Hier zeigen Sie den Zusammenhang zwischen Aufgabe, Funktion, Merkmal (Backlog-Item) einerseits und Anforderung der Kunden oder Anwender andererseits. Dabei wird deutlich, welche Anforderung besonders aufwendig wird und mit welchem Backlog-Item Sie unterschiedliche Anforderungen gleichzeitig erfüllen können (Mehrfachverwendung).

In der folgenden Matrix können Sie zusätzlich den groben Aufwand zur Realisierung der Funktion angeben. Zur Schätzung des Aufwands wird einfach nach Größenklassen unterschieden – wie bei Kleidung: S, M, L für einen geringen, mittleren oder hohen Aufwand. So ergeben sich die einzelnen Prioritäten.

Backlog-Items in Teilaufgaben, Sprint-Tasks zerlegen und Maßnahmenplan erarbeiten

Zerlegen Sie die Backlog-Items in Teilaufgaben. Gehen Sie dabei nach Prioritäten vor; die wichtigsten zuerst. Die Teilaufgaben sind die Sprint-Tasks. Stellen Sie alle Sprint-Tasks im Sprint-Backlog zusammen. Das ist der Maßnahmenplan für Ihr Projektteam.

Halten Sie diesen Maßnahmenplan immer auf dem Laufenden. Planen Sie die gerade anstehenden Aufgaben und überprüfen Sie täglich, welche Aufgaben noch anstehen, welche gerade bearbeitet werden und welche abgeschlossen sind. Überprüfen Sie den Aufwand, der noch notwendig ist und vergleichen Sie ihn mit dem ursprünglich geplanten Aufwand.

Projekt über tägliche Besprechungen – Scrum – steuern

Visualisieren Sie den Arbeitsablauf und den Fortschritt im Projekt mit Hilfe eines Sprint-Taskboards. Nutzen Sie dazu die folgende Vorlage. Sie können die Projektphasen auch feiner gliedern und unterscheiden. Dies ist dann ein Kanban-Board für das Scrum-Projekt.

Klären Sie im täglichen Scrum den Stand des Projekts. Alle Teammitglieder berichten, was sie erreicht haben, was nun ansteht und was Probleme bereitet hat.

Burndown-Chart pflegen

  • Halten Sie bei den täglichen Sprint-Meetings (Scrum) den Projektaufwand im Burndown-Chart fest.
  • Identifizieren Sie Abweichungen.
  • Besprechen Sie, welche Gegenmaßnahmen eingeleitet werden können.

Die folgenden einfachen Diagramme machen für alle sichtbar, ob das Projekt im Zeit- und Kostenplan liegt. Im Diagramm wird „rückwärts gezählt“; nicht das verbrauchte Budget steht im Vordergrund, sondern das noch verfügbare. Das fördert die Motivation.

Sprint-Review-Meeting durchführen

Welche Hindernisse sind im Arbeitsablauf aufgetaucht? Wie können diese beseitigt werden? Halten Sie das Problem fest und sorgen Sie mit den Teammitgliedern dafür, dass es beseitigt wird. Wie kann das geschehen? Halten Sie Ihre Verbesserungsmaßnahmen in der folgenden Vorlage fest.

Premium
schließen
Weiterlesen und alle Vorlagen nutzen.
Premium-Mitgliedschaft

Als Premium-Mitglied haben Sie Zugriff auf das komplette Management-Handbuch:

  • über 150 Kapitel: von ABC-Analyse bis Zeitmanagement
  • über 1.800 Vorlagen, Checklisten, Excel-Tabellen zum Download
  • nur 57 EUR pro Jahr*
  • Ermäßigung für Studierende
Zur Anmeldung
Kapitel kaufen
Kaufen Sie das komplette Kapitel "Scrum" mit allen Vorlagen zum Preis von nur 9,80 EUR*.
Zum Shop

* Preis gültig in Deutschland. In anderen Ländern kann der Preis höher oder niedriger liegen.

Downloads
  • Excel-Vorlagen
    Vorlagen für Controlling, Kennzahlenmanagement, Berichtswesen und Projektmanagement
  • Key Account Management
    32 Seiten E-Book, 10 Excel-Tabellen, 6 Checklisten und 18 Vorlagen