Agilität in a nutshell: Teil 1

SCRUM…damit Sie wissen worum es geht, wie es geht

und wofür man es gebrauchen kann.

Die PMD Akademie ist das Weiterbildungsinstitut der DMS Gruppe

2

(Vor)Urteile SCRUM

Unserer Mitarbeiter sind nicht in der Lage, ohne Hierarchie auszukommen

So´n Zeug brauchen wir nicht

3

Das Problem

1. Projektziele nicht klar definiert 71%

2. Zeitvorgaben sind unrealistisch 61%

3. Mangelnde Abstimmung aller am Projekt Beteiligten 55%

4. Fehlerhafte Kommunikation innerhalb des Unternehmens 45%

5. Projektleiter sind überlastet 44%

6. Budgetrahmen ist unrealistisch 43%

7. Feinplanung erfolgt nicht sorgfältig genug 41%

8. Komplexität des Vorhabens wird unterschätzt 39%

9. Berichtswesen/Reporting funktioniert nicht reibungslos 36%

10. Es fehlt ein Projekt-Cockpit, aus dem heraus das Projekt

gesteuert wird

36%

Die größten Projektfehler

Ergebnis einer Studie aus 2007 die das auf Project Management Offices (PMO) spezialisierte Beratungshaus Assure Consulting durchgeführt hat. 4

Projekt-planung

Terminsituation

Personalsituation

der BeteiligtenAusrichtung

des Unternehmens

Persönliche

SituationPolitik, Umwelt

Kostendruck

Interessen

Einzelner

Interessen

Geschäftsführung

Projekt-Einflussfaktoren

Seite 5 5Quelle: W.M.Walter, PMD Akademie- 2018

bekannt unbekannt

be

ka

nnt

un

be

kann

t

An

ford

eru

ng

en

Technologie

1

1

1

1

2

4

4

3 3

3 4

4

22

2 3

32

23

einfach

kompliziert

komplex

chaotisch

Kompliziertheit ist ein Maß für Unwissenheit. Sie verschwindet durch Lernen.

Komplexität ist das Maß für die Menge der Überraschungen, mit denen man rechnen muss.

6

Kompliziertheit versus Komplexität

Quelle: W.M.Walter, PMD Akademie- 2018

7

I.2018 II.2018

Januar Februar März April Mai Juni Juli

A-Nr. Aktivität Verantwortlich Aufwand in AT Vorgänger Nachfolger Status 1 KW 2 KW 3 KW 4 KW 5 KW 6 KW 7 KW 8 KW 9 KW 10 KW 11 KW 12 KW 16 KW 20 KW 21 KW 22 KW 23 KW 24 KW 28 KW

10.2.13 a1 m1 5 10.2.15 o

10.2.14 a2 m1 10 o

10.2.15 a3 m2 1010.2.13 12.01.01 a

10.2.16 a4 m2 20 e

10.2.17 a5 m1 35 a

12.01.01 a6 m3 1010.2.13 e

12.01.02 a7 m3 100 e

12.01.03 a8 m2 50 e

12.01.04 a9 m1 35 14.13.03 a

12.01.05 a10 m1 10 a

14.13.01 a11 m1 20 o

14.13.02 a12 m3 10 o

14.13.03 a13 m3 5 o

Pla

nu

ng

su

ns

ch

ärf

e

Projektverlauf

1 bis 6 Monate > 12 Monate7 bis 12 Monate

Das Problem von Prognosen ist, dass die Zukunft nicht in der Vergangenheit liegt

Planungs-Unschärfe

Quelle: W.M.Walter, PMD Akademie- 2018

8

Die Lösung

Klassische Planung ./. Agiles Vorgehen

Klassisches Vorgehen

• möglichst langfristig

• häufig detailliert

• hoher Erstellungsaufwand

• pseudo-stabile Planung

• relativ unflexibel

• ggf. hohe Unschärfe

• späte Erfolgserlebnisse

• Korrekturen recht aufwendig

• Auswirkungen erst spät spürbar

• Austausch untereinander spärlich

Agiles Vorgehen

• eher kurzfristig ausgerichtet

• nur so detailliert wie nötig

• geringer Erstellungsaufwand

• kurzfristig-stabile Planung

• sehr flexibel

• geringe Unschärfe

• kurzfristige Erfolgserlebnisse

• Korrekturen einfach umzusetzen

• Auswirkungen sofort spürbar

• Regelm. Austausch untereinander

9

• Kommunikation und Transparenz stehen im Vordergrund

• Veränderungen zur Produktverbesserung sind stets willkommen

• Geliefert wird so früh und regelmäßig wie möglich

• Fachliche wie technische Excellence wird angestrebt

• Zu Kunden wird ein enges und kollaboratives Verhältnis gepflegt

• Kontinuierliche Weiterentwicklung und Prozessverbesserung sind zentrale Faktoren

Was bedeutet überhaupt Agilität

10

11

Konservative Planung ./. Adaptive Planung

