Scrum

Scrum (engl. „Gedränge“) ist ein Vorgehensmodell der agilen Softwareentwicklung. Es besteht aus wenigen und klaren Regeln sowie zunächst aus den drei zentralen Rollen Product Owner, Team und ScrumMaster . Scrum verkörpert die Werte des Agilen Manifests, welches Menschen und deren Interaktionen vor Prozesse und Werkzeuge stellt . Die Arbeit mit Scrum ist iterativ, denn sie erfolgt in zeitlich abgegrenzten Intervallen, so genannten Sprints. Am Ende jedes Sprints sieht Scrum die Lieferung einer fertigen Software-Funktionalität vor (Produkt-Inkrement). Die neu entwickelte Funktionalität sollte in einem Zustand sein, dass sie an den Kunden ausgeliefert werden kann (potential shippable code oder usable software).

Das Wesen von Scrum lässt sich anhand von vier Prinzipien begreifen: 1. Selbstorganisation: Teams sollen so arbeiten, wie sie es für richtig halten. 2. Das Pull-Prinzip: Das Team allein entscheidet, wie viele Funktionalitäten es liefern kann. 3. Klare Grenzen: Alle Aktivitäten sind zeitlich fest beschränkt und am Ende muss ein Ergebnis stehen. 4. Nutzbare Funktionalitäten: Am Ende jedes Intervalls steht eine Lieferung, die den Standards und Vorgaben des Projekts entspricht .

Ken Schwaber, Jeff Sutherland und Mike Beedle haben Scrum entwickelt und etabliert. Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch Wicked Problems, Righteous Solutions (1991) beschrieben. Scrum in Produktionsumgebungen wird zum ersten Mal in dem Artikel The New New Product Development Game erläutert und später in The Knowledge-Creating Company weiter ausgeführt von Ikujirō Nonaka und Hirotaka Takeuchi.

Grundannahmen

Die Anfänge von Scrum lassen sich auf das Jahr 1990 zurückverfolgen. Damals schuf Jeff Sutherland in einem Projekt für die Guiness Peat Aviation eine neue Rolle für die damaligen Projektleiter. Diese wurden zu Teammitgliedern und ihre Rolle war eher die eines Moderators als die eines Managers. Ken Schwaber veröffentlicht auf der OOPSLA 1996 den ersten Konferenzbeitrag über Scrum. Darin schreibt Schwaber: "Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software, die Kosten, die Funktionalität, die Zeit und die Qualität einbeziehend" .

Scrum kann besser verstanden werden, wenn man sich mit der Schlanken Produktion (engl. lean production) auskennt. Scrum überträgt keine Erfahrungen aus der Automobilbranche auf die Softwareentwicklung, aber es lässt sich zeigen, dass diese Erfahrungen zum Verständnis der grundlegenden Probleme in der Software-Entwicklung beitragen. In der Automobilbranche gilt das Unternehmen Toyota als ein Vorreiter der Schlanken Produktion. Das sich ständig in der Weiterentwicklung befindende Toyota Production System (TPS) umfasst dabei Methoden und Arbeitsmittel der Produktion und steht im selben Verhältnis zum Toyota Way, dem TPS zugrunde liegenden Prinzip, wie die Scrum-Methodik zur agilen Softwareentwicklung. Im Mittelpunkt steht bei beiden Systemen die ständige Weiterentwicklung der Mitarbeiter, der Herstellungsprozesse, der Arbeitsmittel und Methoden, unter gleichzeitig konstantem Beibehalten der Grundannahmen, die dahinter stehen. Gemein ist den meisten agilen Vorgehensmodellen dabei die gleichzeitige Weiterentwicklung aller an dem Prozess Beteiligten, auch der Kunden und Partner. Ziel der Grundannahmen ist es, die Produktion ständig zu verbessern, um höchste Qualität bei niedrigstem Aufwand zu erreichen (Kaizen).

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.

Scrum erfüllt als agile Methode die Bedingungen der agilen Software-Entwicklung, die 2001 im Agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:

1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Im Folgenden werden Kernpunkte der Scrum-Arbeitsmittel wiedergegeben. Sie sind nicht zu verwechseln mit den hinter diesen Arbeitsmitteln stehenden oben genannten Grundannahmen und gelten lediglich als bewährte Möglichkeiten zur Umsetzung dieser Grundannahmen.

