PECO: Scrum-Übersicht, (C) Peterjohann Consulting, 2013

AG Scrum 

Übersicht 

Agilität: 

Scrum 

Eine Übersicht 

zur Vertiefung 

für (agile) Entwickler und Projektmanager 

Stand: 03/2012 

Sie finden diese und weitere 

Präsentationen unter (-> Klick): 

http://www.peterjohannconsulting.de/index.php?menuid=downloads 

Alle Rechte vorbehalten. Reproduktion zum nicht-kommerziellen Gebrauch mit Quellenangabe 

gestattet. Reproduktion – auch auszugsweise – zum kommerziellen Gebrauch sowie der 

Gebrauch für Vortragszwecke sind nur mit schriftlicher Bewilligung des Verfassers gestattet. 

Zusammengestellt von H. Peterjohann 

zur Verteilung an Interessierte 

Version 0.54 vom 14.03.2012 

60 Seiten 

Peterjohann Consulting 

Agilität: Scrum – Eine Übersicht 

0.54 – 14.03.2012 

Seite 1 von 60



Vorbemerkung 

Agile Ansätze und Methoden sind seit einigen Jahren etabliert und haben in 

der letzten Zeit große Aufmerksamkeit und enormen Zuspruch erfahren. 

Obwohl ursprünglich für die Software-Entwicklung gedacht, durchdringen 

inzwischen agile Ansätze und Methoden auch andere Bereiche; hier ist 

insbesondere das Projektmanagement zu nennen. 

Besonders erfolgreich ist dabei Scrum, eine im Vergleich besonders einfache 

und schlanke Methode. Diese wird hier vorgestellt. 

Warum noch eine Scrum-Beschreibung? 

Obwohl Scrum „eigentlich“ sehr einfach zu erklären ist, muss sie für die 

einzelnen Zielgruppen (Einsteiger, Aufsteiger, Kenner) mit unterschiedlicher 

Tiefe erläutert werden – deshalb wurden vom Autor drei aufeinander 

aufbauende Präsentationen (siehe nächste Folie) mit durchgängig gleicher 

Darstellung erstellt. 

Dies ist eine Übersicht, die Basis-Know-how voraussetzt und innerhalb 

von wenigen Stunden durchgearbeitet werden kann. 

Auch die Kurz- und Langübersicht sind auf der Website des Autors verfügbar. 



Vorwort 

0.54 – 14.03.2012 

Seite 2 von 60



Zur Einordnung (1/2): 

Die Übersichten 

Möchten Sie in Scrum einsteigen bzw. Ihr Wissen vertiefen? Hierfür haben wir 

folgende drei Präsentationen erstellt, die Sie frei zum privaten Gebrauch 

verwenden können: 

Interesse 

Grundkenntnisse 

Kenntnisse 

Fähigkeiten 

Kurzübersicht Übersicht Langfassung 

Zielpublikum Einsteiger Aufsteiger Kenner 

Voraussetzungen keine Grundkenntnisse Kenntnisse 

Seitenzahl 16 60 ca. 100 

http://www.peterjohann-consulting.de 



Vorwort 

0.54 – 14.03.2012 

Seite 3 von 60



Zur Einordnung (2/2): 

Kennen Sie die Grundbegriffe? 

Kennen Sie diese Basisbegriffe? Wenn Nein, dann sollten Sie vorab die 

Scrum-Kurz-Präsentation (auf der Website verfügbar) lesen. 

ScrumMaster 

Selbstorganisation 

Sprint Backlog 


Sprint 

Retrospective 

Timeboxing 

Burndown Chart 

Daily Scrum 

Sprint Review 

Sprint Planning Meeting 

Team 

Product Owner 

Product Backlog 

http://www.peterjohann-consulting.de 



Vorwort 

0.54 – 14.03.2012 

Seite 4 von 60



Gliederung 

1. Einleitung und Grundlagen 6 – 18 

2. Die Rollen 19 – 23 

Gliederung 

3. Die Meetings 24 – 38 

4. Die Artefakte 39 – 48 

5. Zusammenfassung und Bemerkungen 49 – 51 

A. Anhang: Literatur, Weblinks, Sprüche und Kontakt 52 – 60 

Seite 

6-60 



0.54 – 14.03.2012 

Seite 5 von 60



Kapitel 1: 

Einleitung und Grundlagen 

Kapitel 1 

• Scrum: Was ist das? 

• Scrum: Historie 

• Scrum: Köpfe 

• Warum Scrum (und andere agile Ansätze)? 

• Wer setzt Scrum ein? 

• Der Scrum-Prozess: „Masterbild“ (Darstellung, Beschreibung) 

• Das Herz von Scrum: Der Sprint 

• Die Praktiken und Prinzipien von Scrum 

• Wann Scrum nicht eingesetzt werden sollte 

• Tipps: Das müssen Sie sich merken! 

• Die Basiselemente in der Übersicht 

Seite 

6-18 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 6 von 60



Scrum: 

Was ist das? 


• ist eine agile Methode (– auch wenn das von einigen Autoren anders 

gesehen wird). 

• bedeutet wörtlich übersetzt „Gedränge“ (Spielzug im Rugby, beschreibt das 

Gedränge der Spieler beim Einwurf des Spielballs während des Spiels) 

/Scrum-komp/. 

• ist ein Framework zur nachhaltigen Entwicklung komplexer Produkte 

/Scrum-Guide-d/ (Schwaber). 

• ist ein Framework für das Management agiler Software-Projekte /Wirde11/. 

• ist vor allem ein Change-Management-Ansatz und ein Weg für das Team-, 

Abteilungs- und Organisationsmanagement /Gloger11a/. 

• ist ein Gesamtsystem aus Meetings, Artefakten, Rollen und Werten, das 

aufbauend auf den Rahmengrundsätzen der agilen Softwareentwicklung 

ein Prozessmodell für die Entwicklung von Produkten darstellt /Scrumkomp/. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 7 von 60




Historie 

Die ersten Ansätze von Scrum wurden in den frühen 80er Jahren als Methode 

zur Produkt-Entwicklung von Ikujirō Nonaka und Hirotaka Takeuchi (beide 

Japan) entwickelt (Ursprungsquelle: „The New Product Development Game“ 

/Take86/). Der Begriff Scrum taucht erstmalig in einem Buch von de Grace auf 

/deGra90/. 

Diese Ansätze wurden ab Mitte der 90er Jahre von Jeff Sutherland, Ken 

Schwaber und Mike Beedle weiter ausgebaut und in einigen Praxisprojekten 

ausprobiert. 

Mit dem „agilen Manifest“ /Agile-Man/ wurden auch Ideen von Scrum in die 

agilen Methoden übernommen, ebenso wie Scrum einige Elemente aus dem 

agilen Manifest übernommen hat. 

Scrum hat seit 2008 einen enormen Zulauf und auch einige inhaltliche 

Erweiterungen erfahren. Die Begriffe haben sich standardisiert (so sind alle 

Fachbegriffe inzwischen auf englisch und nicht mehr auf deutsch zu 

verwenden) und einige Elemente sind dazugekommen. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 8 von 60




Köpfe 

Name 

Ikujirō Nonaka 

