The Product Owner's Survival Kit - ein Überblick [DE]

Slide #2017 Michael Mahlberg
The Product Owner’s Survival Kit
Ein Überblick
1

WILLKOMMEN…
2

Slide #2017 Michael Mahlberg 3
Suchen Sie sich einen Partner, den sie noch nicht kennen,
stellen Sie sich einander kurz vor und ﬁnden Sie gemeinsam
5 Dinge, die ein Product Owner nicht sein oder machen
sollte aber dennoch oft ist oder macht.
Minuten Minuten Minuten Minuten
2:00 1:00 0:00

Suchen Sie sich einen neuen Partner, den Sie noch nicht
kennen, stellen Sie sich einander kurz vor und ﬁnden Sie
gemeinsam
5 Dinge, die ein Product Owner sein oder machen sollte
aber dennoch oft nicht ist oder macht.
Minuten Minuten Minuten Minuten
2:00 1:00 0:00

SECHS TRÜMPFE
Nach Sharon Bowman
5

6TRÜMPFE UM WISSEN ZU
ERWEITERN
6
Bewegung schlägt Sitzen
Reden schlägt Zuhören
Bilder schlagen Worte
Unterschiedlich schlägt gleich
Kürzer schlägt Länger
Schreiben schlägt Lesen

ZURÜCK ZUM THEMA
7

DINGE, DIE PRODUCT OWNER
TUN SOLLTEN:
• Anforderungen aufnehmen
• Verantwortlich sein
• Abstimmung mit
Stakeholdern
• Erreichbar sein für dasTeam
• Priorisieren
• Produktvision hüten
• Kundenkenner und
Marktkenner
• Zuhörer
• Kommunikator
• Backlog hüten
• Geschäftswert bestimmen
• Feedback geben (review)
8
Antworten aus dem
Publikum!

DINGE, DIE PRODUCT OWNER
NICHT TUN SOLLTEN:
• In die Umsetzung
einmischen
• Architekt sein
• Micromanagement
• Scrummaster sein
• Davon ausgehen, dass das
was er sendet das ist, was
empfangen wird
• Reiner Requirements
Engineer sein
• Teil des Entwicklungsteams
sein
• Boss des DevTeams
• Stories Schätzen
9
Antworten aus
Publikum

DER PRODUCT OWNER AN SICH
Der Product Owner (Scrum-Guide 2016)
Der Product Owner ist für die Wertmaximierung des Produkts sowie der
Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je
nach OrganisaAon, Scrum Team und Einzelpersonen stark variieren.
Der Product Owner ist die einzige Person, die für das Management des
Product Backlogs verantwortlich ist. Das Product Backlog-Management
umfasst:
• Product Backlog-Einträge klar zu formulieren;
• Die Einträge im Product Backlog so zu sorAeren, dass Ziele und
Missionen opAmal erreicht werden können;
• Den Wert der Arbeit zu opAmieren, die das Entwicklungsteam
erledigt;
• Das Sicherstellen, dass das Product Backlog sichtbar, transparent und
für alle klar ist sowie zeigt, woran das Scrum Team als nächstes
arbeiten wird; und
• sicherzustellen, dass das Entwicklungsteam die Product Backlog-
Einträge im erforderlichen Maße versteht.
 
Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie
durch das Entwicklungsteam erledigen lassen. Der Product Owner bleibt
jedoch immer rechenschaPspﬂichAg [accountable].  
Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar
die Wünsche eines Komitees im Product Backlog wiedergeben, aber
diejenigen, die einen Eintrag des Product Backlogs in seiner Priorität
verändern möchten, müssen sich an den Product Owner wenden.
Damit der Product Owner erfolgreich sein kann, muss die gesamte
OrganisaAon seine Entscheidungen respekAeren. Die Entscheidungen des
Product Owners sind in Inhalt und Reihenfolge des Product Backlogs
sichtbar. Niemand darf vom Entwicklungsteam verlangen, andere
Anforderungen zu bearbeiten. Dem Entwicklungsteam ist es nicht erlaubt,
nach den Angaben einer anderen Person als denen des Product Owners zu
arbeiten.
10

