Scrum einfach verstehen

Scrum ist das wohl bekannteste agile Framework oder Rahmenwerk welches ihren Ursprünglich in der Softwareentwicklung hat, sich jedoch inzwischen in vielen Branchen etabliert hat. In diesem Artikel werden wir das Framework detailliert erklären, die Grundlagen des Scrum-Projektmanagements beleuchten und die verschiedenen Rollen, Events und Artefakte von Scrum vorstellen. Wir gehen dabei auf wichtige Begriffe wie Scrum Master, Daily und das Scrum Board ein und gucken ob es einen Projektmanager gibt.

Was ist Scrum?

Scrum ist ein Framework für agiles Projektmanagement, welches Teams dabei hilft, komplexe Projekte zu organisieren und durchzuführen. Der Name „Scrum“ stammt aus dem Rugby, bedeutet „Gedränge“ und bezieht sich auf die enge Zusammenarbeit eines Teams, um ein gemeinsames Ziel zu erreichen.

In der Praxis bedeutet das, dass ein Team regelmäßig zusammenkommt, um den Fortschritt zu überprüfen, die nächsten Schritte zu planen und schnell auf Veränderungen zu reagieren.

Methode oder Framework

Scrum wird häufig fälschlicherweise als Methode bezeichnet. In Wirklichkeit handelt es sich hierbei allerdings um ein agiles Framework oder Rahmenwerk da es eine strukturierte Vorgehensweise mit spezifischen Rollen, Ereignissen (Events) und Artefakten bietet. Die Scrum Rollen, Events, Artefakte sowie die 5 Werte, etc. sind im Scrum Guide niedergeschrieben. Dieser Guide ist die Grundlage des bekannten Frameworks. In ihm stehen alle relevanten Informationen um Scrum anzuwenden und um zertifizierter Scrum Master zu werden. Mehr über den Guide erfährst du weiter unten. Ich möchte dir hier zunächst einen schnellen Start ermöglichen und dir die Grundlagen zeigen.

Anders als eine Methode, die flexible Prinzipien und Techniken bereitstellt, gibt ein Framework einen Rahmen vor, der strikt eingehalten werden sollte. Innerhalb dieses Rahmens können Teams dann flexibel agieren.

Scrum-Projektmanagement: Die Grundlagen

Scrum-Projektmanagement oder Produktmanagement ist ein Ansatz, bei dem Projekte in kleine, überschaubare Einheiten unterteilt werden, die in festen Zeitabschnitten (zum Beispiel 2 Wochen), sogenannten Sprints, bearbeitet werden. Ergebnis eines jeden Sprints ist ein Inkrement, ein Produkt welches vom Kunden getestet werden kann und in jedem Sprint weiter verbessert oder ergänzt wird. Die grundlegenden Prinzipien des Scrum-Projektmanagements basieren auf Transparenz, Überprüfung und Anpassung. Dies ermöglicht es Teams, regelmäßig Fortschritte zu überprüfen, Probleme frühzeitig zu erkennen und den Kurs bei Bedarf anzupassen.

Erfahre noch mehr über Scrum. In Kürze stehen tiefergehende Informationen für dich bereich. Trage dich in die Liste ein und du erhälst sie als Erster kostenlos.

Die Grundprinzipien vom Scrum-Projektmanagement

Es gibt drei zentrale Grundprinzipien oder empirische Säulen. Diese sind auch im Scrum Guide zu finden und heißen Transparenz (Transparency), Überprüfung (Inspection) und Anpassung (Adaption). Die drei Säulen sind fast schon selbsterklärend und sagen mit drei Wörtern aus worum es bei Scrum geht.

1. Transparenz: Alle Aspekte des Prozesses müssen für alle Teammitglieder sichtbar und verständlich sein. Dies wird durch tägliche Standup-Meetings (Daily Scrum), regelmäßige Reviews und die Nutzung von Artefakten wie dem Sprint Backlog erreicht. Besonders wichtig ist in Scrum auch eine offene Kommunikation nach innen und nach außen.
2. Überprüfung: Regelmäßige Überprüfungen des Fortschritts und der Arbeitsweisen sind ein weiterer zentraler Bestandteil. Dies geschieht in den verschiedenen Scrum-Events  wie dem Sprint Review und der Sprint Retrospektive.
3. Anpassung: Basierend auf den Überprüfungen (aus der vorherigen Säule) nimmt das Team kurzfristig Anpassungen am Prozess oder am Projekt vor um kontinuierlich zu optimieren und auf neue Erkenntnisse oder Veränderungen zu reagieren.