Bedeutung für Scrum 

Zusammen mit Hirotaka Takeuchi Vordenker von Scrum. 

Hirotaka Takeuchi siehe Ikujirō Nonaka. 

Ken Schwaber 

Jeff Sutherland 

Mike Beedle 

Mike Cohn 

Henrik Kniberg 

Boris Gloger 

Roman Pichler 

Zusammen mit Jeff Sutherland und Mike Beedle „Begründer“ von 

Scrum und auch dessen kräftigster Promoter (, der ein exzellentes 

Marketing vornimmt). Buchautor zu Scrum; oftmals in Buch- 

Vorworten zu finden. 

siehe Ken Schwaber. 

siehe Ken Schwaber. 

Scrum-Guru; Buchautor und Trainer; Verfasser der Scrum- 

Minimalübersicht, die in verschiedenen Sprachen frei verfügbar ist. 

Schwedischer Scrum-Trainer und Buch-Autor. 

Bekanntester deutscher Scrum-Trainer und Buch-Autor. 

Deutscher Scrum-Trainer und Buch-Autor. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 9 von 60



Warum Scrum (und andere agile Ansätze)? 

Folgende Beobachtungen wurden (bereits sehr früh, seit den 80er Jahren) bei 

der klassischen Software-Entwicklung gemacht: 

• 50 % der Arbeitszeit eines Programmierers/Entwicklers werden mit Lesen 

und Verstehen von Spezifikationen verbracht. 

• Nur 20 % der (ursprünglich) geforderten Merkmale werden später (in der 

Realität) tatsächlich benötigt. 

Diese Beobachtungen führten zu den agilen Ansätzen und Methoden, da diese 

die üblicherweise verwendeten Dokumente und (starren) Vorgehensweisen in 

den Hintergrund, die handelnden Personen aber in den Vordergrund stellen. 

Gerade bei Entwicklungsteams sind bei der bei Verwendung agiler Ansätze 

signifikante Leistungssteigerungen festzustellen. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 10 von 60



Wer setzt Scrum ein? 

Bekannte Firmen, die sehr früh Scrum eingesetzt haben, sind: 

• Google, die von Beginn an agile Methoden eingesetzt haben und somit 

sehr schnell auch Scrum verwenden konnten. 

• Toyota, da die Ansätze von Scrum in weiten Teilen dem Lean-Thinking des 

Toyota Production System entspricht. 

• Microsoft, die mit Ken Schwaber den Scrum-Protagonisten als Buch-Autor 

und Schulungspartner gewinnen konnten. 

Weitere Firmen, die frühzeitig Scrum verwendet haben /#Mou-Pres/: 

• Yahoo 

• Electronic Arts 

• High Moon Studios 

• Lockheed Martin 

• Philips 

• Siemens 

• Nokia 

• Capital One 

• BBC 

• Intuit 

• SAP 

• 1und1 

• Nielsen Media 

• First American Real Estate 

• BMC Software 

• Ipswitch 

• John Deere 

• Lexis Nexis 

• Sabre 

• Salesforce.com 

• Time Warner 

• Turner Broadcasting 

• Oce 

• Allianz Deutschland 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 11 von 60



Der Scrum-Prozess (1/2): 

„Masterbild“ – Darstellung 

Ein Bild, welches den minimalen Ablauf von Scrum recht gut wiedergibt 

(„Scrum Flow“), stammt von Mike Cohn /Cohn04/. Es ist recht häufig zu finden 

und wird auf der nächsten Folie beschrieben. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 12 von 60



Der Scrum-Prozess (2/2): 

„Masterbild“ – Beschreibung 

Im Product Backlog werden üblicherweise die gewünschten Anwendungsmerkmale 

(nicht Anforderungen) für das Produkt festgehalten und priorisiert. 

Hieraus entsteht das Sprint Backlog, welches diejenigen Merkmale erfasst, 

die unmittelbar im sogenannten Sprint (als grüner Kreis dargestellt; er dauert 

etwa 2-4 Wochen) umgesetzt werden sollen. 

Im Daily Scrum Meeting (welches jeden Tag stattfindet und nur wenige 

Minuten dauert) treffen sich die Entwickler und erläutern, was sie als nächstes 

umsetzen werden. Am Ende des Sprints kommt etwas „Fertiges“ heraus, also 

ein Produkt oder Inkrement, welches für sich vorzeigbar oder lauffähig ist: 

dieses wird als Potentially Shipping Product Increment bezeichnet. 

Achtung: 

Die hier vorgestellten fünf Basis-Begriffe und der Zusammenhang sind für das 

weitere Verständnis unbedingt notwendig. Product Backlog, Sprint Backlog 

und Daily Scrum Meeting werden in den nächsten Kapiteln genauer erläutert, 

der Sprint auf der nächsten Folie. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 13 von 60



Das Herz von Scrum: 

Der Sprint 

Sprint 

Der Sprint bezeichnet einen zwei- bis vierwöchigen Zeitabschnitt, in dem die 

Entwickler (nachfolgend auch als Entwicklungs-Team oder einfach Team 

bezeichnet) an der Umsetzung eines Produktinkrements arbeiten. In diesem 

Zeitraum wird das Team weitestgehend von administrativen Aufgaben 

ferngehalten, um sich so ganz der Entwicklung widmen zu können. Das Team 

organisiert sich während des Sprints selbst, es muss (und darf) keine 

Steuerung von außen erfolgen. 

Was genau umgesetzt werden soll, ergibt sich aus dem Sprint Backlog, 

welches genau die Anwendungsmerkmale enthält, die entwickelt werden. 

Jeder Sprint enthält genau ein Ziel – das sogenannte Sprint Goal, welches zu 

Beginn des Sprints festgelegt wird (hierzu später mehr). 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 14 von 60



Die Praktiken und Prinzipien von Scrum 

Scrum folgt einigen wenigen Praktiken. Diese sind: 

• Selbstorganisation: Das Team organisiert sich selbst ohne Fremdsteuerung 

• Timeboxing: Es wird immer in den genau gleichen Abständen entwickelt, 

dies sind die Sprints 

• Pull-Prinzip: Das Team bestimmt, welche Aufgaben als nächstes umgesetzt 

werden 

• Erstellung von „Potenziell auslieferbaren Produktinkrementen“ (Potential 

Shippable Code): es wird immer nutzbare Funktionalität ausgeliefert 

Als Prinzipien werden angewandt: 

• Transparenz und Feedback 

• kontinuierliches Beobachten und Anpassen (des Prozesses und 

Ergebnisses) 

• Pünktlichkeit 

• Teams scheitern nicht 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 15 von 60



Wann Scrum nicht eingesetzt werden sollte 

Scrum ist nicht für jede Art von Projekten gleichermaßen gut geeignet. 

Folgende Einschränkungen gilt es zu beachten: 

• Scrum ist auf Entwicklungsprozesse (im Kleinen) fokussiert; außerhalb der 

Entwicklung ist der Einsatz schwieriger. 

• Die Teams sollten etwa 7+/-2 Mitglieder haben. Bei kleineren Teams lohnt 

der Aufwand für die Koordinierung nicht, bei größeren funktionieren die 

Absprachen nicht mehr reibungslos. 