Bei der konservativen Planung finden ungeplante Ereignisse statt.

Tritt eine neue Situation (ein Ereignis) ein, wird sich um das

Ereignis gekümmert.

Bei der adaptiven Planung werden Ereignisse provoziert.

(Feedback-Runden bei Auslieferung)

Wurde ein Feedback eingeholt, wird die neue Situation und die

ursprüngliche Planung „gemerged“ (gemischt).

Ereignis-

Management

Planungs-

Management

12

Inkrementelle Vorgehensweise

Verschiedenen Teile des Systems werden zu unterschiedlichen Zeiten und mit verschiedenen Geschwindig-

keiten entwickelt, es erfolgt ein umgehende Integration ins Gesamtsystem.

Gegenbild: gleichzeitige Integration aller Teilsysteme zum Abschluss des Projekts (Big-Bang-Integration).

Das Ergebnis eines inkrementellen Arbeitsschritts ist nicht notwendigerweise Gegenstand weiterer Über-

arbeitung, noch dienen Ergebnisse aus Tests und Benutzerreaktionen als Vorgabe für nachfolgende Arbeits-

schritte.

Iterative Planung

Das Ergebnis wird auf notwendige Änderungen untersucht, vor allem hinsichtlich einer Anpassung der Ziele

späterer Iterationen.

Das Projektteam ist in der Lage, Erfahrungen aus vorangegangenen Entwicklungsschritten unmittelbar zu

nutzen. Erfahrungen werden gezielt sowohl während der Entwicklung als auch aus der Verwendung des

bereits abgeschlossenen Teils des Systems gewonnen.

Bei jeder Iteration kann der Entwurf angepasst werden.

Inkrementelle Vorgehensweise, Iterative Planung

13

Prognose-Genauigkeit über anstehende Aufgaben

Pro

gn

oseg

en

au

igkeit

Pro

gn

oseg

en

au

igkeit

Zeit bis zur Fertigstellung Zeit bis zur Fertigstellung

Konservativ Iterativ bzw. Inkrementell

Quelle: W.M.Walter, PMD Akademie- 2018 Quelle: W.M.Walter, PMD Akademie- 2018

Scrum bedeutet "Menschenauflauf" oder "Gedränge“, ist

aber auch ein Spielzug im Rugby-Sport.

Scrum wurde 1986 von den zwei Wirtschaftswissenschaftlern

Hirotaka Takeuchi und Ikujiro Nonaka entwickelt.

Scrum

Ken Schwaber und Jeff Sutherland haben 1990 die

Idee aufgegriffen und 1995 SCRUM publiziert mit der

Definition:

"Ein Rahmenwerk, innerhalb dessen Menschen komplexe

adaptive Aufgabenstellungen angehen können, und durch

das sie in die Lage versetzt werden, produktiv und kreativ

Produkte mit dem höchstmöglichen Wert auszuliefern."

14

15

Scrum wurde ursprünglich dazu entwickelt, um Produkte zu managen und zu entwickeln. Seit den frühen

1990er Jahren wird Scrum weltweit ausgiebig genutzt zur:

1. Erforschung und Identifizierung rentabler Märkte, Technologien und Produktfähigkeiten

2. Entwicklung von Produkten und Erweiterungen

3. Auslieferung von Produkten und Erweiterungen, regelmäßig und mehrmals täglich

4. Entwicklung und Aufrechterhaltung von Cloud-Umgebungen (online, sicher, on-demand) und anderer

Produktivumgebungen

5. Erhaltung und Erneuerung von Produkten

Warum Scrum *)

*) ©2017 Ken Schwaber and Jeff Sutherland. , Scrum Guide German, Seite 4

16

Das sollten Sie im Vorfeld wissen

Die Erfinder beschreiben SCRUM als

• Leichtgewichtig

• Einfach zu verstehen

• Schwierig zu meistern

Bedeutet:

Ein Marathonläufer muss seine Kondition der zu laufenden Distanz anpassen und man darf nicht die Distanz

verändern, weil die konditionellen Anforderungen nicht erfüllt werden. Dann ist es kein Marathon mehr.

Bei einem SCRUM-Projekt muss die Organisation den Regeln angepasst werden und man darf nicht die

Regeln der Organisation anpassen(*), weil diese aktuell nicht über die Befähigung verfügt. Dann ist es kein

SCRUM mehr.

*) Ausgenommen die täglichen Meetings, die auch alle 2 Tage stattfinden können

Quelle: www.boehmwanderkarten.de

Rahmenbedingungen schaffen

Auch bei einem Agilen Projektmanagement brauchen Menschen Leitplanken zur Orientierung.

17

18

Das SCRUM-Rahmenwerk (Framework)

Rollen

Events Artefakte

Regeln

Wer trägt die Gesamt-

Verantwortung?

Wer ist für die Umsetzung

verantwortlich?

Wer unterstützt?

Was ist in Summe zu tun?

Was ist im Detail zu tun?

Welche Schwierigkeiten

tauchen auf?

Wann stimmen wir uns ab?

