Projektmanagement-Glossar
Alle Glossarbegriffe

Scrum

Scrum ist ein Managementsystem des Agilen Projektmanagements, das in der Software-Entwicklung zum Einsatz kommt und dessen Prozesse sowie Rollen das entwicklungsbegleitende Anforderungsmanagement unterstützen.

Scrum

Scrum ist ein Managementsystem des Agilen Projektmanagements, das in der Software-Entwicklung zum Einsatz kommt und dessen Prozesse sowie Rollen das entwicklungsbegleitende Anforderungsmanagement unterstützen.

Beschrieben wird Scrum in The Scrum Guide, der von Ken Schwaber und Jeff Sutherland kontinuierlich gepflegt wird und der auf der Website www.scrumguides.org frei zum Download in mehreren Sprachen zur Verfügung steht (Schwaber, Ken u. Sutherland, Jeff: The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game, Juli 2013, www.scrumguides.org).

Schwaber und Sutherland entwickelten Scrum in den 1990er Jahren und publizierten 1995 den Scrum Guide. In diesem definieren sie Scrum als: "A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." ("Ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.")

Scrum zählt zu den bekanntesten Methoden des sog. Agilen Projektmanagements. Das Prozessmodell und die Rollendefinitionen von Scrum sind darauf ausgerichtet, auch umfangreiche Software-Entwicklungsprojekte zu managen. Kerngedanke hinter Scrum ist, dass ein Projekt nicht von Anfang bis Ende präzise durchgeplant wird, sondern die Produktentwicklung iterativ in kurzen Feedback-Schleifen, den sog. ↑Sprints, erfolgt. Dies ermöglicht zum einen, in regelmäßigen Abständen den aktuellen Stand der Produktentwicklung zu prüfen, um ggf. steuernd eingreifen zu können. Zum anderen können die Projektbeteiligten durch den iterativen Ansatz kurzfristig auf Änderungen oder Probleme reagieren.

Rollen in Scrum

In Scrum gibt es sechs zentrale Rollen: Scrum Master, Product Owner, Entwicklungsteam, Anwender, Kunde und Manager. Der Scrum Guide definiert die Rollen Scrum Master, Product Owner und Entwicklungsteam als "Scrum-Team". Anwender, Kunde und Manager als externe Rollen führt der Scrum Guide zwar nicht explizit auf, sie werden aber in anderen Publikationen erwähnt (z.B. Gloger, Boris: Scrum, Carl Hanser Verlag, 2011). Nachfolgend eine kurze Beschreibung der einzelnen Rollen:

  • Der ↑Scrum Master ist für die Implementierung von Scrum und die Einhaltung der Regeln im Projekt zuständig. Er ist verantwortlich dafür, möglichst gute Arbeitsbedingungen für das Team zu schaffen und unterstützt es bei der Selbstorganisation.
  • Der ↑Product Owner verantwortet den geschäftlichen Erfolg des Projekts. Er ist zuständig für die sog. Produktvision, die Anforderungen sowie das ↑Product Backlog. Er steht in Kontakt mit dem Kunden und gibt regelmäßig Feedback an das Team.
  • Das Entwicklungsteam entwickelt das Produkt und ist für die Produktqualität verantwortlich. Es setzt die Anforderungen aus dem Product Backlog selbstorganisiert um.
  • Der Kunde ist der Auftraggeber und finanziert das Projekt. Der Product Owner informiert den Kunden laufend über den aktuellen Stand. Zudem erhält der Kunde die Möglichkeit, den Stand kontinuierlich zu begutachten und dazu sein Feedback zu geben.
  • Die Anwender (User) sind die Benutzer des Produkts. Ihre Meinungen und ihr Feedback können während des Projekts in die Entwicklung einfließen. Anwender und Kunde können sowohl gleiche als auch verschiedene Personen sein.
  • Das Management ist für die Rahmenbedingungen verantwortlich. Es muss dafür sorgen, dass alle benötigten Ressourcen zur Verfügung stehen, damit innerhalb der Unternehmensstrukturen Projekte nach Scrum durchgeführt werden können.

Scrum-Artefakte

