Agile Schätzverfahren im Vergleich zu traditionellen Methoden

KLASSISCHE SCHÄTZMETHODE

Eine Aufwandsschätzung ist wichtiger Bestandteil im Planungsvorgang eines Projektes. Klassisch wird dabei die Spezifikation des Ergebniszieles im Projektvorhaben (zB in Form eines Lastenheftes) analysiert und den Anforderungen eine Anzahl konkreter Durchführzeiten und -kosten gegenübergestellt.

ABSTRAKTE SCHÄTZMETHODE

Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen den Aspekten Umfang (Grösse und Komplexität) eines Vorhabens und die des Aufwandes. Geschätzt wird in abstrakten Schätzmethoden nicht der Aufwand in Zeitdimensionen wie Stunden, Tage, Wochen oder Monate, sondern vorab nur der Umfang des zu schätzenden Objektes in Form einer definierten Grösseneinheit (Points) bzw. seine Komplexität (Grad der Abhängigkeiten der Detailaspekte untereinander).

Der Wegbereiter dieser Methodik war Barry W. Boehm, der in der Software Entwicklung mit der Function-Point-Analyse den Fokus im Schätzverfahren von der Umsetzungsdauer hin zur Komplexität einer Software Funktionalität (Feature) verschoben hat. Der Umfang eines fachlichen Features lässt sich in einem abstrakten Komplexitätsmaß (den Function Points) ausdrücken. Der Aufwand, der zur Umsetzung des Features benötigt wird, leitet sich dann aus noch weiteren Faktoren (zB Anzahl von Feldern einer Datenbank) ab. 

Vorteile abstrakter Schätzmethoden

Vergleichende/abstrakte Schätzungen sind schneller durchführbar als das Schätzen absoluter Größen. Menschen können schlecht absolute Dinge schätzen. Sie können aber gut Dinge zueinander in Relation setzen und erkennen, was größer oder kleiner ist.

Umfangsschätzungen sind zeitlos - werden konkrete Zeitmaße verwendet, dann müssen häufig diese Schätzungen im Laufe eines Projektes durch Neuschätzung korrigiert werden. Beispielsweise dauert das Erstellen einer Formular-Eingabe zu Beginn eines Projektes durch fehlende Erfahrung vielleicht deutlich länger als im späteren Projektverlauf. Der Umfang (Grösse und Komplexität) hingegen bleibt aus Sicht des Teammitgliedes die gleiche und muss deshalb im Projektverlauf nicht angepasst werden.

Objektivität - durch die Trennung von Umfang und Aufwand können Schätzungen abgegeben werden, ohne die umsetzenden Individuen zu kennen. Bei der Schätzung des Umfanges einer Aufgabe muss nicht bereits die Geschwindigkeit unterschiedlicher Entwickler einkalkuliert werden, was die Schätzung aufwändig und personenbezogen machen würde.

Agile Schätzmethode in Scrum 

Die theoretische Annahme in der Methode Scrum ist, dass Produktfertigungs- und Entwicklungsprozesse in Softwareprojekten so komplex sind, dass sich die Umsetzung nicht im Voraus planen lässt, geschweige denn, die einzelnen Umsetungsschritte planbar sind. Somit ist es produktiver, wenn ein Team nur die groben Projektvorgaben in Form von User Stories bekommt. Planen wird in den agilen Methoden des Projektmanagements grundsätzlich als wichtiger Kommunikationsprozess zwischen Menschen verstanden, die ein gemeinsames Ziel verfolgen. 

Im Kontext agiler Projekte hat sich das Schätzen in abstrakten Schätzmaßen durchgesetzt. Hier wird nicht ein großes Lastenheft "am Stück" vor Projektstart geschätzt. Stattdessen werden die Anforderungen in Stories zerlegt. Jede Story beschreibt eine Anforderung, die für das Produkt einen Mehrwert darstellt. Die Stories sind so zu formulieren, dass sie innerhalb eines Zeitrahmens von ein bis zwei Wochen umsetzbar sind.

Die Vorteile im Detail