• Generell wird vorausgesetzt, dass alle Teammitglieder Vollzeit mitarbeiten, 

da ansonsten die Kommunikation erschwert ist und das tägliche Meeting 

(Daily Scrum) seine Bedeutung verliert. 

• Bei verteilten Teams funktioniert Scrum nicht sonderlich gut, da üblicherweise 

Besprechungen an einem Ort stattfinden, an dem sich auch die 

meistens eingesetzten Planungs-Wandtafeln befinden. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 16 von 60



Tipps: 

Das müssen Sie sich merken! 

1. Scrum funktioniert bei Projekten mit 5-7 Mitarbeitern am 

besten. 

2. Scrum verlangt, wenn man es richtig einsetzen möchte, 

organisatorische Änderungen im Unternehmen. 

3. Der Sprint ist das Herzstück von Scrum. 

4. Die Sprint-Länge wird einmal festgelegt, kann während des 

Sprints nicht verändert werden und gilt dann „bis auf 

Weiteres“. 

5. Im Sprint sind „Störungen“, wie beispielsweise Change 

Requests oder neue Anforderungen an das Produkt, 

unbedingt zu vermeiden. 

6. Das Team organisiert sich selbst. Eine steuernde Person (wie 

den „klassischen“ Projektmanager) gibt es nicht. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 17 von 60



Die Basiselemente in der Übersicht 

Folgende „Basiselemente“ sind in Scrum essentiell: 

• 3 Rollen (Product Owner, ScrumMaster, Team) 

• 6 (4+2) Meetings (Release Planning, Sprint Planning 1, Sprint Planning 2, 

Daily Scrum, Sprint Review, Retrospective) 

• 3 Artefakte (Product Backlog, Sprint Backlog, Burndown Chart) 

Die hier genannten 3 Rollen, 6 Meetings und 3 Artefakte können als „Minimalumfang“ 

gesehen werden. Viele Autoren fügen (gerade in jüngerer Zeit) 

weitere hinzu, die ebenfalls wichtig sind, jedoch nicht zum Minimalumfang 

gehören. Der Sprint gehört ebenfalls zu den Basiselementen (und wurde 

bereits vorgestellt). 

Rolle Meeting Artefakt Sprint 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 18 von 60



Kapitel 2: 

Die Rollen 

Rolle 

Kapitel 2 

• Übersicht 

• Der Product Owner 

• Der ScrumMaster 

• Das Team 

Seite 

19-23 



1. 2. 3. 

Die Rollen 

4. 5. A. 

0.54 – 14.03.2012 

Seite 19 von 60




Rolle 

Scrum kennt und definiert drei voneinander abgegrenzte Rollen: 

• Den Product Owner, der die wirtschaftliche Verantwortung für das Projekt 

trägt und die Ziele und Prioritäten der Entwicklung festlegt, 

• den ScrumMaster, der den Scrum-Prozess überwacht und die 

Arbeitsbedingungen des Teams sicherstellt und 

• das (Scrum) Team, das die Entwicklung des Produkts vornimmt. 

Deren Aufgaben und Besonderheiten werden auf den nachfolgenden Folien 

beschrieben. 

Weitere drei Rollen werden in der Literatur oftmals erwähnt (und auch hier nicht näher 

erläutert) /Gloger11a/: 

• Der Customer, der die Produktentwicklung finanziert und sie in Auftrag gibt. 

• Der Manager, der die organisatorischen Grundlagen für das Team bereitstellt. 

• Der User, der das Produkt nutzt (und für die Anforderungsermittlung wichtig ist). 



1. 2. 3. 

Die Rollen 

4. 5. A. 

0.54 – 14.03.2012 

Seite 20 von 60



Der Product Owner 

Rolle 

Der Product Owner 

• ist verantwortlich für das finanzielle Ergebnis des Projekts (ROI) 

• ist der Besitzer des Product Backlog und pflegt es auch 

• definiert die Product Features 

• priorisiert die Product Features (abhängig vom Marktwert) 

• bestimmt das Auslieferungsdatum des Product Increments und 

den Inhalt 

• akzeptiert oder weist Arbeitsergebnisse zurück 

• sollte nicht Mitglied des Teams sein, sondern aus „dem 

Management der Organisation“ kommen 

• Kürzel: PO 



1. 2. 3. 

Die Rollen 

4. 5. A. 

0.54 – 14.03.2012 

Seite 21 von 60



Der ScrumMaster 

Rolle 

Der ScrumMaster 

• ist hauptverantwortlich für die Implementierung von Scrum 

• überwacht die Einhaltung von Scrum-Werten, -Techniken und 

-Regeln 

• ist der Besitzer des Scrum-Prozesses 

• stellt optimale Arbeitsbedingungen für das Team sicher und 

schützt das Team vor äußeren Störungen 

• coacht das Team 

• übernimmt die Rolle des Veränderers (und Moderators) 

• hat eine spezielle Schreibweise: ScrumMaster (ohne 

Leerzeichen oder Bindestrich = „CamelCase-Notation“) 

• beseitigt Hindernisse (Impediments) 

• kann selbst Mitglied des Teams sein 

• Kürzel: SM 



1. 2. 3. 

Die Rollen 

4. 5. A. 

0.54 – 14.03.2012 

Seite 22 von 60



Das Team 

Rolle 

Das Team 

• setzt in jedem Sprint Teile des Product Backlogs in potenziell 

auslieferbare Produktinkremente um 

• ist der Besitzer des entstehenden Ergebnisses 

• organisiert sich selbst 

• umfasst typischerweise 5-9 Personen 

• ist für das Abschätzen der Aufwände verantwortlich 

• ist funktionsübergreifend („cross-funktional“) und verzichtet auf 

Spezialisten 

• hat Mitglieder, die bis auf wenige Ausnahmen Vollzeitmitglieder 

sein sollten und deren Mitgliedschaft sich nur den zwischen 

den (und nicht während eines) Sprints verändern kann 

• verzichtet auf Titel der Mitglieder 

• Kürzel: TM 



1. 2. 3. 

Die Rollen 

4. 5. A. 

0.54 – 14.03.2012 

Seite 23 von 60



Kapitel 3: 

Die Meetings 

Meeting 

Kapitel 3 


• Release Meeting 

• Sprint Planning Meeting 

• Sprint Planning Meeting 1 

• Sprint Planning Meeting 2 

• Daily Scrum 

• Sprint Review 

• Sprint Retrospective 

• Meetings im Sprint-Kalender 

Seite 

24-38 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 24 von 60



Übersicht (1/2) 

Meeting 

Scrum kennt und definiert sechs Meetings (früher: „Ceremonies“, dt. Zeremonien): 

• das Release Meeting 

• das Sprint Planning Meeting (1+2, werden oftmals nicht unterschieden) 

• das Daily Scrum (Tägliches Scrum-Meeting) 

• der Sprint Review 

• die Sprint Retrospective 

Deren Aufgaben und Besonderheiten werden auf den nachfolgenden Folien erläutert. 

Anmerkungen: 

1. In den Ursprungsarbeiten von Schwaber und Sutherland gibt es nur drei Meetings: 

1. das (eingliedrige) Sprint Planning Meeting, 2. das Daily Scrum Meeting und 3. 

