R O L L E N. Scrum Master. "Hüter des Scrum- Prozesses", Agile Change Agent, Moderator, Facilitator, Coach

Transkript

1 A g i l e s P r o j e k t m a n a g e m e n t R O L L E N Scrum Master "Hüter des Scrum- Prozesses", Agile Change Agent, Moderator, Facilitator, Coach

2 S c r u m M a s t e r T o p A u f g a b e n Er stellt sicher, dass Scrum richtig angewendet wird. Er personifiziert die Scrum Werte, Regeln und Prinzipien. Er ist eine dienende Führungskraft für das Scrum Team. Er stellt über das Prinzip Inspect & Adapt die kontinuierliche Verbesserung des Produkts und der Arbeitsweise des Teams sicher. Er hilft dem Scrum Team die Ziele des Projekts durch die Beseitigung von Impediments zu erreichen. Team hat Fokus auf Akzeptanzkritieren? Gibt es unausgesprochene Konflikte? Management von Hindernissen (Impediments) In welchem Phase befindet sich mein Team? Ist das Burndown Chart sichtbar Taskboard aktuell? Moderation Retrospektive mit relevanten Ergebnissen... Product Backlog gepflegt?

3 A g i l e s P r o j e k t m a n a g e m e n t R O L L E N Product Owner "Entrepreneur", Mannschaftsdienlicher Leader, Projektleiter, Domänen-Experte, Produktmanager, Business Analyst, Requirements Engineering

4 P r o d u c t O w n e r T o p A u f g a b e n Erstellt die Produktvision und pflegt die Product Roadmap. Der Product Owner definiert, WAS gebaut/entwickelt werden muss. Er pflegt und sortiert das Product Backlog nach Priorität. Er kommuniziert regelmäßig mit den Stakeholdern. Er kommuniziert regelmäßig mit dem Team als Teil des Team. Er betreut die Weiterentwicklung eines bestehende Produkts (Product Life Cycle). Ermittelt den höchsten Nutzen für den Kunden (Wert) Entspricht das Product Backlog den DEEP-Kriterien? Product Backlog gepflegt? Management der Budgets Die Produkt Vision und Release-Planung ist kommuniziert! Kennt den Kunden, daß Produkt und kann den Kunden entsprechend beraten! Jederzeit erreichbar für Scrum Master und Team

5 A g i l e s P r o j e k t m a n a g e m e n t R O L L E N Das Team (Dev) Selbstorganisert, Crossfunktional, T-Shape, Team- Performance, max. 9 Personen, Experten

6 D a s T e a m ( D e v ) T o p A u f g a b e n Das Entwicklungsteam hat sich auf das Erreichen des Sprintziels "Commited". Das Entwicklungsteam besitzt über alle Kenntnisse Ihre Arbeit bestmöglich zu tun. Die Mitglieder des Entwicklungsteam stimmen sich eng ab und kommunizieren dabei vorallem "Face to Face". Das Entwicklungsteam kennt seine "Velocity" (Arbeitsgeschwindigkeit)! Das Entwicklungsteam ist diszipliniert und beteiligt sich im Sinne der Event- Ziele an allen Events/Meetings. Die Teammitglieder respektieren einander Das Team "ergänzt" sich "Fehler" haben Vorrang... Motiviertes Team User-Stories sind verstanden worden! Die Team-Performance stimmt

7 A g i l e s P r o j e k t m a n a g e m e n t E V E N T S Backlog Refinement 1x mtl. max 8 Std., Agenda, klare Ziele, vor Sprint Planning I+II, Verfeinerung PBI und Schätzung

8 B a c k l o g R e f i n e m e n t Mögliche Inhalte: Oberstes Ziel ist die Pflege des Product Backlog. Ziel ist eine aktuelle Release-Planung. Das Backlog-Refinement greift das Feedback aus dem Review-Meeting auf. Bestehende Backlog-Items werden angepasst, Neue Backlog-Items erstellt, zukünftige Backlog-Items verfeinert. Backlog Items für den nächsten Sprint identifizieren und in Bezug auf "Definition of Ready" prüfen. Das Ergebnis des Backlog Refinement ist ein Product Backlog, das inhaltich auf dem aktuellen Stand ist, sinnvoll geschätzte Backlog Items enthält und vom kompletten Scrum-Team mitgetragen wird. Das Backlog-Refinement erzeugt ein gemeinsames Verständnis für die kommenden Produktentwicklungsschritte. Ergebnisse dokumentieren und aktualisieren. Wer? PO, SM, Dev-Team (o. Teile des Teams) C h e c k l i s t e

