29
DER ULTIMATIVE SCRUM GUIDE Ein Buch von Malte Foegen Astrid Meyser Caroline Gansser David Croome Claudia Raak Jörg Battenfeld Anna Katharina Kröll Christoph Fritsch-Leopoldt Simon Porro Manuel Dorn

DER ULTIMATIVE SCRUM GUIDE - wibas.com · DER ULTIMATIVE SCRUM GUIDE Der Ultimative Scrum Guide ist für alle, die Scrum anwen - den oder anwenden möch - ten und ein Buch suchen,

  • Upload
    lamkhue

  • View
    291

  • Download
    0

Embed Size (px)

Citation preview

DE

R U

LTIM

ATIV

E S

CR

UM

GU

IDE

www.wibas.de

Der Ultimative Scrum Guide

ist für alle, die Scrum anwen-

den oder anwenden möch-

ten und ein Buch suchen,

das alle wichtigen Informati-

onen übersichtlich darstellt.

Er bietet wertvolles Wissen

in einem Layout, das Ihnen hilft, relevante

Informationen schnell zu finden. Gleichzeitig

lädt dieses Buch zum Stöbern ein. Der Ulti-

mative Scrum Guide ist ein Buch bei dem Sie

genau das lesen, was Sie interessiert. Und so

viel, wie Sie möchten.

Dies ist ein Buch zum Arbeiten. Das auf Ihrem

Schreibtisch liegt und immer zur Hand ist. In

dem Sie Notizen machen und das Sie zum

Erklären nutzen. Es ist ein ständiger Begleiter.

Mehr braucht es nicht. Deshalb nennen wir es

den Ultimativen Scrum Guide.

Und wenn dieser Scrum Guide für Sie noch

nicht ultimativ ist? Dann schreiben Sie uns.

Dieses Buch ergänzen wir ständig – machen

Sie mit. Wenn Sie einen Beitrag liefern, bekom-

men Sie ein Exemplar der nächsten Auflage

frei Haus. So, nun legen Sie mal los.

Malte FoegenGeschäftsführer wibas GmbH

DER ULTIMATIVESCRUM GUIDE

Ein Buch von

Malte Foegen

Astrid Meyser

Caroline Gansser

David Croome

Claudia Raak

Jörg Battenfeld

Anna Katharina Kröll

Christoph Fritsch-Leopoldt

Simon Porro

Manuel Dorn

BUCHINHALT 10

Gute Praktiken für typische Fragen » 148

Der Zweck von Scrum » 12

Das große Ganze » 26

Die Rollen in Scrum » 52

Meetings zur Optimierung der Arbeit » 64

Hilfsmittel zur Optimierung der Arbeit » 92

Techniken zum Einsatz in Scrum-Projekten » 110

11

Der ultimative Scrum Guide » Der Zweck von Scrum » Agile WerteDer ultimative Scrum Guide » Der Zweck von Scrum » Agile Werte

AGILE WERTE18

Der ultimative Scrum Guide » Der Zweck von Scrum » Agile WerteDer ultimative Scrum Guide » Der Zweck von Scrum » Agile Werte

I II III IV VErmächtigung

und Selbst-

organisation

Frühe und

regelmäßige

Lieferungen

Überprüfung

und Anpassung

Transparenz Festlegung von

Zeitfenstern

Teams sind ermächtigt und verantwortlich, alle notwendigen Entschei-dungen zur Lieferung des Ergebnisses zu treffen. Sie planen ihre Arbeit selbst und entscheiden, wie sie sie am besten durchfüh-ren können. Teams sind funktionsübergreifend und interdisziplinär.

Jedes Mitglied des Teams fokussiert sich auf die inkrementelle Lieferung des Produkts. Frühe und regelmäßige Lieferungen stellen einen stetigen Fluss von Ergebnissen sicher, welcher den Teams eine kontinuierliche Über-prüfung und Anpassung ermöglicht.

Teams reflektieren regel-mäßig darüber, wie sie effektiver und effizienter werden können. Dies bezieht sich ebenso auf die fachliche Produk-tionsweise wie auf die zwischenmenschliche Zu-sammenarbeit im Team.

Teams teilen zur Förde-rung der Zusammenarbeit Informationen und Wissen miteinander, so dass jeder auf die bestmögliche Weise dazu beitragen kann, die Ziele zu erreichen.