Der Vorteil dieser Zerlegung besteht darin, dass Stories sich in ihrem Umfang schnell schätzen lassen. Als Einheit werden Story-Points verwendet, die durch das Vergleichen verschiedener Stories vergeben werden (Analogieverfahren). Die Anzahl der Story Points drückt ausschliesslich ihre Grösse im Vergleich zu anderen User Stories aus. Eine User Story zB mit zwei Punkten ist doppelt so gross, wie eine User Story mit  einem Punkt. Die Anzahl der Story Points sagt jedoch nichts darüber aus, wie lange die Umsetzung der Story dauert. Dennoch sagt die Grösse in Story Ppoints etwas über die relative Dauer aus. Die Umsetzung einer User Story mit zwei Story Points dauert doppelt so lange wie die Umsetzung der User Story mit einem Point. 

Kriterien für den Umfang und damit die Grösse einer User Story können Faktoren sein, wie: Anzahl von Einzeltätigkeiten, generell das Arbeitsvolumen, die Komplexität, Risiken, externe Abhängigkeiten. Die Kriterien sind nicht fest und unterscheiden sich von Team zu Team.

Von der abstrakten Schätzung zur Aufwandsermittlung

Zur Aufwandsschätzung gelangt man durch den sogenannten Velocity-Faktor. Der Faktor gibt an, wieviele Story-Points in einem definierten Zeitbereich umgesetzt werden können. Im wesentlichen gibt es drei Möglichkeiten zur Ermittlung des Velocity-Faktors:

Historische Daten - aus der Vergangenheit ist bekannt, wie viele Story-Points das Team pro Zeiteinheit schafft. Dabei ist es wichtig, dass die Teamzusammensetzung vergleichbar ist.

Vorprojekt - ein kleiner Ausschnitt des Gesamtprojektes wird in einem kurzen Vorprojekt umgesetzt und daraus die Velocity-Kennziffer ermittelt.

Schätzen - liegen keine historischen Daten vor und kann kein Vorprojekt durchgeführt werden, dann kann ein grober Velocity-Wert aus der Erfahrung geschätzt werden. Natürlich können dann alle abgeleiteten Aufwandsschätzungen nur sehr grobe Näherungen darstellen.

Durchführung des eigentlichen Schätzvorganges in der Methode Planning Poker

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Sie wurde 2002 von James Grenning erstmalig beschrieben, später durch Mike Cohn’s Buch Agile Estimating and Planning verfeinert und erst durch seine Publikation populär.  In agilen Projekten wird großer Wert auf das Commitment und die Selbststeuerung eines Teams gelegt. Deshalb ist es beim Schätzen besonders wichtig, dass das gesamte Team einbezogen wird und die Schätzwerte unterstützt. Eine im agilen Umfeld weit verbreitete Technik ist das Ermitteln der Story-Point-Werte über sogenanntes Schätzpoker Verfahren (Planning Poker Methode). Dabei besitzt jedes Teammitglied Karten mit aufgedruckten Zahlen. Zu Beginn des Schätzvorganges einigt sich das Team auf eine verwendete Referenz Story. Das ist die kleinste oder die grösste User Story im Rahmen der zu schätzenden Sammlung an Stories (Backlog). Ich persönlich habe bessere Erfahrungen damit gemacht, als Vorgabe die kleinste gemeinsame User Story als Schätzbasis zu verwenden.  Die gesamte Schätzungsklausur wird vom Scrummaster moderiert und im Beisein des Product Owners abgehalten, der auch für Verständnisfragen zur Verfügung steht. 

Als Masseinheit für die agile Schätzmethode empfiehlt sich, die Zahlen der "unechten Fibonacci Funktion" zu verwenden. Dabei verwende ich persönlich in meinen Projekten nur die Punktereihe von 0 bis ausschliesslich 13, bzw. ?. Die Zahlen, die auf den Schätzpokerkarten aufgedruckt sind, haben folgende Bedeutung:

 0 - Kein Aufwand notwendig.

 1 - Sehr kleiner Umfang.

 2 - Kleiner Umfang: doppelt so wie ein kleiner Umfang.

 3 - Mittlerer Umfang: so gross wie ein sehr kleiner und ein kleiner Umfang zusammen.

 5 - Grosser Umfang: so gross, wie ein kleiner und mittlerer Umfang zusammen.

 8 - Sehr grosser Umfang: so gross, wie ein mittlerer und grosser Umfang zusammen.

13 - Riesiger Umfang: so gross, wie ein grosser und sehr grosser Umfang zusammen.

 ? - Nicht abschätzbar.