9 A g i l e s P r o j e k t m a n a g e m e n t E V E N T S Sprint Planning Teil 1 (Was?), Teil 2 (Wie?), Timeboxed max. 8Std.

10 S p r i n t P l a n n i n g Mögliche Inhalte: Das Sprint Planning kann man in 2 Meetings aufteilen: Das erste Sprint Meeting (I) ist für die Definition WAS im nächsten Sprint umgesetzt wird. Das zweite Sprint Meeting (II) fokussiert WIE (technisch) die Umsetzung durch das Team vorgenommen wird. Sprint Planning I: Sprint Ziel mit den SMART-Kriterien festlegen. Sprint Planning I: Keine "technischen Diskussionen führen". Sprint Planning I: Teamverfügbarkeit für den nächsten Sprint prüfen (Urlaube, Feiertage...). Sprint Planning I: Der Product Owner sollte genau wissen, was im nächsten Sprint umgesetzt werden soll. Sprint Planning II: Das Team einigt sich auf eine (technische) Lösung für die fachliche Anforderung. Sprint Planning II: Backlog Items sollten in Tasks mit max. Dauer von 1 Tag zerlegt werden. Sprint Planning II: Ggfs. Rücksprache mit dem Product Owner. Wer? PO, SM, Dev-Team (o. Teile des Teams) C h e c k l i s t e

11 A g i l e s P r o j e k t m a n a g e m e n t E V E N T S Daily Scrum Pünktlich, Timebox 15 Min, 3 Fragen, Alle Teammitglieder, Teamsynchronisation, StandUp, TaskBoard

12 D a i l y S c r u m C h e c k l i s t e Mögliche Inhalte: 3 Fragen: Was hast Du seit gestern getan? Was wirst Du heute tun? Was hat Dich behindert das zu tun was Du tun wolltest? (Alternativ: Worin benötige ich Unterstützung) Das Daily wird als StandUp durchgeführt. Das Daily Scrum wird als Teamsynchronisation genutzt nicht als Report (Statusmeeting). Die Teilnehmer berichten den Teilnehmern - nicht dem Scrum Master. Es werden im Daily Scrum keine Lösungen und keine "Probleme" besprochen. Direkt nach dem Daily sollte das Burndown-Chart aktualisiert werden, es kann als Motivation dienen. Nach dem Daily Scrum wissen alle Teammitglieder woran die Anderen arbeiten. Die Hindernisse (Impediments) aus dem Daily werden vom Scrum Master in dem Impediment Backlog festgehalten. Zusätzlich empfiehlt es sich mit einem Happyness-Index zu arbeiten. Wer? PO (optional), SM, Dev-Team

13 A g i l e s P r o j e k t m a n a g e m e n t E V E N T S Sprint Review Bsp. 1x im Monat 4 Std., Ergebnis-Präsentation, Feedback des Kunden

14 S p r i n t R e v i e w C h e c k l i s t e Mögliche Inhalte: Das Team stellt vor, was es sin den letzten Wochen seit Beginn des Sprints erreicht hat. Das Review wird genutzt um wertvolles Feedback der Reviewteilnehmer (Stakeholder) zu erhalten. Ergebnisse auf interessante und motivierende Weise vorstellen. (Marketing in eigener Sache) Das Feedback der Teilnehmer im nächsten Backlog Refinement Meeting auswerten. Zu Beginn der Präsentation Überblick auf den Review geben und Bezug auf das Sprint-Ziel nehmen (Ziel erreicht?) Ausblick auf den nächsten Sprint geben. Backlog Items die nicht 100% fertig sind, werden nicht gezeigt. Wer? PO, SM, Dev-Team, Stakeholder/Kunde

15 A g i l e s P r o j e k t m a n a g e m e n t E V E N T S Retrospektive Bsp. 1x im Monat Timebox 3 Std., 6 Phasen, moderiert, "Herzstück", regelmäßig, Kontinuierliche Verbesserung,

