Har du også læst, at Scrum er simpelt, men er du stadig forvirret? Måske skyldes det Scrum-udøvernes store brug af indforståede termer og begreber, der endda ofte ikke oversættes til dansk. Det betyder, at det er sværere for dig at forstå det store billede, fordi mindre detaljer mudrer billedet.
Vi har derfor udviklet dette faktaark, der giver dig et indblik i de mest centrale termer fra Scrum-universet.
Er du nybegynder, vil jeg anbefale, at du læser denne artikel først. Her finder du en helt grundlæggende introduktion til Scrum.
I denne artikel gennemgår vi følgende begreber:
Som du måske ved, er Scrum en såkaldt iterativ proces, der er opbygget af en række Sprints og bygger på hurtig feedback. At processen er iterativ betyder egentlig blot, at den består af en række elementer, der gentages. På den måde udvikles produktet gradvist.
Scrums gradvise, gentagende fremgangsmåde afløser de traditionelle “faser” i “Vandfaldsmodellen”, til fordel for at man udvikler en mindre del af de vigtigste egenskaber først, med tilhørende hurtig feedback.
Hvor Vandfaldsmodellen forudsætter, at du kender alle detaljer ved dit projekt fra starten af, og at meget få fejl opstår undervejs, integrerer Scrum alle udviklingsaktiviteter i én iteration (et Sprint) og tilpasser med faste mellemrum til de ændringer man må opdage undervejs.
Der er størst potentiale ved Scrum i forhold til komplekse projekter, der involverer videnskabelse og samarbejde. F.eks. produkt- og softwareudvikling. Scrum associeres oftest med softwareudvikling, men har også spredt sig til mange andre områder.
Sprintet er hjertet i Scrum. Et Sprint er en afgrænset periode af 2 til 4 ugers varighed, hvor en “færdig”, brugbar og potentiel produktionsmoden funktionalitet er lavet. Et nyt Sprint begynder umiddelbart efter afslutningen af det foregående Sprint.
Under Sprintet må der ikke foretages ændringer, som vil påvirke Sprintets mål.
Scrum teamets sammensætning skal forblive den samme under hele Sprintet
Kvalitetsmålene må ikke mindskes
Projektets omfang kan præciseres og genforhandles mellem Product Owner og teamet, når man lærer nyt.
FAKTA
Ordet “scrum” stammer fra rugby og betyder “skærmydsler”. Og er det rugbyspillere gør, når de samler sig i en klump, inden de løber (sprinter) ned ad banen i samlet flok.
Product Owner
Produktejer. Er ansvarlig for at oversætte de input, ønsker og/eller krav kunden har, til en vision for produktet og til produktets Product Backlog.
Det er Product Owners opgave, at identificere hvor virksomheden får størst værdi for Teamets arbejde. Og prioritere disse, med de vigtigste, mest værdigivende features først.
Scrum Teamet
Udvikler det produkt Product Owner lægger op til. Teamet er selvstyrende og tværfagligt og indeholder ideelt set, alle de kompetencer der skal til for at udvikle et potentielt færdigt produkt. Et Scrum Team består af 7 plus/minus 2 personer.
Teamet laver produktet og udvikler forslag til Produkt Owner, der kan gøre produktet fantastisk.
Scrum Master
Har fokus på Scrum-processen og ikke på opgaver. Har viden og erfaring med Scrum, som han/hun bruger til at hjælpe teamet med Scrum-relaterede udfordringer. Faciliterer Scrum-processen, så det bliver lettere for Teamet at organisere og lede sig selv.
Sørger for at Scrum Teamet bliver succesfuldt. Fjerner f.eks. organisationelle hindringer, faciliterer møder og sørger for at teamet ikke afbrydes unødvendigt.
I Scrum holdes der med faste mellemrum møder for at skabe regelmæssighed og for at minimere behovet for møder, som ikke er defineret i Scrum. Møderne er alle tidsbegrænsede. På den måde bliver der brugt en passende mængde tid på planlægning. Alle møder faciliteres af Scrum Master.
Sprint planlægningsmøde
På dette møde planlægger Scrum Team og Product Owner, hvilke opgaver eller features (Backlog Items) de vil forsøge at gøre til et potentielt fungerende produkt. Det er Produkt Owners opgave, at meddele hvilke opgaver/features, der er mest vigtige, og Teamets opgave er at beslutte, hvor meget arbejde de tror de kan nå at fuldføre i løbet at Sprintet. Teamet “trækker” opgaver fra Produkt Backlog til Sprint Backlog, hvor de aktive opgaver befinder sig.
Ved slutningen af mødet inddeler teamet de valgte opgaver i en første liste af “Sprint Tasks” og forpligter sig endeligt til arbejdsopgaverne.
Daily Scrum og Sprint Execution
Et dagligt møde af maksimalt 15 min. varighed, hvor Scrum Teamet rapporterer til hinanden om fremgang og forhindringer.
Hver team-medlem besvarer følgende tre spørgsmål:
Inden for Scrum findes der en række hjælpemider, opgaver og organiseringsværktøjer, der gør det lettere at overskue de mange bevægelige dele i et Sprint.
Product Backlog
Første skridt i Scrum er, at Product Owner udvikler en vision for produktet. Efterhånden udvikler dette sig til en raffineret og prioriteret liste af features. Dette kaldes Product Backlog.
Vi har allerede vendt Product Backlog Meeting og vender vi tilbage til det, ser vi at formålet, med det møde er, at “gøre Product Backlog items mindre og mere håndterbare”. En Product Backlog indeholder således de arbejdsopgaver (items), der skal løses for at færdiggøre et produkt.
Product Owner er ansvarlig for denne liste, der i prioriteret orden f.eks. opremser alle funktioner, krav, udvidelser og fejlrettelser.
Product Backlog er:
Product Backlog Item
Hver af opgaverne på Product Backloggen kaldes et Produt Backlog Item og udgøres som regel af nye kunde-features (gør det muligt at placere bog i indkøbsvognen), men også udviklingsopgave (ændr købsprocessen, så den gøres skalérbar), forklarende- eller researchopgaver, præstations- og sikkerhedskrav og evt. kendte fejl.
Ofte udtrykkes disse, som det der kaldes “user stories”, der er præcise, tydelige beskrivelser af funktionaliteten ud fra dens værdi for slutbrugeren.
Sprint (eller Release) Backlog
Består af de Product Backlog Items, som er udvalgt til det aktuelle Sprint. Indeholder således Teamets forventning til, hvilke funktionaliteter, der vil være i det næste Sprint, og det arbejde, der er nødvendigt, for at levere denne funktionalitet. Dvs. alt det arbejde Teamet har identificeret som nødvendigt, for at nå Sprintets mål.
Sprint Backlog tilhører udelukkende Teamet og udvikler sig konstant.
Repræsenteres ofte med en fysisk informationsstation. F.eks. en tavle med Post it’s.
Sprint Task
Sprint burndown chart
Bruges til visuelt at vise, hvor mange arbejdstimer der er tilbage i et Sprint og om Teamet er med.
Product/release burndown chart
Svarer i princippet til Sprit Burndown Chart, men gælder her for hele produktet.
Et helt centralt element i Scrum er, at alle der arbejder på projektet, er enige om, hvornår et Item eller en Task er færdig. Så man f.eks. undgår at skulle vende tilbage til tidligere Items, fordi de alligevel ikke var færdige.
Scrum er designet til situationer, hvor krav og/eller teknologi er usikker.
D.v.s. opgaver, som folk tidligere har oplevet som uhåndterlige. Når du skal beslutte om Scrum er det rette for jer, så overvej, om de underliggende mekanismer er veldefinerede eller om arbejdet er afhængigt af videnskabelse og samarbejde. Scrum er f.eks. ikke designet til rutineopgaver. Overvej også om der er engagement i organisationen til at skabe selvorganiserende teams.
I mindre uforudsigelige situationer kan man med fordel anvende de fremgangsmåder, der beskrives i PMBOK(R).
Daily Scrum er ikke et sted, hvor man diskuterer, her finder der kun afrapportering sted. Er der brug for at diskutere noget, gøres dette på et efterfølgende møde.
Det er næsten altid en fordel, at Product Owner deltager i Daily Scrum. Til gengæld kan det være en stor ulempe, at Teamets chef eller andre med autoritet deltager, da det kan få dem til at føle sig “under opsyn” og under pres for at rapportere store (urealistiske) fremskridt hver dag.
Sprint Review Meeting
Et Sprint Review finder sted ved slutningen af hvert Sprint. Afhængig af Sprintets længde, hver 14. eller 30. dag. Her inspiceres den forgangne periode og hvis nødvendigt tilpasses Product Backlog.
Dette møde bruges til, at Product Owner og andre interessenter kan finde ud af, hvordan det går med Teamet (dvs. et tilbageblik på Sprintet) og samtidig skal Teamet finde ud af hvordan det går med produktet og markedet. Det vigtigste ved mødet er altså, en dybdegående samtale mellem Teamet og Product Owner, hvor alle informeres om den nuværende situation samt får og modtager råd.
Mødet inkluderer en demonstration, af hvad Teamet har lavet færdigt i det forgangne Sprint. Denne demo skal dog ikke tage form af en “præsentation”. Og derfor ingen Power Points! Faktisk siger Scrum, at der skal bruges så lidt tid som muligt på denne præsentation; maks 2 timer.
Sprint Retrospective Meeting
En vigtig og meget central del af Scrum er muligheden for løbende at inspicere og tilpasse. I Sprint Retrospective er det Teamets anvendelse af Scrum frameworket, der inspiceres og tilpasses.
Formålet er at:
Inspicere hvordan Sprintet er gået i forhold til personer, relationer, proces og værktøjer.
Identificere og ordne de større ting, der er gået godt, samt mulige forbedringer
Udarbejde en plan for implementering af forbedringer til hvordan Scrum Teamet arbejder.
Scrum Master spiller på dette måde en central faciliterende rolle.
Backlog Refinement Meeting
De fleste Product Backlog ‘items’ har som regel brug for videreudvikling (det der nogle gange kaldes “grooming”). Typisk fordi de er for store eller ikke forstået godt nok. Derfor finder mange Teams det nyttigt, at bruge lidt tid i hvert Sprint på at forberede Sprint Backloggen inden næste Sprint Planning møde.
Store ‘items’ opdeles og tydeliggøres.
Udfyld formularen for at booke en 30-60 minutters session.
Vi vil svarer inden for 24 timer
Kontakt os i dag og hør om dine muligheder