Abb.: Planning Poker Card Set

Ablauf:

• Der Produkt Owner lädt vorm ersten Sprint zu einem Initialmeeting mit nachfolgender Schätzklausur ein. Dazu hat er im Vorfeld alle User Stories (zumindest eine notwendige Anzahl für die ersten 1-3 Sprints) beschrieben und priorisiert.
• Der Product Owner schlägt vor Meetingbeginn den zeitlichen Rahmen vor. Dieser sollte je nach Teamgrösse maximal 90 Minuten nicht überschreiten. Er fasst das große Bild (Produktziel  bzw. die Produkt Vision) des zu entwickelnden Produktes zusammen und stellt dann vor jeder Schätzung das jeweilige  Backlog Item (User Story) kurz vor. 
• Im Schätzverfahren legt nun jedes Teammitglied pro Story verdeckt (und damit von den anderen unbeeinflusst) eine Karte mit dem geschätzten Wert auf den Tisch. 
• Anschliessend werden alle Karten gleichzeitig aufgedeckt. Gibt es nach dem Aufdecken der Karten große Abweichungen in der Einschätzung, dann wird im Team über diese unterschiedlichen Bewertungen diskutiert.  Dabei wird der Scrum Master die beiden jeweiligen Extremausprägungen der Schätzung (kleinster und grösster Schätzwert) befragen und lässt diese beiden Teammitglieder argumentieren, warum sie zu dieser Bewertung gekommen sind. Jedes Teammitglied hat nun damit weitere Standpunkte und Meinungen zur aktuellen Story gehört. Die Karten werden nun wieder aufgenommen. Dieselbe User Story wird jetzt von allen Teilnehmern neuerlich geschätzt. Nach ein bis zwei weiteren Schätzrunden sollten die Werte dann konvergieren. Auf diese Weise gelangt das Team schnell zu einem tieferen Verständnis der umzusetzenden Stories und zu guten Schätzwerten.
• User Stories die aufgrund vom Umfang grösser als 13 Punkte bewertet werden oder von der Detaillierung der Funktionen her betrachtet zu ungenau beschrieben sind, werden vom Team mit einem "?" geschätzt. Dies bedeutet für den Produktverantwortlichen (Product Owner), dass er diese im Anschluss an die Schätzklausur in eine detailliertere User Story zu definieren hat oder diese User Story in mehrere kleiner herunterzubrechen (zu schneiden) wird müssen, die dann neuerlich geschätzt werden.

Voraussetzungen:

• Derartige Schätzklausuren finden in agilen Projekten regelmässig während des Projektverlaufs statt, sodass zumindest immer zwei Projektphasen (Sprints) im Vorhinein die dafür benötigten User Stories geschätzt werden. Ich habe in meinen Projekten gute Erfahrungen gemacht, zu Beginn des Projektes in einer initialen Schätzklausur den kompletten Backlog und regelmässig nur die neu hinzugekommen User Stories zu schätzen. 

Anregungen:

• Teams ermüden nach etwa 2 Stunden Planungspoker.  Daher sind die bei grösseren Vorhaben die initialen Schätzklausuren auf mehrere kürzere Etappen aufzuteilen.

Vorteile:

• Agile Schätzmethoden mit der Methode "Planning-Poker-Verfahren" machen nicht nur mehr Spass als herkömmliche Schätzverfahren, sondern besitzen zudem folgende Vorteile:


• Teamentscheidungen
- Planungspoker ist ein kollaboratives Entscheidungsverfahren. Die Entscheidung sollte auf dem Konsens aller Teammitglieder aufbauen. So stellen sie sicher, dass das gesamte Team hinter den Schätzwerten steht.
• Schnelle Entscheidungen
- nach wenigen Schätzrunden einigen sich Teammitglieder meist rasch auf einen Schätzwert. Meist benötigt das Team dann ca. 2 Minuten oder sogar weniger, um eine User Story  abzuschätzen.
• Transparenz
- Produktverantwortliche, Team und Scrum Master nehmen am Planungspoker teil. Der Produktverantwortliche versteht so besser, wie die Aufwände entstanden sind. Ist das Team nicht in der Lage, einen Eintrag abzuschätzen, so wird dies vermerkt und bedeutet eine Überarbeitung der User Story durch den Produktverantwortlichen.

