Product Ownerens værktøjskasse

Transkript

1 Product Ownerens værktøjskasse 26. marts 2014 Jesper Thaning, agil praktiker & partner i BestBrains

2 Agenda 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)

3 PO in a nutshell Henrik Kniberg

4 Projekt om social dumping Mål 1. Go live-deadline primo Højere kvalitet i løsningen for slutbrugere 3. Højere datakvalitet Behov Nem indtastning for udenlandske brugere Håndtering af dublerede data Mobilitet for myndigheder og udenlandske brugere Validering af adresser

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

6 Værdi Behov Vurdering 1-6 mdr Planlægning Nedbrydning Prioritering Ibrugtagning 1-6 mdr Måling Accept 1-2 uger Implementering Estimering 4-6 uger Afklaring Planlægning Klargøring

7

8 Vurdering

9 Behov Værdi Vurdering 1-6 mdr

10 Case : Telemedicin 2 1,5 1 20% 0,5 80% Mål 1. Empowerment 2. Ressourcer 3. Kvalitet 0 Mill. Kronikere Omkostninger Side 10

11 #1 Øvelse Vurdering - Materiale Forretningsmæssige Behov B1: Opsamling af data fra måleudstyr som borgeren betjener i eget hjem B2: Virtuel konsultation mellem borger og behandler (eks. videokonsultation) 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

12 Mål 1. Empowerment 2. Ressourcer 3. Kvalitet Hvorfor? B4 Nem installation B5 Dataoverførsel B2 Virtuel konsultation B1 Måleudstyr i B3 Vidensoverførsel hjemmet Behov Hvor meget? Hvordan? Krav Hvad?

13 Vurdering af behov Værdi Realisering af specifikke mål 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 VÆRDI Lav Lav RISIKO Høj

14 Høj Specifikke mål: 1. Empowerment 2. Ressourcer 3. Kvalitet i behandlingen Opsamling af data Risiko 1. Forretningsmæssig 2. Social 3. Teknisk 4. Omkostning + tid VÆRDI Viden fra borger til behandler Virtuel konsultation Automatisk overførsel Nem Installation Lav Lav RISIKO Høj

15 Eksempler på Værdi/Risiko

16 Eksempler på Værdi/Risiko

17 Nedbrydning

18 Behov Værdi Vurdering 1-6 mdr Planlægning Nedbrydning

19 Hvorfor nedbryde behov og krav? 1. Prioritere 2. Småt er nemmere 3. Afdække afhængigheder 4. Undgå gold-plating User User Story User Story Story

20 Nedbrydning Start Indtast Indsend Kvittering Metode#1: Handlinger i en arbejdsproces For at kunne implementere en simpel end-to-end og putte komplicerede trin på bagefter

21 Nedbrydning Start Indtast Indsend Kvittering Simpel Kompleks Metode#2 Simpel vs. kompleks Hvad er den simpleste version af denne funktionalitet? De mere komplekse variationer følger efter

22 Nedbrydning Start Indtast Indsend Kvittering Data Metode#3 Variationer i data Hvilke typer af data skal systemet kunne håndtere. Hvad er den mest basale type? Temperatur Blodprøve Blodtryk Lungefunktion

23 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering Metode#4 Operationer De forretningsmæssige operationer kan være spredt over flere forskellige opgaver og roller.

24 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering Metode#5: Hver enkelt forretningsregel Eller grupper af forretningsregler der hører sammen

25 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering Stor indsats Metode#6 Stor indsats og efterfølgende Den første user story bærer den tekniske byrde for de efterfølgende

26 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering Metode#7 Input metode Hvordan ser den simple brugergrænseflade ud? Den mere brugervenlige og smarte?

27 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering 2 s 20 ms Metode#8 Ydeevne Hvordan får vi det til at fungere? Hvordan får vi det til at gå hurtigt?

28 Nedbrydning Start Indtast Indsend Kvittering Modtagelse - behandling Registrering PoC 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)

29 Nedbrydning 9 teknikker Start Indtast Indsend Kvittering #9 PoC #3 #1 Handlinger Data Temperatur Blodprøve Stor indsats #6 Simpel Kompleks #2 Modtagelse - behandling 1 2 #7 Inputmetode #4 Operationer 3 #5 Regler Registrering 2 s 20 ms #8 Ydeevne Blodtryk Lungefunktion

30 #2 Øvelse Nedbrydning 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

31 Epic% #2 Øvelse - løsning? Beskrivelse% Data Acceptkriterie% Delleverance) Afhængigheder) 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) ) ) ) ) Operationer B3.1% Behandleren)definerer)spørgeskemaet)ud)fra) Til)et)skema)skal)der)kunne)knyttes)en) ) ) ) en)skabelon) 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!) Diagnosen)skal)underskrives)digitalt) med)behandlerens)nemid) ) ) ) B3.4% Behandleren)stiller)diagnose)på)baggrund)af) spørgeskema) ) ) ) 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)) Simpel/kompleks B4.1% Udvidelse)til)komplicerede)typer)af) ) ) ) ) måleudstyr)(non7standardiserede)) ) Side 31

32 Det visuelle

33 Tegn så meget du kan!

34 Tilstande

35 Selvbetjeningsløsning.l virksomheder

36 Vindmølle- dri7

37 Det visuelle til styring og koordinering

38

39

40 Afklaring

41 Behov Værdi Vurdering 1-6 mdr Planlægning Nedbrydning Prioritering Estimering 4-6 uger Afklaring Planlægning

42 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)>

43 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. kvittering implementeres i USxx

44 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

45 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?)

46 Processen for Product Owneren Kunde Kunde

47 Processen for Product Owneren Kunde

48 Kanban-board til grooming Board til at få overblik over igangværende arbejde JIRA med Agile plugin.

49 Tip Mødekalender (rytme i aktiviteterne) Roadmapmøde (Sp N++) Roadmapmøde (Sp N++) Groomingmøde (Sp N+2) Groomingmøde (Sp N+1) Estimerings -møde (Sp N+1) Testmøde (Sp N+1) Preplanning (Sp N+1) Sprint planning (Sp N) Retrospektiv (Sp N-1) Test opstart? (Sp N) Demo (Sp N) Man Tirs Ons Tors Fre Man Tirs Ons Tors Fre Uge 1 Uge 2

50 Tip 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

51 Ge9ng real 37 Signals h>p://ge9ngreal.37signals.com/

52 VÆRDI RISIKO Værdi Behov Vurdering 1-6 mdr Planlægning Nedbrydning Prioritering Ibrugtagning 1-6 mdr Måling Accept 1-2 uger Implementering Indtast Estimering 4-6 uger Klargøring PoC Afklaring Planlægning