DER PRODUCT OWNER AN
SICH…
Der Product Owner ist die einzige Person, die für das Management des Product
Backlogs verantwortlich ist. Das Product Backlog-Management umfasst:
• Product Backlog-Einträge klar zu formulieren;
• Die Einträge im Product Backlog so zu sorAeren, dass Ziele und Missionen opAmal
erreicht werden können;
• Den Wert der Arbeit zu opAmieren, die das Entwicklungsteam erledigt;
• Das Sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar
ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird; und
• sicherzustellen, dass das Entwicklungsteam die Product Backlog-Einträge im
erforderlichen Maße versteht.
11

SICH…
Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das
Entwicklungsteam erledigen lassen. Der Product Owner bleibt jedoch immer
rechenschaPspﬂichAg [accountable].  
Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar die
Wünsche eines Komitees im Product Backlog wiedergeben, aber diejenigen, die
einen Eintrag des Product Backlogs in seiner Priorität verändern möchten, müssen
sich an den Product Owner wenden.
12

SICH…
Damit der Product Owner erfolgreich sein kann, muss die gesamte OrganisaAon
seine Entscheidungen respekAeren. Die Entscheidungen des Product Owners sind in
Inhalt und Reihenfolge des Product Backlogs sichtbar. Niemand darf vom
Entwicklungsteam verlangen, andere Anforderungen zu bearbeiten. Dem
Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als
denen des Product Owners zu arbeiten.
13

WAS FÜR EIN PRODUCT-OWNER?
Wer bin ich und wenn ja wie viele?
14

TYPEN VON PRODUCT-OWNERN
Product Owner nach Scrum
Stakeholder Manager
Surrogat Product Owner
Ambassador / Botschafter
Business Analyst
Systemanalytiker
Incident Manager
15
Proxy-POTeil-PO

Accept Reality!
16

DELEGATION BOARD
Nach Jurgen Appelo
18

MANAGE CAPACITY
aka nutze Kanban-Systeme
19

SYSTEMISCHES KONSENSIEREN
Dank an Jo Seibert! (seibert media)
20

NVC / GFK
Gewaltfreie Kommunikation
21

Kreativitätstechniken
22

ZWICKY BOX
Morphologischer Kasten
23

WIRKUNGSMATRIX
Cause-effect diagrams & Simulator
25

WIRKUNGSMATRIX
26

WIRKUNGSMATRIX
27

CAUSE & EFFECT DIAGRAM
28

STORY MAPPING
29

Backlog Management
30

SYSTEMISCHES KONSENSIEREN
Dank an Jo Seibert! (seibert media)
31

BUY A FEATURE
und andere Innovation Games
32

CCC
Card Conversation Conﬁrmation
33

CRC
C{lass|omponent|…} Responsibility Collaboration
34

SWOT
Nicht nur eine Matrix…
35

MOSCOW
&
TRIAGE
37

„DISCOVERY“ KANBAN
38

EISENHOWER MATRIX
39

–Peter Ferdinand Drucker
“It is fundamentally the confusion between
effectiveness and efﬁciency that stands between doing
the right things and doing things right.
There is surely nothing quite so useless as doing with
great efﬁciency what should not be done at all.”
Image: Drucker-portrait-bkt - The Drucker Institute, Claremont
Graduate University

–Peter Ferdinand Drucker
“Es ist im Wesentlichen dieVerwechslung von
Effektivität und Efﬁzienz die
dazwischen steht die richtigen Dinge zu tun und die
Dinge richtig zu tun.
Es gibt sicherlich nichts, dass so nutzlos ist, wie mit
großer Efﬁzienz zu tun was eigentlich überhaupt nicht
getan werden sollte”
Image: Drucker-portrait-bkt - The Drucker Institute, Claremont
Graduate University

SMART & INVEST
42
Speciﬁc
Measurable
Attainable
Realistic
Timed
Independent
Negotiable
Valuable
Estimable
Small
Testable