das Sprint Review Meeting. Die hier gewählte Darstellung mit sechs Meetings ist 

inzwischen aber etabliert. 

2. Neben diesen sechs Meetings finden regelmäßig nach Bedarf Estimation Meetings 

statt, in denen das Team die Aufwände zur Umsetzung der Product Backlog Items 

schätzt. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 25 von 60



Übersicht (2/2) 

Meeting 

Meeting Typ Dauer Organisator Aktive 

Teilnehmer 

Release 

Meeting 

Sprint 

Planning 

Meeting 1 

Sprint 

Planning 

Meeting 2 

strategisch 

1-2 

Stunden 

taktisch bis zu 4 

Stunden 

taktisch bis zu 4 

Stunden 

Daily Scrum operativ 15 

Minuten 

Sprint Review taktisch bis zu 4 

Stunden 

Sprint 

Retrospective 

taktisch 1-3 

Stunden 

Product 

Owner 

Product 

Owner 

Product 

Owner 


Product 

Owner 


Product Owner, 

Team 


ScrumMaster, 

Team 


Team 


Team 



Team 

ScrumMaster. 

Team 

Wann 

Zu Beginn des Entstehungsprozesses 

& zu strategischen 

Zeitpunkten 

Zu Beginn eines Sprints 

Zu Beginn eines Sprints, 

unmittelbar nach dem Sprint 

Planning 1 

Einmal täglich; typischerweise 

morgens 

Am Ende eines Sprints 

Am Ende eines Sprints, nach 

dem Sprint Review 

Anmerkung: Die angegebenen Dauern sind Vorschläge und nicht durch Scrum festgelegt. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 26 von 60



Release Meeting (1/2) 

Meeting 

Das Release Meeting wird nach der (Initial-)Erstellung des Product Backlogs 

vorgenommen und dient zur Ermittlung und Festlegung, welche Produktstände (= 

Releases) wann ausgeliefert werden (sollen). Teilnehmer sind der Product Owner, der 

die Backlog Items priorisiert hat und das Team, welches den Aufwand zur Umsetzung 

der Backlog Items (nochmals) schätzt. 

Typischerweise findet das Release Meeting einmalig zu Beginn des Scrum-Prozesses 

und dann nach einer Anzahl festgelegter Sprints statt (üblich sind 3 bis 6 Sprints) – es 

ist ein strategisches Meeting. 

Steckbrief Release Meeting 

Zweck: Klärung, welche Releases mit welchen Inhalten wann ausgeliefert werden 

Ergebnis: Release Plan 

Basis: Product Backlog (in einer initialen Fassung mit grob abgeschätzten PBL Items) 

Dauer: maximal 2 Stunden 

Wann: Zu Beginn des Entstehungsprozesses & zu strategischen Zeitpunkten 

Teilnehmer: Product Owner, Team 

Organisator: Product Owner 

Kürzel: REL 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 27 von 60



Release Meeting (2/2) 

Meeting 

Voraussetzung für die Bestimmung der Releases sind ein (abgeschätztes) 

Product Backlog, eine (angenommene) Entwicklungsgeschwindigkeit (Velocity) 

des Teams und Ziele (des Product Owners) für die einzelnen Sprints. 

Release 

1.0 

• Login möglich 

• Grundfunktionalität 

vorhanden 

Release 

2.0 

• Gesamtlayout 

• Berichtswesen fertig 

Sprint 1 

Sprint 2 

Sprint 3 Sprint 4 

Sprint 5 

Sprint 6 

Sprint 7 

Apr May Jun Jul 

Aug Sep Oct 

Nov 

In der Literatur findet sich auch der Begriff „Estimation Meeting“, der jedoch nur das 

reine Schätzen (der Product Backlog Items) meint. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 28 von 60



Sprint Planning Meeting (1/2) 

Meeting 

Im Sprint Planning Meeting werden zu Beginn eines Sprints die Weichen für 

die Durchführung (des Sprints) gestellt. Auf Basis des Product Backlogs 

werden vom Product Owner die am höchsten priorisierten Features / User 

Stories als Vorschlag für den nächsten Sprint vorgestellt und mit dem Team 

durchgesprochen. Daraus ergibt sich das Sprint Ziel (Sprint Goal), welches 

durch einen einprägsamen Satz beschrieben werden sollte. 

Da der Aufwand zur Realisierung der Features / User Stories schon vorab 

durch das Team geschätzt worden ist und auch die Entwicklungsgeschwindigkeit 

des Teams (auch Velocity genannt) bekannt ist, können die im aktuellen 

Sprint umzusetzenden Features / User Stories im Selected Product Backlog 

festgehalten und dann im Sprint Backlog weiter in Aufgaben (Tasks) 

feinspezifiziert werden. 

Anmerkung: 

In den Ursprungsarbeiten zu Scrum wird ein Gesamt-Sprint-Planning-Meeting 

beschrieben. Diese Ausarbeitung folgt den neueren Ansätzen und teilt das Sprint 

Planning Meeting in zwei Teile, die getrennt, aber hintereinander durchgeführt werden. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 29 von 60



Team-Kapazität 

(Velocity) 


Sprint Planning Meeting (2/2) 

Sprint-Planungsmeeting 

Sprint Planning 1 

Priorisierung 

• Product Backlog 

analysieren und auswerten 

• Sprint Ziel festlegen 

Bewertet das „Was“ ! 

Analyse 

Value Estimation 

Sprint Ziel 

Meeting 

Business- 

Umgebung 

Aktuelles 

Produkt 

Technologie 


Planung 

• Entscheiden, wie man das 

Sprint Ziel erreichen kann 

(Design) 

• Sprint Backlog (Tasks) aus 

Product Backlog Items (User 

Stories / Features) erstellen 

• Sprint Backlog abschätzen 

Bewertet das „Wie“ ! 

Design 

Effort Estimation 


(nach Cohn /Scrum-Intro-d/) 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 30 von 60



Sprint Planning Meeting 1 

Meeting 

Im Sprint Planning Meeting 1 treffen sich zu Beginn eines Sprints der Product 

Owner, der ScrumMaster und das Team, um abzuklären, WAS im aktuellen 

Sprint umgesetzt werden soll. Dazu macht der Product Owner Vorschläge, 

welche der Features / User Stories aus dem Product Backlog (aus seiner 

Sicht) umgesetzt werden sollten. Diese werden, in Abstimmung mit dem Team, 

in das Selected Product Backlog aufgenommen. 

Steckbrief Sprint Planning 1 

Zweck: Festlegen der umsetzenden Features/User Stories im aktuellen Sprint, 

Herausarbeiten des Sprint Goals (Ziel des aktuellen Sprints) 

Ergebnis: Selected Product Backlog, Sprint Goal, Commitment des Teams 

Basis: Product Backlog 

Dauer: etwa 4 Stunden 

Wann: zu Beginn eines Sprints 

Teilnehmer: Product Owner, ScrumMaster, Team 

Organisator: Product Owner 

Kürzel: SP1 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 31 von 60



Sprint Planning Meeting 2 

Meeting 

Unmittelbar nach dem ersten Sprint Planning Meeting 1 werden durch das 

