Vom leeren Blatt zum vollen geschätzen Product Backlog

Präsentation zum Thema: "Vom leeren Blatt zum vollen geschätzen Product Backlog"—  Präsentation transkript:

1 Vom leeren Blatt zum vollen geschätzen Product Backlog
Dr. Patrick Seifried, Karlsruher Entwicklertag – Agile Day ® 1&1 Internet AG 2012, Dr. Patrick Seifried 1

2 Warm-up ® 1&1 Internet AG 2012, Dr. Patrick Seifried 2

3 Über mich Dr. Patrick Seifried Expertise in Scrum, Projektmanagement, Business Engineering und Business Consulting im Portalumfeld. Beratungen in über 40 Unternehmen. Managing Director MODUSNEXT.ch GmbH, Gründer und Geschäftsführer von TranslationArtwork.com und YOOSOCIAL.ch. Dr. oec. Institut für Medien- und Kommunikationsmanagement, HSG, Universität St. Gallen, Schweiz Diplom-Wirtschaftsinformatiker Universität Mannheim, Deutschland ® 1&1 Internet AG 2012, Dr. Patrick Seifried 3

4 Praxisbeispiel: 1&1 Development Hosting
Wie komme ich im Unternehmen von einem leeren Blatt zum vollen und geschätzten Product Backlog? vollen geschätzten ® 1&1 Internet AG 2012, Dr. Patrick Seifried 4

5 Was war unsere Ausgangslage?
® 1&1 Internet AG 2012, Dr. Patrick Seifried 5 5

6 Was war unsere Ausgangslage?
Ein Product Manager, keine klaren Rollen, den Projektnamen “HIP”, überall verteilte Mitarbeiter, das 1. Releasedatum: 1. Juni“, kein Projektvorgehen, das erwartete Lieferobjekt: „API für HIP“, keinen Backlog, 2 Monate Zeit für einen realen, umsetzbaren Meilensteinplan, keinen Scope, gering geklärte Verantwortlichkeiten, kein Team, aber dafür jede Menge … ® 1&1 Internet AG 2012, Dr. Patrick Seifried 6

7 HIP Product Development
Stakeholder Development DE Development RO Div. Departments Product Management Godparents XY prename name Development DHIP RO Projekt Manager 1 XY Development DHIP RO Projekt Manager 2 XY Vorstand Technology Development Hosting - XY Development Hosting Dev. Server & Domains - XY Development Hosting Frontend Architect - XY Development Hosting Bereichsarchitekt - XY Development DHIP Projekt Manager 1 - XY XY Development DHIP Projekt Manager 2 - Development Hosting Development DHIP - XY XY 1&1 Internet AG Demand & Delivery Mgmt. - XY Development Hosting Dev. Hosting Applications - XY Development Hosting Bereichsarchitekt - Development DHIP Requirements Engineer - XY XY Development Hosting Int. Programm Mgmt. - XY Development DHIP Frontend Integration - XY Development DHIP Development HCS - XY TPM Hosting–Classic Hosting Frontend Production - XY Vorstand Hosting Technical PM Hosting - XY Int. Program Management Projektmanager Host XY Development Romania Int. Programm Mgmt. - Technical PM Hosting PM Domains/SSL - XY Dev. Hosting Applications eBusiness Applications - XY HIP Product Development Project Controlling IT Security - XY Development Romania Process and Delivery Mgmt. - XY XY Technical PM Hosting Business Operations - XY Dev. Hosting Applications ePublishing Applications - IT Ops Access & Shared App, IT Ops Shared Applications - XY Development RO Hosting Domain Development RO - XY Technical PM Hosting Classic Hosting - XY Dev. Hosting Applications Mail, Office & Collaboration - XY XY IT Operations IT Ops Access & Shared App - Development RO Hosting Integration Hosting RO - XY PM Applications SaaS - Development Hosting Programm M. Webdesk - Technical PM Hosting Hosting Quality Offensive - XY XY Dev. Server & Domains Domains - Finance/Administra- tion Strategischer Einkauf IT- und Facility Dienstleistungen - XY Development Romania Development RO Hosting - XY XY Vorstand Hosting PM Applications - Vorstand Hosting PM Applications - XY Technical PM Hosting Server & DevTools - XY XY Dev. Server & Domains Shared Hosting Infrastructure - Operatoins Services OPS Projekt Office - XY Quality, Ops & Services Technical Editors - XY Quality, Ops & Services Quality Assurance - XY Quality, Ops & Services Quality Assurance - XY XY Development Hosting Quality, Ops & Services - Quality, Ops & Services Release & Change Mgmt. - XY ® 1&1 Internet AG 2012, Dr. Patrick Seifried 7