Wann stellen wir etwas vor?

Wann lernen wir aus

unseren Erfahrungen?

Quelle: W.M.Walter, PMD Akademie- 2018

19

Das SCRUM-Rahmenwerk: Regeln

Agile

Manifest8

Werte

Verständnis

Regeln

20

Individuen und

Interaktionen

Funktionierende

Lösungen

Zusammenarbeit

mit dem Kunden

Reaktionen auf

Veränderungen

Prozesse und

Werkzeuge

Umfassende

Dokumentation

Vertrags-

verhandlungen

Einhalten

eines Plans

Das „Agile Manifest“ symbolisiert die Grundprinzipien

21

Versprechen:

Weil wir

zusammenhalten.

Respekt:

Weil wir uns

wertschätzen und so

miteinander arbeiten.

Offenheit:

Weil ich alles

sagen kann.

Kommunikation:

Weil wir aufeinander

zugehen und Dinge

offen ansprechen.

Mut:

Weil wir es einfach

mal versuchen und die

Dinge angehen.

Einfachheit:

Weil wir einfach mal

etwas ausprobieren,

auch wenn wir

scheitern können.

Feedback:

Weil wir zuhören

können.

Fokus

Weil wir uns auf die

Aufgaben konzentrieren

und nicht ablenken lassen.

Alle LEGO®-Figuren sind eine Leihgabe der Fa. Bauduu GmbH (www.bauduu.de)

Die „8 Agilen Werte“ beschreiben den Umgang miteinander

22

Gemeinsames Verständnis für die Zusammenarbeit finden …

Definition of Ready: Wann haben wir eine Aufgabe so genau beschrieben, dass mit der Bearbeitung

gestartet werden kann?

Definition of Done: Wann haben wir eine Aufgabe im Sinne des Auftraggebers abgeschlossen?

Timebox: Alle unsere Tätigkeiten sind zeitlich begrenzt. Das Einhalten der Zeiten hat für uns

höchste Priorität. Aufgaben passen wir den Zeiten an und nicht die Zeiten den Aufgaben.

Sprint: Wir definieren ein festes Zeitfenster (Anzahl Tage) für die Bearbeitung der anstehen

Aufgaben. Wir dürfen einen Sprint ggf. vorzeitig beenden, aber nicht verlängern!

Story: Damit wir die Aufhabe optimal erledigen können, beschreiben wir jede Aufgabe (Item) in

Form einer kleinen Geschichte (Story) und bewerten diese anhand einiger Parameter.

Akzeptanzkriterien: Damit wir prüfen können, ob wir den Auftrag erfüllt haben.

Burndown-Chart: Wir machen die Aufwandplanung und die Verbräuche öffentlich.

Planning Poker: Wir geben unsere persönliche Aufwandschätzung ohne Gruppenzwang ab.

23

Das SCRUM-Rahmenwerk: Rollen

Agile

Manifest8

Werte

SCRUM

Master

Product

Owner

Entwickl.-

Team

Stake-

Holder

Rollen

Regeln

Verständnis

24

… vertritt die Interessen der Stakeholder. (Daher mehr Verantwortung als ein klassischer

Projektleiter.),

… verfügte über sehr gute Marktkenntnisse,

… sorgt dafür, dass agile Scrum-Projekte schnell und flexibel auf wichtige externe

Faktoren, wie geänderte Anwenderwünsche oder neue Marktgegebenheiten, reagieren

können,

… entscheidet, ob die bearbeiteten Aufgabe zu 100 Prozent im Sinne der späteren Anwender realisiert wurde,

… entscheidet über die komplette Ausgestaltung des Produkts,

… ist für den Auslieferungszeitpunkt und die Entwicklungskosten verantwortlich,

… ist gewissermaßen der „Pate des Projekterfolgs“, indem er für die richtige Weichenstellung verantwortlich

ist,

... darf nicht in die Aktivtäten des Entwicklungs-Teams eingreifen.

Product Owner …

25

… trifft keine inhaltlichen Entscheidungen und greift nicht direkt ein,

… steht dem Team als Moderator und Vermittler zur Verfügung und ist für

organisatorische Fragen und Abläufe zuständig,

… ist neutraler Dienstleister und entlastet das Team durch die Übernahme zentraler

Aufgaben,

… wacht über die Werte und Regeln des Projekts, stellt die jeweils benötigten Ressourcen zur Verfügung und

beseitigt etwaige Hindernisse,

… ist für die Durchsetzung des Scrum Frameworks bzw. für die Gewährleistung der Rahmenbedingungen

verantwortlich,

… dient dem Team während des gesamten Projektverlaufs als zentrale Anlaufstelle.

Scrum Master …

26

… wird in Abhängigkeit der Aufgaben individuell zusammengestellt,

… arbeitet selbstorganisiert und gleichberechtigt, teaminterne

Hierarchien gibt es nicht,

… organisiert sich selbst und trifft Entscheidungen ausschließlich auf

fachlicher Basis.

Das Development Team …