Team (meistens ohne den Product Owner) im Sprint Planning Meeting 2 die im 

Sprint Planning Meeting 1 ausgewählten Features / User Stories fachlich und 

technisch durchgesprochen und die einzelnen Tätigkeiten (Tasks), die 

üblicherweise in wenigen Stunden umzusetzen sind, bestimmt. Die Tasks 

werden im Sprint Backlog festgehalten und oftmals auf einer Wandtafel (Task 

Board) visualisiert. Am Ende des Meetings wissen damit die Teammitglieder, 

was im Sprint umgesetzt werden muss. 

Steckbrief Sprint Planning 2 

Zweck: Ermittlung der Tasks für den aktuellen Sprint 

Ergebnis: Sprint Backlog mit einzelnen Tasks (und evtl. Erstbefüllung des Task Boards) 

Basis: Selected Product Backlog 

Dauer: pro Sprint-Woche etwa 1 Stunde; bei vierwöchigen Sprints somit 4 Stunden 

Wann: Zu Beginn eines Sprints, unmittelbar nach dem Sprint Planning 1 

Teilnehmer: ScrumMaster, Team, optional: Product Owner 

Organisator: Team 

Kürzel: SP2 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 32 von 60



Daily Scrum (1/2) 

Meeting 

Einmal pro Tag treffen sich die Team-Mitglieder zum Daily Scrum Meeting, welches 

durch den ScrumMaster moderiert wird. Das Meeting sollte stehend stattfinden, um so 

freies Sprechen und den schnellen Fortgang zu ermöglichen. 

Folgende drei Fragen werden von jedem Team-Mitglied beantwortet: 

• Was habe ich seit dem letzten Daily Scrum Meeting gemacht? 

• Was werde ich bis zum nächsten Daily Scrum Meeting machen? 

• Was hindert mich an meiner Arbeit (Blocker/Hindernisse)? 

Steckbrief Daily Scrum 

Zweck: Besprechung, was am aktuell (= am heutigen Tag) gemacht werden soll 

Ergebnis: Alle Teilnehmer wissen, gerade gemacht wird, SBL und BC ist aktualisiert 

Basis: Sprint Backlog / Task Board 

Dauer: maximal 15 Minuten, d.h. etwa 2 Minuten pro Teilnehmer 

Wann: einmal am Tag, bevorzugt morgens 

Teilnehmer: ScrumMaster, Team; stille Zuhörer sind erlaubt 

Organisator: ScrumMaster 

Kürzel: DS 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 33 von 60



Daily Scrum (2/2) 

Meeting 

Folgende Spielregeln sollten beim Daily Scrum eingehalten werden /Scrum- 

Komp/: 

1. Das Treffen startet immer pünktlich. 

2. Das Treffen findet immer am gleichen Ort und zur gleichen Zeit statt. 

3. Das Treffen findet offen statt, jeder darf teilnehmen, aber nur die 

eigentlichen Rollen haben Sprachrecht. 

4. Das Treffen ist immer auf maximal 15 Minuten, unabhängig von der 

Teamgröße, beschränkt. 

5. Die Teilnehmer stehen während des Treffens. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 34 von 60



Sprint Review 

Meeting 

Im Sprint Review präsentiert das Team zum Abschluss eines Sprints, was es während 

des Sprints erreicht hat, d.h. wie das Potential Shippable Product (Increment) 

ausschaut. Typischerweise läuft der Sprint Review eher informell in Form einer 

Demonstration der neuen Features ab – Folienvorträge sind nicht erlaubt. Die 

User/Stakeholder diskutieren aktiv mit dem Team, der Product Owner stellt fest und 

protokolliert, was fertiggestellt wurde (und was nicht). 

Aus dem Erreichten werden dann Ideen und Vorgaben für den nächsten Sprint 

abgeleitet. 

Steckbrief Sprint Review 

Zweck: Zeigen, was im Laufe eines Sprints erreicht wurde, um Akzeptanz zu erzielen 

Ergebnis: Abnahme des Sprint-Ergebnisses durch den Product Owner 

Basis: Potential Shippable Product (Increment) 

Dauer: 2-4 Stunden 

Wann: am Ende eines Sprints 

Teilnehmer: Product Owner, ScrumMaster, Team, Stakeholder; stille Zuhörer 

Organisator: Team 

Kürzel: SR 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 35 von 60



Sprint Retrospective 

Meeting 

Bei der Sprint Retrospective werden die Probleme, die im gerade erfolgten 

Sprint aufgetreten sind, besprochen. Der ScrumMaster hinterfragt dabei die im 

Impediment Backlog aufgeführten Hindernisse und leitet Maßnahmen ein, um 

diese zu beseitigen. Die Probleme können die Teamzusammensetzung, die 

Kommunikations- und Meetingkultur, die eingesetzten Werkzeuge oder auch 

die Räumlichkeiten betreffen. 

Steckbrief Sprint Retrospective 

Zweck: Überprüfen, ob es Hindernisse bei der Sprint-Durchführung gegeben hat und 

Ableitung von Verbesserungsmaßnahmen (für den nächsten Sprint) 

Ergebnis: Überprüfter und gegebenenfalls verbesserter Scrum-Prozess 

Basis: Impediment Backlog 

Dauer: etwa 1-3 Stunden 

Wann: am Ende eines Sprints 

Teilnehmer: ScrumMaster, Team; ggf. Stakeholder 

Organisator: ScrumMaster 

Kürzel: RET 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 36 von 60



Meetings im Sprint-Kalender (1/2) 

Sprint 

Meeting 

Die Meetings sind auf der nachfolgenden Folie in ihrem zeitlichen Ablauf für 

einen Sprint grafisch dargestellt. Die Team-Mitglieder können außerhalb der 

Meetings ihre Zeit komplett für die Produktentwicklung nutzen. 

Das Release-Meeting ist nicht abgebildet, da es üblicherweise mehrere Sprints 

umfasst. 

Die Schätzmeetings (Estimation Meetings) finden nach Bedarf etwa einmal 

pro Woche mit einer Dauer von 1 bis 2 Stunden statt. Das Team wird hierzu 

von dem Product Owner eingeladen. Es werden die Aufwände zur 

Realisierung der Product Backlog Items durch das Team abgeschätzt. 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 37 von 60



Meetings im Sprint-Kalender (2/2) 

Sprint 

Meeting 

Sprint 

1. Woche 

2. Woche 

3. Woche 

4. Woche 

- 

Mo 

Di Mi Do Fr Mo Di Mi Do Fr Mo Di Mi Do Fr Mo Di Mi Do Fr Mo 

Daily Scrum Daily Scrum Daily Scrum 


Di 

DS 

08:00 

-12:00 

SP 

1 

Develop Time 

Develop Time 

Develop Time 

Develop Time 

S 

R 

SP 

1 

13:00 

-17:00 

SP 

2 

Develop Time 

Develop Time 

Develop Time 

Develop Time 

R 

E 

T 

SP 

2 

EST 

EST 

EST 

EST 

SP1 

SP 2 



etwa 2-4 Stunden 



SR 

- max 15 Minuten 

Sprint Review 


REL Release etwa 2-4 Stunden 

RET 

Sprint Retrospective 