WEITERE AGILE SCHÄTZMETHODEN

Magic Estimation in der Methode nach Lowel Lindstorms

Diese „magische“ Schätzmethode macht eine zügige initiale Schätzung des gesamten Product Backlogs möglich, denn gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den gesamten Umfang der zu entwickelnden Funktionalitäten zu bekommen. Wie schon von der Schätzmethode „Planning Poker“ her bekannt, sollten auch hier vor dem allerersten Sprint ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und vom Product Owner priorisiert sein, um diese dann anschliessend vom Team schätzen zu lassen.

Mit dieser Technik lassen sich mit relativ geringem Zeitaufwand sehr aussagekräftige Schätzungen erstellen. Wie auch beim Planning Poker beschrieben, geht es bei der initialen Schätzung nicht um Präzision, sondern lediglich um eine erste Einschätzung.

Der Ablauf: 

Das Meeting läuft nach folgendem Schema ab:

• Der Product Owner druckt vor dem Meeting die einzelnen Backlog Items auf ein Blatt Papier (User Stories und Akzeptanzkriterien auf einer Seite) aus. Die Blätter werden auf dem Boden verteilt. 
• Er legt mit extra Karten (Planning Poker Karten) am Rand des Bodens eine Schätzskala mit der Reihung ähnlich nach Fibunacci (0, 1, 2, 3, 5, 8, 13, ?) auf.
• Der Product Owner schlägt dann im Meeting den zeitlichen Rahmen für das Meeting vor. Dieser sollte je nach Teamgrösse maximal 90 Minuten nicht überschreiten. Er fasst noch einmal das große Bild (Produktziel  bzw. die Produkt Vision) des zu entwickelnden Produktes zusammen und stellt dann alle Backlog Items einzeln vor.
• Alle Teammitglieder haben nun nacheinander innerhalb von maximal 10 Minuten die Möglichkeit, ihre Schätzung für alle Items auf dem Boden abzugeben. Die Schätzung kann durch das Auflegen von Poker Cards erfolgen oder der Einfachheit halber, mit dem Zuordnen der  User Stories dem entsprechenden Skalenwert auf der Schätzsskala am Bodenrand.
• Die Teammitglieder können bei Unklarheiten beim Product Owner nachfragen. Sie besprechen sich jedoch nicht untereinander, sondern nehmen nur die ausgetauschten Informationen auf.
• Der jeweilige Nachfolger kann die Schätzungen des Vorgängers entsprechend herauf- oder heruntersetzen. Stimmt er mit der Schätzung des Vorgängers überein, bleibt diese unberührt. Nachdem das letzte Teammitglied seine Schätzung abgegeben hat, wird diese Schätzung in das Backlog übernommen. 

Voraussetzung:

• Der wichtige Punkt vor dem Start des Projekts ist die Kenntnis des Big Picture, der Vision und der Zielsetzung des zu entwickelnden Produktes. Unter diesen Bedingungen fällt es einem erfahrenen Team leichter, Schätzung abzugeben.
• Als Voraussetzung für diese Technik sind gut geschriebene (geschnittene) Backlog Items (User Stories) und ein prall gefülltes Product Backlog hilfreich. Dabei kann der Scrum Master dem Product Owner im Vorfeld unterstützend zur Seite stehen und vorab die Backlog Items besprechen. Ausserdem sollte das Team vor dem Meeting in das Backlog sehen können. Das spart wertvolle Zeit im eigentlichen Schätzmeeting. 

Anregung:

• Veränderungen der Schätzwerte im Rahmen der Schätzklausur einer User Story sind ein Indikator für unterschiedliche Meinungen, Erwartungen und der Abschätzung unterschiedlicher Kompexität zur selben Story. Daher mein Tipp: Bei einer Veränderung der Schätzung einer User Story im Schätzvorgang gegenüber dem vorherigen Teammitglied, sollte diese mit einem Markierungspunkt markiert werden. Der Umstand eines Markers und die Anzahl der Markierungspunkte beschreiben den Grad der Meinungsunterschiedlichkeit zu dieser Story im Team. Diese Stories sollte der Product Owner mit dem Team nochmals durchgehen.
• Eine Herabsetzung der Schätzzeit von 10 Minuten auf 3-5 Minuten vermindert zwar in keiner Weise die Schätzqualität, kann jedoch bei übergrossen Backlogs zeitlich sehr hilfreich sein.

