Beruf & Digitalität

Was ist Scrum?

Agiles Arbeiten & Scrum
Veröffentlicht am:
Lesedauer:
12 Minuten

Scrum: Produktivität und Projektergebnis agil steuern
Der Begriff „Scrum“ stammt eigentlich aus dem Rugby und bedeutet so viel wie „Gedränge“. Scrum ist ein Vorgehensmodell des Projekt- und Produktmanagements. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig.

Als wohl führende Methode im agilen Projektmanagement wird Scrum heute nicht nur in der Software-Entwicklung eingesetzt, sondern in allen Bereichen, in denen es um die sukzessive Optimierung des bereits Erreichten durch Hinzufügen immer neuer Produkteigenschaften geht. In Scrum vollzieht sich dieser Fortschritt im Rahmen zeitlich begrenzter, sich zyklischer wiederholender Arbeitsabschnitte, den Sprints.

Scrum ist damit ein Gegenentwurf zur klassischen Top-down-Organisation von Projekten und lässt dem Entwicklungsteam mehr Spielraum für eigenverantwortliches Handeln. Zwar gibt es auch hier eine klare Zielvorgabe „von oben“: die Entwicklung innovativer Produkte - den jeweiligen Weg zum Ziel organisiert das Team jedoch weitgehend selbst.

Scrum besteht aus nur wenigen Regeln. Diese beschreiben vier Ereignisse, drei Artefakte und drei Rollen, die den Kern ausmachen.

Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer formulierten Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Lasten- und Pflichtenhefte. In Scrum werden die Anforderungen in Form von Eigenschaften aus der Anwendersicht formuliert.

Rollen

Das Scrum Framework kennt drei Rollen: Product Owner, Entwicklungsteam und den Scrum Master. Die Gesamtheit dieser Rollen wird als Scrum Team bezeichnet. Ein Scrum Team tritt mit den Beteiligten in Kontakt, den sogenannten Stakeholdern. Fortschritt und Zwischenergebnisse sind für alle Stakeholder transparent. Stakeholder dürfen bei den meisten Ereignissen zuhören.

Product Owner

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er gestaltet das Produkt mit dem Ziel, seinen Nutzen zu maximieren.

Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein. Der Product Owner ordnet, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.

Als Produktverantwortlicher hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.

Entwicklungsteam

Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem trägt es die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Das Entwicklungsteam organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.

Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement). Außerdem bricht das Entwicklungsteam in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte, sogenannte Tasks, herunter, deren Bearbeitung in der Regel nicht länger als einen Tag dauert. Das Ergebnis ist das Sprint Backlog.

Scrum Master

Der Scrum Master ist dafür verantwortlich, dass Scrum als Rahmenwerk gelingt. Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber selbst nicht dazu. Er führt die Scrum-Regeln ein, überprüft deren Einhaltung und kümmert sich um die Behebung von Störungen und Hindernissen. Dazu gehören mangelnde Kommunikation und Zusammenarbeit sowie persönliche Konflikte im Entwicklungsteam, Störungen in der Zusammenarbeit zwischen Product Owner und Entwicklungsteam sowie Störungen von außen, beispielsweise Aufforderungen der Fachabteilung zur Bearbeitung zusätzlicher Aufgaben während eines Sprints.

Ein Scrum Master ist gegenüber dem Entwicklungsteam eine dienende Führungskraft. Er gibt einzelnen Team-Mitgliedern keine Arbeitsanweisungen. Weder beurteilt er sie, noch belangt er sie disziplinarisch.

Stakeholder

Stakeholder sind Rollen außerhalb von Scrum. Beispielsweise Kunden, Anwender, Management.

Sprint

Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Er beginnt mit einem Sprint Planning und endet mit Sprint Review und -Retrospektive. Sprints folgen unmittelbar aufeinander. Während eines Sprints sind keine Änderungen erlaubt, die das Sprintziel beeinflussen.

Ein Sprint umfasst ein Zeitfenster von ein bis vier Wochen. Alle Sprints sollten idealerweise die gleiche Länge haben, um so dem Projekt einen Takt zu geben. Ein Sprint wird niemals verlängert – er ist zu Ende, wenn die Zeit um ist.

Ist das Ziel eines Sprints nicht mehr zu erreichen, beispielsweise weil das Team den Aufwand falsch eingeschätzt hat oder der Product Owner das Produktinkrement so nicht mehr will, dann kann der Sprint vom Product Owner abgebrochen werden. In diesem Fall wird der aktuelle Sprint mit einer Sprint-Retrospektive beendet und der neue Sprint ganz normal mit Sprint Planning begonnen.