Rollen

Bei Scrum gibt es drei klar getrennte Rollen, die von Mitarbeitern ausgefüllt werden können, die im selben Projekt zusammen arbeiten.

Product Owner

Der Product Owner legt das gemeinsame Ziel fest, welches das Team zusammen mit ihm erreichen muss. Zur Definition der Ziele dienen ihm meist User-Storys, wobei auch andere Techniken erlaubt sind. Er setzt regelmäßig die Prioritäten der einzelnen Product-Backlog-Elemente (siehe unten). Dadurch legt er fest, welches die wichtigsten Features sind, aus denen das Entwicklungsteam eine Auswahl für den nächsten Sprint trifft.

Der Product Owner führt den Entwicklungsaufwand durch die Vermittlung seiner fachlichen Vision für das Team, skizziert Arbeit im Scrum-Backlog, und priorisiert es basierend auf der Wert-Analyse. In dieser Rolle muss der Product Owner dem Team die Fragen beantworten und die Richtung vorgeben. Die Scrum Werte Selbst-Organisation und als Ergebnis den eigenen Aktionsplan zu erstellen, muss der Product Owner respektieren. Dies bedeutet, dass es dem Product Owner verboten ist, dem Team in der Mitte des Sprints mehr Arbeit zu geben. Allerdings kann das Team den Scrum Product Owner ersuchen, weniger priore Anforderungen während eines Sprints zurückzustellen. Auch wenn sich die Anforderungen ändern oder eine konkurrierende Organisation ein neues Produkt stellt, welches die Arbeit des Teams überflüssig macht, kann der Scrum Product Owner nichts an der Sprint Planung bis zum nächsten Sprint Meeting ändern, er kann allerdings den laufenden Sprint jederzeit beenden.

Darüber hinaus ist es in der Verantwortung des Product Owner zu prüfen, welche Maßnahmen den meisten geschäftlichen Nutzen erzeugen. Dies bedeutet, dass schwierige Features, die das Team vielleicht während der Sprint-Planung nicht schätzen kann, zerlegt und Entscheidungen getroffen werden müssen. Der Product Owner muss aggressiv prüfen, welche Funktionen eines Produktes am wichtigsten sind, und wann sie entwickelt werden, usw. So wie das Entwicklungs-Team die ausgehandelte Arbeit für den Product Owner produzieren muss, muss der Product Owner das Produkt an den Kunden liefern.

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 höchstpriorisierten Elemente des Backlogs und konkrete Aufgaben aufgeteilt werden. Das Team arbeitet selbstorganisiert im Rahmen einer Time Box (dem Sprint) 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' ist dafür verantwortlich, dass Scrum gelingt. Dafür arbeitet er mit dem Team zusammen, gehört aber selber nicht zum Team. Er führt die Scrum-Regeln ein und schaut nach deren Einhaltung, moderiert die Meetings und kümmert sich um jede Störung des Scrum-Prozesses. Arbeitsmittel des ScrumMaster ist das "Impediment Backlog". Darin festgehalten sind alle Hindernisse ("Impediments"), die das Team an effektiver Arbeit hindern. Der ScrumMaster ist verantwortlich für die Lösung dieser Hindernissen. Dazu gehören sowohl Probleme im Team (z.B. mangelnde Kommunikation und Zusammenarbeit, persönliche Konflikte) als auch Störungen von außen (z.B. Aufforderungen zur Bearbeitung zusätzlicher Aufgaben während eines Sprints).

Ein ScrumMaster ist gegenüber dem Team eine Führungskraft, aber kein Vorgesetzter. Weder kann er einzelnen Team-Mitgliedern konkrete Arbeitsanweisungen geben noch kann er diese beurteilen oder disziplinarisch belangen. Seine Rolle ist die eines Servant Leaders - der ScrumMaster sichert sich Anerkennung und Gefolgschaft, indem er sich der Bedürfnisse der Team-Mitglieder annimmt .

Im Idealfall wird der ScrumMaster vom Team gewählt. Zu Beginn einer Scrum-Implementierung ist ScrumMaster ein Vollzeitjob, da die Umstellung der Abläufe und das Einlernen der Rollen meist sehr aufwändig ist. Ist Scrum erst einmal wohl etabliert, kann die Rolle des ScrumMasters zum Teilzeitjob werden. Der ScrumMaster kann dann selber Aufgaben im Rahmen eines Sprints übernehmen .

