Dr. Matthias Stephan · Zuletzt aktualisiert: 10. April 2023
Scrum ist ein agiles Framework, das geschaffen wurde, um Menschen und Teams eine Struktur zum Management von Projekt zu bieten, die sie in den Arbeitsprozess integrieren können. Das Ziel von Scrum ist es, klar abgegrenzte Arbeitspakete als Team in einem Zyklus von einem Monat oder weniger zu liefern. Kontinuierliches Experimentieren und die zugehörigen Feedbackschleifen tragen dazu bei, dass schrittweise ein Mehrwert generiert und dabei der Prozess im Team kontinuierlich verbessert wird. Das Framework ist flexibel genug, um es an die individuellen Bedürfnisse anzupassen.
Das Scrum-Framework wurde der Welt erstmals 1995 als bessere Möglichkeit der Zusammenarbeit vorgestellt und besteht aus drei Scrum-Rollen, fünf Events und drei Artefakten. Die Scrum-Rollen sind der Product Owner, der Scrum Master und das Entwicklerteam, die unter jeweils bestimmte Verantwortlichkeiten haben. Scrum basiert auf den zentralen Werten: Transparenz, Inspektion und Anpassung. Diese Konzepte treiben die iterative Arbeit voran. Durch das Verständnis und die Einhaltung dieses Frameworks können Teams eine Umgebung mit kontinuierlichen Anpassungen schaffen, so dass auf effiziente Weise mit jedem Sprint eine inkrementelle Verbesserung des Produkts bereitgestellt werden kann.
Die Werte von Scrum
Damit eine Einzelperson, ein Team oder eine Organisation die Vorteile von Scrum realisieren kann, sind strukturelle Komponenten des Scrum-Frameworks notwendig. Die Komponenten bilden ein sichtbares, logisches System von Scrum. Aber Menschen, die mit Scrum arbeiten, haben komplexe Überzeugungen und Werte, die ihr Verhalten beeinflussen. Somit sind die rein strukturellen Komponenten meist nicht ausreichend.
Um sicherzustellen, dass ein Team gut zusammenarbeitet, sollte es darüber hinaus fünf Scrum-Werte verkörpern:
- Engagement bedeutet, sich gemeinsam für gemeinsame Ziele einzusetzen und Taten folgen zu lassen.
- Mut bedeutet, nach Überzeugungen zu handeln, auch wenn es schwer fällt.
- Fokus ist ähnlich wie eine Familie, die sich um einen Herd versammelt, wobei jedes Mitglied seine Anstrengungen darauf verwendet, das gleiche Ziel zu erreichen.
- Offenheit bedeutet, über Schwierigkeiten bei der Durchführung der Arbeit transparent zu sein.
- Respekt bedeutet, andere mit ihren einzigartigen Fähigkeiten wahrzunehmen und ihnen zu vertrauen.
Durch das Leben der fünf Werte machen Scrum-Teams die Strukturen noch effektiver. Sie verleihen der Arbeit auch Sinn und Tiefe. Für den erfolgreichen Einsatz von Scrum brauchen die Menschen ein größeres Bewusstsein sowohl für die Intelligenz der Rahmenstrukturen als auch für die Intention der fünf Werte. Diese müssen vom Scrum-Team geprüft und angepasst werden.
Scrum-Rollen
Das Scrum Framework definiert drei Hauptrollen: Den Product Owner, das Entwicklungs-Team und den Scrum Master.
Der Product Owner ist dafür verantwortlich, dass das Team ein Produkt liefert, das den Mehrwert für den Kunden maximiert und mit den Geschäftszielen der Organisation übereinstimmt.
Das Team ist für die eigentliche Umsetzung des Produkts verantwortlich. Der Scrum Master führt durch den Scrum-Prozess und stellt als Moderator sicher, dass alle im Team den Scrum-Prozess befolgen.
Product Owner
Der Product Owner ist für den Erfolg eines Produkts und seiner Funktionen verantwortlich und wägt die Interessen der Stakeholder ab, und ist stets bestrebt, den Nutzen des Produkts zu maximieren. Er definiert die Produktanforderungen durch das Product Backlog, detailliert diese in Form von User Stories aus und priorisiert diese für das Entwicklerteam. Der Product Owner fungiert als Bindeglied zwischen den Stakeholdern und dem Entwicklungsteam und strebt nach einem ausgewogenen Verhältnis von Eigenschaften, Lieferzeiten und Kosten.
Scrum Master
Der Scrum Master spielt eine wesentliche Rolle dabei, sicherzustellen, dass Scrum effektiv funktioniert. Er achtet auf die Einhaltung des Sprint-Prozesses, identifiziert und vermeidet Störungen und stellt sicher, dass alle Beteiligten im Team zusammenarbeiten und kommunizieren.
Als Servant-Leader hilft der Scrum Master dem Entwicklungsteam, seine Ziele zu erreichen und bietet Orientierung und hilfreiche Ressourcen an. Der Scrum Master ist dafür verantwortlich, das Team bei Bedarf zu coachen und spricht Anerkennung für Beiträge zum Projekterfolg aus.
Entwickler-Team
Das Entwickler-Team ist für die Lieferung und Qualität des Produkts verantwortlich. Die Zusammensetzung des Teams sollte dies widerspiegeln. Jedes Mitglied muss sowohl über Spezialisten- als auch über Generalistenfähigkeiten verfügen, damit jeder als Experte einen Beitrag leisten und zugleich bei Bedarf andere Team-Mitglieder unterstützen kann.
Die Teamgröße sollte auf zehn Personen begrenzt sein, da darüber hinaus die Koordination erschwert wird. Das Schätzen des Product Backlogs in der Sprintplanung und das Aufteilen in Arbeitsschritte sind weitere Aufgaben des Scrum-Teams. Durch das Arbeiten in einem interdisziplinären Team wird ein möglicher Know-how-Mangel kompensiert und es erhöhen sich die Chancen, das Sprintziel zu erreichen.
Stakeholder
Stakeholder in Scrum sind alle Personen, die direkt oder indirekt an dem zu entwickelnden Produkt oder der zu entwickelnden Dienstleistung beteiligt, aber nicht Teil des Entwicklungsteams sind. Dies können Nutzer des Produkts, Kunden oder das Management des Unternehmens sein.
Der Product Owner hat die wichtige Aufgabe, die unterschiedlichen Meinungen und Anforderungen der Stakeholder zu sammeln und abzustimmen, um den maximalen Nutzen für das jeweilige Produkt zu erzielen. Indem er sich das Feedback aller Stakeholder anhört, kann der Product Owner fundierte Entscheidungen treffen. So kann er sicherstellen, dass das Produkt die Bedürfnisse der Zielgruppe erfüllt und gleichzeitig die Ziele des Unternehmens erreicht.
Sprint
Ein Sprint als ein wesentlicher Bestandteil von Scrum ist ein zeitlich begrenzter Zeitraum, in der Regel zwei bis vier Wochen. Während dieser Zeit wird an einer bestimmten Auswahl von Aufgaben gearbeitet, um ein für das Team gemeinsam gesetztes Ziel zu erreichen. Sinn und Zweck eines Sprints ist es, ein funktionierendes Produkt (Shippable Product) mit neuen Funktionen oder Verbesserungen zu liefern.
Zu Beginn des Sprints wird ein Sprint-Planungsmeeting (Sprint Planning) durchgeführt, um Ziele festzulegen und die Aufgaben zu planen, die das Team erfüllen muss.
Am Ende des Sprints findet ein Sprint Review und eine Retrospektive statt, um die abgeschlossene Arbeit zu überprüfen sowie internes Feedback zur Arbeitsweise im Team zu erhalten.
Scrum Events
Scrum-Events bieten wichtige Checkpoints während der Sprint-Phase und helfen dem Team, auf Kurs und synchron zu bleiben. Die Events unterstützen die Kommunikation und Zusammenarbeit, sodass das Team Ressourcen effektiv einsetzen kann, um seine Ziele zu erreichen.
Darüber hinaus stellen die Events sicher, dass Änderungen an der Strategie oder die Implementierung neuer Features zuerst evaluiert werden, bevor mit der Umsetzung begonnen wird.
Sprint Planning
Das Sprint Planning ist der erste Schritt in der Sprint-Iteration. Das Meeting bindet das gesamte Scrum Team ein und dient die Festlegung von Zielen und Aufgaben für den anstehenden Sprint. Das Team bewertet die Aufgaben, die zum Erreichen dieser Ziele erforderlich sind, und bespricht, wie es seine Zeit und Ressourcen effizient einsetzen kann. Das Sprint Planning dient insbesondere der Motivation und Selbstorganisation, bei der jeder Verantwortung für die übertragenen Aufgaben übernimmt.
Bevor der Sprint beginnt, ordnet der Product Owner die Liste der Items im Product Backlog von der höchsten zur niedrigsten Priorität. Der Sprint Backlog wird während des Product Backlog Refinement erstellt und angepasst. Gemeinsam bestimmen dann der Product Owner und das Entwicklungsteam die Akzeptanzkriterien für eine erfolgreiche Umsetzung eines Features. Dies wird für alle Product Backlog Items durchgeführt, die im zu planenden Sprint erfüllt werden sollen. Das Entwicklungsteam diskutiert im Detail mit dem Product Owner eventuelle Folgefragen, z.B. zur Architektur, dem Datenmodell und Schnittstellen. Im Sprint Planning wird final festgelegt, welche Aufgaben notwendig sind, um das Sprintziel zu erreichen. Diese Aufgaben werden abschließend ins Sprint Backlog aufgenommen.
Sprint Planning ist ein wichtiger Schritt im Scrum-Prozess, der dem Team hilft, die Ziele und Aufgaben für den kommenden Sprint zu definieren. Es ist ein Meeting, das alle Mitglieder des Scrum Teams involviert, und dient der Selbstorganisation und Motivation des Teams. Während des Sprint Plannings bewertet das Team die notwendigen Aufgaben, um die Sprintziele zu erreichen und optimiert den Einsatz seiner Ressourcen.
Daily Scrum
Zweck des Daily Scrum im Entwicklungsteam ist der Informationsaustausch während eines maximal 15-minütigen Meetings. Es hat sich bewährt, ein Taskboard zu verwenden, um zu berichten, was seit dem letzten Meeting erreicht wurde, was bis zum nächsten erledigt werden muss und ob es irgendwelche Hindernisse bei der Fertigstellung der Aufgaben gibt.
Wenn Aufgaben länger dauern als erwartet, kann es von Vorteil sein, sie in kleinere Aufgaben aufzuteilen, die andere Mitglieder des Teams übernehmen können. Sollten während des Daily Scrum Fragen auftauchen, die nicht innerhalb von 15 Minuten beantwortet werden können, können diese zur weiteren Diskussion notiert oder in einem zeitversetzt anschließenden Meeting beantwortet werden.
Sprint Review
Das Sprint Review ist der krönende Abschluss des Sprints in Scrum und dauert in der Regel maximal eine Stunde pro Sprint. Im Sprint Review werden die Ergebnisse vom Entwicklungsteam präsentiert, diskutiert und final überprüft, ob das zu Beginn des Sprints gesetzte Ziel erreicht wurde. Die aktive Beteiligung von Stakeholdern wie Kunden und Anwendern ist wichtig, um Feedback für die weitere Produktgestaltung zu erhalten.
Das Entwicklungsteam präsentiert seine Ergebnisse dem Product Owner und Stakeholder. Der Product Owner bewertet dann, ob die definierten Funktionalitäten akzeptiert werden können. Es ist ratsam, bei der Überprüfung der Ergebnisse Kompromisse nur in Ausnahmefällen einzugehen und alle fast fertigen, aber ungetesteten Funktionalitäten nicht hinzunehmen. Nach der Diskussion der Ergebnisse und der nächsten Schritte notiert der Product Owner das Feedback der Stakeholder. Dies wird in der nächsten Produkt-Backlog-Verfeinerung verwendet.
Sprint-Retrospektive
Die Sprint-Retrospektive ist ein reflektierender Prozess, der vom Scrum Master am Ende eines Sprints geleitet wird, um bewährte Praktiken und Verbesserungsbereiche für das Scrum-Team zu identifizieren. Dies sollte offen und ehrlich in einem geschützten Raum geschehen, zu dem Stakeholder nur auf Einladung eingeladen werden.
Zur Dokumentation und Planung von Verbesserungsmaßnahmen können verschiedene Techniken eingesetzt werden, wie z. B. die Stop-Start-Continue-Methodik.
Die Sprint-Retrospektive ist unerlässlich, um dem Scrum-Team dabei zu helfen, seinen Arbeitsablauf zu verstehen und zu verbessern.
Artefakte
Scrum-Artefakte sind die greifbaren, sichtbaren Elemente, die zur Verwaltung und Verfolgung des Fortschritts in einem Scrum-Projekt verwendet werden:
- Produkt-Backlog: Eine nach Prioritäten geordnete Liste von Features, User Stories und Anforderungen für das zu entwickelnde Produkt. Sie wird ständig weiterentwickelt und vom Product Owners priorisiert.
- Sprint Backlog: Eine Liste von Elementen aus dem Product Backlog, zu deren Fertigstellung sich das Team während des aktuellen Sprints verpflichtet. Es wird vom Entwicklungsteam verwaltet.
- Inkrement: Die Summe aller Product Backlog Items, die während eines Sprints fertiggestellt werden, sowie der Wert der Inkremente aller vorherigen Sprints. Es stellt die Entwicklung des Produkts dar.
- Burn-Down-Diagramm: Eine grafische Darstellung des im Sprint Backlog verbleibenden Arbeitsumfangs. Es wird verwendet, um den Fortschritt zu verfolgen und mögliche Probleme zu identifizieren.
Die Artefakte helfen dem Team, sich darauf zu konzentrieren, am Ende jedes Sprints ein potenziell veröffentlichungsfähiges Produktinkrement zu liefern. Damit wird der Fortschritt für alle Stakeholder sichtbar und das Team wird in die Lage versetzt, sich selbst zu organisieren und Entscheidungen darüber zu treffen, wie ein Inkrement erstellt werden soll.
Product Backlog
Das Product Backlog ist eine Liste von Anforderungen für ein Produkt, die vom Product Owner dynamisch aktualisiert und priorisiert wird. Anforderungen werden nach ihrem wirtschaftlichen Nutzen, Risiko und ihrer Notwendigkeit für die Entwicklung ausgewählt. Das Produkt-Backlog sollte User Stories enthalten, die gemäß der INVEST-Methode formuliert sind – Independent, Negotiable, Valuable, Estimable, Small and Testable.
Der Product Owner ist für die Reihenfolge und Priorisierung der Liste verantwortlich und trägt Sorge, sie auf dem neuesten Stand zu halten. Dadurch wird sichergestellt, dass die Arbeiten mit der höchsten Priorität zuerst abgeschlossen werden und das neue Produkt wertvoll und funktional korrekt ist.
Product Backlog Refinement
Das Product Backlog Refinement ist ein wesentlicher Prozess für den Product Owner und das Entwicklungsteam. Es umfasst das Organisieren, Löschen, Hinzufügen, Detaillieren, Zusammenfassen, Schätzen und Planen von Elementen.
Stakeholder können dem Scrum-Team wichtige Informationen zur Verfügung stellen, um das Produkt und das Product-Backlog zu gestalten.
Üblicherweise wird das Product Backlog Refinement in einem Meeting zwischen dem Product Owner, dem Scrum Team und den Stakeholdern durchgeführt. Die Verfeinerung des Product Backlogs sollte nicht mehr als 10 % der Zeit des Entwicklungsteams in Anspruch nehmen.
Sprint Backlog
Das Sprint Backlog ist ein wesentlicher Bestandteil von Scrum, einer agilen Projektmanagement-Methodik. Es ermöglicht Teams, den Fortschritt eines Arbeitssprints und die Aufgaben, die erledigt werden müssen, zu verfolgen.
Es liegt in der Verantwortung aller Teammitglieder, das Sprint Backlog zu aktualisieren, wenn sie Aufgaben erledigen, um sicherzustellen, dass alle Fortschritte sichtbar sind. Zur Vereinfachung wird häufig ein Task Board als visuelle Darstellung des Backlogs verwendet. Dieses Tool unterstützt das Team bei der Fertigstellung des Sprints, indem es die abgeschlossenen und verbleibenden Aufgaben darstellt.
Product Increment
Das Product Increment bezieht sich auf die Summe aller Product Backlog Items, die während des aktuellen Sprints und aller vorherigen Sprints abgeschlossen wurden. Es ist ein wichtiges Konzept innerhalb des Sprint-Prozesses.
Bei Scrum ist es entscheidend, dass das Produkt am Ende jedes Sprints in einem funktionierenden Zustand ist. Dabei wird sichergestellt, dass die Qualität der Arbeit ausreicht, und mit der Definition of Done die von festgelegten Erwartungen erfüllt werden.
Definition der Anforderungen für ein erfolgreiches Scrum-Projekt
Ein wichtiger Bestandteil eines erfolgreichen Scrum-Projekts ist es, die Anforderungen an das Projekt richtig zu ermitteln, zu erfassen und in User Stories und Story Cards zu definieren. User Stories stellen die Benutzerperspektive des Produkts dar, indem sie die Bedürfnisse, Aufgaben und Erwartungen der Benutzer beschreiben. Story Cards werden formuliert, um den Entwicklungsprozess zu ermöglichen und für die Präsentation gegenüber Kunden oder Benutzern. Anhand der Benutzeranforderungen wird bestimmt, was das Team entwickelt und welche Erwartungen der Kunde an das Produkt hat.
Die User Stories beschreiben die erforderlichen Funktionen für jedes Produkt. Story Cards werden verwendet, um eine Liste von Aufgaben zu formulieren, die zum Erstellen des Produkts verwendet werden. Die Story Cards enthalten Informationen zu den damit verbundenen Aufwänden. Um die Anforderungen zu ermitteln, müssen alle User Stories und Story Cards ermittelt und erfasst werden.
Scrum-Theory: Empirische Prozesssteuerung
Im Gegensatz zu einem umfassenden Prozess enthält Scrum bewusst nicht alle erforderlichen Schritte. Stattdessen bietet es Regeln und Komponenten, die in einer Reihe von Prozessen und Techniken angewendet werden können. Die Komponenten und Regeln müssen genau befolgt werden, um das Scrum-Framework zu verwenden. Das Ökosystem des Frameworks existiert nur in seiner Gesamtheit, wobei jeder Teil seinen eigenen Zweck hat.
Komplexe adaptive Probleme sind ein weiteres Konzept, das mit Scrum verbunden ist. Um sie zu verstehen, müssen wir ein Spektrum betrachten, das von einfachen, vorhersehbaren und statischen Problemen bis hin zu komplexen, unvorhersehbaren und adaptiven Problemen reicht. Probleme am ersten Ende erfordern normalerweise einen Plan, der aus detaillierten Schritten besteht. Dieser Plan kann mühelos angewendet werden, wenn das System vorhersehbar ist. Solche Techniken werden oft als definierte Prozesskontrolle bezeichnet, bei der jeder Schritt speziell geplant ist.
Unter Verwendung des Ansatzes der empirischen Prozesssteuerung ist Scrum ein leichtgewichtiges Framework, das einfach zu verstehen, aber schwer zu beherrschen ist. Es besteht aus mehreren Rollen, Ereignissen, Artefakten und Regeln, die für alle für die Ergebnisse Verantwortlichen sichtbar sind. Scrum nutzt Transparenz, Inspektion und Anpassung, um bei Bedarf Abweichungen zu erkennen und zu beheben. Die Inspektionshäufigkeit ist ausgewogen, um Störungen der Arbeit zu vermeiden, ohne die Wirksamkeit zu beeinträchtigen.
Wenn eine Anpassung erforderlich ist, erfolgt dies umgehend, um optimale Ergebnisse zu gewährleisten. Der Ansatz der empirischen Prozesskontrolle wird empfohlen, wenn die Mechanismen, nach denen ein Prozess funktioniert, nicht leicht zu verstehen sind.
Verweise
- Scrum-Projekt: Der Ablauf Schritt für Schritt | mit Beispielen
- Scrum – Wikipedia
- What is Scrum? | Scrum.org
- Clock Money Growth Grow Time (Bild-Quelle)
- Running Track Numbers Fog (Bild-Quelle)
- five person by table watching turned on white iMac (Bild-Quelle)
- Skillful students from the Department of Classical Archeology, Faculty of Arts, Trnava University in Trnava, document artifacts and process field documentation. (Bild-Quelle)