In Scrum hat alles ein Zeitfenster, d. h. jede Akti-vität hat einen definitiven Anfang und ein definitives Ende, die nicht verscho-ben werden. Dadurch werden Disziplin, Fokus und pünktliche Lieferun-gen sichergestellt.

19

DAS GROSSE GANZE

Ist Scrum einzigartig? » 44

Scrum Praxisbeispiel » 42

Es gibt keine 42. » 50

Mit Unsicherheit intelligent umgehen. » 48

Was Scrum ist. Und was es nicht ist. » 46

Ausgewogenheit von Stabilität und Agilität » 40

Meetings » 34

Ergebnisse » 36

Rollen » 38

Der Scrum Flow » 30

Der ultimative Scrum Guide » Das große GanzeDer ultimative Scrum Guide » Das große Ganze

27

Der ultimative Scrum Guide » Das große Ganze » Der Scrum FlowDer ultimative Scrum Guide » Das große Ganze » Der Scrum Flow

EINFACHER ALS NACH HAUSE ZU FAHREN: DER SCRUM FLOW.

30

Der ultimative Scrum Guide » Das große Ganze » Der Scrum FlowDer ultimative Scrum Guide » Das große Ganze » Der Scrum Flow

31

Das Scrum Team der Bundesbehörde für Informatik und Telekommunikation in der Schweiz hat

für das Projekt sedex erfolgreich eine Balance zwischen Stabilität und Agilität gefunden.

Der ultimative Scrum Guide » Das große Ganze » PraxisbeispielDer ultimative Scrum Guide » Das große Ganze » Praxisbeispiel

EIN BEISPIEL:SCRUM IN DER PRAXIS

42

Eine bestehende IT-Lösung für die Harmonisie-rung der Statistiken bei Behörden auf Bundes-, kantonalen und kommunalen Ebenen wird optimiert und erweitert. Dies war nötig wegen der stetig steigenden Zahl der Anwender und zunehmenden Datenvolumina. Die Arbeit wurde durch eine Dienstleistungsvereinbarung (DLV) nach Aufwand beauftragt, worin ein Kostendach und der terminliche Rahmen von einem Jahr festgelegt waren.

Desweiteren regelte die DLV die Art der Zusammenarbeit und das Vorgehen:

• Eswurdevereinbart,ScrumalsVorgehen anzuwenden. Die Gesamtzeit wurde in Sprints von je 3 Wochen Länge aufgeteilt.

• DieErweiterungensollteninFormvon Patches oder Minor-Releases zusammen- gefasst werden, die mit dem Sprint- Rhythmus synchronisiert wurden.

• DieInteraktionenmitdemProductOwner wurden festgelegt: am Anfang jedes Sprints ein Planungsmeeting; nach jedem Sprint ein Review-Meeting, bei dem die erbrachten Arbeiten abgenommen werden. In den Zwischenwochen fand jeweils ein Abstim- mungsmeetingmitdemPOstatt.

• EswurdeneinEntwicklerteam,einScrum Master und ein Einsatzplan festgelegt. Die Leistung des Entwicklerteams wird nach erbrachtem Aufwand abgerechnet.

Die gesammelten Erweiterungswünsche werden in ein Product Backlog im Tool TFS (Team Foundation Server) erfasst, priorisiert und grob geschätzt. Dann erfolgt die Detailab-sprache, Planung, Umsetzung und Abnahme der anlässlich des Planningmeetings jeweilig ausgewählten Product Backlog-Einträge iterativ in den Sprints.

Nach mehreren Sprints wurde die Kommu-nikationmitdemProductOwnerunddieSchätzung / Commitment vom Team immer zuverlässiger. Folgender Arbeitsmodus hat sich etabliert:

• JedeWocheistderProductOwnerfüreinen Tag zu Besuch beim Entwicklungsteam: einmal im Sprint für den Sprint-Wechsel und zweimal während der Sprint-Arbeit, um Fragen vom Entwicklungsteam zu klären.

• KurzvordemSprint-Wechselpasstder ProductOwnerdasProductBacklogan (aktuelle Priorisierung, angepasste Stories, neue Stories) und schickt dem Scrum Master einen Vorschlag für den nächsten Sprint.