Die Rollen in Scrum

Wer denkt, dass bei selbstorganisierten Teams im agilen Projektmanagement Anarchie herrscht da es keinen klassischen Projektmanager gibt liegt falsch. Der Scrum-Guide definiert klare Rollen, die dafür sorgen, dass jeder im Team weiß, was von ihm erwartet wird und wie er zum Projekterfolg beitragen kann.

Rolle im Scrum-Team	Hauptaufgaben
Scrum Master	Scrum Prozess unterstützen
Product Owner	Produktvision
Developer	Umsetzung der Produktvision

Wer macht was?

Es gibt im Scrum-Team drei Rollen. Der Scrum Master unterstützt den Prozess, der Product Owner ist der der die Produktvision hat und hauptsächlich mit den Stakeholdern kommuniziert und die Developer setzen die Produktvision vom Product Owner um indem sie die Arbeit durchführen. Unter der Bild kannst du genauer sehen welche Funktion jede Rolle hat.

Der Scrum Master

Der Scrum Master spielt eine zentrale Rolle in diesem agilen Framework. Er ist dafür verantwortlich, den Scrum-Prozess zu leiten und sicherzustellen, dass das Team die Prinzipien und Praktiken einhält. Der Scrum Master ist kein traditioneller Projektmanager, sondern ist ein Servant Leader, der Hindernisse beseitigt, das Team unterstützt und dafür sorgt, dass alle Voraussetzungen für eine erfolgreiche Zusammenarbeit gegeben sind.

Aufgaben des Scrum Masters

• Coaching und Schulung: Der Scrum Master hilft dem Team, die Rollen, Events und Artefakte zu verstehen und richtig anzuwenden. Er bietet Schulungen an und unterstützt das Team bei der kontinuierlichen Verbesserung.
• Entfernung von Hindernissen: Der Scrum Master beseitigt alle Hindernisse (Inpediments), die den Fortschritt des Teams blockieren könnten. Dies könnte alles sein, von technischen Problemen bis hin zu internen Kommunikationsbarrieren.
• Förderung der Selbstorganisation: Der Scrum Master ermutigt das Team, selbstorganisiert zu arbeiten und eigenständig Entscheidungen zu treffen, die den Fortschritt fördern.

Zertifizierter Scrum Master

Ein zertifizierter Scrum Master ist jemand, der eine offizielle Zertifizierung einer anerkannten Organisation erhalten hat. Diese Zertifizierung stellt sicher, dass die Person über fundiertes Wissen und praktische Fähigkeiten im Umgang mit Scrum verfügt. Es gibt verschiedene anerkannte Zertifizierungsstellen, wie z. B. die Scrum Alliance oder Scrum.org, die Schulungen und Prüfungen anbieten. Die Prüfungen sind auf internationalem Niveau und werden auf Englisch angeboten. Die Zertifizierungsschulungen sind nicht nur für angehende Scrum-Master sondern auch für dessen Teammitglieder relevant da diese das Framework verstehen und anwenden müssen.

Vorteile einer ScrumMaster-Zertifizierung

• Anerkennung: Eine Zertifizierung zeigt potenziellen Arbeitgebern und Kollegen, dass du über das notwendige Wissen und die Fähigkeiten verfügst, um Scrum effektiv anzuwenden.
• Bessere Karrierechancen: Zertifizierte Scrum Master sind in der Regel gefragter, da Unternehmen die Vorteile eines gut geführten Scrum-Prozesses erkennen.
• Tieferes Verständnis: Der Zertifizierungsprozess hilft dir, ein tieferes Verständnis für die Prinzipien dieses agilen Frameworks zu entwickeln und zu lernen, wie du sie in verschiedenen Situationen anwenden kannst.

Product Owner

