Scrum – Eine Einführung

Einführung

Scrum ist ein Produktentwicklungsframework, das ursprünglich in der Softwareentwicklung eingeführt wurde, aber auch in anderen Branchen Anwendung findet. Das Hauptziel von Scrum ist es, die Zusammenarbeit, Kommunikation und Flexibilität innerhalb eines Teams zu fördern, um schnell auf Änderungen reagieren und hochwertige Produkte oder Lösungen liefern zu können.

Scrum basiert auf der Arbeit in kleinen, iterativen Schritten, sogenannten „Sprints“, die normalerweise zwei bis vier Wochen dauern. Jeder Sprint hat ein definiertes Ziel, und das Team arbeitet gemeinsam daran, dieses Ziel zu erreichen. Am Ende eines Sprints findet eine Überprüfung statt, in der das Team die im Sprint erreichten Ergebnisse präsentiert und Feedback von Stakeholdern und Kunden einholt.

Es gibt drei Hauptrollen in einem Scrum-Team:

1. Product Owner: Der Product Owner ist verantwortlich für die Definition der Produktvision und -prioritäten. Er oder sie verwaltet und pflegt das „Product Backlog“, eine Liste von Anforderungen und Funktionen, die in das Produkt aufgenommen werden sollen.

2. Scrum Master: Der Scrum Master ist dafür verantwortlich, dass das Team die Scrum-Prinzipien und -Praktiken einhält. Er oder sie unterstützt das Team bei der Selbstorganisation, beseitigt Hindernisse und sorgt dafür, dass die Zusammenarbeit effektiv und effizient verläuft.

3. Entwickler: Die Entwickler sind die Fachleuten, die gemeinsam daran arbeiten, die im Product Backlog definierten Anforderungen in jedem Sprint umzusetzen.

Zusätzlich zu diesen Rollen gibt es verschiedene Artefakte und Veranstaltungen, die Teil des Scrum-Frameworks sind, wie z.B. das Product Backlog, das Sprint Backlog, die Daily Stand-Ups und die Sprint Retrospektive.

Die Entstehung von Scrum

Scrum entstand in den frühen 1990er Jahren als Reaktion auf die Unzulänglichkeiten traditioneller Projektmanagementmethoden, insbesondere im Bereich der Softwareentwicklung. Die Schöpfer von Scrum, Ken Schwaber und Jeff Sutherland, waren auf der Suche nach einem Ansatz, der Flexibilität und Anpassungsfähigkeit an sich ständig ändernde Anforderungen bietet.

Der Begriff „Scrum“ stammt aus einem Artikel, der 1986 von Hirotaka Takeuchi und Ikujiro Nonaka im „Harvard Business Review“ mit dem Titel „The New New Product Development Game“ veröffentlicht wurde. In diesem Artikel beschrieben die Autoren erfolgreiche Produktentwicklungsteams als solche, die in einem hochkommunikativen, inkrementellen und iterativen Ansatz arbeiten, ähnlich wie ein Rugby-Team in einem Scrum während eines Spiels.

Schwaber und Sutherland griffen diese Ideen auf und entwickelten daraus das Scrum-Framework. Sie stellten Scrum erstmals 1995 auf der OOPSLA-Konferenz (Object-Oriented Programming, Systems, Languages & Applications) vor. In den folgenden Jahren wurde Scrum weiterentwickelt und verfeinert, und es wurde zunehmend in der Softwareentwicklung und darüber hinaus eingesetzt.

2001 trugen Schwaber und Sutherland zur Entwicklung des „Agile Manifesto“ bei, einer Sammlung von Prinzipien und Werten, die den agilen Ansatz zur Softwareentwicklung fördern. Dieses Manifest bildet die Grundlage für verschiedene agile Methoden, einschließlich Scrum.

In den Jahren seit der Einführung von Scrum hat sich das Framework weiterentwickelt und ist zu einem der am häufigsten verwendeten agilen Ansätze in der Softwareentwicklung und in vielen anderen Branchen geworden. Scrum hat dazu beigetragen, die Art und Weise, wie Teams zusammenarbeiten und Produkte entwickeln, grundlegend zu verändern und bietet einen flexiblen, anpassungsfähigen Ansatz, der sich gut für komplexe Projekte eignet.

Die Verantwortlichkeiten und Rollen innerhalb des Scrum-Frameworks

Im Scrum-Framework gibt es drei zentrale Rollen: Product Owner, Scrum Master und Entwicklungsteam. Jede Rolle hat spezifische Verantwortlichkeiten, die dazu beitragen, ein effektives und effizientes Arbeitsumfeld zu schaffen. Hier sind die Hauptverantwortlichkeiten jeder Rolle:

Product Owner:

• Definiert und kommuniziert die Produktvision und -ziele.
• Erstellt und pflegt das Product Backlog, eine Liste von Anforderungen, Funktionen und Verbesserungen für das Produkt.
• Priorisiert die Elemente im Product Backlog basierend auf Geschäftswert, Kundenbedürfnissen und technischen Aspekten.
• Arbeitet eng mit dem Entwicklungsteam und dem Scrum Master zusammen, um sicherzustellen, dass die Anforderungen klar verstanden werden.
• Nimmt an Scrum-Meetings wie Sprint Planning, Review und Retrospektiven teil.
• Stellt sicher, dass das Entwicklungsteam während des Sprints Feedback erhält und auf Kundenanforderungen reagiert.

Scrum Master:

• Fördert und unterstützt die Anwendung der Scrum-Prinzipien und -Praktiken im Team.
• Coacht das Team in Selbstorganisation und Zusammenarbeit.
• Beseitigt Hindernisse und Blockaden, die die Fortschritte des Teams beeinträchtigen könnten.
• Arbeitet mit dem Product Owner zusammen, um das Product Backlog zu verwalten und für das Team verständlich zu gestalten.
• Organisiert und moderiert Scrum-Meetings wie Daily Stand-ups, Sprint Planning, Sprint Review und Retrospektiven.
• Stellt sicher, dass das Team kontinuierlich lernt und sich verbessert.

Entwickler:

• Entwickler sind die Fachleuten, die die notwendigen Fähigkeiten besitzen, um die Anforderungen des Product Backlogs umzusetzen (z. B. Softwareentwickler, Tester, Designer).
• Arbeiten selbstorganisiert und gemeinsam daran, die im Sprint Backlog definierten Elemente zu implementieren.
• Schätzten den Arbeitsaufwand für die Umsetzung von Backlog-Elementen und hilft bei der Planung des Sprints.
• Treffen technische Entscheidungen und organisiert die Arbeit innerhalb des Teams.
• Nehmen an Scrum-Meetings wie Daily Stand-ups, Sprint Planning, Review und Retrospektiven teil.
• Kommunizieren Fortschritte, Probleme und Hindernisse regelmäßig an den Scrum Master und den Product Owner.

Obwohl diese Rollen spezifische Verantwortlichkeiten haben, ist es wichtig zu betonen, dass Scrum auf Zusammenarbeit und gemeinsamen Entscheidungen basiert. Alle Teammitglieder sollten aktiv an Diskussionen und Entscheidungsprozessen teilnehmen, um ein erfolgreiches Ergebnis zu gewährleisten.

Scrum und seine Stakeholder

In Scrum sind Stakeholder Personen oder Gruppen, die ein Interesse am Ergebnis eines Projekts oder Produkts haben und von dessen Erfolg oder Misserfolg betroffen sein können. Sie sind nicht direkt Teil des Scrum-Teams, das aus dem Product Owner, Scrum Master und Entwicklungsteam besteht, aber ihre Bedürfnisse und Erwartungen beeinflussen die Arbeit des Teams. Zu den Stakeholdern in Scrum können folgende Gruppen gehören:

• Kunden: Diejenigen, die das Produkt oder die Lösung nutzen oder kaufen werden. Sie haben ein starkes Interesse daran, dass das Produkt ihren Bedürfnissen und Anforderungen entspricht.
• Endbenutzer: Die Personen, die das Produkt tatsächlich verwenden werden. Sie sind daran interessiert, dass das Produkt benutzerfreundlich, funktional und effizient ist.
• Geschäftsleitung: Führungskräfte oder Manager, die die strategische Ausrichtung des Projekts oder Produkts steuern und die Ressourcen bereitstellen, die das Scrum-Team benötigt. Sie sind an den finanziellen und geschäftlichen Ergebnissen des Projekts interessiert.
• Projekt- oder Programmmanager: Personen, die für die Gesamtleitung und Koordination mehrerer Projekte oder Programme verantwortlich sind, von denen das Scrum-Projekt möglicherweise ein Teil ist.
• Interne Abteilungen: Andere Abteilungen innerhalb der Organisation, wie Marketing, Vertrieb, Support, Finanzen oder Recht, die von den Ergebnissen des Projekts betroffen sein könnten oder deren Arbeit das Projekt beeinflussen kann.
• Lieferanten und Partner: Externe Unternehmen oder Einzelpersonen, die Produkte oder Dienstleistungen liefern, die für das Projekt erforderlich sind oder die mit dem Projekt zusammenarbeiten.
• Regulierungsbehörden: Behörden oder Organisationen, die für die Einhaltung gesetzlicher oder regulatorischer Anforderungen im Zusammenhang mit dem Produkt oder Projekt verantwortlich sind.

Das Scrum-Team sollte aktiv mit Stakeholdern zusammenarbeiten und regelmäßig Feedback von ihnen einholen, um sicherzustellen, dass ihre Bedürfnisse und Anforderungen berücksichtigt werden. Dies kann durch formelle oder informelle Kommunikationswege sowie durch Veranstaltungen wie Sprint Reviews geschehen, bei denen Stakeholder die Möglichkeit haben, den Fortschritt des Teams zu bewerten und Feedback zu geben.

Der Sprint als zentrales Element in Scrum

Ein Sprint ist ein zentraler Bestandteil des Scrum-Frameworks und bezieht sich auf einen festgelegten Zeitraum, in dem das Scrum-Team an der Umsetzung eines bestimmten Ziels oder einer bestimmten Anzahl von Aufgaben aus dem Product Backlog arbeitet. Sprints sind iterativ und inkrementell, was bedeutet, dass das Team in jedem Sprint auf dem aufbaut, was in den vorherigen Sprints erreicht wurde.

Die Dauer eines Sprints beträgt in der Regel zwei bis vier Wochen, kann aber je nach Projekt und Team variieren. Während eines Sprints konzentriert sich das Team darauf, die im Sprint Backlog enthaltenen Aufgaben abzuschließen, um das für den Sprint festgelegte Ziel zu erreichen.

Ein Sprint beinhaltet mehrere Aktivitäten und Events:

• Sprint Planning: Zu Beginn eines Sprints trifft sich das gesamte Scrum-Team, um den Umfang und die Ziele des Sprints festzulegen. Hierbei werden die höchstpriorisierten Elemente aus dem Product Backlog ausgewählt und in das Sprint Backlog übertragen. Das Team schätzt die Arbeitsaufwände und legt fest, welche Elemente im Sprint abgeschlossen werden können.
• Daily Stand-up: Während des Sprints trifft sich das Team täglich für ein kurzes Status-Meeting, das als Daily Stand-up oder Daily Scrum bezeichnet wird. In diesem Meeting informieren sich die Teammitglieder gegenseitig über ihren Fortschritt, besprechen Probleme und Hindernisse und planen die Arbeit für den nächsten Tag.
• Arbeit am Sprint Backlog: Das Entwicklungsteam arbeitet während des gesamten Sprints an der Umsetzung der im Sprint Backlog enthaltenen Aufgaben. Dies geschieht in enger Zusammenarbeit mit dem Product Owner und dem Scrum Master, um sicherzustellen, dass die Arbeit auf Kurs bleibt und den Anforderungen entspricht.
• Sprint Review: Am Ende des Sprints findet ein Sprint Review-Meeting statt, bei dem das Team die im Sprint erreichten Ergebnisse präsentiert und Feedback von Stakeholdern und dem Product Owner einholt. Dies ist eine Gelegenheit, den Fortschritt zu bewerten und Anpassungen für zukünftige Sprints vorzunehmen.
• Sprint Retrospektive: Nach dem Sprint Review findet eine Sprint Retrospektive statt, bei der das Scrum-Team seine Zusammenarbeit, Prozesse und Tools reflektiert und Verbesserungsmöglichkeiten identifiziert. Diese Erkenntnisse werden genutzt, um den nächsten Sprint besser und effektiver zu gestalten.

Nach Abschluss eines Sprints beginnt das Team sofort mit dem nächsten Sprint und setzt den iterativen Prozess fort, bis das Projekt abgeschlossen oder das Produkt ausgeliefert ist. Sprints ermöglichen es dem Scrum-Team, schnell auf Änderungen zu reagieren und kontinuierlich Verbesserungen in ihrem Produkt und Arbeitsprozess vorzunehmen.

Die Artefakte innerhalb des Scrum-Frameworks

In Scrum gibt es drei Hauptartefakte, die dazu dienen, den Fortschritt, die Anforderungen und die Planung des Projekts oder Produkts transparent und sichtbar zu machen. Diese Artefakte sind:

1. Product Backlog: Der Product Backlog ist eine geordnete Liste von Anforderungen, Funktionen, Verbesserungen und anderen Aufgaben, die für die Entwicklung eines Produkts oder Projekts erforderlich sind. Der Product Backlog wird vom Product Owner erstellt und gepflegt, der die Elemente nach Priorität ordnet, wobei der Geschäftswert, Kundenbedürfnisse und technische Aspekte berücksichtigt werden. Der Product Backlog ist ein lebendes Dokument, das während des gesamten Projekts ständig aktualisiert und verfeinert wird, um auf sich ändernde Anforderungen und Umstände zu reagieren.

1. Sprint Backlog: Der Sprint Backlog ist eine Liste von Aufgaben, die aus dem Product Backlog ausgewählt wurden und im aktuellen Sprint vom Entwicklungsteam bearbeitet werden sollen. Der Sprint Backlog wird während des Sprint Planning-Meetings erstellt und ist das Ergebnis der gemeinsamen Planung des Scrum-Teams. Er enthält die ausgewählten Product-Backlog-Elemente sowie einen Plan zur Umsetzung dieser Elemente. Während des Sprints arbeitet das Team daran, die im Sprint Backlog enthaltenen Aufgaben abzuschließen, um das für den Sprint festgelegte Ziel zu erreichen.

1. Inkrement: Das Inkrement ist das verwendbare, potenziell auslieferbare Ergebnis der Arbeit, die während eines Sprints abgeschlossen wurde. Es beinhaltet alle fertiggestellten Product-Backlog-Elemente, die im aktuellen Sprint sowie in vorherigen Sprints bearbeitet wurden. Das Inkrement sollte am Ende eines Sprints den Definition of Done (DoD) -Kriterien entsprechen, was bedeutet, dass es in einem Zustand ist, der eine Auslieferung an den Kunden oder eine Integration in das Gesamtprodukt ermöglicht. Das Inkrement stellt sicher, dass das Scrum-Team kontinuierlich Wert für das Projekt oder Produkt liefert.

Diese Artefakte sind für das Scrum-Team und die Stakeholder sichtbar und ermöglichen eine transparente Kommunikation über den Fortschritt, die Prioritäten und die erwarteten Ergebnisse des Projekts oder Produkts. Sie unterstützen auch die Inspektion und Anpassung, zwei der wichtigsten Prinzipien im Scrum-Framework.

Zusätzliche Anforderungen und Techniken in Scrum

Definition of Done

Die Definition of Done (DoD) ist ein gemeinsames Verständnis im Scrum-Team darüber, welche Kriterien erfüllt sein müssen, damit ein Produkt-Backlog-Element als „fertig“ betrachtet wird. Die DoD stellt sicher, dass alle Teammitglieder dieselben Erwartungen haben und dass die erstellten Inkremente konsistent und von hoher Qualität sind.

Die Definition of Done kann von Projekt zu Projekt und von Team zu Team variieren, sollte jedoch bestimmte Qualitätsstandards und Anforderungen abdecken, die sowohl vom Entwicklungsteam als auch vom Product Owner und den Stakeholdern als notwendig erachtet werden. Die DoD kann Aspekte wie Codequalität, Dokumentation, Testabdeckung, Benutzerakzeptanzkriterien und Performance-Anforderungen umfassen.