• DerSprint-Wechselwirdwiefolgtdurch- geführt: ° Vormittags Review des vergangenen Sprints ° Sprint Planung 1 nachmittags mit dem ProductOwner.Klärungderausgewählten Erweiterungen. Ergebnis: ein Protokoll der besprochenen Abweichungen zum VorschlagdesPO. ° Sprint Planung 2 nachmittags ohne Product Owner.KlärungderAufgabenimEntwick- lungsteam, Detailschätzung. Ergebnis: unterschriebener Sprint Contract mit Angaben zu den verpflichteten Arbeiten für den folgenden Sprint.

• WährendderSprint-ArbeithatderProduct OwnerdasEntwicklungsteamniemit Änderungen gestört.

Der ultimative Scrum Guide » Das große Ganze » PraxisbeispielDer ultimative Scrum Guide » Das große Ganze » Praxisbeispiel

EIN BEISPIEL:SCRUM IN DER PRAXIS

Dieses Beispiel zeigt, wie man den scheinbar gegensätzlichen Ansprüchen von Agilität und Stabilität durch einen Vertrag und eine partnerschaftliche Arbeitsweise gerecht wird.

43

Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.

WAS SCRUM IST –UND WAS NICHT.Scrum bedeutet nicht

„Umsetzen ohne Plan“.

Scrum begrüßt Änderungen im Plan – auch sehr spät in der Umsetzung. Deswegen vermeidet Scrum die ver-schwenderische Detailplanung von Dingen, die weiter in der Zukunft liegen und die sich wahrscheinlich sowieso ändern.ZurlangfristigenOrientierunghatdasScrumTeam die Produktvision.

Der Realisierungsplan für das gesamte Produkt existiert in Form des Product Backlogs und des Releaseplans. Je näher die Product Backlog-Einträge rücken, desto detaillierter werden sie beschrieben und geschätzt. Epics werden in mehrere Stories gesplittet.

Für den Sprint gibt es einen detaillierten Task-Plan für das Entwicklungsteam.

Scrum bedeutet nicht

„Keine Dokumentation“.

Das Agile Manifest sagt einerseits, dass es wichtiger ist, einsetzbare Ergebnisse zu liefern als eine allumfassende Dokumentation zu erstellen und anderseits, dass die Interaktion mit Menschen wichtiger ist als der Einsatz von Tools und Verfahren. Die Betonung liegt auf der Diskussi-on, um ein gemeinsames Verständnis zwischen Product OwnerundEntwicklungsteamzuschaffen,aber:

Der generelle Dokumentationsgrad für jedes neue Feature wird gemeinsam in der „Definition of Done“ festgelegt, z. B. Bedienungsanleitung, Anwendungsfall, Testfall (ho-her Dokumentationsgrad) oder User Story mit Akzeptanz-kriterium (niedriger Dokumentationsgrad).

Die Planung kann nur auf einem Planning-Board doku-mentiert werden oder in einem Tool erfasst und gepflegt werden. Dies hängt von den Bedürfnissen des Scrum Teams ab. Häufig wird das Product Backlog in einem Tool erfasst und gepflegt, während das Sprint Backlog wegen der besseren Visualisierung an einer Wand in Form eines Sprint Boards geführt wird.

Dafür hilfreiche

Elemente in Scrum:

« Produktvision

Definition of Done »

« Product Backlog

« Releaseplan

« Sprint Backlog

Planning Board oder

Tool »

46

Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.

WAS SCRUM IST –UND WAS NICHT.

Scrum bedeutet nicht

„Keine Kennzahlen“.

Für die Fortschrittsverfolgung der Sprint-Arbeit gibt es tagesaktuelle Sprint-Burndown Zahlen und eine ent-sprechende Grafik, in der die Wahrscheinlichkeit der Erreichung des geplanten Umfangs bis zum Sprint-Ende immer ersichtlich ist.

Nach dem Sprint Review wird die Anzahl der im Sprint erledigten Story-Points ermittelt – die sogenannte Velocity. Dies dient der realistischeren Planung zukünftiger Sprints.

Für die Fortschrittsverfolgung der Releases gibt es Pro-dukt- bzw. Release Burndown-Zahlen und eine entspre-chende Grafik, wo die Wahrscheinlichkeit der Lieferung der für den Release geplanten Features bis zum Release-Datum immer ersichtlich ist.

Scrum bedeutet nicht

„Kein Risikomanagement“.

Die Priorisierung der Product Backlog-Einträge berück-sichtigt das Risiko. Einträge, die das Risiko vermindern können werden höher priorisiert.