Der Product Owner ist meiner Meinung nach die wichtigste Rolle in Scrum. Er ist verantwortlich für das Produkt-Backlog, also die Liste der Anforderungen und Aufgaben, die im Projekt umgesetzt werden sollen. Der Product Owner stellt sicher, dass das Team an den wertvollsten Features arbeitet. Für ein Produkt darf es immer nur einen einzigen Product Owner geben. Er ist das Bindeglied zwischen den Kunden bzw. Stakeholdern und den Developern. Dies bedeutet jedoch nicht, dass die Stakeholder nicht auch direkt mit den Developern kommunizieren dürfen. Der Product Owner ist die einzige Person die einen Sprint vorzeitig beenden darf. Dies geschieht jedoch nur wenn dieser erkennt, dass das Ergebnis den laufenden Sprints obsolet geworden ist. Der Sprint wird dann beendet um kostbare Ressourcen zu schonen.

Von Product Ownern wird viel verlangt und sie tragen auch viel Verantwortung. Daher ist es wünschenswert das die Personen die diese Rolle innehaben zertifizierte Product Owner sind. Meistens sind sie auch gleichzeitig zertifizierte Scrum Master.

Das Entwicklungsteam

Das Entwicklungsteam besteht aus den Fachkräften oder Developern, die die eigentliche Arbeit erledigen. Es handelt sich dabei um ein selbstorganisiertes und interdisziplinäres Team, welches in Sprints zusammenarbeitet, um die festgelegten Aufgaben zu erledigen. Das Team ist verantwortlich für die Qualität der Arbeit und die Einhaltung der Sprint-Ziele. Das Team soll so aufgestellt sein, dass es alle Aufgaben eines Sprints ohne externe Hilfe meistern kann. Es soll möglich klein und flexibel sein, jedoch noch groß genug für die Erledigung aller Aufgaben. Dem Scrum Guide nach sollte das Team die Anzahl von 10 Personen nicht überschreiten.

Die Entwickler sind auch die einzigen Personen die den Aufwand von Aufgaben schätzen können (da sie ja auch diese Arbeit erledigen). Bei Rückfragen über das Ziel des Sprints oder von Aufgaben sprechen sie den Product Owner an. Bei Impediments, also Problemen die ihre Arbeit stören (zum Beispiel fehlendes technisches Material, Software, etc.) wenden sie sich an den Scrum Master.

Die Rolle des Projektmanagers im Scrum

Im Scrum-Framework gibt es keinen Projektmanager, wie man ihn aus dem klassischen Projektmanagement kennt. Die Aufgaben eines Projektmanagers sind hier auf die verschiedenen Rollen aufgeteilt:

• Scrum Master: Zuständig für den Scrum-Prozess und die Unterstützung des Teams.
• Product Owner: Verwalter des Product Backlogs und Verantwortlicher für die Produktvision und Priorisierung.
• Entwicklungsteam: Verantwortlich für die Durchführung der Arbeit und die Qualität des Ergebnisses.

Ein Projektmanager in einem Scrum-Kontext könnte sich daher auf andere Rollen konzentrieren oder seine Fähigkeiten in einer der Rollen einbringen, z. B. als Scrum Master oder Product Owner. Denkbar ist auch, dass ein Projektmanager einen Teil seines Projektes an ein Scrum Team abgibt. Dabei muss jedoch klargestellt sein, dass dieses Team selbständig und unabhängig agieren darf und der Projektmanager keine Weisungsbefugnisse über das Team hat.

5 Scrum-Events

Scrum beinhaltet eine 5 regelmäßig stattfindenden Ereignissen oder Events. Diese werden in Timeboxen, also festgelegten Zeitlängen abgehalten. Während dem sich bis zum Ende des Projektes oder Lebens des Produktes wiederholenden Sprints wird die eigentliche Arbeit am Produkt geleistet.

Während dem Sprint findet täglich eine kurze Besprechung statt in der die Developer sich gegenseitig über den aktuellen Stand der Arbeiten austauschen. Am Ende eines Sprints wird das Inkrement im Sprint Review den Stakeholdern vorgestellt. Anschließend findet die Retrospektive im Team statt um die Arbeitsweise des Teams zu analysieren. Vor dem Beginn des nächsten Sprints wird dieser im Sprint Planning Meeting geplant.

Sprint

Das ganze Projekt wird in kleine Sprints geteilt. Ein Sprint ist ein fester Zeitraum zwischen 1 und 4 Wochen während denen die Arbeiten am aktuellen Inkrement stattfinden. Alle Sprints in einem Projekt haben dieselbe Dauer. Während dem Sprint setzen die Developer alle Anforderungen aus dem Sprint Backlog ab, nehmen an den Meetings (Daily Scrum, Sprint Planning, Sprint Review und Retrospektive) teil und unterstützen den Product Owner nach Bedarf.

