Tilbakeblikk på INT sprint 2016-10

Tilbakeblikk på sprint 2016-10, med fokus på UH-Cerebrum.

Fokusområder frå retrospectiven

  • 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.
  • fhl lager arbeidsgruppe for å konkretisere kva som må til for å refaktorere Cerebrum, og grov-estimerer dette, så PO veit kor mange sprintar det krever
  • SM tek med sjekklistene til neste planleggingsmøta, og presser på for å holde gjennomgang av brukerhistoriene kort, så det vert mange timar til å subtaske.
  • SM printer ut sjekklistene, og deler ut på starten av planleggingsmøtet.
  • SM markerer brukarhistorie for parprogrammering, berre for å komme i gang med det. Håpet er at det går seg til etterkvart.
  • SM blir hissig når saker stopper opp. Ser på saker som står lengre på In Progress enn estimert.
  • SM blir hissig når saker har stått over ein dag på QA.
  • SM set av tid rett etter Daily Scrum av og til for å diskutere kva vi skal gjere for å få prioriterte saker gjennom.'
  • 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.
  • 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.

Tilstades

  • hanskfje
  • fhl
  • sgs
  • jbr
  • jsama
  • hamar
  • raymonm
  • tgk
  • jokim (ref)

    Sak 1: Oppsummering

    SM tek ei kort oppsummering av sprinten og måla frå forrige runde. Vi tek ein runde rundt bordet, der alle kjem med sine innspel til sprinten. Diskuterer det vi kjem over, og lager action items for neste sprint.

    Runde rundt bordet:

    • Vanleg sprint
    • Ønskeleg med kjappare sprint planlegging
    • Brukt lenger tid på story enn estimert
    • Burde komt på å prodsette personreg enn det vi gjorde
    • Inntrykk av at sprinten gjekk bra i starten av siste veka, men vi snubla litt på målstreken. Nokre saker var 99% ferdige.
      • For ein del stories oppdager vi at stories er vanskelege å oppfylle.
    • Greit med grupperinga av stories på Sprint Review
    • Fredrik holdt på med ei brukarhistorie, som nok var ein del underestimert!
      • Involverte utvikling av mykje rundt, som kanskje burde hatt fleire stories for denne.
      • Burde adressert på planlegginga at vi treng verktøy og tech stories for å få løyst brukarhistorien.
      • Burde tatt eit overblikk over korleis Cerebrum skal sjå ut.
      • Bør bruke tid på å diskutere løysing.
      • Diskuterte litt rundt bruken av tech stories:
        • Ha det med i sprintar eller td. sette av tid?
        • Når og kor skal tech stories komme opp?
        • Ønskeleg med roadmaps for produkta, ein del fram i tid, for å kunne diskutere korleis td. Cerebrum skal fungere teknisk no og framover.
    • Mykje prodsettingar siste dagen.
      • Instansar klaga over nedetid. Ønsker informasjon i forkant om når det skjer, men kan ikkje informere om kvar prodsetting, sjølv om det er ein viss fare for at det kan gå ned.
      • Om vi veit om store endringar må vi klart informere.
      • Rom for å forbedre deployeringa vår. Treng ikkje alltid å restarte job_runner kvar gang til dømes - spesielt om dette kunne blitt vurdert automatisk. Hinderet vårt er teknisk gjeld.
      • Rom for å sette forventingar om nedetid. Krav til oppetid. Forklare dette på Cerebrum-seminaret.

    Frå forrige sprint:

    • SM tek med sjekklistene til neste planleggingsmøta, og presser på for å holde gjennomgang av brukerhistoriene kort, så det vert mange timar til å subtaske.
      • Vart ikkje utført i forrige. Tek det opp på neste planlegging.
    • SM printer ut sjekklistene, og deler ut på starten av planleggingsmøtet.
      • Vart ikkje utført.
    • SM markerer brukarhistorie for parprogrammering, berre for å komme i gang med det. Håpet er at det går seg til etterkvart.
      • Prata om det, men fann ingen som passa så godt til det. Ta det med vidare.
    • SM blir hissig når saker stopper opp. Ser på saker som står lengre på In Progress enn estimert.
      • Ikkje hissig nok
      • Er teamet sitt ansvar og ikkje enkeltpersonar. SM må adresse saker sjølv om andre er borte.
      • Når skal begynne å mase? 4 user stories betyr etter 4 dagar!
    • SM blir hissig når saker har stått over ein dag på QA.
      • Samme som over.
    • SM set av tid rett etter Daily Scrum av og til for å diskutere kva vi skal gjere for å få prioriterte saker gjennom.'
      • Vart ikkje utført. Tek det med.
    • 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.
      • Blitt bedre, bra å dele inn brukerhistoriene.
      • Treng å få teamet enige om prosessen.
      • Fortsetter som denne gangen.
      • SM går gjennom rekkefølge og prosess dagen før.
    • SM kaller inn til halvtime med forberedande møte før Sprint Review. Frå 09:30 til 10:00 for planlegging. Dei som kjem for seint ringast, og sistkomande vert dagvakt for labdag.
      • Sprint Review er eit teamansvar og ikkje din eigen sak.
      • Alt burde blitt gjort klart før den siste halvtimen.
      • Set opp at alt skal vere klart før dette møtet.
      • Bruker møtet, med agenda, for å diskutere rekkefølge etc.

      Sak 2: Lean Coffee?

      Vi går gjennom og diskuterer innspel til kaffepraten.

      Tema som vart tatt opp:

      1. Ubrukt bollebudsjett - Vi har ikkje fullført ein sprint på lang tid, dette bør ikkje bli normalen og noko vi bør akseptere. Kva gjer vi?
        • AI: 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.
      2. Cerebrum-moduler. Kva skjer med dette? Ønskeleg å komme i gang med å få lagt inn skikkelig støtte for modular i Cerebrum
        • Dette bør vere ein atomisk operasjon, vert veldig vanskeleg å gjere det gradvis sidan det riv opp i kjernen.
        • Får truleg gjort mykje på ein sprint.
        • Handler om å refaktorere Cerebrum
        • AI: fhl lager arbeidsgruppe for å konkretisere kva som må til for å refaktorere Cerebrum, og grov-estimerer dette så PO veit kor mange sprintar det krever
        • Vi har fleire relaterte sprintar som også handler om teknisk gjeld, bl.a. om Unicodifisering og DevOps. Vi må finne ut kva som er viktigast.
      3. Testkriterie - korleis unngå å bomme?
        • Meir vage testkriterier som default?
        • Er skilnad på det vi har som "testkriterier", som er meir "how to demo", og det som heiter "acceptance criteria", som er bestillaren sin måte å sjekke om leveranser er ok. To forskjellige ting, ofte vanskeleg å få demonstrert eit akseptansekriterie.
        • SM endrer bruken frå acceptance criteria i Jira til "how to demo", for å gjere det tydelegare. Løyser ikkje problemet vårt, men greit å bruke riktige namn.
        • SM ser over sjekklista vår, om vi har riktige spørsmål rundt testkriterier, til dømes: Er det for dyrt å demonstrere? Har vi satt tekniske føringar? Er kriteriet fritt nok til at utviklinga ikkje vert bunden til ein måte å implementere det på?

      Tema vi ikkje nådde:

      1. Stående estimering - Kva kan vi gjere for å korte ned estimeringa?
      2. Rekkefølge i utviklinga. Kjem som følge av subtaskinga vår og at vi ikkje treff heilt på dette.
      3. Autotesting. Skal vi begynne å sette krav til autotesting før deployering?
      4. Teamet blir flinkere til å utvikle standardserte utv-verktøy i fellesskap?
      5. Tvitringa, korleis funker den?
      6. Heltidsansatte prioriterer større tasks, lar småtaskene ligge igjen til de(n) deltidsansatte
      7. Metodikk-forum - innspill til tema å ta opp?
      Publisert 27. juni 2016 11:14 - Sist endret 26. sep. 2017 11:48