Für die Steuerung eines Scrum-Projekts, stehen in Scrum die sog. "Artefakte" zur Verfügung. Der Scrum Guide definiert Artefakte wie folgt: "Die Artefakte von Scrum repräsentieren Arbeit oder Wert auf verschiedene nützliche Weisen, die Transparenz und Gelegenheit zur Überprüfung und Anpassung schaffen. Die in Scrum definierten Artefakte sind spezifisch dafür entwickelt worden, die Transparenz über Schlüsselinformationen zu maximieren, die sicherstellen, dass Scrum Teams erfolgreich ein "done" (fertiges) Inkrement liefern können."

In der Literatur zu Scrum gibt es unterschiedliche Auffassungen, wie viele Artefakte in Scrum als solche zu zählen sind. Hauptgrund hierfür dürfte eine unklare Begriffsdefinition von "Artefakt" sein. Der Scrum Guide definiert als Artefakte das Product Backlog, das Sprint Backlog sowie das Produktinkrement. Darüber hinaus werden auch vereinzelt das Burndown-Chart, das Impediment Backlog sowie die Definition of "Done" zu den Artefakten gezählt.

Die Definition of "Done" beschreibt der Scrum Guide nicht als Artefakt, sondern als eigenständiges Hilfsmittel, mit dem sich die Einträge im Product Backlog sowie die Inkremente als "erledigt" deklarieren lassen. Das Burndown Chart als Instrument zur Fortschrittsmessung wird u.a. von der Scrum Alliance als Artefakt angesehen (Wintersteiger, Andreas: Scrum, entwickler.press, 2012).

Scrum-Meetings

Neben den Artefakten existieren in Scrum vier Meetings zur Projektsteuerung: Das Sprint Planning, das Daily Scrum, das Sprint Review sowie die Sprint-Retrospektive. Der Scrum Guide fasst diese vier Meetings gemeinsam mit dem Sprint unter dem Oberbegriff "Scrum Ereignisse" zusammen.

Vereinzelt ist in der Literatur auch von weiteren Scrum-Meetings die Rede. So wird das Sprint Planning aufgrund seiner Struktur und der unterschiedlichen Inhalte auch häufig in Sprint Planning 1 und Sprint Planning 2 aufgeteilt. Dabei findet im ersten Teil des Meetings eine Prüfung statt, wie viele Einträge des Product Backlogs im anstehenden Sprint umgesetzt werden sollen. Im zweiten Teil des Meetings erfolgt die Planung des Teams, wie es diese Anforderungen genau umsetzen möchte. Weiter wird auch das sog. Estimation Meeting in verschiedener Literatur zu den Scrum-Meetings gezählt. Darüber hinaus gibt es zahlreiche weitere Meetings, wie z.B. Design- oder Architektur-Meetings, die vereinzelt als Scrum-Meeting aufgeführt werden, die aber nicht Teil des Scrum-Frameworks sind.

Arbeitsablauf nach Scrum

Ein mit Scrum gesteuertes Projekt beginnt mit der Entwicklung einer Produktvision. Die Vision darf zu Beginn des Projekts noch ungenau sein, da sie im Laufe des Projekts weiter konkretisiert werden kann. Auf Basis der Vision verfasst der Product Owner das Product Backlog.

Die eigentliche Produktentwicklung erfolgt in den sog. Sprints, die in der Regel einen Entwicklungszeitraum von zwei bis vier Wochen vorsehen. Zu Beginn eines Sprints präsentiert der Product Owner dem Team das priorisierte Product Backlog. Das Team entscheidet eigenständig, wie viele der am höchsten priorisierten Anforderungen es im anstehenden Sprint umsetzen will. Daraus ergibt sich das sog. Sprint Backlog.

Am Ende des Sprints präsentiert das Team in einem Review den Zuwachs der Funktionalität den Stakeholdern, sodass diese auf der einen Seite die Funktionalität überprüfen und auf der anderen Seite rechtzeitige Anpassungen oder Änderungen vornehmen können. Weiter erfolgt am Ende eines Sprints eine Retrospektive, in der das Team den Entwicklungsprozess sowie die Zusammenarbeit im vorangegangenen Sprint analysiert und bei Bedarf Verbesserungen für die Arbeitsorganisation entwickelt.

Bewertungen

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 9