27

… beschreiben gemeinsam mit dem Team die Product-Vision,

… schauen sich regelmäßig die (Zwischen-) Ergebnisse an,

… sind die Ansprechpartner für den Product Owner.

Stakeholder …

28

Das SCRUM-Rahmenwerk: Artefakte

Agile

Manifest8

Werte

SCRUM

Master

Product

Owner

Entwickl.-

Team

Stake-

Holder

Product-

Backlog

Sprint-

Backlog

Product-

Inkrement

Events Artefakte

Rollen

Regeln

Verständnis

29

Ausgehend von der gemeinsamen Vision erstellt der

Product Owner eine Liste mit allen Anforderungswünschen

für das Produkt/Projekt. Diese Liste nennt man Product Backlog.

Jeder Eintrag ist ein „Item“:

Qualitätsanforderungen, Funktionale Anforderungen,

User Stories, Fehler (Bugs), Verbesserungen.

Das Scrum-Team darf zwar Eintragungen vornehmen, aber die

Reihenfolge legt der Product Owner fest.

Ein wichtiger Einflussfaktor ist der "Business Value" (der Geschäftswert) der Backlog Items.

Das Product Backlog „lebt“ und kann vom Product Owner umsortiert werden. Dabei soll immer das Item mit

dem größten Einfluss auf das Unternehmen / das Projekt priorisiert bearbeitet werden.

Backlog Items die im Product Backlog "oben" stehen sollen möglichst "Ready" sein. Das bedeutet, dass

dieses Item im nächsten Sprint bearbeitet werden kann.

Product Backlog

Steckbrief

Event: Sprint Planning Meeting

Ziel: Transparenz über die anstehen

Aufgaben und ihre Priorität

Verantwortlich: Product Owner

Teilnehmer: Entwicklungsteam

Ergebnis: Liste der Items, die zur

Bearbeitung anstehen

30

In jedem Sprint soll ein funktionsfähiges Zwischenprodukt

entwickelt werden.

Deshalb wird bereits vorab im Sprint Planning Meeting

entschieden, welche Anforderungen aus dem Product Backlog

in das Sprint Backlog übertragen werden.

Voraussetzung is : das Item hat den Status „ready“.

Letztendlich entscheidet der Product Owner allein, welche Anforderungen im nächsten Sprint bearbeitet

werden und damit im Sprint Backlog landen.

Ergänzt werden die Projektaufgaben um weitere Details, die das Scrum Team benötigt, um das Sprintziel

(Sprint Goal) zu erreichen.

Wird eine Aufgabe erledigt (Lieferung eines auslieferungsfähigen Produktes = Potential Shipping Increments),

wird der Sprint Backlog aktualisiert, das Item bekommt den Status „done“.

Wird die Aufgabe nicht erledigt, geht das Item zurück in den Product Backlog.

Sprint Backlog

Steckbrief

Event: Sprint Planning Meeting

Ziel: Transparenz über die im nächsten

Sprint zu bearbeitenden Aufgaben

Verantwortlich: Product Owner

Teilnehmer: Entwicklungsteam

Ergebnis: Liste der Items, die im nächsten

Sprint bearbeitet werden sollen

Nach der Beendigung eines Sprint soll die Entwicklung des

Inkrements den Status „deployed“ (= bereitgestellt) hat.

So kann es bspw. sein, dass man sich für einen Newsletter

anmelden kann aber eben es noch nicht die Möglichkeit gibt,

sich eine Sprache auszuwählen. Dieses Feature könnte dann

Bestandteil des nächsten Sprintzyklus sein.

Das gezeigte Ergebnis muss nicht vollständig und fertig sein,

aber es muss gewissen Mindestansprüchen/ Kernfunktionalitäten genügen. Man könnte dies auch mit dem

klassischen „Time to Market“ in Verbindung bringen: Möglichst schnell ein Produkt an den Markt bringen,

verbunden mit der Möglichkeit, möglichst schnell Feedback von den Nutzern zu erhalten.

Die Vorstellung führt zu einer erheblichen Reduktion der Risiken: Denn ein Produkt wird nicht erst dem Nutzer

vorgestellt, wenn zu 100% den maximalen Ausprägungen entspricht, sondern dessen Akzeptanz kann bereits

in einem frühen Stadium durch Nutzerfeedback getestet werden

Product Increment*)

31*) wird manchmal auch genannt: Minimum Viable Product (MVP) oder Potentially Shippable Increment (PSI)

Steckbrief

Event: Sprint Review

Ziel: Die Beteiligten über das Ergebnis

informieren

Verantwortlich: Product Owner

Teilnehmer: SCRUM-Team, Stakeholder

Ergebnis: Einvernehmliche Klarheit über

das Ergebnis

32

Im Impediment Backlog wird all das erfasst, was eine

effiziente Arbeit des Entwicklungsteams stört/erschwert

und dieses somit daran hindert, fristgerecht alle Aufgaben

zur Erreichung der Ziele zu erledigen.