Durch den iterativen Sprint-Ansatz werden sowohl Produkt-Zwischenergebnisse beim Sprint Review als auch Arbeitsweisen bei der Sprint Retrospektive früh und regel-mäßig überprüft. Dabei werden Probleme früh erkannt und Maßnahmen eingeleitet.

Durch das Daily Scrum werden Risiken täglich besprochen und adressiert.

Ein wesentliche Aufgabe des Scrum Masters ist die Beseitigung von Hindernissen.

Dafür hilfreiche

Elemente in Scrum:

Priorisierung im

Product Backlog »

« Sprint Burndown

Sprint Review und

Sprint Retrospektive »

« Velocity

Daily Scrum »

« Release Burndown

Scrum Master »

47

DIE ROLLEN IN SCRUM

Scrum Master » 58

Entwicklungsteam » 60

Scrum Team » 62

Stakeholder » 63

Product Owner » 56

Der ultimative Scrum Guide » Die Rollen in Scrum

52

Der ultimative Scrum Guide » Die Rollen in Scrum » Product OwnerDer ultimative Scrum Guide » Die Rollen in Scrum » Product Owner

PRODUCT OWNER

Der Product Owner ist für die Merkmale und den Return On Investment

(ROI) des Produkts verantwortlich. Diese Person erstellt, ordnet und ver-

waltet die Anforderungen im Product Backlog. Der Product Owner stellt

durch die öffentliche Verfügbarkeit des Product Backlogs sicher, dass das

Entwicklungsteam aus einer geschäftlichen Perspektive heraus an den

„richtigen Dingen“ arbeitet. Er oder sie entscheidet, was in einem Sprint

fertiggestellt wurde oder nicht.

Der Product Owner ist eine Person, kein Gremium, und ist bevollmäch-

tigt, endgültige Entscheidungen über das Produkt, seine Merkmale und

die Reihenfolge der Implementierung zu treffen.

Der Product Owner ist eine Person und kein Gremium. Ein Product Owner ist eine Person mit einer natürli-chen Authorität. Product Owner sind Netzwerker

und vermitteln gerne zwischen verschiede-nen Anspruchsgrup-pen.

In ihrer Arbeitszeit sind Product Owner mindes-tens 50%, idealerweise 100% mit dem Produkt beschäftigt.

56

Der ultimative Scrum Guide » Die Rollen in Scrum » Product OwnerDer ultimative Scrum Guide » Die Rollen in Scrum » Product Owner

PRODUCT OWNERCheckliste für einen

ergebnisorientierten Product Owner Kompetenzen • Siedenkenunternehmerischundvisionär. • SieübernehmenVerantwortungfüreinProdukt. • SievermittelnzwischenihrenStakeholdernundverhandelnim Sinne des bestmöglichen Produktergebnisses.

Verantwortung • SiesindverantwortlichfürdenwirtschaftlichenErfolgdesProduktes (ROI). • SiebestimmendieReihenfolgederfertigenInkrementeundden Liefertermin des Endprodukts. • SiebildendieSchnittstellezuallenStakeholdernundvertretendie Interessen des Kunden.

Aufgaben • SiegestaltendieProduktvision. • SiedefinierendenProduktumfangunddie-eigenschaften. • SieordnendieArbeit,umdenMitteleinsatzzuoptimieren. • SieüberprüfendasErgebnisundpassenggf.dieRichtungan. • SienehmendieErgebnissefürdenSprintbzw.fürdasReleaseab. • SiekommunizierendenFortschrittund-statusandieStakeholder.

„Es war gar nicht so einfach,

mich in die neue Rolle einzufinden.

Gut, dass ich einen erfahrenen Scrum Master

an der Seite hatte, der mich bei meiner

Arbeit unterstützt hat.“

57

MEETINGS ZUR OPTIMIERUNG DER ARBEIT

Der ultimative Scrum Guide » MeetingsDer ultimative Scrum Guide » Meetings

64

MEETINGS ZUR OPTIMIERUNG DER ARBEIT Sprint Planung Zwei » 76

Daily Scrum » 80

Sprint Review » 82

Sprint Retrospektive » 84

Beispiel: Ein typischer 14-Tage-Sprint » 90

Grooming » 86

Sprint Planung Eins » 74

Plan, Do, Check, Act. » 72

Sprint » 70

Der ultimative Scrum Guide » MeetingsDer ultimative Scrum Guide » Meetings