8 Was waren unsere Maßnahmen?
® 1&1 Internet AG 2012, Dr. Patrick Seifried 8 8

9 Was waren unsere Maßnahmen?
Scrum eingeführt, Product Manager für Scrum sensibilisiert, Verantwortlichkeiten mit dem Management geklärt, Rolle eines Technischen Product Owners eingeführt, Rolle zwischen Product Manager, Technischer Product Owner, Projektleiter sowie Teamleiter und Abteilungsleiter geklärt, 1 Entwicklungsteam vor Ort aufgestellt, Stakeholder abgeholt, Requirements Prozess eingeführt und bekannt gemacht, Scope formuliert, und ein … ® 1&1 Internet AG 2012, Dr. Patrick Seifried 9

10 … Product Owner Board eingeführt.
Interagiert Schreibt Development Team Face to the customers Technical Product Owner Product Manager Requirements Engineer Supporter I Stakeholders Systemarchitect Supporter II As who I want what so that why User Story Software-Developer Supporter III Head of Supporter IV ScrumMaster Supporter V ® 1&1 Internet AG 2012, Dr. Patrick Seifried 10

11 Das Product Owner Board hat die Aufgaben:
User Stories schreiben, diskutieren und verabschieden. User Stories immer wieder auf den neuen Scope anpassen. Definition of Done festlegen und aktualisieren. Unklarheiten mit diversen Stakeholdern abklären. Den nächsten Sprint bzw. die nächsten Sprints vorbereiten. Die Ergebnisse des Sprints intern verkaufen. Product Backlog aufbauen und stets aktuell halten. User Stories priorisieren. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 11

12 Praxisbeispiel: 1&1 Development Hosting
Wie komme ich im Unternehmen von einem leeren Blatt zum vollen und geschätzten Product Backlog? vollen geschätzten ® 1&1 Internet AG 2012, Dr. Patrick Seifried 12

13 TEMPO Erklärt in 13. Schritten.
AffiniTy Estimation and MoSCoW PriOritization TEMPO Erklärt in 13. Schritten. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 13 13

14 1. Vorbereitung Der Product Owner kennt sein Product Backlog.
“Sichere” User Stories ausgedruckt. Eine User Story, eine Karte. Großer Raum, freien Wände. Workshop-Utensilien: Super Stickies (Post-it), Indexkarten, Marker (Edding 3000), Klebestift (PRITT), Schere, mehrfarbige runde Klebepunkte, 2 Flip-Charts und ein Pinboard “Questions Marks”. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 14

15 2. Story Point Game (10 min) Timebox der Schätzung vorstellen.
Spielerische Übung. Alle Teilnehmer schätzen das Ergebnis des Workshops vorab. Geheime Schätzung der Summe aller Story Points. Jeder Teilnehmer schreibt Namen und eine Zahl auf ein Post-it. ScrumMaster hält die Schätzungen unter Verschluss bis Workshop Ende. Preis für die beste Schätzung. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 15

16 3. Stilles relatives Einordnen (30 min)
Links “Smaller”, rechts “Larger”. Die Teammitglieder dürfen nicht miteinander sprechen. Jedes Teammitglied ordnet die User Stories gemäß eigenem Empfinden für den Entwicklungsaufwand ein. Der Entwicklungsaufwand für die Einhaltung der „Definition of Done“ fließt mit ein. Ist eine User Story unklar wird Sie an das Pinboard „Questions Marks“ gehängt. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 16