EST Estimation etwa 1-2 Stunden 



1. 2. 3. 

Die Meetings 

4. 5. A. 

0.54 – 14.03.2012 

Seite 38 von 60



Die Artefakte 

Artefakt 

Kapitel 4 


• Product Backlog (Aufbau, Aussehen, Workflow) 

• Sprint Backlog (Aufbau, Aussehen) 

• Burndown Chart (Aufbau, Aussehen) 

Seite 

39-48 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 39 von 60




Artefakt 

Scrum kennt und definiert drei Artefakte: 

• das Product Backlog 

• das Sprint Backlog 

• das Burndown Chart 

Deren Aufgaben und Besonderheiten werden auf den nachfolgenden Folien 

beschrieben. 

Weitere typische Dokumente, die hier nicht erläutert werden, sind: 

• das Impediment Backlog, welches die Hindernisse im Sprint festhält und bei 

der Sprint Retrospective besprochen wird 

• der Release Plan, welcher die nach außen sichtbaren Versionsstände (die 

im Release Meeting ermittelt werden) im vorhinein benennt 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 40 von 60



Product Backlog (1/4): 

Aufbau 

Artefakt 

Das Product Backlog enthält die Beschreibungen der (von den Anwendern 

gewünschten) Merkmale (Features) des zu erstellenden Produkts. Diese 

werden in einzelnen Punkten, den sogenannten Product Backlog Items, 

„tabellenartig“ festgehalten (siehe nächste Folie). 

Die Backlog Items selbst sind bevorzugt User Stories (hierzu mehr im 

nächsten Kapitel), es können aber auch Mindmaps o.Ä. verwendet werden. 

Typischerweise wird das Product Backlog über ein Software-Tool verwaltet. 

Steckbrief Product Backlog 

Zweck: Hält die Beschreibungen der gewünschten Merkmale fest 

Umfang: groß, da alle Merkmale (nach und nach) enthalten sind 

Basis für: alle weiteren Aktivitäten 

Erstellungszeitpunkt: (Initial) vor dem eigentlichen Scrum-Prozess 

Update-Zyklus: regelmäßig 

Wird verwendet durch: Product Owner, Team; für jedermann öffentlich einsehbar 

Besitzer: Product Owner 

Kürzel: PBL 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 41 von 60




Aussehen 

Artefakt 

Das Product Backlog kann als Tabelle aufgebaut sein und dann folgenden, 

minimalen Aufbau besitzen: 

ID 

Beschreibung 

Priorität 

Story Points 

Notizen 

1 

2 

3 

Eintrag durch 

das Team 

4 

Eintrag durch 

Product Owner 

ID 

Beschreibung 

Priorität 

Story Points 

Notizen 

Fortlaufende ID, durch das System generiert 

Freitext - oder besser: Story-Text, wenn es User Stories sind 

Priorität; typische Skalen [A, B, C] oder [hoch, mittel, niedrig] 

Abschätzung für den Aufwand 

Freitext; kann auch leer bleiben 

Ein Product Backlog Item entspricht genau einer Zeile in der Tabelle. 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 42 von 60




Workflow 1v2 

Artefakt 

Das Product Backlog wird fortlaufend vom Product Owner ergänzt und gepflegt; zu 

Beginn werden die Einträge gruppiert eingetragen (1) und anschließend priorisiert (2). 

Das Schätzen des Realisierungsaufwands (der hochpriorisierten Backlog Items) erfolgt 

durch das Team (3), welches dann eine Detaillierung vornimmt (4). 

1. 2. 3. 4. 

PBL 

PBL 

PBL 

PBL 

Priorität A 

Priorität B 

Priorität C 

Priorität A 

Priorität B 

Priorität C 

1 

3 

1 

5 

3 

1 

1 

1 

5 

Priorität A 

Priorität B 

1 

3 

1 

5 

3 

1 

1 

• gruppiert 

• unpriorisiert 

• nicht abgeschätzt 

• nicht detailliert 

• gruppiert 

• priorisiert 

• nicht abgeschätzt 


• gruppiert 


• abgeschätzt 


• gruppiert 



• detailliert 

Themengruppe 1 





1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 43 von 60




Workflow 2v2 

Artefakt 

Aus dem Product Backlog werden im Sprint Planning Meeting 1 die am höchsten priorisierten 

Backlogs Items ausgewählt (5+6) (und „virtuell“ ins Selected Product Backlog 

übertragen). Auf Basis der Schätzungen und der Teamgeschwindigkeit gelangen diese 

Backlog Items in das Sprint 

Backlog (7) und werden 

realisiert. 






1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 44 von 60



Sprint Backlog (1/2): 

Aufbau 

Artefakt 

Das Sprint Backlog enthält die Beschreibung der in dem aktuellen Sprint 

umzusetzenden Merkmale (Features/User Stories). Da die Merkmale aus dem 

Product Backlog (Items) abgeleitet werden, hat das Sprint Backlog prinzipiell 

den gleichen Aufbau wie das Product Backlog, jedoch sind die Features auf 

Tasks (einfach umsetzbare Teilbereiche) „runtergebrochen“. 

Das Sprint Backlog wird oft über das Task Board visualisiert (siehe nächstes 

Kapitel), es können auch Software-Tools verwendet werden (siehe Anhang). 

Steckbrief Sprint Backlog 

Zweck: Hält fest, was (welche Features/User Stories) in einem Sprint umgesetzt werden 

Umfang: klein, da nur die Merkmale eines Sprints enthalten sind 

Basis für: Umsetzung im Sprint; Burndown Chart 

Erstellungszeitpunkt: Bei Sprint-Start (im Sprint Planning) 

Update-Zyklus: regelmäßig (täglich im Daily Scrum) 

Wird verwendet durch: Team; für jedermann öffentlich einsehbar (über Task Board) 

Besitzer: Team 

Kürzel: SBL 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 45 von 60



Sprint Backlog (2/2): 

Aussehen 

Artefakt 

Im Sprint Planning Meeting 2 werden die im Selected Backlog enthaltenen 

Items ins Sprint Backlog übertragen und dort weiter in Tasks unterteilt, die 

dann durch das Team realisiert werden. 

7. 


(SBL) 

A 

A 

A 

A 

B 

1 

3 

1 

5 

3 

Status 

8. Sprint Backlog 

(SBL) 

A 

A 

A 

A 

B 

1 

3 

1 

5 

3 

Task 

Status 

Das Sprint Backlog hat große 

Ähnlichkeit mit dem Product Backlog, 

ist jedoch zumindest um zwei Spalten 

ergänzt (rote Pfeile): 

• eine Spalte, die die Tasks aufnimmt 

(falls notwendig) 

• eine Spalte, in der der 

Umsetzungsstatus festgehalten 

wird 

• gruppiert 




• + ausgewählt 

• + in Sprint übertragen 

• gruppiert 




• + ausgewählt 

• + in Sprint übertragen 

• + in Tasks eingeteilt 

Bereits umgesetzte Items werden aus 

dem Sprint Backlog „entfernt“, so dass 

das SBL am Ende des Sprints „leer“ ist.. 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 46 von 60



Burndown Chart (1/2): 

Aufbau 

Artefakt 