STORY-SPLITTING
43
Zuletzt aktualisiert am 10.8.2012Copyright © 2011-2012 Agile For All. Alle Rechte vorbehalten.
Unter http://www.richardlawrence.info/splitting-user-stories/ gibt es mehr Infos zu den Story Splitting Mustern.
Ins Deutsche übersetzt von Kai Simons - Agilist.de
www.agileforall.com
USER STORIES AUFTEILEN
DIE EINGANGSSTORY
VORBEREITEN
MUSTER
ANWENDEN
WORKFLOW SCHRITTE
OPERATIONEN
VARIATION DER
GESCHÄFTSREGELN
VARIATION DER
SCHNITTSTELLEN
VARIATION
DER DATEN
SIMPEL / KOMPLEX
PERFORMANCE
NACHLAGERN
EINEN SPIKE
HERAUSBRECHEN
GRÖßTER AUFWAND
DIE AUFTEILUNG
ÜBERPRÜFEN
Erfüllt die große Story die INVEST*-
Kriterien (abgesehen von SMALL)?
Sind die neuen Stories
etwa gleich groß?
Beschreibt die Story
einen Workflow?
Kann man die Story so aufteilen, dass
Workflowbeginn und -ende zuerst und
Stories aus der Mitte des Workflows als
Erweiterung umgesetzt werden?
Kann man zuerst einen
Minimalworkflow herausteilen,
welcher später mit anderen
Stories erweitert wird?
Enthält die Story mehrere
Operationen? (z.B. etwas "verwalten"
oder "konfigurieren"?)
Kannst Du die Operationen in
separate Stories aufteilen?
Enthält die Story verschiedene Ausprägungen
von Geschäftsregeln? (z.B. gibt es einen
Domänenbegriff wie "flexible Datumswerte",
der mehrere Variationen nahelegt?)
Kann man die Story so aufteilen, dass erst
eine Teilmenge der Regeln und später
erweiterte Regeln umgesetzt werden?
Macht die Story die
gleichen Dinge mit
unterschiedlichen Daten?
Kann man die Story so aufteilen,
dass erst ein Teil der Daten und
später ein anderer Teil der Daten
verarbeitet wird?
dass erst die Daten einer Schnittstelle
und später die der anderen
Schnittstellen verarbeitet werden?
Bekommt die Story die selben Daten
über unterschiedliche Schnittstellen?
Sind nach der naheliegendsten
Aufteilung alle Stories gleich schwer
zu implementieren, unabhängig
davon, mit welcher man anfängt?Kann man erstmal nur eine Story-Ausprägung
mit dem Hauptaufwand auswählen und
weitere Ausprägungen später hinzufügen?
Hat die Story einen einfachen
Kern, der den größten
Wert / Lernerfahrung beinhaltet?
dass zuerst der einfache Kern und
später Erweiterungen umgesetzt werden?
Wird die Story dadurch komplex,
dass nicht-funktionale Anforderungen
wie Performance umgesetzt
werden sollen?
dass erst eine nur funktionierende
Version umgesetzt wird und später
der nicht-funktionale Anteil?
Immer noch keine Idee, wie die
Story aufgeteilt werden kann?
Gibt es ein kleine Stück,
das verständlich genug ist,
um damit zu beginnen?
Welche 1-3 Fragen
halten Dich am
meisten zurück? Mach eine Pause
und versuch
es erneut.
Schreibe eine explorative
Story, welche mit minimalem Aufwand
zur Klärung dieser Fragen führt und
beginne diesen Prozess von vorne.
Schreibe diese Story zuerst,
setze sie um und beginne diesen
Prozess wieder von vorne.
Hat die Story eine
komplexe Schnittstelle?
Gibt es eine simple Version,
die zuerst erstellt werden kann?
Probiere ein anderes Muster
mit der Ursprungsstory oder den
neu entstandenen Stories.
Probiere ein anderes
Muster. Wahrscheinlich ist
noch etwas Überflüssiges
in jeder der Stories.
Probiere ein
anderes Muster.
Könnten manche der Stories
prinzipiell depriorisiert oder
komplett gestrichen werden?
Gibt es eine Story mit der
man offensichtlich anfangen
kann, um frühen Wert, Lernen oder
Risikovermeidung usw. zu erreichen?
Kombinere sie mit einer anderen Story
oder formuliere sie um, damit es eine
gute, wenn auch große,
Ausgangsstory wird.
Ist die Storygröße 1⁄10
bis 1⁄6 der Velocity?
Ist jede Story in etwa
1⁄10 bis 1⁄6 der Velocity groß?
Erfüllt die Story die
INVEST-Kriterien?
Die Story muss
aufgeteilt werden.
Fertig.
Probiere ein anderes
Muster, um die
Story zu zerlegen.Du bist fertig oder testest
noch ein anderes Muster
auf bessere Eignung.
JA
NEIN
Beginnehier
* INVEST - Stories sollten sein:
1
2
3
Independent (Unabhängig)
Negotiable (Diskutierbar)
Valuable (Werterzeugend)
Estimable (Schätzbar)
Small (Klein)
Testable (Testbar)
Letzte Möglichkeit
JA
NEIN