17 4. Editieren wie bei Wikipedia (60 min)
Validierung von Schritt 3 durch das Team. User Stories werden nun gemeinsam diskutiert, neu eingeordnet, bleiben hängen oder werden zu „Questions Marks“. Diskussionen zu Design und Architektur beginnen. Fehlende User Stories werden identifiziert. Klärungsbedarf durch Product Owner wird aufgezeigt. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 17

18 5. Zuordnung relativer Schätzgrössen (30 min)
Kategorisierung auf relative Grössen. “Smaller” und “Larger” werden durch Schätzgrössen ersetzt. Bspw. 1, 2, 3, 5, 8, 13, 21, 42. Zusätzlich wird die 100 verwendet. 100 steht für ein Epic, das viel zu gross ist, um in einem Sprint erledigt werden zu können. Jede User Story ist eindeutig einer Kategorie zugeordnet. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 18

19 6. Auflösung der „Questions Marks“ (30 min)
® 1&1 Internet AG 2012, Dr. Patrick Seifried 19

20 7. Prüfung der geschätzen Backlog Items (30 min)
Product Owner überprüft die Schätzung des Entwicklungsteams. Markierung der User Stories, die seiner Meinung nach zu hoch oder zu niedrig eingestuft wurden. Idealerweise hat das Entwicklungsteam in diesem Schritt eine Pause, so das der Product Owner ungestört ist. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 20

21 8. Estimation Challenge (60 min)
Der Product Owner stellt die markierten User Stories genau vor. Möglicherweise werden weitere Informationen ergänzt. Akzeptanzkriterien können angepasst, ergänzt und gestrichen werden. “Challenge” oder “Battle” der User Stories, die seiner Meinung nach falsch kategorisiert oder falsch interpretiert wurden. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 21

22 9. MoSCoW Estimation (60 min)
Must, Should, Could, Won‘t Die User Stories werden durch das Entwicklungsteam gemeinsam priorisiert. Häufig tritt die Frage auf: „Auf welches Ziel sollen wir priorisieren?“. Antwort: „Priorisierung um unsere Zielsetzung im Rahmen der Timebox zu erreichen. In unserem Beispiel „Funktionsfähige API am 1. Juni“. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 22

23 10. MoSCoW Challenge (60 min)
Identisch zu Estimation Challenge. User Stories können als “Out of Scope” markiert werden. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 23

24 11. Auswertung der Schätzergebnisse (10 min)
® 1&1 Internet AG 2012, Dr. Patrick Seifried 24

25 12. Auflösung (30 min) ® 1&1 Internet AG 2012, Dr. Patrick Seifried 25

26 13. Abbildung in ein elektronisches Tool (2 - 4 h)
Jedes Teammitglied übernimmt ein oder mehrer Kategorien und überträgt die gewonnen Informationen in das elektronische Tool (z.B. Jira). ® 1&1 Internet AG 2012, Dr. Patrick Seifried 26

27 Praxisbeispiel: 1&1 Development Hosting
Wie komme ich im Unternehmen von einem leeren Blatt zum vollen und geschätzten Product Backlog? vollen geschätzten ® 1&1 Internet AG 2012, Dr. Patrick Seifried 27

28 Monitoring des Product Backlogs.
® 1&1 Internet AG 2012, Dr. Patrick Seifried 28

29 Was waren die markanten Erfolgsfaktoren?
Team-, Abteilungs- und Bereichsleitung stehen hinter der Einführung von Scrum. Timebox von 2 Monaten, in denen „in Ruhe“ an den Maßnahmen gearbeitet werden konnte bevor erste offensichtliche Ergebnisse präsentiert werden. Offenheit aller Mitarbeiter für die agile Arbeitsweise. „Leben“ der Scrum Werte. Ein Technischer Product Owner der sich mit dem Produkt vollständig und bedingungslos identifiziert und das technische Know-how mitbringt. Ein starker ScrumMaster, der als agiler Coach wirken soll und darf. Kompromissloser Schutz des Entwicklungsteams vor unternehmensinternen Einflüssen. Erfolgreiche Reviews vor dem Management. ® 1&1 Internet AG 2012, Dr. Patrick Seifried 29

30 Vielen Dank für Ihre Aufmerksamkeit. Ihre Fragen?
® 1&1 Internet AG 2012, Dr. Patrick Seifried 30 30