Daily Scrum: Das tägliche Stand-up-Meeting

Das Daily Scrum ist ein kurzes tägliches Meeting, das in der Regel 15 Minuten dauert und im stehen abgehalten wird. Es dient dazu, den aktuellen Stand der Arbeit zu besprechen, Hindernisse (Impediments) zu identifizieren und die nächsten Schritte zu planen. Grob kann gesagt werden, dass jedes Teammitglied drei Fragen beantworten sollte. Das kann jedoch auch variieren.

1. Was habe ich seit dem letzten Daily erledigt?
2. Was werde ich bis zum nächsten Daily tun?
3. Welche Hindernisse (Impediments) stehen mir im Weg?

Das Daily Scrum fördert die Transparenz und hilft dem Team, sich täglich zu synchronisieren.

Sprint Review

Am Ende jedes Sprints findet das Sprint Review statt. In diesem Meeting präsentiert das Team das Inkrement, also die abgeschlossene Arbeit und sammelt Feedback von den  Stakeholdern (zum Beispiel dem Kunden). Das Review bietet die Möglichkeit, die Arbeitsergebnisse zu präsentieren und den Fortschritt im Projekt zu bewerten. Das Sprint Review ist auch eine gute Möglichkeit um dem Team mehr Sichtbarkeit zu geben. Der Kunde und andere Stakeholder zum Beispiel Personen aus der eigenen Firma welche in anderen Abteilungen arbeiten erhalten die Möglichkeit das Team und seine Fähigkeiten kennen zu lernen.

Sprint Retrospektive

Die Sprint Retrospektive ist ein wichtiges Meeting, welches nach dem Sprint Review stattfindet. Hier reflektiert das Team den vergangenen Sprint und überlegt, was gut gelaufen ist und was verbessert werden kann. Ziel ist es, kontinuierlich den Prozess zu optimieren und das Team zu stärken. Es geht hier also nicht um das Produkt oder Inkrement sondern darum wie das Team zusammen arbeitet. Externe Gäste wie im Sprint Review gibt es in der Retrospektive nicht. Die Retrospektive soll ein geschützter Ort für das Team sein und was während dessen besprochen wird soll auch im Team bleiben.

Sprint Planning

Das Sprint Planning ist das Meeting, in dem der nächste Sprint geplant wird. Die Developer und der Product Owner besprechen die Aufgaben, die im nächsten Sprint erledigt werden sollen, schätzen den benötigten Aufwand und erstellen einen Plan, wie diese Aufgaben umgesetzt werden. Das Ziel ist es, einen klaren Sprint Backlog zu erstellen, der die Arbeit für den kommenden Sprint definiert. Um ein erfolgreiches Sprint Planning durchzuführen muss der Product Owner das Product Backlog zuvor gepflegt und aktualisiert haben.

3 Scrum-Artefakte

Die Scrum-Artefakte setzen sich aus zwei Werkzeugen oder Dokumenten und einem (Zwischen-)Produkt zusammen. Die drei Artfakte werden im Scrum Guide definiert. Ohne die Artefakte kann Scrum nicht funktionieren daher ist es wichtig sie zu kennen.   

Das Product Backlog

Das Product Backlog ist eine priorisierte Liste von Anforderungen und Aufgaben, die im Projekt umgesetzt werden sollen. Es wird vom Product Owner verwaltet und enthält alle Features, Bugs, technische Aufgaben und andere Arbeitselemente, die für das Produkt relevant sind. Das Product Backlog besteht aus Epics (allgemeine oder vage Ideen die sich im unteren Teil der Liste befinden), User Stories und Aufgaben (welche planungsreif sind da sie sehr detailliert sind). Um die konkreten Aufgaben detailliert zu definieren und um den notwendigen Aufwand zu schätzen ist der Product Owner auf die Hilfe der Developer angewiesen. Die Pflege des Product Backlogs findet kontinuierlich statt sobald sich neue Erkenntnisse ergeben.

Das Sprint Backlog

Das Sprint Backlog ist eine Auswahl der obersten Aufgaben aus dem Product Backlog, die das Team im aktuellen Sprint bearbeiten wird. Es wird während des Sprint Plannings vor dem nächsten Sprint erstellt und dient als Arbeitsplan für den kommenden Sprint. Die einzelnen Aufgaben können in Form von Karten dann auf ein Scrum Board geheftet werden damit jeder im Team sieht wie der aktuelle Stand ist.   