Magic Estimation in der Methode nach Boris Gloger

Die Idee von Lowel Lindstroms modifizierte Boris Gloger in seiner Schätzmethode "Magic Estimation". Die von Herrn Gloger entwickelte Methode schafft Schätzgeschwindigkeiten von ca. 100 Stories mit einer Gruppe von ca. 10 Personen in etwa 30 Minuten. Die dabei erreichte Schätzgenauigkeit ist für die weitere Umsetzung ausreichend. Diese Schätzmethode wird besonders bei Angebotsschätzungen oder bei sehr grossen Backlogs erfolgreich angewendet.

Der Ablauf: 

Das Meeting läuft nach folgendem Schema ab:

• Der Product Owner druckt vor dem Meeting die einzelnen Backlog Items auf ein Blatt Papier (User Stories und Akzeptanzkriterien auf einer Seite) aus. 
• Er legt mit extra Karten (Planning Poker Karten) am Rand des Bodens eine Schätzskala mit der Reihung ähnlich nach Fibunacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?) auf.
• Er bespricht zu Beginn nochmals die Product Vision und verteilt nun die Backlog-Item Karten an das Team. Jedes Teammitglied bekommt ungefähr gleich viele Karten.
• Das Schätzen wird von jetzt an nur mehr schweigend durchgeführt. Man darf sich mit niemanden (auch nicht mit dem Product Owner) austauschen. Voraussetzung dafür sind natürlich gut formulierte User Stories, die im Bedarfsfall schon im Vorfeld kommuniziert wurden.
• Jedes Teammitglied liest nun seine Backlog Items durch und legt sie zu der Zahl, die seiner Meinung nach das Verständnis dieser Story repräsentiert. Dabei gilt, je grösser die Zahl, desto grösser der geschätzte Umfang, wobei die Zahlen 20, 40 und 100 Epics und keine User Stories mehr repräsentieren. Es gelten nur die Werte der Schätzskala, also keine Zwischenwerte.
• Wenn ein Teammitglied seine Karten verteilt hat, liest es die Karten, die von den anderen Teammitgliedern ausgelegt wurden und verändert die Position der Karte, wenn es der Meinung ist, dass diese Karte an eine andere Position gehört. Dieses Lesen und allfällige Verrücken führen alle Teammitglieder parallel und ohne dass sie sich gegenseitig beraten durch.
• Der Product Owner beobachtet das Team beim Durchführen der Schätzungen. Wenn er sieht, dass eine Karte in der Bewertungsskala "springt", markiert er diese Karte. An einer Karte die springt, also die ein- oder mehrmals von Mitgliedern in der Skala verändert werden, lässt sich leicht erkennen, dass eine Meinungsverschiedenheit vorliegt.
• Wenn ein Teammitglied nicht weiss, was eine Karte bedeutet, dann wird es auf den Skalenwert "?" gelegt. Der Skalenwert "?" dient in diesem Schätzverfahren nur den unbekannten, also nicht interpretierbaren Backlog Items.
• Die Schätzung ist beendet, wenn sich keine Karte mehr bewegt oder es aber nur mehr "springende" Karten gibt.
• Zum Abschluss schreibt das Team die ermittelten Zahlen auf die Backlog Item Karten.
• Der Product Owner erhält als Ergebnis alle Backlos Items nach dem Verständnis "bewertet und final geschätzt".

Voraussetzung:

• Hier gilt ebenso die Voraussetzung von gut geschriebenen (geschnittenen) Backlog Items (User Stories).
• Das Team sollte vor dem Meeting das Backlog einsehen und dem Product Owner Fragen stellen können.
• Die Karten müssen in dieser Schätzmethode gut lesbar (in Großbuchstaben)  geschrieben werden.

Team Estimation Game

Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument höre ich dabei oftmals: “Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man nun diese Diskussionen als Scrum Master ausufern läst, dauert die initiale Schätzung des Product Backlog länger als geplant. Das Team Estimation Game nach Steve Bockman liefert dazu eine schöne Lösungsmöglichkeit für dieses Problem. 

Ablauf:

Die Regeln für das Spiel sind sehr einfach gehalten und lauten:

• Das Team ist komplett vertreten. Der Product Owner ist anwesend. Der Scrum Master moderiert das Meeting.
• Alle User Stories liegen auf einzelnen Story Cards aufgedruckt und verdeckt auf einem Stapel.
• Jemand aus dem Team nimmt sich die oberste Story, liest sie laut vor und hängt sie an die Wand. Es kann bei umfangreicheren Backlogs durchaus der Boden als Platz für die Schätzung verwendet werden.
• Der nächste aus dem Team nimmt die nächste Story, liest sie laut vor und hängt sie ebenfalls an die Wand. Er hat drei Möglichkeiten:
• Die Story ist (seiner Meinung nach) ähnlich komplex wie die Erste. Dann hängt er sie neben die bereits an der Wand hängende Story.
• Die Story ist (seiner Meinung nach) weniger komplex als die bereits hängende, die neue Story wird über die bereits an der Wand hängende gehängt. 
• Die Story ist (seiner Meinung nach) komplexer als die bereits hängende, die neue Story wird unter die bereits an der Wand hängende gehängt.
• Ab der dritten Story Card gibt es die folgenden Optionen:
• Ausspielen der obersten Story Card wie oben beschrieben
• Umhängen einer bereits gespielten Karte, verbunden mit einer (kurzen) Erklärung, ohne Diskussion. Beim Umhängen der Story gegenüber dem vorherigen Teammitglied sollte diese mit einem Punkt farbig markiert werden.
• Aussetzen
• Das Spiel (Schätzklausur) ist beendet, wenn keine Story Cards mehr auf dem Tisch liegen bzw. alle Spieler aussetzen.

Man bekommt nun sehr schnell einen Überblick über die relative Komplexität des gesamten Backlogs, ohne dass man sich in Lösungsdiskussionen für einzelne Stories verlaufen hat. In der Regel wird man bei den Story Cards eine Cluster-Bildung beobachten, die sich nach dem Ende des Spiels hervorragend auf die Fibonacci-Reihe des Planning Poker Games projizieren lässt. Sollten es mehr als sieben Cluster sein (0, 1, 2, 3, 5, 8, 13, ?), kann man gemeinsam mit dem Team überlegen, ob und wie man Cluster zusammenfasst, z.B. indem man die beiden “kleinsten” Cluster zu einem macht. Dabei sollte man immer im Blick behalten, dass es sich hier um eine grobe Schätzung handelt und nicht um die Vorhersage der Zukunft.

Voraussetzung:

• Auch hier gilt als Voraussetzung, gut geschriebene (geschnittene) Backlog Items (User Stories) und ein prall gefülltes Product Backlog durch den Product Owner vorbereitet zu haben. Ausserdem sollte das Team vor dem Meeting in das Backlog sehen können. Das spart wertvolle Zeit im eigentlichen Schätzmeeting. 

Anregung:

• Je mehr farbige Punkte eine Story Card am Ende hat, desto weiter gehen offensichtlich die Meinungen bzgl. deren Komplexität auseinander. Dies ist auch ein gutes Indiz für den Product Owner, dass die Story möglicherweise noch nicht gründlich genug durchdacht wurde.

WEITERFÜHRENDE LITERATUR

Beck, K. et al. (2001): The Agile Maifesto, http://www.agilemanifesto.org, (Abfrage: 18.03.2009).

Bockmann, S. (2008): Team Estimation Game http://agileworks.blogspot.co.at/2008/01/team-estimation-game-by-steve-bockman.html. (Abfrage 14.04.2013).

Boehm, B.W.(1981): Software Engineering Economics, Boston.

Cohn, M. (2004): User Stories Applied. For Agile Software Development, Boston.

Derby, E./Larsen, D. (2006): Agile Retrospectives. Making Good Teams Great, Boston.

Grenning, J. (2002): Planning Poker. Renaissance Software Consulting. http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html. (Abfrage 14.04.2013).

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Kaner et al. (1996): Facilitator´s Guide to participatory Decision Making. New York.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, New York.

Schwaber, K. (2004): Agile Project Management with Scrum, Redmond.

Schwaber, K. (2007): The Enterprise and Scrum, Redmond.

Wirdemann, R. (2009): Scrum mit User Stories, München, Wien.