best brains product_owners_værktøjskasse_juni2014v2_handout

Product Ownerens værktøjskasse

11. juni 2014

Jesper Thaning, Partner

BestBrains

• Vurdering af behov (værdi og risiko) • Nedbrydning • Det visuelle • Afklaring af User Stories • PO i større organisationer • Tips om møder (rytmer og agendaer)

Agenda

PO in a nutshell – Henrik Kniberg

Mål

Behov

1.  Go live-deadline primo 2014 2.  Højere kvalitet i løsningen for slutbrugere 3.  Højere datakvalitet

•  Nem indtastning for udenlandske brugere •  Håndtering af dublerede data •  Mobilitet for myndigheder og udenlandske

brugere •  Validering af adresser

Projekt om social dumping

Hvorfor er det svært at udfylde rollen som Product Owner?

Vision

Roadmap

Release

Iteration

Dagligt

Prioritering

Nedbrydning

Klargøring

Planlægning Afklaring

Accept

Ibrugtagning

Estimering

Implementering

Behov

Værdi

Planlægning

1-6 mdr

Vision

Roadmap

Release

Iteration

4-6 uger

Dagligt

Vurdering

Måling

Vurdering

Behov

Værdi

Planlægning

1-6 mdr

Vision

Roadmap Vurdering

Case : Telemedicin

Side 11

80%

20%

0

0,5

1

1,5

2

Kronikere Omkostninger

Mill.

Mål 1. Empowerment 2. Ressourcer 3. Kvalitet

Forretningsmæssige Behov

B1: Opsamling af data fra måleudstyr som borgeren betjener i eget hjem

B2: Virtuel konsultation mellem borger og behandler (eks. video-konsultation)

B3: Nem vidensoverførsel fra borger til behandler om borgerens tilstand (eks. spørgeskema)

B4: Nem installation af måleapparater og opsamlingsenheder B5: Automatisk overførsel af data fra måleudstyr til relevant behandler

#1 Øvelse Vurdering - Materiale

Mål 1. Empowerment 2. Ressourcer 3. Kvalitet Hvorfor?

Hvordan? B1 Måleudstyr i hjemmet

B2 Virtuel konsultation B3 Vidensoverførsel

B4 Nem installation B5 Dataoverførsel

Hvad?

Behov

Krav

Empowerment Mål: Borgeren føler sig selvhjulpen i eget hjem (Hvorfor?) Behov: Borgeren kan selv følge med i data og agere proaktivt (Hvordan?) Metrik: •  Stigning i livskvalitet på 70% •  Reduktion af genindlæggelse med 30% (Hvor meget?)

Værdi •  Realisering af

specifikke mål

Vurdering af behov

Høj

Lav

Lav Høj

VÆR

DI

RISIKO

Risiko 1.  Forretningsmæssig 2.  Social 3.  Teknisk 4.  Omkostning + tid

Specifikke mål: 1.  Borgeren føler sig

selvhjulpen –Empowerment

2.  Frigøre ressourcer hos personale

3.  Højere kvalitet i behandlingen

Høj

Lav

Lav Høj

VÆR

DI

RISIKO B4: Nem

Installation B2 Virtuel

konsultation B5: Automatisk

overførsel B3: Viden fra borger

til behandler

B1 Opsamling af data

Specifikke mål: 1.  Empowerment 2.  Ressourcer 3.  Kvalitet i

behandlingen

Risiko 1.  Forretningsmæssig 2.  Social 3.  Teknisk 4.  Omkostning + tid

Forretningsmæssige Behov




B4: Nem installation af måleapparater og opsamlingsenheder

B5: Automatisk overførsel af data fra måleudstyr til relevant behandler

Forretningsmæssige Mål Forretningsmæssige Behov Relaterede krav

1. Empowerment ved at borgeren føler sig selvhjulpen i eget hjem


…

2. Frigøre ressourcer ved reduktion af ambulante besøg


…

3. Højere kvalitet ved bedre planlægning af behandlingen


…

2. Frigøre ressourcer i regi af kommunal pleje

B4: Nem installation af måleapparater og opsamlingsenheder

…

3. Højere kvalitet ved mere systematisk opfølgning på data og målinger

B5: Automatisk overførsel af data fra måleudstyr til relevant behandler

…

#1 Øvelse Vurdering - Materiale

Eksempler på Værdi/Risiko

Nedbrydning

Nedbrydning

Behov

Værdi

Planlægning

1-6 mdr

Vision

Roadmap

Release

Vurdering

1.  Prioritere 2. Småt er nemmere 3. Afdække afhængigheder 4.  Undgå gold-plating og gidsler

Hvorfor nedbryde behov og krav?

User Story

User Story

User Story

Start Indtast Indsend Kvittering

Nedbrydning

Metode#1: Handlinger i en arbejdsproces For at kunne implementere en simpel end-to-end og putte komplicerede trin på bagefter