Inkrement

Das Inkrement ist das Endergebnis eines Sprints. Es handelt sich um ein fertiges Produktinkrement, welches potentiell auslieferbar ist und den Anforderungen des Product Owners und der Kunden bzw. Stakeholdern entspricht. Am Ende jedes Sprints sollte das Team ein solches Inkrement liefern können.
Das Inkrement ist ein Produkt welches vom Kunden benutzt werden könnte und alle vorhergegangenen Eigenschaften samt der neuen Eigenschaften aus dem aktuellen Sprint besitzt.

Soll zum Beispiel ein neues Navigationssystem programmiert werden kann zum Beispiel im 1. Sprint erst einmal eine Karte erstellt werden die im Endgerät angezeigt wird. Nach dem 2.  Sprint ist es möglich in dieser Karte einen Startpunkt und ein Ziel anzugeben und der Benutzer bekommt eine Route vorgeschlagen. Das Inkrement des 3. Sprints wurde um Sehenswürdigkeiten auf der Route ergänzt… Mit jedem Inkrement wächst das Produkt.

Das Scrum Board

Das Scrum Board ist kein offizielles Artefakt aus dem Scrum Guide hast sich aber in vielen Teams erfolgreich etabliert. Es ist eine Tafel auf der der Fortschritt aller Aufgaben des aktuellen Sprints verfolgt werden können. Es ist ein wichtiges und häufiges Werkzeug im Scrum-Projektmanagement. Das Scrum Board ist abgeleitet vom Kanban Board und besteht aus mehreren Spalten, die typischerweise die Phasen „To Do“, „In Progress“ und „Done“ repräsentieren.

Jede Aufgabe im Sprint wird als Karte auf dem ScrumBoard dargestellt und durchläuft diese Phasen. Das Board hilft dem Team, den Überblick zu behalten und schnell zu erkennen, wo es möglicherweise Engpässe gibt. Bei Bedarf können noch mehr Spalten wie zum Beispiel „Test“ hinzugefügt werden.

Aufbau eines Scrum Boards

• Spalten: Die typischen Spalten auf einem ScrumBoard sind „To Do“, „In Progress“ und „Done“. Je nach Bedarf können zusätzliche Spalten hinzugefügt werden, z.B. „Testing“ oder „Review“.
• Karten: Jede Aufgabe im Sprint wird durch eine Karte auf dem ScrumBoard repräsentiert. Diese Karte enthält wichtige Informationen wie die Beschreibung der Aufgabe, die verantwortliche Person und eventuell ein Fälligkeitsdatum.
• WIP-Limits: Um zu verhindern, dass zu viele Aufgaben gleichzeitig bearbeitet werden, können Work-In-Progress-Limits (WIP-Limits) festgelegt werden.

Das ScrumBoard sollte an einem zentralen Punkt hängen wo es vom ganzen Team zu jedem Zeitpunkt gesehen und aktualisiert werden kann. Am effektivsten ist es wenn das Daily Scrum vor dem ScrumBoard abgehalten wird.

Die 5 Werte von SCRUM

Im Scrum-Guide wurden 5 Scrum-Werte aufgezählt die ein Scrum-Team immer besser leben sollte damit um Scrum zum Erfolg zu führen. Die fünf Werte sind: Commitment, Fokus, Offenheit, Respekt und Mut.

• Commitment
• Fokus
• Offenheit
• Respekt
• Mut

Commitment

Das Commitment ist eine Selbstverpflichtung vom Team zur gegenseitigen Unterstützung und um gemeinsam dran zu Arbeiten die festgelegten Ziele zu erreichen. Dies ist besonders wichtig da es sich hier um selbstorganisierte Teams handelt die selbständig entscheiden wer, wie, welche Arbeiten verrichtet. Ein Zusammenhalt ist hier besonders wichtig. Alle ziehen an einem Strang.

Fokus