2003 legte Ken Schwaber ein Zertifizierungsprogramm für Scrum Master auf. Das Ziel ist es, die Software-Entwicklung durch das Nutzen von Scrum zu professionalisieren.

Zusammenspiel

Bei der Rollenaufteilung wurde berücksichtigt, dass das Team sich selbst organisiert. Der Product Owner gibt nicht vor, welches Teammitglied wann was macht und wer mit wem zusammenarbeitet. Bei Scrum wird von der Annahme ausgegangen, dass das Team sich intuitiv selbst organisiert, und zu jeder Aufgabe dynamisch eine optimale innere Organisationsstruktur bildet, die sich relativ schnell an die sich wandelnden komplexen Aufgaben anpasst. Der Scrum Master hat die Pflicht, darauf zu achten, dass der Product Owner nicht in diesen adaptiven Selbstorganisationsprozess eingreift und das Team stört oder Verantwortlichkeiten an sich nimmt, die ihm nicht zustehen.

Zyklusmodell

Der Scrum-Prozess

Sprint-Planungstreffen 1

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. Außerdem einigt er sich mit dem Scrum-Team auf das Sprint-Ziel. Dieses Sprint-Ziel bildet nach dem Sprint die Basis für die Abnahme. Die höchst priorisierten Einträge des Product Backlog werden entsprechend dem Ergebnis des Treffens in das Selected Backlog übernommen.

Sprint-Planungstreffen 2

Dieses Treffen organisiert das Scrum-Team eigenverantwortlich. Hier werden alle Arbeiten (also die Einträge im Selected Backlog) an die Mitglieder möglichst gleich verteilt. Dazu werden die Selected-Backlog-Einträge in Aufgaben zerlegt, die in weniger als einem Tag bearbeitet werden können. Aus den Aufgaben und deren Verteilung entsteht das Sprint Backlog.

Sprint

Zentrales Element des Entwicklungszyklus von Scrum ist der Sprint. Ein Sprint bezeichnet die Umsetzung einer Iteration, Scrum schlägt ca. 30 Tage als Iterationslänge vor; in der Praxis liegt die Dauer (je nach Team) bei einer bis vier Wochen. Vor dem Sprint werden die Produkt-Anforderungen des Kunden in einem Product Backlog gesammelt. Auch technische und administrative Aufgaben werden dort aufgenommen. Das Product Backlog muss nicht vollständig sein; es wird laufend fortgeführt. Die Anforderungen für den ersten Sprint sind meistens rasch aufgestellt. Die Anforderungen werden informell skizziert. 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.

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. Empfohlener Zeitpunkt für das Scrum-Meeting ist die Zeit nach dem Mittagessen, da morgendliche Scrum-Meetings oft mit flexiblen Gleitzeitregelungen kollidieren und der müde Punkt nach dem Mittagessen bei einem Scrum-Meeting, das durchaus im Stehen abgehalten werden kann, nicht so stark ins Gewicht fällt wie bei anderen Tätigkeiten. Die Meetings sind kürzer als am Morgen, weil allgemeine Dinge und Neuigkeiten schon vorher diskutiert wurden und die Mitarbeiter mit dem Kopf ganz bei der Arbeit sind.

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?

Die Sitzung dient dem Informationsaustausch des Teams untereinander. Hier geht es darum, dass möglichst alle alles wissen. Falls neue Hindernisse erkannt wurden, müssen diese vom Scrum Master bearbeitet werden. Dazu werden sie in das Impediment Backlog eingetragen. Im Daily Scrum haben nur die Teammitglieder und der Scrum Master eigenständiges Rederecht; alle anderen Zuhörer (Interessierte, z. B. Product Owner, Vorgesetzte, Kunden, Gäste, andere Scrum Teams) reden nur, wenn sie gefragt werden.

Größere Projekte werden durch das Einführen von Scrum-of-Scrum-Meetings, Product Owner Daily Scrums und Scrum Master Weekly gesteuert.

Review

