READY-STEADY-DONE! Der Product Owner are you READY for agile?!

Größe: px

Ab Seite anzeigen:

Download "READY-STEADY-DONE! Der Product Owner are you READY for agile?!"

Monica Schreiber
vor 8 Jahren
Abrufe

1 READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring Oberhaching Germany Tel:

2 Neue Ideen sind durch ihre Ungewohntheit oft schwer verständlich Franz Marc Sein Talent kann man nicht einsetzen, wenn man sein Handwerk nicht versteht Harald Leibniz -2-

3 Die Szenarien Szenario 1: Interne Entwicklung Szenario 2: Externer Auftraggeber Weiterentwicklung eines bestehenden Software-Produktes Team arbeitet mit Scrum Ein Software- Entwicklungsprojekt Team des Auftragnehmers arbeitet mit Scrum -3-

Software-Produktes Team arbeitet mit Scrum Ein Software-

4 READY - STEADY - DONE Der Product Owner ist verantwortlich für das Product Backlog Sprint READY Verfügbar Priorisiert INVEST Verstanden STEADY Während des Sprints stabil Keine neuen Anforderungen DONE Potentiell lieferbares Produktinkrement Erfüllt die Definition of Done Abgenommen -4-

STEADY Während des Sprints stabil Keine neuen Anforderungen DONE

5 Zentrale Fragen 1. Wo sind die Unterschiede zum klassischen Anforderungsmanager und Projektleiter Wie bringt der PO beide Rollen unter einen Hut 2. Wie füllt der Product Owner das Backlog Welche Herausforderungen muss er dabei meistern 3. Was unterstützt den PO dabei, User Stories zu erstellen, die READY sind Entwickler und Kunden glücklich machen 4. Sind User Stories das Einzige, was ein guter PO kennen muss? 5. Wie stellt der PO sicher, dass er agil arbeitet -5-

einen Hut 2. Wie füllt der Product Owner das Backlog Welche Herausforderungen muss er dabei meistern 3.

6 Szenario 1: Interne Entwicklung Frage 1: Wo sind die Unterschiede zum klassischen Anforderungsmanager und Projektleiter In welchem Status der Scrum- Einführung befindet sich die Organisation? Wer sollte die PO-Rolle übernehmen? Gibt es bereits ein Product Backlog? -6-

Status der Scrum- Einführung befindet sich die Organisation?

7 Szenario 1: Interne Entwicklung Frage 2: Wie füllt der Product Owner das Backlog? Stakeholder Management Sind alle Anforderungen und Wünsche aller Stakeholder an das Produkt für den kommenden Sprint im Backlog enthalten? Priorisierung Sind alle Backlog Items priorisiert? -7-

Stakeholder Management Sind alle Anforderungen und Wünsche aller

8 Verfügbar: Stakeholder-Analyse I Interesse am Produkt Hoch Steigender Einfluss auf den Produkterfolg Niedrig Niedrig Hoch Stakeholder Einfluss / Macht -8-

9 Priorisiert Nach Stakeholdern Nach Themen MuSCoW Nach Risiko Backlog Grooming Nach Business Value Für den Kunden Für Ihr Unternehmen (Folgekosten, Kostensenkung) Nach Kano Nicht-Funktionale Aspekte/ Architektur Abhängigkeiten Organisatorischem (Abhängigkeiten vom Zulieferer) Spielen Sie Priorisierungs-Poker Zeitliche Rahmenbedingungen (Launch Date) -9-