Die ganze Konzentration des Teams liegt auf der Arbeit die innerhalb eines Sprints erledigt werden muss um den bestmöglichen Fortschritt zu erreichen um am Ende jedes Sprints ein potentiell auslieferbares Inkrement zu liefern. Daher sollen die Teammitglieder nach Möglichkeit keine weiteren Tätigkeiten innerhalb der Firma wahrnehmen müssen wenn diese nicht zum aktuellen Projekt gehören. Im Notfall muss der Scrum Master sich einschalten und sowohl den Teammitgliedern als auch den Externen (zum Beispiel ein Vorgesetzter der einen Mitarbeiter für andere Tätigkeiten teilweise abziehen möchte) die Wichtigkeit erklären, wo der Fokus liegt.

Offenheit

Sowohl die Teammitglieder als auch die Stakeholder sind offen für die Arbeit und die Herausforderungen die diese mit sich bringen. So muss das Team auch offen für Veränderungen sein. Im Sinne der kontinuierlichen Verbesserung werden Änderungen und Kundenwünsche gerne bearbeitet um das bestmögliche Produkt zu erstellen. Es wird auch offen und transparent miteinander Kommuniziert. 

Respekt

Das Team ist interdisziplinär aufgebaut und respektiert sich gegenseitig als fähige Personen. Sie werden als solche auch von denen Respektiert mit denen sie zusammenarbeiten. Ein Product Owner sollte zudem im Sprint Review das Team das Inkrement vor den Kunden und Stakeholdern präsentieren lassen damit die Teammitglieder das Lob und den Respekt der Externen bekommen.

Mut

Die Scrum-Mitglieder haben den Mut das Richtige zu tun und schwierige Probleme zu lösen. Sie sie interdisziplinär aufgestellt sind sind sie Experten auf ihrem Gebiet. Die Developer bekommen nicht vom Product Owner gesagt wie sie etwas machen sollen. Das entscheiden die Developer alleine.

Das Team lernt im Verlauf der Zeit diese 5 Scrum Werte zu leben. Der Scrum-Master kann dabei eine große Unterstützung sein. Je besser das Team die Werte lebt, desto besser wird auch der Zusammenhalt, angenehmer die Arbeit im Team und besser die Kommunikation mit den Stakeholdern.

Vor- und Nachteile von Scrum

Du weißt nung, das dies ein mächtiges agiles Framework ist welches in vielen Bereichen nicht mehr wegzudenken ist. Es erfreut sich dank seiner Vorteile großer Beliebtheit doch es ist nicht für alle Projekte geeignet. Denn wo es Vorteile gibt gibt es natürlich auch Nachteile. Das klassische Projektmanagement hat noch lange nicht ausgedient und es muss für jede Firma, jedes Produkt und Projekt abgewogen werden wo die Vorteile überwiegen und ob ein agiler Ansatz mit Scrum im einzelnen Fall die richtige Entscheidung ist. Nach der kurzen Gegenüberstellung der Vor- und Nachteile werden diese auch unten kurz erläutert.

Pro	Kontra
Flexibilität und Anpassungsfähigkeit	Anfangsschwierigkeiten
Fokus auf den Kunden	Erfordert diszipliniertes Team
Förderung von Teamarbeit	Hohe Anforderungen an den Product Owner
Kontinuierliche Verbesserung	Nicht immer gut für große Projekte
Transparenz
Motivation und Eigenverantwortung

Vorteile von Scrum 

Als agiles Framework ist die Flexibilität und Agilität natürlich eng in Scrums DNA verwurzelt. Dank den relativ kurzen Sprints und dem regelmäßigem Feedback von Kunden kann das Scrum-Team schnell auf Veränderungen, neue Anforderungen und auf Kundenwünsche reagieren. So erhält der Kunde stetig die Produktanpassungen welche er benötigt. Auch der Kunde lernt in jeder Iteration was er wirklich benötigt. An der Lösung der Probleme arbeitet das ganze Team gemeinschaftlich. Die Kommunikation im Team wird durch kurze tägliche Stand-Up-Meetings sowie der Retrospective gefördert.

Durch diese regelmäßigen Events findet eine kontinuierliche Verbesserung, nicht nur des zu erstellenden Produktes, sondern auch der Zusammenarbeit im Team statt. Dabei wird ein offener und transparenter Umgang gefördert. Was zum Beispiel im Team während der Retrospective besprochen wird bleibt im Team und wird nicht nach außen getragen. Dieser offene Umgang und das selbständige Arbeiten des Teams führt zu mehr Eigenverantwortung und dadurch auch zu einer besseren Motivation des Teams.   

Nachteile von Scrum