16 R e t r o s p e k t i v e Mögliche Inhalte: Die Retrospektive hat zum Ziel, daß das gesamte Team (PO, SM, Dev-Team) gemeinsam untersucht, wie Sie Ihre Zusammenarbeit, Prozesse und Produktqualität verbessern können. Anwendung des 12. Prinzip: "In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an" Der Product Owner ist Bestandteil der Retrospektive kann aber von Zeit zu Zeit auf Wunsch "aussetzen". Nach jedem Sprint findet eine Retrospektive statt. Retrospektive läuft in 6 Schritten ab (nach Derby/Larsen): 1. Intro 2. Set the Stage 3. Gathering Data 4.Generate Insights 5.Decide what to Do 6. Close Der Scrum Master moderiert die Retrospektive-Meetings. In der Retrospektive greift der Scrum Master Impediments aus den Dailys auf. Das Ergebnis der Retrospektive sind konkrete Verbesserungsmaßnahmen bis zur nächsten Retrospektive. Wer? (PO),SM, Dev-Team (ext. Agile Coach) C h e c k l i s t e

17 A g i l e s P r o j e k t m a n a g e m e n t A R T E F A K T E Product Backlog User-Stories, Backlog-Items, priorisiert, DEEP

18 P r o d u c t B a c k l o g Beschreibung: Das Product Backlog enthält die Beschreibung der Merkmale (Features) des Produkts. Das Product Backlog wird nach den DEEP-Kriterien angelegt. Die Anforderungen des Product Backlogs werden als User Stories formuliert. User Stories berücksichtigen INVEST-Kriterien. Es sollten keine User Stories ohne Akzeptanzkrtierien geschrieben werden. Die Anforderungen des Product Backlog wird nach dem MoSCoW-Prinzip priorisiert. Product Backlog nicht überstrukturieren um Raum für Ideen und Kommunikation zu lassen. Wer? PO und SM, Team

19 A g i l e s P r o j e k t m a n a g e m e n t A R T E F A K T E Sprint Backlog User-Stories, Backlog-Items, priorisiert, DEEP

20 S p r i n t B a c k l o g Beschreibung: Das Sprint Backlog enthält die Beschreibung der Merkmale (Features) des Produkts. Das Sprint Backlog wird nach den DEEP-Kriterien angelegt. Für das Sprint Backlog ist besonders darauf zu achten das alle Backlog Items eine Dauer nicht größer als 1 Tag haben. Die Entwickler sollten keine offenen Fragen mehr in Bezug auf die Backlog-Items haben. Das Team entscheidet welche Backlog Items in den nächsten Sprint aufgenommen werden, nicht der Product Owner. Der Sprint Backlog ist das Ergebnis des Sprint Planning- Events. Wer? Team, SM und PO

21 A g i l e s P r o j e k t m a n a g e m e n t A R T E F A K T E Inkrement Potentiell ausflieferbares Produkt, Abnahme PO oder Kunde

22 I n k r e m e n t Beschreibung: Ist das Ergebnis aus allen in einem Sprint fertiggestellten Sprint-Backlog-Einträge und das Resultat der Inkremente aller früheren Sprints Ein Produkt-Inkremement wird am Ende des Sprints im Sprint Review vorgestellt. Das Produkt-Inkrement sollte verwendbar sein. (Potential Shippable Product) Am Ende eines Sprints muss das neue Inkrement in nutzbarem Zustand sein und der "Definition of Done" entsprechen. Wer? PO, SM, Team und Management

23 A g i l e s P r o j e k t m a n a g e m e n t A R T E F A K T E Sprint Burndown-Chart Story-Points, Sprints, Velocity, KPI

24 S p r i n t B u r n d o w n - C h a r t Beschreibung: Das Burndown Chart ist für das Team (Entwickler) immer "sichtbar". Das Burndown-Chart zeigt die Anzahl noch nicht erledigter Tasks. Das Burndown-Chart wird täglich aktualisiert. Das Entwicklungsteam aktualisiert das Burndown-Chart (nicht der SM). Wenn das Sprint Burndown Chart mögliche Probleme aufzeigt, werden diese diskutiert und Entscheidungen werden vorbereitet oder getroffen. Wer? Team, SM und PO