agilität in a nutshell: teil 1 › wp-content › uploads › 2019 › ... · reihenfolge legt der...
TRANSCRIPT
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: [email protected]
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: [email protected]
PMD Projektmanagement Deutschland Akademie GmbH, Reichsstraße 5, 07545 Gera
[email protected] • 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
Markus Dubois
Trainer
Regelindis Reichel
Trainerin
Wolfram M. Walter
Trainer, Berater, Coach
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)