Product Ownerens værktøjskasse

Preview:

DESCRIPTION

 

Citation preview

Product Ownerens værktøjskasse

3. december 2013

Jesper Thaning

BestBrains

Hvordan føles det at være Product Owner?

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

Vurdering

Prioritering

Nedbrydning

Klargøring

Planlægning Afklaring

Accept

Ibrugtagning

Estimering

Måling

Implementering

Behov Værdi

Planlægning

1-2 uger

4-6 uger

1-6 mdr

1-6 mdr

Vurdering

Vurdering

Behov Værdi

1-6 mdr

Case : Telemedicin

Side 8

80%

20%

0

0,5

1

1,5

2

Kronikere Omkostninger

Mill.

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

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

Hvor meget?

Værdi •  Realisering af

specifikke mål

Vurdering af behov

Høj

Lav

Lav Høj

RD

I

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

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

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

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

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

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

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

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

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

Nedbrydning

Vurdering

Nedbrydning

Behov Værdi

Planlægning 1-6 mdr

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

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

Start Indtast Indsend Kvittering

Nedbrydning

Simpel

Kompleks

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

Start Indtast Indsend Kvittering

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.

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

§1 §2

§3

Nedbrydning

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

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

Stor indsats

Nedbrydning

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

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

Nedbrydning

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

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

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?

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

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)

Start Indtast Indsend Kvittering Modtagelse - behandling Registrering

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

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 27

Data

Operationer

Simpel/kompleks

Afklaring

Vurdering

Prioritering

Nedbrydning

Planlægning Afklaring

Estimering

Behov Værdi

Planlægning

4-6 uger

1-6 mdr

Skabelon til User Stories/Epics

B23 <Titel>

User story: Som <hvem> ønsker jeg at <hvad> for at <hvorfor>

B23 <Titel>

User story: Som <hvem> ønsker jeg at <hvad> for at <hvorfor>

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

Skabelon til User Stories/Epics

B23 <Titel>

User story: Som <hvem> ønsker jeg at <hvad> for at <hvorfor>

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

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

Skabelon til User Stories/Epics

B23 <Titel>

User story: Som <hvem> ønsker jeg at <hvad> for at <hvorfor>

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

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

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

Skabelon til User Stories/Epics

Skabelon til User Stories/Epics

B23 <Titel>

User story: Som <hvem> ønsker jeg at <hvad> for at <hvorfor>

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

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

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

Afhængigheder: <ressourcer, teknik (eksterne systemer)>

Afklaring: Acceptkriterier

B23

Acceptkriterier:

Detaljerne for en User Story •  Hvad skal med? •  Hvad skal ikke med? •  Hvad skal demoes? •  Forretningsregler etc.

Tip1: Rytmer i møderne

Backlog grooming møde Frekvens: Hver 2. uge, onsdag i uge 1 af sprintet Tidsramme: 1 time Mødeansvarlig: Product Owner (PO) Deltagere: SM og PO samt relevante forretnings- eller tekniske ressourcer Formål: · At markere US klar til klargøring · At informere om ændringer i den øvrige backlog, herunder emner til estimering Forudsætning: · Forud for mødet, fx. tirsdag, har kunden internt afholdt pre-grooming møde, hvor det fastlægges hvilke US der reelt er færdigafklaret. · SM har senest to timer inden (senest kl 12.00) backlog grooming mødet haft mulighed for at gennemlæse de afklarede US der skal gennemgås til mødet Agenda: 1. Til mødet præsenterer PO over afklarede US, 2. SM/Scrum teamet giver feedback på hvorvidt US er tilstrækkeligt beskrevet til at sprint teamet kan formulere en løsningsbeskrivelse. 3. Efter fælles tilpasning af US beskrivelse til mødet, sætter mødeansvarlig status til Klargøring i gang 4. … 5. … 6. Til Backlog grooming mødet præsenterer PO også alle nye eller markant ændrede backlog items for udviklingsteamet, således at disse kan estimeres i story points.

Tip2: Specifikke møder

Recommended