• Das (Sprint) Burndown Chart zeigt die Umsetzung von der Story Points während 

eines Sprints an. Dabei werden die im aktuellen Sprint noch umzu-setzenden Story 

Points auf der Y-Achse eingetragen. Die X-Achse enthält den zeitlichen Verlauf, so 

dass jederzeit den Stand der Umsetzung erkennbar ist. 

• Alternativen: Zu erbringende Stunden statt Story Points auf der Y-Achse 

• Ähnlich: Release Burndown Chart (dort wird der Gesamtfortschritt betrachtet) 

Steckbrief Burndown Chart (für Sprints) 

Zweck: Zeigt, wie weit die Umsetzungen in einem Sprint fortgeschritten sind 

Umfang: eine Grafik, da nur die Merkmale des aktuellen Sprints enthalten sind 

Basis für: allgemeines Berichtswesen 

Erstellungszeitpunkt: Bei Sprint-Start 

Update-Zyklus: regelmäßig (im Sprint-Berichtszyklus, typischerweise ein bis zweitäglich 

oder beim Daily Scrum) 

Wird verwendet durch: Team; für jedermann öffentlich einsehbar 

Besitzer: Team 

Kürzel: BC 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 47 von 60



Burndown Chart (2/2): 

Aussehen 

Artefakt 

Story 

Points 

Das hier dargestellte Sprint 

Burndown Chart zeigt den 

Verlauf eines 20-Tage-Sprints 

bis zu 14ten Tag. Die 

Geschwindigkeit des Teams 

beträgt 55 Story Points pro 

Sprint. 

Zu Stichtag entsprechen die 

tatsächlich umgesetzten Story 

Points dem idealen Verlauf. 

50 

45 

40 

35 

30 

25 

20 

15 

10 

idealer Verlauf 

tatsächlicher Verlauf 

5 

1 3 5 7 9 11 13 15 17 19 

today 

Time 



1. 2. 3. 

Die Artefakte 

4. 5. A. 

0.54 – 14.03.2012 

Seite 48 von 60



Zusammenfassung und Bemerkungen 

• Das „große Bild“: Rollen, Meetings und Artefakte im 

Zusammenspiel 

• Was sie bis hierher kennen sollten 

Kapitel 5 

Seite 

49-51 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 49 von 60



Das „große Bild“: 

Rollen, Meetings und Artefakte im Zusammenspiel 

Rolle 

Meeting 

Artefakt 

Sprint 

Planning 1 

Release 


Sprint 

Planning 2 

Product 

Backlog 

Sprint 

Backlog 

Sprint 

Sprint 

Review 

Burndown 

Chart 

Sprint 

Retrospective 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 50 von 60



Was Sie bis hierher kennen sollten 

Die folgenden Begriffen „rund um Scrum“ sollten Sie nun einordnen und 

beschreiben können (die „grünen“ Begriffe wurden hier bereits vorausgesetzt): 


Impediment (Backlog) 

Selbstorganisation 

Burndown Chart 

Potential Shippable Product 



Team 


Estimation Meeting 

Sprint Review 

Sprint Goal 

Release 

Sprint 

Sprint Planning Meeting 


Retrospective 

Timeboxing 

Product Owner 

Sie wollen Ihr Scrum-Wissen weiter vertiefen? Lesen Sie bitte dazu die Langfassung. 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 51 von 60



Anhang: 

Literatur, Weblinks, Sprüche und Kontakt 

• Literatur 

• Weblinks 

• Sprüche 

• Kontakt zum Autor 

Anhang 

Seite 

52-60 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 52 von 60



Literatur (1/3) 

/Appelo11/ Jurgen Appelo: Management 3.0: Leading Agile Developers, Developing Agile Leaders, Addison- 

Wesley Professional, Old Tappan (NJ) 2011, ISBN 978-0-321-71247-9 

/Cohn04/ Mike Cohn: User Stories Applied: For Agile Software Development, Addison-Wesley Longman, 

Amsterdam 2004, ISBN 978-0-321-20568-1 

/Cohn05/ Mike Cohn: Agile Estimating and Planning, Prentice Hall International, Upper Saddle River (New 

Jersey) 2005, ISBN 978-0-13-147941-8 

/Cohn09/ Mike Cohn: Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Longman, 

Amsterdam 2009, ISBN 978-0-321-57936-2 

/Cohn10a/ Mike Cohn: User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a., mitp-Verlag, Bonn 

2010, ISBN 978-3-8266-5898-3 

/Cohn10b/ Mike Cohn: Agile Softwareentwicklung: Mit Scrum zum Erfolg!, Addison-Wesley, München 2010, ISBN 

978-3-8273-2987-5 

/deGra90/ Peter deGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalogue of Modern 

Engineering Paradigms, Prentice Hall International, Upper Saddle River (New Jersey )1990, ISBN 978-0- 

13590-126-7 

/Gloger11a/ Boris Gloger: Scrum: Produkte zuverlässig und schnell entwickeln. Mit beigehefteter Scrum- 

Checkliste 2010, Hanser, München 3. Auflage 2011, ISBN 978-3-446-42524-8 

/Gloger11b/ Boris Gloger, Andre Häusling: Erfolgreich mit Scrum – Einflussfaktor Personalmanagement: Finden 

und Binden von Mitarbeitern in agilen Unternehmen, Hanser, München 2011, ISBN 978-3-446-42515-6 

/Gloger13/ Boris Gloger: Scrum: Produkte zuverlässig und schnell entwickeln, Hanser, München, 4. Auflage 

2013, ISBN 978-3-446-43338-0 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 53 von 60




/Kniberg07/ Henrik Kniberg: Scrum and XP from the Trenches, lulu.com, Raleigh (NC) 2007, ISBN 

978-1-4303-2264-1 

/Kniberg10/ Henrik Kniberg, Mattias Skarin: Kanban and Scrum – Making the Most of Both, 

lulu.com, Raleigh (NC) 2010, ISBN 978-0-557-13832-6 

/Nonaka95/ Ikujiro Nonaka, Hirotaka Takeuchi: The Knowledge-Creating Company: How Japanese 

Companies Create the Dynamics of Innovation, Oxford University Press, Oxford 1995, ISBN 

978-0-19-509269-1 

/Pichler07/ Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen, dpunkt, 

Heidelberg 2007, ISBN 978-3-89864-478-5 

/Pichler10/ Roman Pichler: Agile Product Management with Scrum: Creating Products That 

Customers Love, Addison-Wesley Longman, Amsterdam 2010, ISBN 978-0-321-57936-2 

/Pichler11/ Roman Pichler, Stefan Roock: Agile Entwicklungspraktiken mit Scrum, dpunkt, 

Heidelberg 2011, ISBN 978-3-89864-719-9 

/Rasmus10/ Jeff Rasmusson: The Agile Samurai: How Agile Masters Deliver Great Software 

Pragmatic Programmers, Raleigh (NC) 2010, ISBN 1-978-1-934356-58-6 

/Schwaber01/ Ken Schwaber, Mike Beedle: Agile Software Development with Scrum, Prentice Hall 

International, Upper Saddle River (New Jersey) 2001; ISBN 978-0-13-067634-4 