Nedbrydning

Simpel

Kompleks

Metode#2 Simpel vs. kompleks Hvad er den simpleste version af denne funktionalitet? De mere komplekse variationer følger efter


Data

Lungefunktion

Blodprøve

Blodtryk

Temperatur

Nedbrydning

Metode#3 Variationer i data Hvilke typer af data skal systemet kunne håndtere. Hvad er den mest basale type?

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

Nedbrydning

Metode#4 Operationer De forretningsmæssige operationer kan være spredt over flere forskellige opgaver og roller.


§1 §2

§3

Nedbrydning

Metode#5: Hver enkelt forretningsregel Eller grupper af forretningsregler der hører sammen


Stor indsats

Nedbrydning

Metode#6 Stor indsats og efterfølgende Den første user story bærer den tekniske byrde for de efterfølgende


Nedbrydning

Metode#7 Input metode Hvordan ser den simple brugergrænseflade ud? Den mere brugervenlige og smarte?


2 s 20 ms

Nedbrydning

Metode#8 Ydeevne Hvordan får vi det til at fungere? Hvordan får vi det til at gå hurtigt?


PoC

Nedbrydning

Metode#9 Undersøgelse (spike) og implementation Ved dårlig forståelse af løsning eller manglende afhængigheder. Et nyt område enten teknisk eller forretningsmæssigt. Et Proof Of Concept (PoC)


Data

Lungefunktion

Blodprøve

Blodtryk

Temperatur

§1 §2

§3

Stor indsats

PoC 2 s 20 ms

Nedbrydning – 9 teknikker

Simpel

Kompleks

#1 Handlinger

#2 #3

#5 Regler

#4 Operationer

#6

#7 Inputmetode

#8 Ydeevne

#9

B1: Opsamling af data fra måleudstyr som borgeren betjener i eget hjem Følgende måleudstyr ønskes understøttet: blodtryks-måling, hæmoglobin-måling, spirometri(lungefunktion)-måling og vægt. B3: Understøttelse af spørgeskema til borger fra behandler Behandleren definerer spørgeskemaet ud fra en skabelon, borgeren udfylder spørgeskemaet, behandleren kvitterer for udfyldelse af spørgeskemaet, behandleren stiller diagnose på baggrund af spørgeskema og sender til borgeren. B4: Det skal være muligt at udvide systemet med nye måleapparater

#2 Øvelse Nedbrydning


Data

Lungefunktion

Blodprøve

Blodtryk

Temperatur

§1 §2

§3

Stor indsats

PoC 2 s 20 ms

Nedbrydning – 9 teknikker

Simpel

Kompleks

#1 Handlinger

#2 #3

#5 Regler

#4 Operationer

#6

#7 Inputmetode

#8 Ydeevne

#9

B1: Opsamling af data fra måleudstyr som borgeren betjener i eget hjem Følgende måleudstyr ønskes understøttet: blodtryks-måling, hæmoglobin-måling, spirometri(lungefunktion)-måling og vægt.

B3: Understøttelse af spørgeskema til borger fra behandler Behandleren definerer spørgeskemaet ud fra en skabelon, borgeren udfylder spørgeskemaet, behandleren kvitterer for udfyldelse af spørgeskemaet, behandleren stiller diagnose på baggrund af spørgeskema og sender til borgeren.

B4: Det skal være muligt at udvide systemet med nye måleapparater

Epic%

Beskrivelse% Acceptkriterie%

Delleverance)

Afhængigh

eder)

Reference)nr)

B2.1% Videokonsultation-–-borgerens-opsætning---

Videokonsultationen-skal-kunne-understøtte-alle-gængse-skærmstørrelser-

) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

% ) ) ) ) )

)

#2 Øvelse Nedbrydning af behov

Epic%

Beskrivelse% Acceptkriterie%

Delleverance)

Afhængigh

eder)

Reference)nr)

B1.1% Understøttelse)for)vægt7måling)))

Minimum)2)typer)af)vægte)skal)understøttes)

) ) )

B1.2% Understøttelse)for)hæmoglobin7måling) Skal)overholde)standard)XYZ)v1.4b) ) ) )

B1.3% Understøttelse)for)spirometri(lungefunktion)7måling)

) ) ) )

B1.4% Understøttelse)for)blodtryks7måling) ) ) ) )

B3.1% Behandleren)definerer)spørgeskemaet)ud)fra)en)skabelon)

Til)et)skema)skal)der)kunne)knyttes)en)eller)flere)diagnoser)

) ) )

B3.2% Borgeren)udfylder)spørgeskemaet) ) ) ) )

B3.3% Behandleren)kvitterer)for)udfyldelse)af)spørgeskemaet)

Det)skal)være)muligt)at)udskrive)besvarelser)mhp.)at)gemme)i)papirjournal.)Lovkrav!)

) ) )

