Sprinten gjekk totalt sett bra, men litt turbulent mot slutten. Ikkje alt vart fullførd, og kom nokre småendringar i løpet av sprinten som ikkje endra skopet.
Agenda
- Oppsummer retrospective frå forrige sprint
- Ikkje tekniske detaljar i stories.
- Opne taskoppdelingsmøter
- Sprint review seinare på dagen
- Be kvar person ta opp det dei meiner var viktig - lag timeline
- Kva gjekk bra? Gule lappar
- Kva kan forbedrast? Oransje/rosa lappar
- Kva kan/vil vi forbedre? Kven kan forbedre?
Referat
Ønskeleg å bli enige om rekkefølge på Sprint Review dagen før, så vi veit kven som gjer kva i løpet av demo. Forslag om plakat som hengast opp der folk kan skrive seg på i rekkefølge.
Kva gjer vi med hastesaker for PR på slutten av sprinten? Dersom det kjem inn PR onsdag kl 16, som inneheld småfeil, og demo er morgonen etter - kva gjer vi då?
Innspel frå Hans Kristian: Som policy skal vi ikkje fire på kvalitet. Det er bedre å la det gå utover sprinten enn å ha dårleg kvalitet.
Det var litt for mange uplanlagte aktivitetar som dukka opp i sprinten, så det kan sjå ut til at vi kanskje ikkje klarer fokusfaktor på 60%.
Det var diskutert om vi skulle satt deadline for alle stories ein dag før sprinten. Dette bunna ut i at vi bruker for lite tid på testing av det vi levererer. Diskuterte ei stund korleis bake inn meir testing. Forslaga var:
- Sette av heile siste dagen som test-dag, der ein ser over alle stories i samanheng og spesielt dependencies mellom desse.
- Justere ned fokusfaktoren for å handtere dette. Kom fram til at dette er feil bruk av fokusfaktor, då testing er inne i sprinten og fokusfaktor er for det som ligg utanfor. Det samme gjeld å evt. justere ned velocity, heng saman med fokusfaktor.
- Justere opp estimatet per story
- Lage eigen story for QA på slutten, der ein ser på alle stories i samanheng. Merk at vanleg testing av kvar story skal skje i storyen, som før.
Dette var tanken rundt personreg-v2-storyen, men vart ikkje heilt som tiltenkt/misforstått. Tanken var QA, å sjå over og teste samanhengen, men vart meir ein demo-lapp.
Konsensus vart at vi ser det an på planleggingsmøtet. Vi treng gjerne eigne QA-stories berre når det er store leveransar eller mange stories med dependency.
Vi må uansett bli bedre og meir strukturert rundt testing, så må uansett legge det inn i estimatet per story.
Denne sprinten var litt spesiell:
- Release av stor versjon - Personreg
- Vi var sterkt avhengig av SAP-folk, spesielt for å kunne oppfylle demokriteria.
- Det vart litt endringar i løpet av sprinten rundt det tekniske i samanheng med SAP, som skapte litt turbulens. Det endra ikkje skopet, men gjorde at arbeidet gjekk litt treigare enn det kunne.
- Dette kjem ikkje til å vere vanleg i sprintane. Vi må oppdage dette i planlegginga, vi ser at mange stories heng saman og er obs på det når vi ser kor mykje vi kan ta inn i sprinten.
Spørsmål rundt PR: Korleis gjerast PR i dag? Forslag om å legge inn eigen task på tavla for PR. Vi konkluderte ikkje noko på dette, sidan vi allereie har flytta lappar til kanten av linja på tavla for å markere at den er klar for code review.
Fokus for neste sprint
I prioritert rekkefølge:
- Svar på Pull Requests innen 1(?) dag
- Ikke konsistens mellom Jira, tavle og regneark. Foreslår lapper eller lignende for å markere endringer/inkonsistens.
- Vanskelig å finne oppgaver som er små nok for <50% ansatte.
- Henge opp liste der folk kan sette opp rekkefølgen for stories på Sprint Review
- Egen story for akseptanse-test
- Bruk mer tid på testing
Andre tilbakemeldingar:
- Fullførte etter spec, ble allikevel endringer og krøll
- Syncscript mot w3utv og feilmeldinger rundt dette - spesielt for permissions på filnivå. Tidkrevende å feilsøke og sette opp på nytt.
- Destiller stories mtp redundans og utvetydig/feil innhold. Ikke wall-of-text!
- QA: Folk må teste andre sine stories
- Forslag om egen task for PR, per story.
- Treng vi bedre tid til å forberede demo?
- Når jeg tester, må jeg mase på andre for å kunne teste
- Bedre informasjonsflyt med tanke på funksjonalitetsendringer som brekker miljø
- Oppdater dokumentasjon/guider om oppsett når de ikke lenger er gyldige
Vi fekk ikkje tid til å gå gjennom alle tilbakemeldingane.