Einige Beispiele für Kriterien, die in einer Definition of Done enthalten sein könnten, sind:

• Der Code ist geschrieben und entspricht den vereinbarten Programmierstandards und -richtlinien.
• Der Code ist überprüft und genehmigt worden (z. B. durch Code Reviews oder Pair Programming).
• Die Funktion ist getestet, und alle Tests (z. B. Unit-, Integrations- und Systemtests) wurden erfolgreich durchgeführt.
• Die Benutzerdokumentation und technische Dokumentation sind aktualisiert und vollständig.
• Die Funktion wurde in einer Staging- oder Testumgebung erfolgreich bereitgestellt und validiert.
• Die Funktion erfüllt alle in den Akzeptanzkriterien festgelegten Anforderungen.
• Die Funktion ist abwärtskompatibel und hat keine negativen Auswirkungen auf bestehende Funktionen.
• Alle identifizierten Bugs oder Probleme wurden behoben und erneut getestet.

Die Definition of Done sollte regelmäßig überprüft und angepasst werden, um sicherzustellen, dass sie den Bedürfnissen des Projekts und der Stakeholder entspricht. Dies kann beispielsweise in Sprint-Retrospektiven geschehen, bei denen das Team seine Arbeitsprozesse reflektiert und Verbesserungen identifiziert. Eine klare und gemeinsam vereinbarte Definition of Done trägt dazu bei, dass das Scrum-Team konsistente, qualitativ hochwertige Ergebnisse liefert, die den Erwartungen der Stakeholder entsprechen.

User Story

Eine User Story ist eine kurze, einfache Beschreibung einer Funktion oder Anforderung aus der Perspektive eines Endbenutzers oder Stakeholders. In Scrum und anderen agilen Methoden werden User Stories häufig verwendet, um die Anforderungen im Product Backlog zu erfassen und zu kommunizieren. Sie helfen dabei, den Fokus auf den Wert und Nutzen für den Endbenutzer zu legen und stellen sicher, dass das Entwicklungsteam die Bedürfnisse der Benutzer versteht und berücksichtigt.

User Stories folgen in der Regel einem einfachen Format, das den Kontext, die gewünschte Aktion und das erwartete Ergebnis beschreibt. Ein Beispiel für eine User Story könnte lauten:

„Als Online-Shop-Kunde möchte ich die Möglichkeit haben, meine Lieferadresse während des Bestellvorgangs zu ändern, damit ich meine Bestellung an eine andere Adresse als meine Hauptadresse schicken kann.“

Dieses Format (Als [Rolle] möchte ich [Aktion], damit [Ergebnis oder Nutzen]) hilft dabei, die Anforderungen auf einfache und verständliche Weise zu beschreiben und den Fokus auf den Wert für den Endbenutzer zu legen.

User Stories können auch zusätzliche Informationen enthalten, wie Akzeptanzkriterien, die die spezifischen Anforderungen und Bedingungen definieren, unter denen die User Story als abgeschlossen gilt. Diese Kriterien helfen dem Entwicklungsteam, die Anforderungen besser zu verstehen und die Qualität der Implementierung zu gewährleisten.

In Scrum werden User Stories im Product Backlog priorisiert und vom Product Owner gepflegt. Während des Sprint Planning-Meetings wählt das Team User Stories aus dem Product Backlog aus, um sie im aktuellen Sprint umzusetzen, und erstellt daraus das Sprint Backlog. User Stories bieten eine effektive Methode, um Anforderungen zu kommunizieren und sicherzustellen, dass das Entwicklungsteam die Bedürfnisse der Benutzer und Stakeholder berücksichtigt.

Task Board

Ein Task Board, auch als Scrum Board oder Kanban Board bezeichnet, ist ein visuelles Hilfsmittel, das in Scrum und anderen agilen Methoden verwendet wird, um den Fortschritt der Arbeit während eines Sprints zu verfolgen und die Zusammenarbeit innerhalb des Entwicklungsteams zu fördern. Das Task Board hilft, den Status der verschiedenen Aufgaben und User Stories, die im aktuellen Sprint bearbeitet werden, transparent und für alle Teammitglieder sichtbar zu machen.

Ein typisches Task Board ist in mehrere Spalten unterteilt, die verschiedene Stadien des Arbeitsprozesses repräsentieren, z. B. „To Do“, „In Progress“, „In Review“ und „Done“. Jede Aufgabe oder User Story wird als Karte oder Post-it-Note auf dem Board dargestellt und entsprechend ihrem aktuellen Status in die passende Spalte eingefügt.

Während des Sprints aktualisieren die Teammitglieder das Task Board kontinuierlich, indem sie die Karten von einer Spalte zur nächsten verschieben, um den Fortschritt der Arbeit zu zeigen. Dies geschieht häufig während des täglichen Stand-up-Meetings, in dem das Team seinen Fortschritt und mögliche Hindernisse bespricht.

Ein Task Board bietet mehrere Vorteile für ein Scrum-Team:

• Transparenz: Es ermöglicht allen Teammitgliedern und Stakeholdern, den aktuellen Status der Arbeit und den Fortschritt des Sprints auf einen Blick zu sehen.
• Kommunikation: Es fördert die Zusammenarbeit und den Informationsaustausch innerhalb des Teams und hilft dabei, mögliche Hindernisse oder Probleme frühzeitig zu erkennen.
• Fokus: Es hilft dem Team, sich auf die im Sprint Backlog enthaltenen Aufgaben zu konzentrieren und Prioritäten zu setzen.
• Selbstorganisation: Es ermöglicht dem Team, seinen eigenen Arbeitsprozess zu verwalten und Verantwortung für den Fortschritt der Arbeit zu übernehmen.

Ein Task Board kann physisch (z. B. mit einem Whiteboard und Post-it-Notes) oder digital (mit Hilfe von Projektmanagement- oder Kollaborationssoftware) erstellt werden. Beide Ansätze bieten die Möglichkeit, den Arbeitsfortschritt auf einfache und effektive Weise zu verfolgen und die Zusammenarbeit im Team zu fördern.

Planungspoker

Planungspoker, auch bekannt als Scrum-Poker oder Estimation Poker, ist eine konsensbasierte Technik zur Schätzung der Arbeitsaufwände von Aufgaben und User Stories in Scrum und anderen agilen Methoden. Planungspoker wird während des Sprint Planning-Meetings oder in einem separaten Schätzungsmeeting eingesetzt, um dem Entwicklungsteam zu helfen, gemeinsam und effektiv Zeit- oder Komplexitätsschätzungen für die im Product Backlog enthaltenen Elemente abzugeben.

Der Planungspoker-Prozess verläuft wie folgt:

1. Jedes Teammitglied erhält einen Satz von Karten, auf denen verschiedene Schätzwerte abgebildet sind. Diese Werte können Zeiteinheiten (z. B. Stunden oder Tage) oder abstrakte Einheiten wie Story Points repräsentieren. Häufig wird eine modifizierte Fibonacci-Sequenz verwendet (z. B. 0, 1, 2, 3, 5, 8, 13, 21, …), um die Schätzwerte zu repräsentieren.
2. Der Product Owner oder ein anderes Teammitglied präsentiert die zu schätzende User Story oder Aufgabe und erläutert die Anforderungen und Erwartungen.
3. Die Teammitglieder überlegen individuell, wie viel Aufwand sie für die Umsetzung der User Story oder Aufgabe benötigen, und wählen die entsprechende Karte aus ihrem Satz aus.
4. Alle Teammitglieder legen gleichzeitig ihre ausgewählte Karte offen auf den Tisch. Wenn alle Schätzungen ähnlich sind, kann ein Konsens schnell erreicht werden. Wenn die Schätzungen jedoch weit auseinanderliegen, diskutiert das Team die Unterschiede und versucht, ein gemeinsames Verständnis der Aufgabe und der damit verbundenen Herausforderungen zu entwickeln.
5. Nach der Diskussion wählen die Teammitglieder erneut eine Karte aus ihrem Satz aus, die ihrer überarbeiteten Schätzung entspricht, und der Prozess wird wiederholt, bis ein Konsens gefunden wurde.

Planungspoker hat mehrere Vorteile:

• Konsensfindung: Es fördert die Zusammenarbeit und den Austausch von Informationen zwischen den Teammitgliedern und hilft dabei, ein gemeinsames Verständnis der Aufgaben und Anforderungen zu entwickeln.
• Anonymität: Da alle Schätzungen gleichzeitig offen gelegt werden, wird die Beeinflussung durch dominante Teammitglieder oder voreilige Schätzungen reduziert.
• Lernen: Planungspoker ermöglicht es den Teammitgliedern, voneinander zu lernen und ihr Wissen über die verschiedenen Aspekte des Projekts und der Technologien zu erweitern.
• Genauigkeit: Die konsensbasierte Schätzung hilft dabei, eine genauere Schätzung der Arbeitsaufwände zu erreichen, da sie auf der kollektiven Erfahrung und den Fähigkeiten des gesamten Teams basiert.

Impediment Backlog

Ein Impediment Backlog, auch als Hindernis- oder Blocker-Backlog bezeichnet, ist eine Liste von Hindernissen oder Problemen, die den Fortschritt des Scrum-Teams während eines Sprints oder im gesamten Projektverlauf beeinträchtigen. Diese Hindernisse können technische, organisatorische oder persönliche Herausforderungen sein, die das Team daran hindern, effizient zu arbeiten und seine Ziele zu erreichen.

Das Impediment Backlog wird häufig vom Scrum Master erstellt und verwaltet, dessen Hauptaufgabe es ist, Hindernisse zu identifizieren, zu verfolgen und zu beseitigen, die das Team bei der Ausführung seiner Arbeit beeinträchtigen. Das Impediment Backlog kann während des täglichen Stand-up-Meetings oder der Sprint-Retrospektive aktualisiert und besprochen werden, um sicherzustellen, dass das Team sich der bestehenden Probleme bewusst ist und Maßnahmen ergreift, um sie zu lösen.

Einige Beispiele für Hindernisse, die im Impediment Backlog erfasst werden könnten, sind:

• Technische Schulden oder instabile Systeme, die das Team bei der Implementierung neuer Funktionen behindern.
• Unzureichende Ressourcen oder mangelnde Verfügbarkeit von Teammitgliedern.
• Externe Abhängigkeiten oder Blockaden, wie z. B. ausstehende Genehmigungen oder Lieferungen von Drittanbietern.
• Kommunikations- oder Koordinationsprobleme innerhalb des Teams oder mit externen Stakeholdern.
• Organisatorische Barrieren oder bürokratische Hürden, die die Entscheidungsfindung oder das Handeln des Teams verlangsamen.