Nach einem Sprint wird das Sprint-Ergebnis einem informellen Review durch das Team und durch den Product Owner unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Product Owner prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht. Eventuelle Änderungen können in Form von Erweiterungen, Umpriorisierungen oder durch das Entfernen von Elementen des Product Backlogs dokumentiert werden.

Retrospektive

In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet. Es handelt sich dabei nicht um „Lessons Learned“, sondern um einen zunächst wertungsfreien Rückblick auf die Ereignisse des Sprints. Eine mögliche Vorgehensweise ist, dass alle Teilnehmer dazu die für sie wichtigen Ereignisse auf Zetteln notieren und sie dem Zeitstrahl des Sprints zuordnen. Anschließend schreiben die Teilnehmer alle Punkte auf, welche ihnen zu den Fragen „Was war gut?“ (Best practice) bzw. „Was könnte verbessert werden?“ (Verbesserungspotential) einfallen. Jedes Verbesserungspotential wird priorisiert und einem Verantwortungsbereich (Team oder Organisation) zugeordnet. Alle der Organisation zugeordneten Themen werden vom Scrum Master aufgenommen und in das Impediment Backlog eingetragen. Alle teambezogenen Punkte werden in das Product Backlog aufgenommen. Egal, wie die Retrospektive gestaltet wird, das Ziel ist, den vergangenen Sprint zu beleuchten und daraus zu lernen.

Wird für die Retrospektiven und deren Vorbereitung nicht genug Zeit eingeräumt, bleiben die Erkenntnisse und Ergebnisse oberflächlich und die Resultate nach jedem Sprint ähneln sich. Dann läuft man Gefahr, dass die Retrospektiven an Stellenwert verlieren oder ganz gestrichen werden, weil die Ergebnisse der Retrospektiven vorhersehbar sind.

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.

Selected Backlog

Das Selected Backlog enthält alle diejenigen Einträge aus dem Product Backlog, die notwendig sind, um das Ziel des Sprints zu erfüllen. Es wird von dem Product Owner zusammen mit dem Scrum Team erstellt und gilt somit als Vereinbarung und als Grundlage der späteren Abnahme.

Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen. Eine Aufgabe sollte dabei in nicht länger als einem Tag erledigbar sein. Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Team in diesem Sprint für realistisch durchführbar hält. Üblicherweise wird dies aus der Geschwindigkeit des vorangegangenen Sprints errechnet.

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 des Gefälles bereits während des Sprints erkennen, ob der anfangs geschätzte Aufwand umgesetzt werden kann.

Impediment Backlog

In das Impediment Backlog werden alle Hindernisse des Projekts eingetragen. Der Scrum Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen.

Parallelisiertes Pipelining von Sprints

Die Begründer von Scrum in Produktionsumgebungen Takeuchi und Nonaka präsentierten in einem Harvard Business Paper Review drei verschiedene Arten, wie Scrum in Firmen benutzt werden kann. Diese unterscheiden sich vor allem durch die unterschiedliche Lösung der Nullphasen zwischen zwei Sprintphasen. Nullphasen sind Zeiträume, in denen nichts produziert wird, weil verschiedene Regularien, wie Review, Retrospektive, Sprint Planning usw. durchgearbeitet werden müssen:

Parallelisiertes Pipelining von Sprints in Scrum

Typ A – Scrum

Durchführung von Sprints mit absolutem Fokus auf eine Iteration im Prozess. Nullphasen zwischen den Sprints um Vor- bzw. Nachbereitungen für die Sprints durchzuführen.

Typ B – Scrum

Entfernung der Nullphasen durch Durchführung der Vor- und Nachbereitungen am Ende des vorangegangenen bzw. Beginn des nachfolgenden Sprints. Reduktion der Aufwände für Vor- und Nachbereitungen der Sprints durch beispielsweise minimale und funktionale Spezifikationen.

Typ C – Scrum

Aufteilung mehrerer Sprints, oft sogar aus unterschiedlichen Projekten zur gleichen Zeit auf ein Team. Dies erfordert von dem Team ein hohes Verständnis von Scrum-Arbeitsweisen und die Einführung von sogenannten Scrums von Scrums, übergeordneten Scrum Meetings an denen z.B. Product Owner und ScrumMaster von mehreren untergeordneten Scrums teilnehmen, um die groben Aufgaben global zu verteilen.