Die Zeit in Scrum » 68 65

Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.

72

Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.

PLAN, DO, CHECK, ACT. PLAN – Beim Sprint Start wird

der Sprint üblicherweise in

zwei aufeinanderfolgenden

Meetings geplant: Sprint Pla-

nung Eins und Sprint Planung

Zwei.

DO – Die Sprint Arbeit um-

fasst die wesentliche Arbeits-

zeit eines Sprints. Das Scrum

Team macht die Arbeit, um die

Einträge des Sprint Backlogs

umzusetzen und das Inkre-

ment fertigzustellen. Das Team

hält jeden Tag ein Daily Scrum

ab. Dieses dient der gemein-

samen Information, Abstim-

mung und Identifikation von

Behinderungen. Das Daily

Scrum setzt den Demingkreis

auf der täglichen Ebene um.

Üblicherweise werden wäh-

rend der Sprint Arbeit ein oder

mehrere Grooming Bespre-

chungen durchgeführt, um ein

gemeinsames Verständnis des

Product Backlogs zu erreichen

und das Backlog mit Ideen aus

dem Entwicklungsteam anzu-

reichern.

CHECK & ACT – Beim Sprint

Abschluss konzentriert sich

das Team auf eine Bewertung

des vergangenen Sprints und

bereitet den nächsten vor. Zwei

Besprechungen werden beim

Sprint Abschluss durchgeführt:

beim Sprint Review fokussiert

das Scrum Team auf das um-

gesetzte Ergebnis, während

es bei der Sprint Retrospektive

die Arbeitsweise betrachtet.

Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.

Scrum setzt den Plan-Do-Check-Act-Zyklus (Demingkreis) konsequent auf der Ebene des Sprints und eines jeden Tags um.

73

HILFREICHE TECHNIKENFÜR SCRUM-PROJEKTE

Der ultimative Scrum Guide » TechnikenDer ultimative Scrum Guide » Techniken

Sprint Burndown » 128

Magic Estimation » 126

Impediment Backlog » 146

Planning Poker » 124

Definition of Ready » 122

User Story » 118

KANO-Analyse » 120

Collocation » 116

Produktvision » 114

110

Der ultimative Scrum Guide » TechnikenDer ultimative Scrum Guide » Techniken

Retrospektiven – Aus Fehlern lernen » 130

Seestern-Retrospektive » 134

Feedback Capture Grid » 136

Zeitleiste » 138

Weitere Gedanken zu Retrospektiven » 140

Release Plan » 142

Release Burndown » 144

Fünf Phasen einer Retrospektive » 132

111

Mike Cohn (2004)

Der ultimative Scrum Guide » Techniken » User StoryDer ultimative Scrum Guide » Techniken » User Story

„User Stories ersetzen das Gespräch

zwischen Product Owner und Team nicht,

sondern dokumentieren dessen Ergebnis.“

118

Der ultimative Scrum Guide » Techniken » User StoryDer ultimative Scrum Guide » Techniken » User Story

USER STORY

User Story ist eine Technik zur

Beschreibung von Anforderungen

aus der Perspektive eines Be-

nutzers, unter Verwendung von

Alltagssprache. In Scrum werden

User Stories als Product Backlog-

Einträge verwendet.

Das Verfassen von User Stories

liegt in der Verantwortung des

Product Owners.

Eine User Story beschreibt, was

der Benutzer erreichen will und

warum.

User Stories folgen im Allgemeinen diesem Muster:

„Als NUTZER will ich ZIEL/WUNSCH damit NUTZEN.“

Eine User Story sollte kurz und präzise sein und auf eine kleine Kartei-karte passen. User Stories sind ein einfacher und leichter Weg, mit Anforderungen von Kunden umzugehen. Dabei kann es sich nicht nur um Produkt- oder Dienstleistungsanforderungen handeln, sondern auch um Lieferobjekte und nicht-funktionale Anforderungen. Das Ziel von User Stories ist es, die Anforderungen zu erfassen und sie schritt-weise zu verfeinern und aufzuschlüsseln.

Gute User Stories enthalten Anforderungen, die sich durch die INVEST-Kriterien überprüfen lassen:

[ I ] ndependent Eine User Story ist unabhängig von anderen User Stories. Eine User Story sollte möglichst nicht davon abhängen, dass zuerst eine andere User Story umgesetzt werden muss.