Nicht-Funktionale Aspekte/ Architektur Abhängigkeiten Organisatorischem (Abhängigkeiten

10 Szenario 1: Interne Entwicklung Frage 3: Was unterstützt den PO dabei, User Stories zu erstellen, die READY sind Entwickler und Kunden glücklich machen Stakeholder Management Priorisierung Informationsmodell -10-

die READY sind Entwickler und Kunden glücklich

11 Informationsmodell Ebenen & Artefakte Ebenen Artefakte Notation Aktivitäten Problem Warum? Vision Epic, damit Backlog Grooming Was? Product Backlog User Story Als User will ich Planning I Wie? SW-Design z.b. UML Modell z.b. Use Case Planning II Lösung Was? Tasks Stichworte Stichworte Planning II Seite 11

Product Backlog User Story Als User will ich Planning I Wie? SW-Design z.b.

12 Ein Informationsmodell Verantwortung Verantwortlich: PO Beteiligt: Team Verantwortlich: Team Beteiligt: PO Der PO ist in allen Scrum-Meetings anwesend und steht jederzeit (auch während des Sprints) zur Beantwortung von Fragen zur Verfügung Seite 12

in allen Scrum-Meetings anwesend und steht jederzeit (auch

13 Ein Informationsmodell - Stakeholder Stakeholder (Business, Technisch,...) Technische Stakeholder (zentrale Architekur, Betrieb, Wartung...) Seite 13

14 INVEST Qualitätskriterien Problem Warum? Vision Epic, damit Backlog Grooming Was? Product Backlog User Story Als User will ich Planning I Wie? SW-Design z.b. UML Modell z.b. Use Case Planning II Lösung Was? Tasks Stichworte Stichworte Planning II Negotiable Valuable Estimateable Small Seite 14

Product Backlog User Story Als User will ich Planning I Wie? SW-Design z.

15 INVEST Qualitätskriterien Abhängigkeiten finden Stakeholder Themen Risiko Toolunterstützung Independent unabhängig Negotiable verhandelbar Valuable nützlich Abhängigkeiten Auflösen Rücksprache mit Stakeholdern und Team Schneiden von Stories Vertical - vertikal Estimateable schätzbar Small klein Testable testbar -15-

nützlich Abhängigkeiten Auflösen Rücksprache mit Stakeholdern und Team

16 INVEST Qualitätskriterien Independent unabhängig Negotiable verhandelbar Valuable nützlich Akzeptanzkriterien Anforderungen an die Story (keine neuen!) Nicht-funktionale Anforderungen Abnahmekriterien Vertical - vertikal Estimateable schätzbar Small klein Testable testbar Testumgebung Frühzeitig aufbauen Continuous Integration Regressionstests -16-

) Nicht-funktionale Anforderungen Abnahmekriterien Vertical - vertikal Estimateable

17 Szenario 1: Interne Entwicklung Frage 4: Sind User Stories das Einzige, was ein guter PO kennen muss? Stakeholder Management Priorisierung Informationsmodell -17-

18 User Story 1 User Story 2 User Story n Schneiden von Stories Präsentationsschicht Logikschicht Datenhaltungschicht Seite 18

19 Hilfsmittel beim Vertikalen Schneiden Business Use Case Modelle Use Case Beschreibungen Business Process Modelle Bleiben Sie auf Business-/ Problemebene -19-

20 Ein Informationsmodell - Stakeholder Technische Stakeholder (zentrale Architekur, Betrieb, Wartung...) Anforderungen an die Implementierung Seite 20

21 Ein Informationsmodell - Stakeholder Anforderungen an die Implementierung User Stories Use Cases Test Cases Seite 21

22 Szenario 1: Interne Entwicklung Frage 5: Wie stellt der PO sicher, dass er agil arbeitet Stakeholder Management Priorisierung Informationsmodell -22-

23 Embrace Change und STEADY Sprint 2 READY STEADY Änderungen Sprint 1 READY STEADY DONE t -23-

24 Embrace Change und DONE Definition of DONE z.b. Dokumentation Tests Refactoring Abnahme Sprint 1 READY STEADY DONE t -24-

25 Szenario 1: Interne Entwicklung Zusammengefasst: Beziehen Sie das Team in die Anforderungsmanagementaktivitäten ein Definieren Sie nicht die Lösung fragen Sie die Experten Beziehen Sie die Stakeholder mit ein und vergessen Sie externe Stakeholder nicht Versuchen Sie, auch die technische Lösungsfindung zu verstehen Holen Sie sich Hilfe vom Team beim Formulieren und Schneiden von User Stories Seien Sie aktiv, bringen Sie sich ein und geben Sie Feedback -25-

26 READY - STEADY - DONE Der Product Owner ist verantwortlich für das Product Backlog Sprint READY Verfügbar Priorisiert INVEST Verstanden STEADY Während des Sprints stabil Keine neuen Anforderungen DONE Potentiell lieferbares Produktinkrement Erfüllt die Definition of Done Abgenommen -26-

27 READY for Fragen oder sind Sie DONE? -27-

28 Vielen Dank! Susanne Mühlbauer HOOD GmbH Büro München Keltenring Oberhaching Germany Tel:

29 Backup -29-

30 Kano-Klassifikation Kano-Modell Kundenzufriedenheit Begeisterungsfaktoren neu unerwartet nicht ausgesprochen / unbewusst Leistungsfaktoren erwartet ausgesprochen bewusst Erfüllungsgrad Basisfaktoren selbstverständlich erwartet teilweise nicht bewusst Die Erfüllung von Basisanforderungen reicht nicht aus, um die Kunden zufrieden zu stellen Innovation bedeutet Erfüllen der Begeisterungsanforderungen Produkt Visionen enthalten normalerweise Begeisterungsfaktoren Quelle: Angepasst von Kurek R Erfolgsstrategien für Automobilzulieferer. Springer, Berlin. S

Ähnliche Dokumente

Susanne Muehlbauer 29. November 2011

Susanne Muehlbauer 29. November 2011 Machen Sie noch Modellierung Anforderungsmanagement oder sind Sie schon READY for SCRUM? Susanne Muehlbauer 29. Wer ist HOOD unser Geschäftsfeld Der Einsatz von Requirements Engineering und kontinuierliche