Fokusområder frå retrospectiven
- Bedre deploy for samtlige produkter! - Fredrik ser på brukarhistorier og ber Hans Kristian om prioritet!
- Fordele brukarhistorier som er avhengige av kvarandre over fleire sprinter - epics! SM passer på på Sprint Planning.
- Jonas ber www-drift om meir tilgang på www-hoster, slik at det er mulig å prodsette uten mykje styr.
Tilstades
hanskfje- tvl
- fhl
- sgs
- jbr
- jsama
hamarraymonm- tgk
sis- jokim (ref)
- kvaade
- estephaz
- elisabhs
Innholdsfortegnelse
Sak 1: Oppsummering
SM tek ei kort oppsummering av sprinten og måla frå forrige runde. Vi tek deretter ein runde rundt bordet, der alle kjem med sine innspel til sprinten. Diskuterer det vi kjem over, og lager action items for neste sprint.
Frå forrige sprint:
- SM set av neste Sprint Retrospective som ikkje vert ferdig til å sjå på alle sakene i sprinten i detalj. Dette for å kartlegge kva vi gjorde feil i sprinten, spesielt i planlegginga.
Gjer dette no etterpå! - fhl lager arbeidsgruppe for å konkretisere kva som må til for å refaktorere Cerebrum, og grov-estimerer dette, så PO veit kor mange sprintar det krever
Ikkje påbegynt, utsetter til neste-neste sprint. Tar tid. - SM tek med sjekklistene til neste planleggingsmøte, og presser på for å holde gjennomgang av brukerhistoriene kort, så det vert mange timar til å subtaske.
Fungerte i teorien, men fekk ikkje utbytte av tasksa som forventa. Kan kanskje bli bedre med meir erfaring med subtasking. I våre sprintar er mange stories avhengige av kvarandre, så går i beina på kvarandre. - SM printer ut sjekklistene, og deler ut på starten av planleggingsmøtet.
Hadde den, men såg ikkje på den. Kjekt når td. drift er med. - SM markerer brukarhistorie for parprogrammering, berre for å komme i gang med det. Håpet er at det går seg til etterkvart.
Prøver litt til. - SM blir hissig når saker stopper opp. Ser på saker som står lengre på In Progress enn estimert.
Fortsetter med denne. - SM blir hissig når saker har stått over ein dag på QA.
Fortsetter med denne. - SM set av tid rett etter Daily Scrum av og til for å diskutere kva vi skal gjere for å få prioriterte saker gjennom.'
Fortsetter med denne. - SM bruker lenger tid på å oppsummere brukerhistoriene i Sprint Review. Bruker nokre minuttar på dette, for å gje ein god intro og gjere demo litt meir profesjonell.
Gjordet meir forståeleg. Fortsetter. - SM kaller inn til halvtime med forberedande møte før Sprint Review, 09:30-10:00. Agenda: Diskutere rekkefølge og forberede demo. Alle saker må vere fullførte før møtet. Dei som kjem for seint ringast, og sistkomande vert dagvakt for labdag.
Fortsetter med denne. Positive til dette.
Runde rundt bordet:
- Vart ikkje heilt ferdig.
- Trur stories vi hadde med var feil stories. Td. burde AD microservice vore klar, men det var den ikkje så måtte fikse den først, så fleire saker måtte stå på vent.
- Trur vi er dårleg på å sette sammen sprinter. Fokuserer for mykje på kor mykje story points det er plass til og ikkje samansettinga av sprinten.
- Kanskje det er bedre å fordele forskjellige stories i samme sprint, altså litt av AD-microservice og litt av alt anna, så ikkje mange stories må vente på andre stories i samme sprinten.
- Forslag til å endre rekkefølga vi implementerer på: Først lage deploy, så testar, så begynne å implementer. I dag gjerast det i omvendt rekkefølge, så måtte refaktorere AD-microservicen.
- Måtte holde på med masse andre som berre hadde indirekte med stories å gjere, td. refaktorere micorservicen. Mangla felleskomponentar.
- Vart ikkje så enkelt med arbeidsfordeling med alle subtasks. Vart vanskeleg å plukke tasks, vart ein del parprogrammering
- Føler ikkje seg så produktiv når ein parprogrammerer.
- Var mange og store stories. Drift følte ikkje for å ta ansvar for ein story.
- Nokre saker trengde meir enn to personar, sjølv om det står som PARprogrammering. Vi definerer dette ikkje så hardt.
- Ukjend platform og miljø. Sleit med bl.a. MS sin Execution Policy. Mykje å sette seg inn i og få miljøet til å funke. Tok ein del dagar før ein kunne begynne på sjølve utviklinga.
- Ang testperioden saman med drift:
- Mykje nytt, kanskje ikkje den beste sprinten å starte med. Føler ikkje har bidratt så mykje, men har lært mykje. Håper på å bidra meir etterkvart!
- Kom litt brått på, så ikkje tid til å forberede så mykje. Litt kaotisk, men positivt.
- Litt atypisk sprint, men det er mykje variasjon i sprintane våre.
Sak 2: Gjennomgang av alle brukarhistorier
Frå forrige Retrospective skulle vi neste gang ein sprint ikkje vert 100% fullført sjå på alle brukarhistoriene i detalj, for å kartlegge kva vi gjorde feil i sprinten, spesielt i planlegginga.
Forslag til framgangsmåte:
- Alle får utdelt penn og lappar, og kan henge opp forslag til Action Items på tavla i løpet av gjennomgangen.
- Vi ser på kvar story i sprinten, kommenterer, ser på faktisk tid brukt, og kva som var avvikande frå planlegginga. På tavla noterast differansen i tidsbruk, og årsaker til avvik.
- Etter gjennomgangen ser vi på oversikten og diskuterer kva som var årsakene til at sprinten ikkje vart fullførd. Noterer Action Items fortløpande.
- Diskuterer kva som er passande fokusområder for neste sprint, for å unngå at det skjer igjen.
Gjekk gjennom alle sakene, og fekk oversikten:
Vi brukte då omtrent 8 story points meir enn planlagt, som er rundt 22% av sprinten. Dette ser ut til å stemme nokonlunde med det som er att i sprinten - ish.
Etter gjennomgang av dette, trakk vi fram nokre gjengåande årsaker:
- Nye produkt/miljø/verktøy tar tid!
- Utrulling tar dessverre tid!
- Fleire uidentifiserte avhengigheter vi ikkje fekk tatt under Sprint Planning
- Intern QA-faktor var noko vi ikkje identifiserte, spesielt for småsakene - «kvalitet koster»!
Ut av dette fekk vi Action Items:
- Bedre deploy for samtlige produkter! (5 poeng) - Fredrik ser på brukarhistorier og ber Hans Kristian om prioritet!
- Fordele brukarshistorier som er avhengige av kvarandre over fleire sprinter - epics! (4 poeng)
- Jonas ber www-drift om meir tilgang på www-hoster, slik at det er mulig å prodsette uten mykje styr. (4 poeng)
- Legge til story points for kvar avhengighet mellom saker som dukker opp i ein sprint (1 poeng). Til dømes 0.5 story point per avhengighet - samanliminga av saker etterpå koster!
- Begynne å registrere faktisk tidsbruk i kvar brukarhistorie, for å enklare ha oversikt over kva som tok tid i ein sprint på neste retrospective (1 poeng)
- Få inn ein windows-konsulent, til dømes Pål eller Gunnar frå IT-drift, for å lære oss opp i powershell og windows-miljøet. (0 poeng)
- Få inn folk som er gode på windows som QA i sprinten, til dømes Pål eller Gunnar frå IT-drift. (0 poeng)
- Story: Verktøy for vedlikehold av GPG-kryptert innhold (migrere en nøkkel til en annen). (0 poeng)
Sak 3: Lean Coffee Retrospective
Hvis tid til overs, tek vi ein Lean Coffee Retrospective.
Nådde ikkje dette.