Es werden nur Impediments aufgenommen, die vom

Entwicklungsteam nicht per Selbstorganisation in den

Griff bekommen werden können.

Wichtig ist dabei, dass das Impediment Backlog jederzeit

öffentlich einsehbar ist.

Verwaltet wird das Impediment Backlog jedoch ausschließlich vom Scrum Master: Er entscheidet, was erfasst

wird und wann ein Problem als gelöst betrachtet bzw. abgehakt werden kann.

Impediment*) Backlog

Steckbrief

Event: Daily Scrum

Ziel: Transparenz über Hindernisse

Verantwortlich: Scrum Master

Teilnehmer: Scrum-Team, ggf. Stakeholder

Ergebnis: Liste der Themen, die das Projekt /

das Team behindern

*) Behinderung, Störung. Wird in manchen Publikationen den Artefakten zugeordnet.

33

Das SCRUM-Rahmenwerk: Events

Agile

Manifest8

Werte

SCRUM

Master

Product

Owner

Entwickl.-

Team

Stake-

Holder

Sprint-

Planning

Daily-

Scrum

Backlog-

Refinement

Sprint-

Review

Retro-

Perspective

Product-

Backlog

Sprint-

Backlog

Product-

Inkrement

Events Artefakte

Rollen

Regeln

Verständnis

Es beginnt mit einer Vision

Seite 34 34

35

Jeff Sutherland definiert die Vision als eine mitreißende, überzeugende Idee, mit der er den Kunden seines

Projekts, die Firma und das gesamte Entwicklungsteam für Scrum begeistern kann:

„Ein Produkt herzustellen, das alle haben wollen, bei dem, wenn die Leute es sehen, sich alle fragen,

wie sie jemals ohne es leben konnten”.

Die Product Vision bei SCRUM dient insbesondere der Orientierung des Teams bzw. der gemeinsamen

Ausrichtung auf ein Ziel und ist die Basis, auf der die „User Storys“ (Nutzererzählungen) aufbauen.

Die Vision beschreibt, warum das Projekt überhaupt umgesetzt wird und was der gewünschte Zustand ist, der

erreicht werden soll.

„Storytelling“ bietet eine Hilfestellung, um die Lösungsfindung zu einem bestimmten Problem zu vereinfachen.

Storys fördern die Vorstellungskraft und Kreativität des Menschen mit dem Ziel, neue Ideen zu entwickeln.

Produkt-Visionen

36

EPIC =

Große User Story

Große User Story, ggf. mit zusätzlichen Informationen. EPICS werden i.d.R. in

kleinere Stories aufgeteilt, die direkt realisiert werden können.

Gruppen von User Stories, die man zur monatlichen Berichterstattung

zusammenfasst.

Themes

Beschreibt die kleinste Aufgabe, die ein Nutzer erledigen kann. Besteht aus

einem Titel, einer Beschreibung und den sogenannten Akzeptanzkriterien.

Eine User Story wird immer so einfach und klar wie möglich und in wenigen

Sätzen beschrieben.