B3.4% Behandleren)stiller)diagnose)på)baggrund)af)spørgeskema)

Diagnosen)skal)underskrives)digitalt)med)behandlerens)NemID)

) ) )

B3.5% Behandler)sender)diagnose)til)borgeren) Diagnosen)skal)afsendes)via)meddelelseskomponent)på)sundhed.dk)

) ) )

B4.1% Udvidelse)til)specifikke)simple)typer)af)måleudstyr)(standardiserede))

) ) ) )

B4.1% Udvidelse)til)komplicerede)typer)af)måleudstyr)(non7standardiserede))

) ) ) )

)

#2 Øvelse - løsning?

Side 36

Data

Operationer

Simpel/kompleks

Det visuelle

Tegn så meget du kan!

Tilstande…

Selvbetjeningsløsning .l virksomheder

Vindmølle-‐dri7

Det visuelle til styring og koordinering

Roadmap med a;ængigheder

Afklaring

Prioritering

Nedbrydning

Klargøring


Estimering

Behov

Værdi

Planlægning

1-6 mdr

Vision

Roadmap

Release

Iteration

4-6 uger

Vurdering

Skabelon til User Stories/Epics <ID> <Titel>

Story-line: Som <hvem - rolle> ønsker jeg at <hvad - behov> for at <hvorfor - værdi>

Beskrivelse: <kontekst for at forstå acceptkriterier – undgå ”skal”>

Afklaringer: <spørgsmål der skal besvares inden implementering>

Acceptkriterier: <kravene til det der skal implementeres – brug ”skal” (nummereret liste)>

Skabelon for User Stories - 1

Story-line Som <rolle>, ønsker jeg at <behov>, for at <mål> Beskrivelse •  Kontekst for behovet (som regel en kort brødtekst) •  Brug helst IKKE "skal" i sætningerne, da der ikke skal optræde

krav i beskrivelsen (de skal stå i acceptkriterierne) •  Afgrænsninger. Fx denne US omhandler ikke betaling. •  Referencer til andre Epics/US som beskriver relateret

funktionalitet. Fx. emailkvittering implementeres i USxx

Skabelon for User Stories – 2

Afklaringer •  Hvad ved vi ikke endnu? •  Spørgsmål der skal besvares inden implementering af user

story Acceptkriterier •  Nummeret liste af krav. Inddel gerne i over- og underpunkter. •  Brug gerne "SKAL" i acceptkriterierne •  Specificér evt. behov - hvad og ikke hvordan. Fx. •  Valideringer: Hvilke data skal valideres og evt. hvordan? •  Beskrivelse af forretningsregler •  Fejlscenarier

Hvordan modner man en hel organisation til at bruge agile

metoder? (og træner Product Ownere + hjælpere til at

styre backloggen i agile projekter?)

Processen for Product Owneren

Kunde Kunde

Processen for Product Owneren

Kunde

Tip Kanban-board til grooming

Board til at få overblik over igangværende arbejde

Tip

Man Man Tirs Tirs Ons Ons Tors Tors Fre Fre

Sprint planning

(Sp N)

Test opstart? (Sp N)

Demo (Sp N)

Retrospektiv (Sp N-1)

Pre-planning (Sp N+1)

Testmøde (Sp N+1)

Estimerings-møde

(Sp N+1)

Grooming-møde

(Sp N+1)

Grooming-møde

(Sp N+2)

Uge 1 Uge 2

Mødekalender (rytme i aktiviteterne)

Roadmap-møde

(Sp N++)

Roadmap-møde

(Sp N++) Sprint N+2

Sprint N+1

Sprint N

Tip - mødeagendaer

Backlog grooming-møde Frekvens: Hver uge Tidsramme: 1 time Mødeansvarlig: Product Owner Deltagere: Scrum Master, Product Owner samt relevante personer fra forretning eller udvikling Formål: •  At sikre at US til næste sprint bliver afklaret og beskrevet •  Sikre at acceptkriterier dækker ønskede forretningsbehov •  Sikre at afklaringer bliver håndteret Aktiviteter: •  Til mødet præsenterer Product Owner kort de US under

afklaring •  Evt. afklaringer besluttes på mødet eller uddelegeres •  Der uddeles opgaver indtil næste Grooming-møde

Ge>ng real – 37 Signals

hBp://ge>ngreal.37signals.com/ ”Build less” ”Start With No – Don’t be a yes man”

Prioritering

Nedbrydning

Klargøring


Accept

Ibrugtagning

Estimering

Implementering

Planlægning

1-6 mdr

Vision

Roadmap

Release

Iteration

4-6 uger

Dagligt

Vurdering

Måling ? VÆ

RD

I

RISIKO

Indtast

PoC

best brains product_owners_værktøjskasse_juni2014v2_handout

Business