Defintion

Scrum ( zu deutsch: Gedränge) ist ein Vorgehensmodell der agilen Softwareentwicklung, welches von Ken Schwaber & Jeff Sutherland entwickelt wurde. Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch Wicked Problems, Righteous Solutions (1991). Scrum in der Produktionsentwicklung wird zum ersten Mal in dem Artikel "The new new Product Development Game erläutert und später ind "The Knowledge Creating Company" weiter ausgeführt - von Nonaka und Takeuchi.

Annahmen

Bei Scrum wird grundsätzlich angenommen, dass Produktfertigungs- und Entwicklungsprozesse so komplex sind, dass sie sich im Voraus weder in große abgeschlossene Phasen noch in einzelne Arbeitsschritte mit der Granularität von Tagen oder Stunden pro Mitarbeiter vorher planen lassen. Somit ist es produktiver, wenn sich ein Team in einem festen äußeren Rahmen mit sehr grober Granularität selbst organisiert. Dieses selbstorganisierte Team übernimmt in diesem mit dem Product Owner abgestimmten Rahmen die gemeinsame Verantwortung für die Fertigstellung der selbstgewählten Aufgabenpakete. Ein Management „von oben“ sowie traditionelle Methoden zur Kommunikation oder Projektsteuerung, die die Zusammenarbeit im Team regeln sollen, werden abgelehnt.

Rollen

Product Owner

• Der Product Owner legt das gemeinsame Ziel fest, das das Team zusammen mit ihm erreichen muss
• Er setzt regelmäßig die Prioritäten der einzelnen Product-Backlog-Elemente. Dadurch legt er fest, welches die wichtigsten Features sind, aus denen das Entwicklungsteam eine Auswahl für den nächsten Sprint definiert.(Sprint Backlog)

Team

• Das Team besteht idealerweise aus 7+2 Personen.
• Es schätzt die Aufwände der einzelnen Backlog-Elemente ab und beginnt mit der Implementierung der für den nächsten Sprint machbaren Elemente.
• Dazu wird vor dem Beginn des Sprints ein weiteres Planungstreffen durchgeführt, bei dem die Aufgaben zur Erreichung des Story-Points definiert werden.  Das Team arbeitet selbstorganisiert und hat das Recht (und die Pflicht), selbst zu entscheiden, wie viele Elemente des Backlogs nach dem nächsten Sprint erreicht sein müssen, man spricht dabei von commitments.

Scrum Master

Der [ScrumMaster] hat die Aufgabe, die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht und unterstützt dabei, Verbesserungspotentiale zu erkennen und zu nutzen. Er ist keinesfalls für die Kommunikation zwischen Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren. Er steht dem Team zur Seite, ist aber weder Product Owner noch Teil des Teams. Der [ScrumMaster] sorgt mit allen Mitteln dafür, dass das Team produktiv ist, also die Arbeitsbedingungen stimmen und die Teammitglieder zufrieden sind. Er tritt somit für die ordnungsgemäße Durchführung und Implementierung von Scrum im Rahmen des Projektes ein.

Artefakte

Product Backlog

Das Product Backlog enthält die Features des zu entwickelnden Produkts. Es umfasst alle Funktionen, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in den Sprint Backlog übernommen. Ein wesentliches Merkmal des Backlogs ist die Tiefe der Beschreibung von einzelnen Features. Hoch priorisierte Features werden im Gegensatz zu niedrig priorisierten sehr detailliert beschrieben. Somit wird viel Zeit für die wesentlichen Elemente und wenig für unwesentliche verwendet

Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen. Eine Aufgabe sollte dabei nicht länger als 16 Stunden dauern. Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Team an Kapazität aufweisen kann.

Die Kapazität berechnet sich gemäß folgender Formel: Kapazität (in Stunden) = Arbeitstage × Anzahl Personen × 7 h. (8h Tag inkl. 1h Puffer) Außerdem benennt das Sprint Backlog die für die Aufgaben Verantwortlichen.

Burndown Chart

Das Burndown Chart ist eine graphische, pro Tag zu erfassende Darstellung des noch zu erbringenden Restaufwands pro Sprint. Im Idealfall fällt die Kurve kontinuierlich (daher Burndown) und der Restaufwand ist am Ende des Sprints Null. Das Chart lässt anhand der Verlängerung der negativen Steigung bereits während des Sprints erkennen, ob der anfangs geschätzte Aufwand umgesetzt werden kann

Meetings

Planning

In diesem Treffen erklärt der Product Owner dem Team alle einzelnen Backlog-Einträge, die für den nächsten Sprint benötigt werden. Im nächsten Schritt werden vom Team die Arbeitsschritte (das Wie) zur Erreichung der Stories ( das Was) definiert. Die Auflistung der Stories, die das Team commited abzuarbeiten - bildet das Sprint Backlog,

Sprint

Zentrales Element des Entwicklungszyklus von Scrum ist der Sprint. (2-4 Wochen) Für einen Sprint wird ein  Sprint Backlog erstellt. In diesen werden Anforderungen übernommen, die während des Sprints umgesetzt werden sollen. Welche Anforderungen umgesetzt werden, wird vom Team entsprechend den Prioritäten entschieden, die von Product Owner und Kunden festgelegt wurden. Dazu nimmt sich das Team aus dem  Product Backlog die am höchsten priorisierten Aufgaben, die das Team in diesem Sprint für realistisch durchführbar hält. Zum Sprint organisiert sich das Entwicklungsteam selbst, braucht also keine detaillierten methodischen Vorschriften. Am Ende eines Sprints steht immer eine lauffähige, getestete, inkrementell verbesserte Software oder Produkt.

Daily Scrum

An jedem Tag findet ein kurzes (maximal 15-minütiges) Daily Scrum statt.Scrum definiert keine konkrete Uhrzeit für das Meeting, das Meeting sollte jedoch täglich zur gleichen Zeit stattfinden.

Das Team stellt sich gegenseitig die folgenden Fragen:

• Welche Aufgaben hast du seit dem letzten Meeting fertiggestellt?
• Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten?
• Gibt es Probleme, die dich bei deinen Aufgaben behindern?

Review

Im Review Meeting werden die Ergebnisse des Sprints vorgeführt. Der Product Owner überprüft, ob die Ergebnisse den Anforderungen entsprechen.

Retrospektive

In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet. Allen Teilnehmer wird die Frage gestellt: Was war gut (Best Practice) und "Was könnte verbessert werden?"