Darüber hinaus sollten 1-4 „Akzeptanzkriterien“ definiert werden. (Kriterien, die

erfüllt sein müssen, damit die Story als „erledigt“ definiert werden kann.

User

Story

1

User

Story

1

User

Story

2

User

Story

3

User Story, EPICs, Themes

37

Sprint Planning

Im Sprint Planning wird die Realisierung des jeweils

nächsten Produkt-Inkrements (Ergebnis) geplant.

Das Meeting findet alle paar Wochen zwischen den Sprints statt.

In Rahmen der Anforderungsanalyse stellt der Product Owner

eine von ihm vorgenommene Vorauswahl priorisierter

Anforderungen aus dem Product Backlog vor und beantwortet

die Fragen des Entwicklungsteams.

Im nächsten Schritt entscheidet das Team dann, welche Anforderung zum jetzigen Zeitpunkt im nächsten

(Bearbeitungszyklus) Sprint tatsächlich umgesetzt werden kann. Dies erfolgt dann, wenn die „Definition of

Ready“ erfüllt werden.

Danach wird diese in einzelne Tasks (Stories) zergliedert und in das Sprint Backlog übernommen. Moderiert

wird das Sprint Planning Meeting vom Scrum Master.

Steckbrief

Event: Sprint Planning

Ziel: Identifizierung von Aufgaben

Verantwortlich: SCRUM Master

Zeitpunkt: Während eines Sprint

Teilnehmer: SCRUM-Team

Methode: Moderierte Diskussion

Dauer: ca. 4 Std., ggf. länger

38

Das Daily Scrum ist ein (idealerweise) tägliches Meeting

welches zu einer festen Uhrzeit (heurfix) stattfindet und nicht

länger als 15 Min. dauern sollte.

Die Teilnehmer sind der Scrum Master, ggf. der Product Owner

und das Entwicklerteam.

Der übergeordnete Zweck dieses Meetings ist es, den

Informationsaustausch und die Selbstorganisation des Teams

zu unterstützen bzw. zu ermöglichen.

Die Teilnehmer berichten, was seit dem letzten Meeting passiert ist, was in nächster Zeit zu tun ist und um

welche Themen man sich kümmern muss (Herausforderungen, Hindernisse, …)

Gibt es Punkte, die das Team nicht selbständig lösen kann, kümmert sich der Scrum Master im Nachgang um

die Probleme.

Daily Scrum

Steckbrief

Event: Daily Scrum

Ziel: Abgleich der aktuellen Informationen

Verantwortlich: Scrum Master

Zeitpunkt: tägliches Treffen

Teilnehmer: Development Team, Scrum-Master

Methode: Moderierte Diskussion

Dauer: ca. 15 Min.

39

Im Backlog Refinement werden ausgewählte (priorisierte)

Maßnahmen (Backlog Items) soweit verfeinert, dass sie

möglichst gut in einem nächsten Sprint bearbeitet werden

können.

Verfeinerung bedeutet, dass über die als nächstes zu

bearbeitenden Aufgaben (Item bzw. Story) ein hohes Maß

an Klarheit und Transparenz besteht.

Dies setzt voraus, dass den einzelnen Stories „Akzeptanz Kriterien“ (Qualitätskriterien, anhand deren das

Ergebnis und die Anforderungen verifiziert werden können) zugeordnet wurden und der Aufwand (Story

Points) für die Bearbeitung der Story möglichst genau vom Development Team geschätzt wurden.

Eine weitere Tätigkeit der Verfeinerung des Product Backlogs ist das „Herunterbrechen“ von großen Product

Backlog Items (oft als „Epics“ bezeichnet) in die kleineren Backlog Items (wie z.B. „User Stories „).

Idealer Weise sind diese Backlog Items von möglichst gleicher Größe, tendenziell lieber klein als groß.

Backlog Refinement

Steckbrief

Event: Backlog Refinement

Ziel: Klarheit über anstehende Aufgaben

Verantwortlich: Product Owner

Zeitpunkt: Am Anfang eines Sprint

Teilnehmer: SCRUM-Team

Methode: Moderierte Diskussion

Dauer: ca. 1-2 Std.

40

User Story Card

Name (Titel)

der StoryPriorisierung Story Points

geplant

1 – 4 Akzeptanzkriterien

Business

Value

Erstellungs-

datum

Erstellt

von

Wer

Was

Warum

Story Points

benötigt

Ziel

(Goal)

Bei klassischen Projekten werden die Arbeitspakete in Zeiteinheiten geschätzt. Dies unterscheidet sich

maßgeblich von der agilen Methode SCRUM. Hier erfolgt die Schätzung der User Stories in sogenannte Story

Points oder Komplexitätspunkte im Rahmen des Refinement Meetings.

Die Story Points sind nach der Fibonacci-Reihe aufgebaut:

1, 2, 3, 5, 8, 13, 20, 40, 100

Vorteil der Schätzung nach Fibonacci: Man verliert sich nicht in

Detaildiskussionen sind diskutiert über einen Trend.

Die Schätzungen werden durch diese Methode im Grundsatz genauer.

Die Geschwindigkeit (Velocity) eines Teams während des Sprints ergibt sich aus der Summe aller erledigten

User Stories und der darin enthaltenen Story Points.

Eine gleichbleibende Velocity und eine damit bessere Planbarkeit der für einen Sprint möglichen User Stories

ergibt sich meist erst nach 5-7 Sprintzyklen.

Agiles Schätzen

Planning Poker Karten *)

*) Bildquelle: amazon.de

42

Zur Aufwandsschätzung gelangt man durch den 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:

1. 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.

2. Vorprojekt: Ein kleiner Ausschnitt des Gesamtprojektes wird in einem kurzen Vorprojekt umgesetzt und

daraus die Velocity-Kennziffer ermittelt.

3. 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.

Velocity-Faktor

Sprint Burndown Chart

44

Am Ende eines Sprints wird ein Sprint Review abgehalten,

um das [Produkt‐]Inkrement zu überprüfen bzw. dem

Product Owner vorzustellen und das Product Backlog

bei Bedarf anzupassen.

Während des Sprint Reviews beschäftigen sich das

Scrum Team und ggf. die Stakeholder gemeinsam mit den

Ergebnissen des Sprints.

Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des

Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.

Für einen einmonatigen Sprint wird für dieses Meeting eine Time Box von ca. 4 Stunden angesetzt. Für

kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt.

Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass das Sprint Review wertvollen

Input für die kommenden Sprint Plannings liefert. Es erfolgt eine Begutachtung, ob sich durch die

Marktsituation oder den möglichen Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritte

ergeben haben.

Sprint Review

Steckbrief

Event: Sprint Review

Ziel: Überprüfung der Ergebnisse

Verantwortlich: SCRUM Master

Zeitpunkt: Am Ende eines Sprint

Teilnehmer: SCRUM-Team

Methode: Moderierte Diskussion

Dauer: ca. 4 Std.