Bei der Einführung der Typen B und C ist darauf zu achten, dass zunächst Scrum gut eingeführt werden muss (was gut und gerne mehrere Monate dauern kann). Außerdem ist für die notwendige Steigerung der Produktivität ein automatisiertes Managing und Testing notwendig. Erst dann ist die Scrum-Arbeitsweise derart automatisiert, dass man nutzbare Ergebnisse erhält.

Kritische Betrachtung

Auch das Vorgehensmodell Scrum kann unausgewogen eingesetzt werden und dann scheitern. Ein besonderes Risiko sind dominante Teamplayer, die den Prozess der Selbstorganisation stören, ohne einen gleichwertigen eigenen Beitrag in diesen Organisationsprozess und ohne einen angemessenen eigenständigen Beitrag in die Problemlösung einzubringen.

Zudem muss eine Entwicklungsabteilung generell bereits auf recht hohem Niveau mit einer modernen Programmiersprache arbeiten, um in kurzen Abständen lieferbare, qualitätsgetestete Software zu produzieren. Auch bei umfangreichen und vielschichtigen Projekten wird von Scrum gefordert, dass prinzipiell alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können, was beispielsweise in Projekten, die auf unterschiedlichen technologischen Basen bestehen, häufig nicht gegeben ist.

Häufige Änderungen erfordern Refactoring, dieses wiederum benötigt eine ausreichende Testabdeckung durch Unittests. Häufige Lieferungen zum Kunden benötigen wiederum eine ausreichende fachliche Testabdeckung durch Regressionstests. Gerade in alten, gewachsenen Programmen ist eine ausreichende Testabdeckung durch Testautomatisierung mit vertretbarem Aufwand oft nicht zu erreichen. Manuelle Tests generieren nach jedem Sprint erneut Testaufwand.

Software

Es gibt diverse Softwareanwendungen wie Agilo for Scrum, JIRA in Kombination mit Greenhopper, Icescrum, in-Step oder Scrumworks, um Scrum-basiertes Arbeiten zu unterstützen. Ein großer Teil dieser ist Open Source.

Literatur

• Ken Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, 2007, ISBN 978-3-86645-631-0 (englisch: Agile Project Management with Scrum. Übersetzt von Thomas Irlbeck). 
• Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall, 2002, ISBN 978-0-13-067634-4. 
• Roman Pichler: Scrum: Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag, 2008, ISBN 978-3-89864-478-5
• Holger Koschek: Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten. dpunkt.verlag, 2009, ISBN 978-3-89864-640-6
• Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, 2008, ISBN 978-3-86645-643-3 (englisch: The Enterprise and Scrum.). 
• Boris Gloger: Scrum-Produkte zuverlässig und schnell entwickeln. Hanser Verlag, 2008, ISBN 3-446-41495-9
• Ken Schwaber: Scrum Development Process, Advanced Development Methods, 131 Middlesex Turnpike Burlington, MA01803
• Jeff Sutherland, Ph.D.: Future of Scrum: Parallel Pipelining of Sprints in Complex Projects. Hrsg.: Patientkeeper, Inc. Brighton, MA 2005 (PDF-Version [abgerufen am 24. März 2010]). 
• Mike Cohn: Agile Softwareentwicklung. Mit Scrum zum Erfolg! Hrsg.: Addison-Wesley. München 2010, ISBN 978-3-8273-2987-5, S. 498 (http://www.amazon.de/Agile-Softwareentwicklung-Mit-Scrum-Erfolg/dp/3827329876#reader_3827329876 Blick ins Buch! [abgerufen am 16. Juli 2011]). 

Siehe auch

• Feature Driven Development
• Extreme Programming (XP)
• Testgetriebene Entwicklung
• Kanban in der IT
• Story-Cards

Weblinks

• Die offizielle Website der Scrum Alliance (englisch)
• Die offizielle Webseite der Scrum.org (english)
• Einführung in Scrum
• Wissenswertes über Scrum
• Artikel über Scrum (Original in IX 6/09 veröffentlicht)
• Scrum auf einen Blick (englisch; PDF-Datei; 665 kB)
• Kriterien für eine Entscheidung für Scrum oder Kanban in der IT (PDF-Datei; 326 KB; veröffentlicht in heise developer 2. September 2010)