Tilstades
- fhl
- jsama
- mathiasm
- raymonm
- jbr
- jokim (ref)
- hamar (etter video)
- elisabhs
Sak 1: Gjennomgang av Scrum-metodikken [informasjon]
Vi repeterer Scrum-metodikken ved å sjå videoen frå Mike Cohn, Getting Agile with Scrum (56 min).
Sak 2: Tankar om gjennomgangen [diskusjon]
Har det dukka opp tankar etter å ha sett videoen? Noko vi ønsker å endre?
Vi diskuterte litt laust og fast rundt korleis vi arbeider. Ingen aksjonspunkt i møtet, så vi tek det opp att i samtalar, rundt Daily Scrum. Joakim tek det også opp i neste Sprint Retrospective, men vi bør diskutere det i kvardagen og ikkje vente på eit møte!
Stikkord frå diskusjonen:
- Mike snakka om at diskusjonar rundt designvalg høyrer til Sprint Planning. Vi har ikkje dette i dag, vi har fokusert på kortast mulig tid, men Mike seier at designvalg er nyttig å diskutere der. Usikkert kva vi ønsker, men vi ser at det kan vere nyttig. Gjer det enklare å få oversikt over kor store brukarhistorier eigentleg er, men krever at vi skriv ned konklusjonane frå planlegginga.
- Mike tok opp at det er teamet som velger stories i sprinten. PO set berre prioritering. Hos oss er det ein annleis balanse mellom team og PO. PO har hos oss større påvirkingskraft. Vi bør sei frå at vi ønsker å ha meir å sei til PO, td. rundt behovet for å arbeide med teknisk gjeld og tech stories. Korleis løyser vi det?
- Dagens Daily Scrum-møter følast slappe. Folk må dele meir av det som er relevant.
- Ang. kompleksitet er vi ofte langt oppe mot høgre hjørnet (anarchy). Cerebrum er td. eigentleg 50 produkt slått saman, og vi må få separert dei. Før vi får splitta produkta opp i reine, enklare produkt vil det framleis vere komplisert og vanskeleg, bl.a. å estimere.
- Har vi reglar for å splitte opp i INT? Er ikkje uttald, men føler vi har fokus på dette i det daglege, og for teknisk gjeld.
- Ønsker å ha muligheter, til dømes for fleksibilitet i templating. Generere og teste templates utan at det gjerast internt i eit batch-system.
- Vi må rapportere tilbake til PO om at dette går ut over kvalitet og påvirker kor lang tid tek. Det bør bli prioritert og bli inkludert i kvar sprint. I Lean snakkast det om å dedikere 20% av arbeidstida til å jobbe med slike forbedringar, fortløpande!
- Diskuterte story points og korleis vi bruker dei. Bør vi gå over til å bruke det som relativ faktor og ikkje som ideell arbeidsdag?
- Er gjerne slik det brukast andre stader. Mindre fokus på å knytte det til reell tid. Vi har til dømes velocity på 25 story points i gjennomsnitt, treng ikkje måtte telle arbeidsdagar per person for å vite dette.
- Kva gjer WAPP? Dei estimerer ikkje?
- Må gjere meir med teknisk gjeld fortløpande. Vanskeleg å få prioritert eigne teknisk-gjeld-sprintar.