Auch die Nachteile müssen beachtet werden um ein Projekt zum Erfolg zu führen und um unnötige Fehler zu vermeiden. Scrum und agiles Projektmanagement ist nicht die Lösung aller Probleme auch wenn es bei sehr vielen helfen kann. Die wohl größte Hürde sind die Anfangsschwierigkeiten für ein neues Team oder evtl. noch viel vorher wenn Vorgesetzte aus der klassischen Projektmanagement-Welt für agiles Arbeiten begeistert werden sollen. Es gibt bei vielen Vertretern des klassischen Projektmanagement noch einige Bedenken oder Vorurteile was agiles Projektmanagement betrifft da es für sie eine große Unbekannte darstellt. Da das Scrum-Team selbstorganisiert arbeitet muss das ganze Team diszipliniert sein und selbstverantwortlich arbeiten. Es wird einem Developer nicht wie beim klassischen Projektmanagement aus einer höheren hierarchischen Ebene Arbeit an zugewiesen.

Einen Teil der Arbeit des klassischen Projektmanagers übernimmt der Product Owner an den hohe Anforderungen gestellt werden. Er begleitet im Idealfall das Produkt von der Entstehung bis während des gesamten Lebenszyklus und versucht dabei das bestmögliche Produkt mit seinem Team im Interesse des Kunden zu erstellen.   
Da in Scrum in realtiv kleinen Teams von 10 oder weniger Personen gearbeitet wird kann es schwierig werden größere und aufwendigere Projekte zu meistern. Das Team soll klein sein damit es agil und flexibel ist aber groß genug um innerhalb eines Sprints die festgelegten Arbeiten aus dem Sprint Backlog selbständig und ohne externe Hilfe zu erledigen. Bei größeren Projekten muss auf andere Frameworks zurückgegriffen werden. Manche können auf Scrum basieren (wie zum Beispiel Nexus). 

Scrum Guide

Über den Scrum Guide wurde im Internet schon viel geschrieben. Es beinhaltet die Regeln des Rahmenwerkes bzw. Frameworks. Es wurde so geschrieben, dass in ihm das absolute Minimum zu finden ist. Es sind all die Sachen die unbedingt eingehalten werden müssen damit das agile Framework erfolgreich werden kann. Jeder Scrum Master kann nach Belieben weitere Methoden hinzufügen, sollte jedoch keine Rollen, Artefakte oder Events aus dem Scrum Guide streichen oder abändern. Nach den Autoren des Guides muss dieses Minimum an Anforderungen gegeben sein um erfolgreich als Team zu sein.

Die Autoren des Scrum Guides sind Ken Schwaber und Jeff Sutherland. Wenn du dich schon in der agilen Welt bewegst hast du bestimmt schon von ihnen gehört. Beide gehören auch zu den Autoren des Agilen Manifestes bzw. dem Manifest für Agile Softwareentwicklung in denen auch die Werte der agilen Arbeit und die Prinzipien aufgezählt werden. Das agile Framework wurde schon Anfang der 90er Jahre entwickelt. Der Guide wurde von Schwaber und Sutherland erst Jahre später in 2010 geschrieben. Die aktuelle Version des Scrum Guides stammt aus dem Jahr 2020.

Der Guide beinhaltet die Scrum-Werte, das Team mit ihren 3 Rollen Developer, Product Owner und Scrum Master, die 5 Events Sprint, Sprint Planning, Daily Scrum, Sprint Review und die Sprint Retrospective, die drei Artefakte Product Backlog, Sprint Backlog und das Increment.

Alle Informationen aus dem Guide sind wortwörtlich zu nehmen. Die Prüfungen zum Scrum Master und Product Owner basieren auf dem Scrum Guide (abgesehen von ein paar praktischen Fragen aus dem realen Projektgeschäft).

Jeder der in einem Scrum Team arbeitet sollte sich den Guide ausführlich und ganz in Ruhe durchgelesen und verstanden haben. Den Guide kannst du dir kostenlos auf der offiziellen Seite auch auf Deutsch runterladen. 

Wichtige Werkzeuge

Abgesehen vom oben erklärten Scrumboard gibt es noch weitere wichtige Werkzeuge. Diese sind durch den Scrum Guide zwar nicht explizit gefordert, können vom agilen Team jedoch verwendet werden um noch besser agil zu arbeiten. Zwei der wichtigsten oder bekanntsten Werkzeuge sind das Burn-Down-Chart und Planning-Poker.