/Schwaber04/ Ken Schwaber: Agile Project Management with Scrum, Microsoft Press, Redmond 

(Washington) 2004, ISBN 978-0-7356-1993-7 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 54 von 60




/Schwaber07a/ Ken Schwaber: Agiles Projektmanagement mit Scrum, Microsoft Press, München 

2007, ISBN 978-3-86645-631-0 

/Schwaber07b/ Ken Schwaber: The Enterprise and Scrum, Microsoft Press, Redmond 

(Washington) 2007, ISBN 978-0-7356-2337-8 

/Schwaber08a/ Ken Schwaber: Agile Software Development with Scrum, Prentice Hall 

International, Upper Saddle River (New Jersey) 2008, ISBN 978-0-13-207489-6 

/Take86/ Hirotaka Takeuchi and Ikujiro Nonaka: New Product Development Game in Harvard 

Business Review, January-February 1986, p. 137-146. Beispielsweise zu finden unter: 

https://www.iei.liu.se/fek/frist/723g18/articles_and_papers/1.107457/TakeuchiNonaka1986HBR 

.pdf 

/Wirde11/ Ralf Wirdemann: Scrum mit User Stories, Hanser, München 2. Auflage 2011, ISBN 978- 

3-446-42660-3 

/Wolf10a/ Henning Wolf, Wolf-Gideon Bleek: Agile Softwareentwicklung. Werte, Konzepte und 

Methoden, dpunkt, Heidelberg zweite Auflage 2010, ISBN 978-3-89864-701-4 

/Wolf10b/ Henning Wolf, Rini van Solingen, Elco Rustenburg: Die Kraft von Scrum: Inspiration zur 

revolutionärsten Projektmanagement-Methode, Addison-Wesley, München 2010, ISBN 978-3- 

8273-3052-9 

/Wolf11/ Henning Wolf: Agile Projekte mit Scrum, XP, Kanban im Unternehmen durchführen: 

Erfahrungsberichte aus der Praxis, dpunkt, Heidelberg 2011, ISBN 978-3-89864-752-6 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 55 von 60



Weblinks (1/3) 

Zeitschriften-Artikel zum freien Download 

/OS-Agile-Zerts/ OBJEKTspektrum, 25.08.2012: „Agile Personen-Zertifizierungen: 

Möglichkeiten und Vergleiche“: http://www.sigsdatacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht.html?tx_mwjourna 

ls_pi1%5Bpointer%5D=0&tx_mwjournals_pi1%5Bmode%5D=1&tx_mwjournals_pi1 

%5BshowUid%5D=7219, Artikel vom Autor dieser Präsentation zum kostenfreien 

Download; eingesehen am 25.08.2012 

/OS-Agility-2011/ OBJEKTspektrum, 20.10.2011: Online-Special „Agility 2011“: 

http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/onlinethemenspecials/artikelansicht.html?show=2895, 

9 pdf-Einzelartikel zum kostenfreien 

Download; eingesehen am 07.03.2012 

/OS-Agility-2010/ OBJEKTspektrum, 2010: Online-Special „Agility 2010“: 


12 pdf-Einzelartikel zum 

kostenfreien Download; eingesehen am 07.03.2012 

/OS-Agility-2009/ OBJEKTspektrum 2009: Online-Special „Agility 2009“: 


17 pdf-Einzelartikel zum 

kostenfreien Download; eingesehen am 07.03.2012 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 56 von 60




Kostenfreie & Empfehlenswerte Downloads 

/#Kniberg07/ Frei verfügbare pdf-Version des Buchs /Kniberg07/ „Henrik Kniberg: 

Scrum and XP from the Trenches“ inkl. Übersetzungen in einige Sprachen (z.B. 

deutsch): http://www.infoq.com/minibooks/scrum-xp-from-the-trenches; eingesehen 

am 07.03.2012 

/#Mou-Pres/ Seite mit direkt verwendbarer Grundlagen-Präsentation von Mike Cohn in 

mehreren Sprachen: http://www.mountaingoatsoftware.com/presentations/30-anoverview-of-scrum; 

eingesehen am 07.03.2012 

/#Scrum-Guide-e/ (Englische) Website mit 16seitiger Kurzdarstellung von Ken 

Schwaber und Jeff Sutherland, aktualisiert im Oktober 2011: 

http://www.scrum.org/scrumguides; eingesehen am 07.03.2012 

/#Scrum-Guide-d/ Website mit 19seitiger Kurzdarstellung von Ken Schwaber und Jeff 

Sutherland – deutsche Übersetzung – aktualisiert im Oktober 2011: 

http://www.scrum.org/scrumguides; eingesehen am 07.03.2012 



1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 57 von 60




Interessante Websites zu Scrum und Agilität 

/Agil-Glos/ Glossar für die wichtigsten agilen Begriffe (deutsch); in: 

http://www.holisticon.de/cms/AgileGlossar/Startseite; eingesehen am 07.03.2012 

/Agil-Man/ Das agile Manifest: http://agilemanifesto.org; eingesehen am 07.03.2012 

/Beyond-Scrum/ Website (englisch) mit Anmerkungen und Templates für Scrum: 

http://www.beyond-scrum.de; eingesehen am 07.03.2012 

/Scrum-Browser/ Scrum-Browser (engl.) von Wibas, kurze Definitionen zu Scrum: 

http://www.scrumbrowser.com; eingesehen am 07.03.2012 

/Scrum-komp/ Deutsche Website mit kurzer Darstellung von Scrum: http://www.scrumkompakt.de; 


/#Wiki-Agilität/ Wikipedia: 

http://de.wikipedia.org/wiki/http://de.wikipedia.org/wiki/Agile_Softwareentwicklung; 


/#Wiki-e-Agility/ Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development; 




1. 2. 3. 4. 5. A. 


0.54 – 14.03.2012 

Seite 58 von 60



Sprüche 

Tom Gilb: „What's the difference between a methodologist and a terrorist? One 

can negotiate with a terrorist.” 

„Je mehr Du nach Plan arbeitest, um so mehr bekommst Du das, was Du 

geplant hast, aber nicht das, was Du brauchst.“ /Wiki-d/ 

Jim York: „Scrum is simple. Doing Scrum is hard.“ 

Dwight Eisenhower: „Planning is everything, the plan is nothing.“ 

Fa. Holisticon: „Projektmanagement braucht keine Balken.“ 



1. 2. 3. 4. 5. A. 

Literatur, Weblinks, Sprüche, und Kontakt 

0.54 – 14.03.2012 

Seite 59 von 60



Kontakt zum Autor 

Sie benötigen noch weitere Informationen? 

Kontaktieren Sie uns! 


Dipl.-Inform. 

Horst Peterjohann 

Asamstraße 24 

81541 München 

Telefon: 0 89 / 48 95 34 53 

Mobil: 0 162 / 9 77 47 65 

E-Mail: kontakt@peterjohann-consulting.de 

Website: http://www.peterjohann-consulting.de 



1. 2. 3. 4. 5. A. 

Literatur, Weblinks, Sprüche, und Kontakt 

0.54 – 14.03.2012 

Seite 60 von 60

PECO: Scrum-Übersicht, (C) Peterjohann Consulting, 2013

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?