Das Impediment Backlog hilft dabei, Transparenz über die bestehenden Herausforderungen zu schaffen und das Team zu ermutigen, proaktiv nach Lösungen zu suchen und kontinuierliche Verbesserungen im Arbeitsprozess anzustreben. Der Scrum Master spielt eine entscheidende Rolle dabei, das Team bei der Bewältigung dieser Hindernisse zu unterstützen und eine Umgebung zu schaffen, in der das Team effektiv und erfolgreich arbeiten kann.

Burndown Chart

Ein Burndown-Chart ist ein visuelles Hilfsmittel, das in Scrum und anderen agilen Methoden verwendet wird, um den Fortschritt und das Arbeitstempo eines Teams während eines Sprints zu verfolgen. Das Burndown-Chart zeigt die Menge der verbleibenden Arbeit im Sprint-Backlog im Verlauf der Zeit und hilft dem Team, ihre Leistung zu bewerten und einzuschätzen, ob sie auf dem richtigen Weg sind, um die im Sprint geplanten Aufgaben abzuschließen.

Ein typisches Burndown-Chart hat zwei Achsen:

1. Die horizontale Achse repräsentiert die Zeit, normalerweise in Tagen des Sprints.
2. Die vertikale Achse repräsentiert die verbleibende Arbeit, häufig in Story Points oder Arbeitsstunden.

Zu Beginn des Sprints zeigt das Burndown-Chart die gesamte Menge an geplanter Arbeit, die im Sprint-Backlog enthalten ist. Während des Sprints wird die verbleibende Arbeit täglich aktualisiert, basierend auf den vom Team abgeschlossenen Aufgaben. Die verbleibende Arbeit wird als Linie oder Kurve dargestellt, die im Laufe der Zeit abfällt, wenn das Team die geplanten Aufgaben abschließt.

Das ideale Burndown-Chart zeigt eine stetig abfallende Linie, die am Ende des Sprints auf null trifft, was darauf hindeutet, dass das Team alle geplanten Aufgaben abgeschlossen hat. In der Praxis kann das Burndown-Chart jedoch Schwankungen aufweisen, die auf Veränderungen in der Schätzung, unerwartete Hindernisse oder die Aufnahme zusätzlicher Arbeit in den Sprint zurückzuführen sind.

Ein Burndown-Chart bietet mehrere Vorteile für ein Scrum-Team:

• Transparenz: Es ermöglicht allen Teammitgliedern und Stakeholdern, den Fortschritt des Sprints und die verbleibende Arbeit auf einen Blick zu sehen.
• Anpassungsfähigkeit: Es hilft dem Team, mögliche Probleme oder Verzögerungen frühzeitig zu erkennen und geeignete Maßnahmen zu ergreifen, um den Sprint erfolgreich abzuschließen.
• Fokus: Es ermöglicht dem Team, sich auf die verbleibenden Aufgaben zu konzentrieren und Prioritäten entsprechend der verfügbaren Zeit und Ressourcen zu setzen.
• Lernen: Es bietet dem Team wertvolle Informationen über ihre Leistung und ihre Schätzgenauigkeit und hilft ihnen, ihre Arbeitsprozesse und Planungspraktiken in zukünftigen Sprints kontinuierlich zu verbessern.
• Ein Burndown-Chart kann entweder physisch (z. B. auf einem Whiteboard) oder digital (mit Hilfe von Projektmanagement- oder Kollaborationssoftware) erstellt und während des täglichen Stand-up-Meetings oder anderen Scrum-Events besprochen werden. Es ist ein effektives Werkzeug, um den Fortschritt des Sprints zu verfolgen und das Team dabei zu unterstützen, ihre Ziele zu erreichen und kontinuierliche Verbesserungen anzustreben.

Adaption von Scrum

Im Laufe der Zeit haben sich verschiedene Adaptionen von Scrum entwickelt, um den unterschiedlichen Bedürfnissen und Anforderungen von Organisationen und Projekten gerecht zu werden. Einige dieser Adaptionen sind Kombinationen aus Scrum und anderen agilen Methoden oder Frameworks, während andere spezifische Anpassungen des Scrum-Frameworks sind, um bestimmte Herausforderungen oder Branchen besser zu adressieren. Hier sind einige Beispiele für Scrum-Adaptionen:

• Scrumban: Scrumban ist eine Kombination aus Scrum und Kanban, die darauf abzielt, die Flexibilität von Kanban mit der Struktur und den Rollen von Scrum zu verbinden. Scrumban ist besonders nützlich für Teams, die kontinuierliche Verbesserungen und Anpassungen an ihren Arbeitsprozessen vornehmen möchten oder in Umgebungen, in denen die Anforderungen häufig wechseln.
• Scaled Agile Framework (SAFe): SAFe ist ein Framework, das auf Scrum und anderen agilen Methoden basiert und darauf abzielt, die Agilität auf Unternehmensebene zu skalieren. SAFe integriert Scrum auf der Team- und Program-Ebene und bietet zusätzliche Rollen, Artefakte und Prozesse, um die Koordination, Planung und Ausrichtung zwischen mehreren Scrum-Teams und den verschiedenen Ebenen einer Organisation zu unterstützen.
• Large Scale Scrum (LeSS): LeSS ist ein Framework zur Skalierung von Scrum für große Organisationen und mehrere Teams, das sich auf Einfachheit und das Prinzip der minimalen Viable Bureaucracy konzentriert. LeSS bietet zwei Varianten: LeSS für bis zu 8 Teams und LeSS Huge für bis zu Hunderten von Teams. LeSS legt Wert darauf, die Grundprinzipien von Scrum beizubehalten und die Koordination und Integration zwischen den Teams zu verbessern, ohne unnötige Komplexität hinzuzufügen.
• Nexus: Nexus ist ein Framework, das von Scrum.org entwickelt wurde, um Scrum für mehrere Teams zu skalieren. Nexus baut auf Scrum auf und erweitert es durch zusätzliche Rollen, Veranstaltungen und Artefakte, um die Zusammenarbeit, Integration und Planung zwischen den Teams zu fördern. Nexus zielt darauf ab, die Abhängigkeiten und Herausforderungen, die mit der Skalierung von Scrum verbunden sind, effektiv zu bewältigen und die Agilität und Effizienz der Organisation zu erhalten.
• Scrum of Scrums: Scrum of Scrums ist eine Methode zur Skalierung von Scrum, bei der mehrere Scrum-Teams in einer Matrixstruktur organisiert sind und ihre Aktivitäten in regelmäßigen Scrum-of-Scrums-Meetings koordinieren. In diesen Treffen, die in der Regel von einem Vertreter (z. B. dem Scrum Master) jedes Teams besucht werden, werden der Fortschritt, die Abhängigkeiten und die Hindernisse über die Teams hinweg besprochen und koordiniert.

Es ist wichtig zu beachten, dass es keine „One-Size-Fits-All“-Lösung für die Implementierung von Scrum gibt. Die verschiedenen Adaptionen von Scrum bieten unterschiedliche Ansätze, um den spezifischen Bedürfnissen und Herausforderungen individueller Projektumfelder zu begegnen.

Die Grenzen und Nachteile von Scrum

Obwohl Scrum ein weit verbreitetes und erfolgreiches agiles Framework ist, hat es einige Grenzen und Nachteile, die in bestimmten Situationen und Projektkontexten problematisch sein können. Hier sind einige der Grenzen und Nachteile von Scrum:

Weniger geeignet für nicht iterative Projekte: Scrum ist am besten für Projekte geeignet, die sich gut in iterative und inkrementelle Entwicklungszyklen unterteilen lassen. Für Projekte, die einen eher linearen oder sequenziellen Entwicklungsansatz erfordern, ist Scrum möglicherweise nicht die beste Wahl.

• Schwierigkeiten bei der Schätzung: Scrum basiert auf Schätzungen der Arbeitsaufwände und der verbleibenden Zeit, die oft schwierig und ungenau sein können. Ungenaue Schätzungen können zu Fehlplanungen und -priorisierungen führen, die den Projektfortschritt beeinträchtigen.
• Abhängigkeiten zwischen Teams: Bei Projekten mit vielen Abhängigkeiten zwischen Teams oder externen Ressourcen kann die Koordination und Integration der Arbeit eine Herausforderung darstellen. In solchen Situationen können skalierbare Frameworks wie SAFe, LeSS oder Nexus hilfreich sein.
• Anfänglicher Widerstand und Anpassungsschwierigkeiten: Die Einführung von Scrum kann in Organisationen, die traditionelle, hierarchische und plangetriebene Projektmanagementansätze gewohnt sind, auf Widerstand stoßen. Die Umstellung auf Scrum kann Zeit, Anpassung und kontinuierliche Verbesserung erfordern.
• Ineffektiv ohne engagierte Teammitglieder: Scrum setzt auf Selbstorganisation und Eigenverantwortung der Teammitglieder. Wenn Teammitglieder nicht engagiert oder nicht in der Lage sind, selbstständig Entscheidungen zu treffen und Probleme zu lösen, kann dies die Effektivität von Scrum beeinträchtigen.
• Unzureichender Fokus auf technische Praktiken: Scrum legt den Schwerpunkt auf Prozesse, Rollen und Artefakte, bietet jedoch wenig spezifische Anleitung in Bezug auf technische Praktiken. In Kombination mit anderen agilen Methoden wie Extreme Programming (XP) kann Scrum jedoch sowohl Prozess- als auch technische Verbesserungen bieten.
• Zu viel Flexibilität: Scrum kann in Situationen, in denen strenge Kontrolle und Dokumentation erforderlich sind, wie z. B. in stark regulierten Branchen oder bei sicherheitskritischen Projekten, Schwierigkeiten bereiten. In solchen Fällen kann eine Anpassung von Scrum oder die Verwendung eines anderen Frameworks erforderlich sein.

Es ist wichtig zu beachten, dass die Grenzen und Nachteile von Scrum von Projekt zu Projekt und von Organisation zu Organisation variieren können. In einigen Fällen können die Herausforderungen durch Anpassungen des Scrum-Frameworks oder die Kombination mit anderen Methoden und Praktiken bewältigt werden. Eine gründliche Analyse der spezifischen Anforderungen und Herausforderungen eines Projekts ist entscheidend, um festzustellen, ob Scrum oder ein anderes Framework am besten geeignet ist.

Risikomanagement und Kostenkontrolle in Scrum

Scrum selbst bietet keine expliziten Prozesse oder Werkzeuge für das Risikomanagement. Dennoch können mehrere Aspekte des Scrum-Frameworks dazu beitragen, Risiken in Projekten zu identifizieren, zu bewerten und zu steuern. Hier sind einige Scrum-Praktiken, die das Risikomanagement unterstützen:

• Kurze Iterationen (Sprints): Scrum basiert auf kurzen Entwicklungszyklen, die es ermöglichen, schneller auf Änderungen zu reagieren und Probleme frühzeitig zu erkennen. Durch die regelmäßige Überprüfung und Anpassung von Plänen und Prioritäten können Risiken frühzeitig identifiziert und angegangen werden.
• Transparenz: Scrum fördert Transparenz durch regelmäßige Kommunikation, Stand-up-Meetings und die Verwendung von Artefakten wie dem Product Backlog, dem Sprint Backlog und dem Burndown-Chart. Diese Transparenz ermöglicht es dem Team und den Stakeholdern, Risiken und Probleme leichter zu erkennen und geeignete Maßnahmen zu ergreifen.
• Inspektion und Anpassung: Scrum legt Wert auf die kontinuierliche Inspektion und Anpassung von Prozessen und Ergebnissen. Sprint-Review- und Sprint-Retrospektiven-Meetings bieten dem Team die Möglichkeit, Risiken und Hindernisse zu identifizieren und Maßnahmen zur Verbesserung und Risikominimierung zu ergreifen.
• Selbstorganisierende Teams: Scrum vertraut darauf, dass selbstorganisierende Teams proaktiv Risiken erkennen und angehen können. Teammitglieder haben die Verantwortung, Risiken zu identifizieren, zu kommunizieren und Lösungen zu entwickeln, um diese Risiken zu steuern oder zu reduzieren.
• Produktinkremente: Scrum fördert die Lieferung von potenziell auslieferbaren Produktinkrementen am Ende jedes Sprints. Dies ermöglicht es, frühes Kundenfeedback zu erhalten und Risiken im Zusammenhang mit Markt- oder Kundenerwartungen zu reduzieren.
• Scrum Master Rolle: Der Scrum Master ist dafür verantwortlich, Hindernisse und Risiken zu identifizieren und zu beseitigen, die das Team daran hindern, effektiv zu arbeiten. Diese Rolle kann auch dazu beitragen, Risikomanagementpraktiken zu fördern und sicherzustellen, dass das Team über mögliche Risiken informiert ist und Maßnahmen ergreift, um sie zu adressieren.

Um das Risikomanagement in Scrum weiter zu verbessern, können Teams zusätzliche Techniken und Werkzeuge integrieren, wie z. B. Risikoregister, Risikoanalysen oder regelmäßige Risikobewertungen. Es ist wichtig, dass das Team und die Organisation ein gemeinsames Verständnis für Risikomanagement entwickeln und eine Kultur schaffen, die die Identifizierung, Kommunikation und Behandlung von Risiken fördert.

Scrum bietet keinen expliziten Mechanismus zur Kostenkontrolle, aber viele seiner Prinzipien und Praktiken können zur Kostenkontrolle beitragen und die Wahrscheinlichkeit von Budgetüberschreitungen reduzieren. Hier sind einige Aspekte von Scrum, die helfen können, die Kosten in Projekten zu kontrollieren:

• Priorisierung: Im Product Backlog werden Anforderungen und Aufgaben nach Priorität geordnet. Der Product Owner ist dafür verantwortlich, sicherzustellen, dass die höchstpriorisierten Elemente zuerst bearbeitet werden, was dazu beiträgt, den Wert und die Rentabilität des Projekts zu maximieren.
• Kurze Iterationen (Sprints): Scrum basiert auf kurzen Entwicklungszyklen, die eine bessere Kostenkontrolle ermöglichen, da Probleme und Herausforderungen frühzeitig erkannt und angegangen werden können. Dies ermöglicht es, Korrekturmaßnahmen zu ergreifen, bevor Kosten außer Kontrolle geraten.
• Transparenz: Die Transparenz, die durch die Scrum-Praktiken und -Artefakte (z. B. Product Backlog, Sprint Backlog und Burndown-Chart) gefördert wird, erleichtert die Überwachung des Projektfortschritts und die Erkennung von Abweichungen von den Kostenzielen.
• Kontinuierliche Verbesserung: Scrum legt Wert auf kontinuierliche Verbesserung durch Inspektion und Anpassung. In den Sprint-Retrospektiven identifiziert das Team Verbesserungsmöglichkeiten, die auch zur Kostenreduktion oder -kontrolle beitragen können.
• Flexibilität und Anpassungsfähigkeit: Scrum ermöglicht es Teams, schnell auf Veränderungen zu reagieren und sich anzupassen. Diese Flexibilität kann dazu beitragen, die Kosten im Griff zu behalten, indem ineffiziente oder weniger wertvolle Arbeiten reduziert und der Fokus auf die wichtigsten Aufgaben gelegt wird.
• Selbstorganisierende Teams: Scrum vertraut darauf, dass selbstorganisierende Teams in der Lage sind, ihre Arbeit effizient und kosteneffektiv zu gestalten. Das Team hat die Verantwortung, die Kosten im Auge zu behalten und mögliche Kosteneinsparungen oder -überschreitungen zu identifizieren und anzugehen.

Um die Kostenkontrolle in Scrum-Projekten weiter zu verbessern, können Teams zusätzliche Praktiken und Werkzeuge einführen, wie z. B. Budgetüberwachung, Kostenschätzungen oder regelmäßige Kostenüberprüfungen. Wichtig ist, dass das Team und die Organisation ein gemeinsames Verständnis für die Bedeutung der Kostenkontrolle entwickeln und eine Kultur schaffen, die die Identifizierung und Behandlung von Kostenthemen fördert.

Entdecken Sie unser Trainingsangebot zu Scrum