Ereignisse

In Scrum spricht man von Ereignissen oder Events statt von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Alle Ereignisse von Scrum haben feste Zeitfenster (Timeboxen), die nicht überschritten werden sollen.

Sprint Planning

Im Sprint Planning werden zwei Fragen beantwortet:

  • Was kann im kommenden Sprint entwickelt werden?
  • Wie wird die Arbeit im kommenden Sprint erledigt?

Teil 1: Festlegung des Was

Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor. Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement soweit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt sind.

Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln.

Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht (siehe Definition of Done). Ziel ist die Fertigstellung eines auslieferbaren Produkts: ein Produktinkrement, das hinreichend getestet und integriert ist, um für den Benutzer freigegeben werden zu können.

Teil 2: Festlegung des Wie

Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind. Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte.

Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung. Häufig wird dafür ein Taskboard als Technik verwendet.

Daily Scrum

Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem max. 15-minütigen Daily Scrum, bei dem Scrum Master und Product Owner häufig anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten. Zweck des Daily Scrum ist der Informationsaustausch. Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.

Sprint Review

Das Sprint Review steht am Ende des Sprints. Hier überprüft das Scrum-Team das Inkrement, um das Product Backlog bei Bedarf anzupassen. Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als Nächstes zu tun ist.

Im Sprint Review ist die Beteiligung von Kunden und Anwendern wichtig, da diese die fertige Funktionalität des Inkrements benutzen und validieren können. Hieraus ergibt sich wichtiges Feedback für die weitere Produktgestaltung.

Das Ergebnis des Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder. Dies ist eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product-Backlog-Refinement.

Sprint-Retrospektive

Die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist ein gemeinsames Ereignis des Scrum Teams.

Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein.

Artefakte

Product Backlog

Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Das Product Backlog ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss ihren Ursprung im Product Backlog haben. Der Product Owner ist für die Pflege des Product Backlogs verantwortlich. Er verantwortet die Reihenfolge bzw. Priorisierung der Einträge.

Das Product Backlog ist nicht vollständig und erhebt auch nicht diesen Anspruch. Zu Beginn eines Projektes enthält es die bekannten und am besten verstandenen Anforderungen. Die Priorisierung der Eintragungen erfolgt unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Eintragungen mit der höchsten Priorität werden als erste im Sprint umgesetzt.

Die Anforderungen im Product Backlog sollten nicht technisch, sondern fachlich und anwenderorientiert sein. Eine Möglichkeit, um diese Sichtweise zu unterstützen, ist die Formulierung der Produkteigenschaften als User Stories.

Product Backlog Refinement

Das Product Backlog Refinement ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören:

  • Ordnen der Einträge
  • Löschen von Einträgen, die nicht mehr wichtig sind
  • Hinzufügen von neuen Einträgen
  • Detaillieren von Einträgen
  • Zusammenfassen von Einträgen
  • Schätzen von Einträgen
  • Planung von Releases

Für die Gestaltung des Produkts und des Product Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product-Backlog-Refinement-Treffen zusammen mit ausgewählten Stakeholdern.

Sprint Backlog

Das Sprint Backlog ist der aktuelle Plan der für einen Sprint zu erledigenden Aufgaben. Es umfasst die Product-Backlog-Einträge, die für den Sprint ausgewählt wurden, und die dafür nötigen Aufgaben (z. B. Entwicklung, Test, Dokumentation). Das Sprint Backlog wird laufend nach der Erledigung einer (Teil-)Aufgabe von den Team-Mitgliedern aktualisiert. Dies dient zur Übersicht des aktuellen Bearbeitungsstands. Um es für alle sichtbar zu machen, wird häufig ein Taskboard genutzt.

Product Increment

Das Inkrement ist die Summe aller Product-Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden. Am Ende eines Sprints muss das neue Inkrement in einem nutzbaren Zustand sein und der Definition of Done entsprechen.

Transparenz des Fortschritts

Zum Kern von Scrum gehört eine Transparenz über den Fortschritt des Produkts und des Sprints – innerhalb und außerhalb des Teams. Während das Produktinkrement den Fortschritt am deutlichsten sichtbar macht, so sind dennoch andere Techniken zur Fortschrittstransparenz notwendig.

Definition of Done