45

Es gibt immer die Möglichkeit, sich zu verbessern.

Das Team diskutiert hier den vollendeten Sprint und

bestimmt, was verändert werden könnte, um den

nächsten Sprint noch produktiver und besser zu gestalten.

Die Sprint Retrospective ist gewöhnlich der letzte Schritt

eines Sprints, häufig direkt nach dem Sprint Review.

Alle Teammitglieder diskutieren den Verlauf, machen Verbesserungsvorschläge, diskutieren Ideen, die ihre

Produktivität steigern könnten, und klären, was gut lief und was verbessert werden könnte.

Gute Retrospektiven sind in sehr positiver Abschluss für einen abgelaufenen Sprint. Schlecht durchgeführte

und moderierte Retrospektiven dagegen können sinnlos und erschöpfend sein.

Der Scrum Master priorisiert Aktionen und Lektionen, die gelernt wurden.

Die Retrospektive unterstützt die Team-Gliederung und – Bindung. Vor allem Konfliktbereiche können

identifiziert und behandelt werden.

Sprint Retrospective

Steckbrief

Event: Sprint Retroperspective

Ziel: Identifizierung von Verbesserungen

Verantwortlich: SCRUM Master

Zeitpunkt: Häufig am Ende eines Sprint

Teilnehmer: SCRUM-Team

Methode: Moderierte Diskussion

Dauer: ca. 3 Std.

46

Sprint PlanningProduct Owner

Development-

(Entwicklungs -)TeamScrum-Master

Daily Scrum

Backlog Refinement

Sprint Review

Retroperspective

Development-

(Entwicklungs -)TeamScrum-Master

Product OwnerDevelopment-

(Entwicklungs -)TeamScrum-Master

Product OwnerDevelopment-

(Entwicklungs -)TeamScrum-Master

Development-

(Entwicklungs -)TeamScrum-Master

4-8 Std.

15 Min.

1-2 Std.

2-4 Std.

1-2 Std.

Zu Beginn eines Sprints

täglich (3 mal wöchentlich)

Regelmäßig während eines

Sprints

Am Ende eines Sprints

Am Ende eines Sprints

Sprint Übersicht

Stakeholder

47

SCRUM-Projekt

Es beginnt mit

einer VisionProduct-Backlog

Festlegung von

Aufgaben, um das

Ziel zu erreichen

Übersicht

der Aufgaben

(Items) und Epics

Sprint Planning

Meeting

Zu jedem Item

wird eine Story

geschrieben

Sprint-Backlog

Stories

Dokumentation

der Stories

(anstehende

Aufgaben)

Backlog-Refinement

Meeting

Daily-

Scrum

Items,

Epics

Sprint-Review

Meeting

Retroperspective

Meeting

JA

Wer? Was?

Warum? Wann?

Schätzung?

Wurden alle

Akzeptanzkriterien

erfüllt?

Product

Increment

Potentiell

auslieferbares

Produkt

NEIN

Aktualisierung Detaillierung

Wird n

eu

be

sch

rie

be

n

Impediment-Backlog

Auflistung

aufgetretener

Hindernisse

Start-

Meeting

Sprint zu Ende?

NEIN

JA

Was kann / soll

bearbeitet werden?

SCRUM-Flow

49

Zu finden auf

oder senden Sie mir bitte eine Mail, dann schicke ich Ihnen den Guide kostenlos zu.

Der offizielle Scrum-Guide

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf

50

Fazit

SCRUM eignet sich für nahezu alle Projekte in einem Unternehmen.

Ein „bisschen“ SCRUM geht nicht.

Passen Sie nicht die SCRUM-Regeln der Organisation an sondern die Organisation den SCRUM-Regeln.

SCRUM löst nicht Ihre Probleme sondern macht sie transparent. Das muss man aushalten können.

Bereiten Sie die Mitarbeiterinnen und Mitarbeiter auf die neue Arbeitsweise frühzeitig und umfassend vor.

Geben Sie allen Beteiligten die Chance, zu lernen.

51

SCRUM-Inhouse-Seminar

Gerne sende ich Ihnen den Flyer zu und erstelle Ihnen ein individuelles Seminarkonzept.

52

Agilität in a nutshell:

Eine Trilogie zu den Themen

- Agile Projekte

- SCRUM Grundlagen, Donnerstag den 23.08.2018, 11:00 – 11:45 Uhr

- Agile Organisationen

- 7 Stufen zu einer erfolgreichen Agilen Organisation, Donnerstag, den 30.08.2018, 11:00 – 11:45 Uhr

- Agile Führungskräfte

- So werden Sie zu einer Agilen Führungskraft, Donnerstag, den 06.09.2018, 11:00 – 11:45 Uhr

Wie immer ist die Teilnahme kostenlos und sowohl die Präsentation als auch die Video-Aufzeichnung steht

den Teilnehmerinnen und Teilnehmern kostenlos zur Verfügung.

Wer sich im Grundsatz mit dem Thema „Agilität“ beschäftigen möchte, findet das Webinar-Video

