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.
Scrum møder
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:
Hvad har du nået siden sidst?
Hvad regner du med at afslutte inden næste møde?
Hvilke forhindringer oplever du?
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.
### Scrum artefakter
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:
En prioriteret liste over ønskede funktionaliteter.
Synlig for alle interessenter.
Alle interessenter, inklusive Teamet, kan tilføje items.
Omprioriteres konstant af Product Owner.
Items øverst på listen er mere detaljerede end de nederste.
Vedligeholdes under Product Refinement Meeting.
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
Specificerer hvordan Product Backlog item’ets “hvad” opnås.
Kræver en dags arbejde, eller mindre.
Tilbageværende arbejde revurderes dagligt, typisk i antal timer.
I løbet af et Sprint, kan en person melde sig til at være hovedansvarlig for en opgave.
Ejet af hele holdet. Samarbejde er centralt.
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.
Kilde: https://lederindsigt.dk/vaerktoejer-skabeloner/ledelse-og-organisation/scrum-faktaark-de-vigtigste-begreber/
Sprintet
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.
Scrum møder 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:
Hvad har du nået siden sidst?
Hvad regner du med at afslutte inden næste møde?
Hvilke forhindringer oplever du?
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.
### Scrum artefakter 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:
En prioriteret liste over ønskede funktionaliteter. Synlig for alle interessenter. Alle interessenter, inklusive Teamet, kan tilføje items. Omprioriteres konstant af Product Owner. Items øverst på listen er mere detaljerede end de nederste. Vedligeholdes under Product Refinement Meeting. 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
Specificerer hvordan Product Backlog item’ets “hvad” opnås.
Kræver en dags arbejde, eller mindre.
Tilbageværende arbejde revurderes dagligt, typisk i antal timer.
I løbet af et Sprint, kan en person melde sig til at være hovedansvarlig for en opgave.
Ejet af hele holdet. Samarbejde er centralt.
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.