product ownerens værktøjskasse juni 2014
TRANSCRIPT
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
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
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
Eksempler på Værdi/Risiko
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
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
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
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
Planlægning Afklaring
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
Planlægning Afklaring
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