„Liberté, Egalité, Agilité“ dazu auf unserer Webseite: http://webinare.pmd-akademie.de/start

Ihre Ansprechpartner

Sie haben Fragen zu den Bildungskonzepten der PMD Akademie?

Dann nehmen Sie bitte Kontakt zu uns auf.

Heike Wenzel

Seminarmanagement

Telefon: +49 365 55220-140

Mobil: +49 151 5804 6557

E-Mail: h.wenzel@pmd-akademie.de

Wolfram M. Walter

GeschäftsführerProfessional Scrum Master

Member of German Speakers Association

Telefon: +49 365 55220-140

Mobil: +49 171 566 1155

E-Mail: w.walter@pmd-akademie.de

PMD Projektmanagement Deutschland Akademie GmbH, Reichsstraße 5, 07545 Gera

info@pmd-akademie.de • www.pmd-akademie.de • https://pmdablog.wordpress.com/ •

http://webinare.pmd-akadmie.de

53

Die PMD Akademie live

54

Ihr Trainerteam

55

André Engelhardt

Trainer

a.engelhard@dms-gruppe.de

Markus Dubois

Trainer

m.dubois@dms-gruppe.de

Regelindis Reichel

Trainerin

r.reichel@dms-gruppe.de

Wolfram M. Walter

Trainer, Berater, Coach

w.walter@dms-gruppe.de

Das sagen unserer Kunden

56

„Das ich das Gelernte

in der Praxis bei der

Arbeit anwenden

kann“

„Lockere und entspannte

Art, das Wissen anschaulich

vermittelt“

„Es war nichts, dass

mir nicht gefallen

hat“

57

zuverlässig – innovativ – nachhaltig

Backup

58

59

Der Product Owner

Hat die Rolle des Auftraggebers bzw. Kunden und trägt die Hauptverantwortung für den geschäftlichen Erfolg

des zu entwickelnden Produkts. (Kombination aus Shareholder und Projektleiter)

Der Scrum Master

ist der Hauptverantwortliche für die Implementierung des Scrum Prozesses, d.h. die Anwendung der Methodik

und die Einhaltung der dazugehörigen Prinzipien. (Promoter)

Das Team oder auch Umsetzungsteam (Development-Team)

Sind die Personen, die die Hauptverantwortung für die technische Umsetzung tragen. (Entwicklungsteam)

Das Scrum-Team

Product Owner, Scrum Master und Team bilden ein übergeordnetes Team. (Projektteam)

Der Sprint

ist eine meist zwei- bis vierwöchige Entwicklungsphase, in der das Team selbstorganisiert an der Umsetzung

der für diesen Zeitraum festgelegten Anforderungen arbeitet und dabei potenziell auslieferbare Zwischen-

ergebnisse erstellt. (Jourfix bzw. Heurfix)

3. Scrum-Begriffe (1/3)

60

Der Product-Backlog

Ist eine priorisierte, dynamische Anforderungsliste für ein Projekt. Die Aufgaben werden zunächst grob, später

verfeinert beschrieben. Wird vom Product-Owner gepflegt. (Projektplan)

Der Sprint-Backlog

Ist eine priorisierte Liste aller Aufgaben zur Umsetzung des aktuellen Sprints. Wird vom Team gepflegt. (ToDo-

Liste)

Das Sprint-Burn-Down-Chart

Ist die täglich aktualisierte visuelle Darstellung der Aufgaben, die das Team während des aktuellen Sprints

noch zu erledigen hat. Wird vom Team gepflegt. (Projektbericht)

Der Impediment-Backlog

Ist eine Liste mit Hindernissen, die das Entwicklungsteam bei der Arbeit stören. Diese wird vom Scrum Master

geführt. (PPA, Potentielle Problem Analyse)

Das Daily-Scrum-Meeting

Ist ein maximal 15-minütiges Zusammentreffen, in dem sich die Teammitglieder während eines Sprints täglich

synchronisieren. (Heurfix)

3. Scrum-Begriffe (2/3)

61

Das Sprintplanungs-Meeting

Vor jedem Sprint findet Zusammentreffen statt, in dem die Aufgaben-Prioritäten für die nächsten Sprints

festgelegt werden. Am Ende des Meetings steht ein abgestimmtes Sprint-Ziel (commitment), zu dem sich das

Team verpflichtet. (Jourfix)

Das Sprint-Review-Meeting

Am Ende eines Sprints gibt es ein Meeting oder ein Prozess, in dem das Team über die Sprint-Ergebnisse

berichtet und ggf. Korrekturmaßnahmen eingeleitet werden. (Sitzung der Projektleiter / Teilprojektleiter und

ggf. Projekt-Steuerungs-Gremium)

Die Retrospektive

Rückblick auf die Arbeitsergebnisse und ggf. Einleitung von Maßnahmen für Umsetzung eines kontinuierlichen

Verbesserungsprozesses. (Projekt-Review)

3. Scrum-Begriffe (3/3)