STORY-SPLITTING
44
http://agileforall.com/wp-content/uploads/2012/08/Story-
Splitting-Flowchart-DE.pdf

Stakeholder Management
45

KLASSISCHE MATRIX
46

RACI MATRIX
47
Responsible
Accountable
Consulted
Informed

Abnahmen
48

DAS ENDE DER STORY
… so that?
49

http://geek-and-poke.com/geekandpoke/2016/2/21/agile-families

AKZEPTANZKRITERIEN
Gherkin or not?
51

1: Feature: Some terse yet descriptive text of what is desired
2: Textual description of the business value of this feature
3: Business rules that govern the scope of the feature
4: Any additional information that will make the feature easier to understand
5:
6: Scenario: Some determinable business situation
7: Given some precondition
8: And some other precondition
9: When some action by the actor
10: And some other action
11: And yet another action
12: Then some testable outcome is achieved
13: And something else we can check happens too

DIE LÖSUNGEN VON GESTERN
SIND DIE PROBLEME VON HEUTE
53

DIE LÖSUNGEN VON GESTERN
SIND DIE PROBLEME VON HEUTE
54
Und das ist auch gut so

Accept Reality!
55

LIMIT YOUR WIP
56
Observe Orient Decide Act Nutzung
(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
doing doing doingdone done done
3

SICHTBARKEIT UND TRANSPARENZ
57
Delegation Board Eisenhower
Wichtig
Unwichtig
Dringend Nicht Dringend
Machen
Planen
Delegieren
Eliminieren

LINKS UND REFERENZEN
58
SWOT: https://de.wikipedia.org/wiki/SWOT-Analyse
Delegation Board https://management30.com/practice/delegation-board/
SechsTrümpfe http://bowperson.com/wp-content/uploads/2014/11/SixTrumpsArticle220101.pdf
Systemisches Konsensieren http://www.sk-prinzip.eu/das-sk-prinzip/zusammenfassung/
MoSCoW https://de.wikipedia.org/wiki/MoSCoW-Priorisierung
Zwicky-Box http://www.methodik.net/documents/lit%20Wyler%20kdf.pdf
Cause and Effect http://www.geraldmweinberg.com/Site/QSM_vol_1.html & https://www.chacocanyon.com/pointlookout/
130327.shtml & http://agilecoach.typepad.com/agile-coaching/2009/10/how-to-create-a-diagram-of-effects.html
Buy a feature http://www.innovationgames.com/buy-a-feature/
Story Splitting http://agileforall.com/wp-content/uploads/2012/08/Story-Splitting-Flowchart-DE.pdf
Story Mapping http://jpattonassociates.com/the-new-backlog/ & http://jpattonassociates.com/user-story-mapping/
Triage https://en.wikipedia.org/wiki/Triage
Discovery Kanban https://www.infoq.com/presentations/kanban-delivery-discovery
Scrum Guide http://www.scrumguides.org bzw. http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-
German.pdf
Akzeptanzkriterien Gojdko Adzic,,Speciﬁcation by Example: How SuccessfulTeams Deliver the Right Software, Manning, 2011 https://
www.amazon.de/Speciﬁcation-Example-Successful-Deliver-Software/dp/1617290084
Gherkin https://github.com/cucumber/cucumber/wiki/Gherkin
INVEST & SMART http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Impact Mapping https://www.impactmapping.org

ABSCHLIEßEND…
59
Viel Erfolg!

KONTAKTINFORMATIONEN
60
• Bei Fragen: Einfach anmailen: oop2017@michaelmahlberg.com
• BeiTwitter ﬁndet man mich als MMahlberg
• I blog about every two weeks in english at 
http://agile-aspects.michaelmahlberg.com
• Deutlich seltener schreibe ich in meinem deutschen Blog unter
http://shu-ha-ri.michaelmahlberg.de
• Ach ja: Meine Homepage ist http://www.michaelmahlberg.de

The Product Owner's Survival Kit - ein Überblick [DE]

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (7)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie The Product Owner's Survival Kit - ein Überblick [DE]

Ähnlich wie The Product Owner's Survival Kit - ein Überblick [DE] (20)

Mehr von Michael Mahlberg

Mehr von Michael Mahlberg (18)

The Product Owner's Survival Kit - ein Überblick [DE]