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

Vom leeren Blatt zum vollen geschätzen Product Backlog

Dr. Patrick Seifried, 10.5.2012Karlsruher Entwicklertag – Agile Day

1® 1&1 Internet AG 2012, Dr. Patrick Seifried

Warm-up


Ü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-WirtschaftsinformatikerUniversität Mannheim, Deutschland


Praxisbeispiel: 1&1 Development Hosting

Wie komme ich im Unternehmen von einem leeren Blatt zum vollen und geschätzten Product Backlog?

4

vollen geschätzten

® 1&1 Internet AG 2012, Dr. Patrick Seifried

Was war unsere Ausgangslage?


Was war unsere Ausgangslage?

Ein Product Manager,

den Projektnamen “HIP”,

das 1. Releasedatum: 1. Juni“,

das erwartete Lieferobjekt: „API für HIP“,

2 Monate Zeit für einen realen, umsetzbaren Meilensteinplan,

gering geklärte Verantwortlichkeiten,

keine klaren Rollen,

überall verteilte Mitarbeiter,

kein Projektvorgehen,

keinen Backlog,

keinen Scope,

kein Team,

aber dafür jede Menge …


Dev. Hosting ApplicationseBusiness Applications

-

Development RomaniaInt. Programm Mgmt. -

Technical PM HostingPM Domains/SSL

-

Int. Program ManagementProjektmanager Host.1234

-

Dev. HostingApplications Mail, Office

& Collaboration-

Development RO HostingDomain Development RO

-

Technical PM Hosting Classic Hosting

-

IT Ops Access &Shared App, IT Ops Shared

Applications -

Dev. Hosting ApplicationsePublishing Applications

-

Development RomaniaProcess and Delivery Mgmt.

-

Technical PM Hosting Business Operations

-

Project ControllingIT Security

-

Development DHIP Development HCS

-

Vorstand HostingTechnical PM Hosting

-

Development HostingInt. Programm Mgmt.

-

TPM Hosting–Classic Hosting Frontend Production

-

Development DHIPRequirements Engineer

-

Development DHIPFrontend Integration

-

1&1 Internet AGDemand & Delivery Mgmt.

-

Development HostingBereichsarchitekt

-

Development DHIPProjekt Manager 2

-

Development HostingDev. Hosting Applications

-

Development DHIPProjekt Manager 1

-

Development HostingDevelopment DHIP

-

Quality, Ops & ServicesQuality Assurance

-

Quality, Ops &Services Release & Change

Mgmt. -

Quality, Ops & ServicesTechnical Editors

-

Development HostingQuality, Ops & Services

-

Operatoins ServicesOPS Projekt Office

-

Quality, Ops & ServicesQuality Assurance

-

Development HostingDev. Server & Domains

-

Development HostingBereichsarchitekt

-

Development HostingFrontend Architect

-

Vorstand TechnologyDevelopment Hosting

-

Vorstand HostingPM Applications

-

Dev. Server & DomainsShared HostingInfrastructure -

Development RomaniaDevelopment RO Hosting

-

Technical PM Hosting Server & DevTools

-

Finance/Administra-tion Strategischer Einkauf

IT- und Facility Dienstleistungen -

Vorstand HostingPM Applications

-

Development HostingProgramm M. Webdesk

-

Dev. Server & DomainsDomains

-

Development RO HostingIntegration Hosting RO

-

Technical PM Hosting Hosting Quality Offensive

-

IT OperationsIT Ops Access & Shared App

-

PM ApplicationsSaaS

-

Stakeholder

HIP Product

Development

XY

XY

XYXY

XY

XY

XY

XY

XY

XY

XY

XY XY

XY

XY

XY

XY

XY

XY

XY

XY

XY

XY XY

XY XY

XYXY

XY

XY

XY

XY

XY

XY

XY

XYXY

XY

XY

XY

XY

Development DE Development RO

Div. Departments Product Management

Godparents

XYprename name

XY

7

Development DHIP ROProjekt Manager 1

Development DHIP ROProjekt Manager 2

XY XY XYXY


Was waren unsere Maßnahmen?


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 …


… Product Owner Board eingeführt.

Face to the customers

Technical Product Owner

Supporter I

Supporter II

Supporter III

Supporter IV

Supporter V

RequirementsEngineer

Systemarchitect

Software-Developer

Head of

ScrumMaster

Development Team

Product Manager

Stakeholders

As who I want what so that why

User Story

Interagiert Schreibt


Das Product Owner Board hat die Aufgaben:

11

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.




12

vollen geschätzten


13

AffiniTy Estimation and MoSCoW PriOritization

Erklärt in13. Schritten.

TEMPO


Der Product Owner kennt seinProduct 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. Vorbereitung


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.

2. Story Point Game (10 min)


Links “Smaller”, rechts “Larger”.

3. Stilles relatives Einordnen (30 min)

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.


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.

4. Editieren wie bei Wikipedia (60 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.

5. Zuordnung relativer Schätzgrössen (30 min)


6. Auflösung der „Questions Marks“ (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.

7. Prüfung der geschätzen Backlog Items (30 min)


Der Product Owner stellt die markierten User Stories genau vor.

8. Estimation Challenge (60 min)

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.


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

9. MoSCoW Estimation (60 min)


10. MoSCoW Challenge (60 min)

Identisch zu Estimation Challenge.

User Stories können als “Out of Scope” markiert werden.


11. Auswertung der Schätzergebnisse (10 min)


12. Auflösung (30 min)


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




27

vollen geschätzten


Monitoring des Product Backlogs.


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.


Vielen Dank für Ihre Aufmerksamkeit.

Ihre Fragen?


Documents

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