Die Definition of Done (DoD) ist ein gemeinsames Verständnis des Scrum Teams, unter welchen Bedingungen eine Arbeit als fertig bezeichnet werden kann. Sie enthält für gewöhnlich Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen. Mit zunehmender Erfahrung des Scrum Teams entwickelt sich die Definition of Done weiter. Sie enthält dann strengere Kriterien für höhere Qualität.

Definition of Ready

Die Definition of Ready (DOR) folgt dem Ansatz der Definition of Done. Sie soll sicherstellen, dass ein Eintrag im Produkt Backlog vom Team implementiert werden kann, also wirklich alle notwendigen Vorbedingungen und Inputs verfügbar sind, beispielsweise stabile und freigegebene Interfacedokumente (ICDs). Zudem muss ein gemeinsames Verständnis über den Inhalt des Eintrags vorhanden sein. Verantwortlich für die Einhaltung der DOR ist der Produkt Owner. Nur Einträge, die Ready sind, können in einen Sprint übernommen werden.

Ergänzende Techniken

User Story

User Stories sind eine Technik zur Beschreibung von Anforderungen aus der Perspektive eines Benutzers unter Verwendung von Alltagssprache. In Scrum werden User Stories zur Formulierung der Product-Backlog-Einträge verwendet. Eine User Story beschreibt, welche Produkteigenschaft der Benutzer will und warum.

User Stories folgen im Allgemeinen diesem Muster:
Als NUTZER will ich FUNKTION oder EIGENSCHAFT, damit NUTZEN.

Bei einem Projekt zur Entwicklung eines städtetauglichen Elektrofahrrads könnte eine User Story demnach folgendermaßen lauten:
Als 30-jährige Geschäftsfrau möchte ich auf dem Weg zur Arbeit nur wenig in die Pedale treten müssen, damit ich nicht verschwitzt in der Firma ankomme.

Es ist Aufgabe des Product Owners und des Teams, im Product Backlog Refinement zu klären, was genau damit gemeint ist, und welches die Akzeptanzkriterien sein sollen. So könnte zum Beispiel vereinbart werden, dass bis zu einer Steigung von maximal 20 Prozent der elektrische Antrieb so stark sein muss, dass die Fahrerin nicht mehr als 50 Watt durch eigenes Treten beisteuern muss. Zudem muss das Entwicklungsteam mit dem Product Owner klären, ob sich diese User Story überhaupt in einem Sprint erledigen lässt oder ob sie in kleinere Stories heruntergebrochen werden muss. Sobald eine User Story umgeschrieben oder um weitere Information ergänzt wird, werden auch diese Änderungen im Product Backlog festgehalten.

Fragen nach dem Wie, also nach der technischen Umsetzung einer User Story, gehören ins Sprint Planning und werden nicht im Product Backlog, sondern im Taskboard mit Hilfe der einzelnen Tasks festgehalten.

Taskboard

Das Taskboard ist eine Technik zur Visualisierung des Sprint Backlogs. Darauf lässt sich jederzeit erkennen, welche Product Backlog Einträge für den Sprint ausgewählt wurden, welche Aufgaben dazu zu bearbeiten sind, und in welchem Bearbeitungszustand diese Aufgaben sind. Das Taskboard ist eine Kanban-Tafel.

Typischerweise besteht das Taskboard aus vier Spalten. In der ersten Spalte Anforderungen werden die Product Backlog Einträge eingetragen, die das Entwicklungsteam für diesen Sprint ausgewählt hat – in der vom Product Owner priorisierten Reihenfolge. Die drei weiteren Spalten enthalten die Aufgaben oder Tasks, die zur Umsetzung der jeweiligen Anforderung notwendig sind, in ihrem jeweiligen Bearbeitungszustand. Die zweite Spalte enthält alle noch zu erledigenden Aufgaben, die nächste Spalte diejenigen in Bearbeitung und die letzte Spalte alle erledigten.

Im Daily Scrum erklärt jedes Mitglied des Entwicklungsteams anhand des Taskboards, an welcher Aufgabe es am Vortag gearbeitet hat, und ob diese erledigt wurde. Tasks, die an einem Tag nicht beendet werden konnten oder bei denen Hindernisse den Fortschritt aufhalten, werden markiert. In diesem Fall sollten die Aufgaben zur Beseitigung des Hindernisses in das Taskboard aufgenommen werden. So können Hindernisse schnell identifiziert und die Beseitigungsmaßnahmen transparent gemacht werden.

Quellen

Schlagwörter:
AgilProjektmanagementScrum