Burn-Down-Chart

Das Burn-Down-Chart ist ein wichtiges Werkzeug welches oft in Scrum verwendet wird um Fortschritt des Sprints zu verfolgen und vorherzusagen. Weitere Werkzeuge die verwendet werden können sind das Burn-Up-Chart und das Cumulative-Flow-Diagramm. Beim Burn-Down-Chart handelt es sich um eine Grafik mit zwei Achsen.

Die x-Achse, die horizontale, zeigt den Zeitverlauf bis zum Ende des Sprints. Die y-Achse, die vertikale, zeigt anfangs die Gesamte und danach die Restarbeit die bis zum Ende des Sprints erledigt werden muss. Die Linie mit der Restarbeit erstreckt sich somit von links oben (Zeit-Anfang und viel zu erledigende Arbeit) bis rechts unten (Zeit-Ende und keine Arbeit mehr zu erledigen). Eine gerade Verbindungslinie zwischen dem ersten und dem letzten Punkt repräsentiert die Ideallinie. Befinden sich die Punkte der Restarbeit oberhalb der Ideallinie bedeutet das, dass das Team hinter dem Zeitplan liegt. Wenn sich die Punkte der Restarbeit unterhalb der Ideallinie befinden bedeutet das, dass das Team dem Zeitplan voraus ist.

Die zu erledigende Arbeit auf der y-Achse wird in „Story-Points“ gemessen und ist die Summe aller Story-Point der zu erledigende Arbeiten aus dem Sprint-Backlog. Die Anzahl der Story-Point wurde im Sprint-Planning von den Developern geschätzt. Um diese zu schätzen können sie auf Verschiedene Methoden und Hilfsmittel zurückgreifen wie zum Beispiel dem Planning-Poker.

Planning-Poker

Das Planning-Poker ist nur eine von verschiedenen Schätzmethoden in agilen Projekten. Hierbei erhalten die Developer jeweils ein Kartendeck mit verschieden gewichteten Karten. Oft folgen Sie der Fibonacci-Reihe. In dem Fall ergibt sich eine Karte aus der Summe der Werte der zwei vorherigen Zahlen (0, 1, 2, 3, 5, 8, 13, etc.). Beim Planning-Poker gibt es allerdings noch den Wert ½ und nach oben hin (meistens ab der 20) wird die Fibonacci-Reihe verlassen und die Werte wachsen noch schneller. (0, ½, 1, 2, 3, 8, 13, 20, 40, 100, Unendlich, Fragezeichen und Kaffetasse). Die Kaffetasse steht dann selbstsprechend für eine benötigte Pause.

Bei der Schätzung einer Aufgabe hebt jeder Developer eine Karte hoch mit seinem Schätzwert. Nun kann entweder direkt im ganzen Team diskutiert werden oder, die beiden Developer die den höchsten und den niedrigsten Wert geschätzt haben argumentieren über ihre Wahl. Nach der Diskussion kann das Team erneut Schätzungen abgeben und sich so annähern. Im Anschluss kann die Liste der Arbeiten um ihre Story-Points erweitert werden.

Fazit

Scrum ist ein mächtiges Framework, das Teams hilft, komplexe Projekte effizient zu managen und flexibel auf Veränderungen zu reagieren. Durch die klare Struktur und die definierten Rollen ermöglicht Scrum eine transparente und kollaborative Arbeitsweise, die sich in vielen Branchen bewährt hat. Egal, ob du in der Softwareentwicklung, im Marketing oder in einer anderen Branche tätig bist – Scrum kann dir die Werkzeuge und Prinzipien bieten, die du benötigst, um dein Projekt erfolgreich zu managen.

Durch das Verständnis von Scrum als Framework, den Rollen wie dem Scrum Master, dem Einsatz von Scrum Boards und der Teilnahme an regelmäßigen Meetings wie dem Daily Scrum kannst du die Grundlagen dieses Framewoks erlernen und anwenden. Die Möglichkeit, sich als zertifizierter Scrum Master zu qualifizieren, bietet zudem eine ausgezeichnete Gelegenheit, dein Wissen zu vertiefen und deine Karrierechancen zu verbessern.

Erfahre noch mehr über Scrum. In Kürze stehen tiefergehende Informationen für dich bereich. Trage dich in die Liste ein und du erhälst sie als Erster kostenlos.