[ N ] egotiable User Stories sind kein in Stein gemeißeltes Gesetz. Kunden und Entwickler besprechen und präzisieren (verhandeln) sie gemeinsam.

[ V ] aluable Die User Stories sollten einen erkennbaren Nutzen liefern. Beinhaltet eine User Story keinen klaren Mehrwert, so muss sie entweder umformuliert oder gestrichen werden.

[ E ] stimable Das Entwicklungsteam muss die Arbeitsauf-wände für jede User Story schätzen können. Dazu muss die User Story klar und verständlich formuliert sein.

[ S ] mall Die User Stories sollten möglichst kurz gehal-ten werden. Als grobe Regel gilt: Die komplette Umsetzung einer User Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.

[ T ] estable Die User Stories sollten testbar sein. Tests bilden den Maßstab ob eine User Story erfolgreich abgeschlossen wurde.

119

RETROSPEKTIVEN – FRÜH FEHLER MACHEN UND SCHNELL DARAUS LERNEN.

Der ultimative Scrum Guide » Techniken » RetrospektivenDer ultimative Scrum Guide » Techniken » Retrospektiven

130

Der ultimative Scrum Guide » Techniken » RetrospektivenDer ultimative Scrum Guide » Techniken » Retrospektiven

131Es gibt viele verschiedene Techniken,

um eine Retrospektive durchzuführen.

Wir stellen Ihnen

das Vorgehen und drei Techniken vor,

mit denen Sie gleich starten können.

Der ultimative Scrum Guide » Gute Praktiken Der ultimative Scrum Guide » Gute Praktiken

Wie läuft Scrum in Service- oder Devop-Teams ab? » 160

Wie skaliert Scrum? » 166

Funktioniert Scrum außerhalb der IT? » 158

Passen Scrum und CMMI zusammen? » 156

Wie funktioniert eine Scrum Transition? » 154

Was ist Scrum Coaching? » 152

Wie beginne ich mit Scrum? » 150148

GUTE PRAKTIKEN FÜR TYPISCHE FRAGEN

Der ultimative Scrum Guide » Gute Praktiken Der ultimative Scrum Guide » Gute Praktiken

149

Ihre Kritik ist wertvoll.

Dieses Buch entsteht in Iterationen

und Sie halten gerade die erste Version

in der Hand. Das Wissen, das Sie hier

finden, dürfen Sie natürlich behalten.

Sollten Sie aber Fehler finden, dann

geben Sie sie uns bitte zurück, damit

das nächste Inkrement wieder ein

Stückchen besser wird.

Der ultimative Scrum Guide » Ihr Beitrag

SIE SIND DRAN.

Der ultimative Scrum Guide » Ihr Beitrag

168

DE

R U

LTIM

ATIV

E S

CR

UM

GU

IDE

www.wibas.de

Der Ultimative Scrum Guide

ist für alle, die Scrum anwen-

den oder anwenden möch-

ten und ein Buch suchen,

das alle wichtigen Informati-

onen übersichtlich darstellt.

Er bietet wertvolles Wissen

in einem Layout, das Ihnen hilft, relevante

Informationen schnell zu finden. Gleichzeitig

lädt dieses Buch zum Stöbern ein. Der Ulti-

mative Scrum Guide ist ein Buch bei dem Sie

genau das lesen, was Sie interessiert. Und so

viel, wie Sie möchten.

Dies ist ein Buch zum Arbeiten. Das auf Ihrem

Schreibtisch liegt und immer zur Hand ist. In

dem Sie Notizen machen und das Sie zum

Erklären nutzen. Es ist ein ständiger Begleiter.

Mehr braucht es nicht. Deshalb nennen wir es

den Ultimativen Scrum Guide.

Und wenn dieser Scrum Guide für Sie noch

nicht ultimativ ist? Dann schreiben Sie uns.

Dieses Buch ergänzen wir ständig – machen

Sie mit. Wenn Sie einen Beitrag liefern, bekom-

men Sie ein Exemplar der nächsten Auflage

frei Haus. So, nun legen Sie mal los.

Malte FoegenGeschäftsführer wibas GmbH

DER ULTIMATIVESCRUM GUIDE

Ein Buch von

Malte Foegen

Astrid Meyser

Caroline Gansser

David Croome

Claudia Raak

Jörg Battenfeld

Anna Katharina Kröll

Christoph Fritsch-Leopoldt

Simon Porro

Manuel Dorn