Skip to main content

Scrum-ceremonier er en central del af praksissen med at implementere Agile, en tankegang, der værdsætter mennesker, fungerende arbejdsprodukter, interessentsamarbejde og tilpasning til forandringer.

Scrum-metoden og ceremonierne er baseret på Det agile manifest, som rummer flere metoder til at samarbejde og fungere som et team, alt sammen med den agile tankegang og det agile manifest in mente.

Hvis du har arbejdet på et team, der har talt om “Scrum-begivenheder”, “sprints”, “backlogpleje” og “sprintgennemgange”, har du sandsynligvis arbejdet med et team, der forsøgte at arbejde efter Scrum-metoden. Husk, at det agile rammeværk er en tankegang, mens Scrum er en metode.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

infografik over Scrum-metoden og den agile paraply
Scrum er en af de mange metoder, der hører under den agile paraply.

Hvad er Scrum-ceremonier?

Scrum-ceremonier (sommetider kaldet Scrum-begivenheder) er vigtige begivenheder eller elementer i Scrum-metoden, der følger den agile tankegang og ofte anvendes inden for softwareudvikling eller iterative projekter. 

Der findes fem specifikt definerede Scrum-ceremonier, som jeg gennemgår i dybden i næste afsnit af denne artikel.

Scrum-ceremonier er ikke bare møder for mødets skyld. I stedet udgør de rammen for, at teams kan få arbejdet udført på en struktureret måde, hjælper med at afstemme forventninger, giver teamet mulighed for at samarbejde effektivt og skaber i sidste ende resultater.

Hvis de ikke styres hensigtsmæssigt, kan de overfylde kalendere og overdøve den værdi, de er beregnet til at skabe. Når det er sagt, er Scrum i sig selv, ligesom Scrum-ceremonierne, bevidst enkelt og ukompliceret.

Lær mere i vores videogennemgang:

Hvad er de 5 Scrum-ceremonier?

Klar til at gennemgå de fem Scrum-ceremonier og -begivenheder? Lad os se på deres formål, deltagere samt tips og tricks til at gøre dem så effektive som muligt.

  1. Sprintet
  2. Sprintplanlægning
  3. Daglig Scrum
  4. Sprintgennemgang
  5. Sprintretrospektiv

Det er særligt værd at bemærke, at hver eneste af disse begivenheder er tidsafgrænset, målrettet og tjener det overordnede Scrum-team. Med andre ord findes de for at gøre det muligt at levere resultater. 

oversigt over det agile Scrum-rammeværk
En oversigt over det agile Scrum-rammeværk eller den agile Scrum-metode.

Bemærk: At gennemføre disse begivenheder isoleret vil ikke automatisk gøre dit team agilt, og det vil heller ikke sikre, at dit team arbejder efter Scrum-metoden. For at køre Scrum effektivt skal disse begivenheder være en del af en større, velforstået og tydeligt beskrevet proces. 

De bør understøtte samtaler i det agile team, så tingene bliver gjort. Og hvilken projektleder bryder sig ikke om at få tingene gjort? 

Sprintet

Et sprint i Scrum er en fast tidsperiode (som regel en måned eller mindre), hvor idéer omsættes til værdi. Sprints forekommer fortløbende, indtil produktet er færdigt (eller uden slutdato). Ofte måler teams deres fremtid i sprints. 

Sprintets formål

Formålet med sprintet er at tidsafgrænse arbejdstiden og få teams til at levere i overensstemmelse med deres forpligtelser. Sprints gør det muligt at opstille mål, der er kortsigtede, men solide. Under et sprint bør intet ændres, som kan bringe sprintmålet i fare. 

Sprintets deltagere

Hele Scrum-teamet—produktejeren, udviklingsteamet og Scrum-masteren.

Sprintets varighed

Et sprint varer mellem 1 og 4 uger, aldrig længere. Denne begrænsning gør det muligt for teams at komme i gang og levere løbende fremskridt uden at drive folk til vanvid. 

Når jeg implementerer Scrum med et nyt team, starter jeg ofte med 1-ugesprints, da vi generelt kan planlægge 1 uge frem i tiden. Mere avancerede teams, især dem, der leverer software, kører ofte 2-ugesprints for at skabe mere innovation og afprøvning i løbet af tidsboksen.

Nyttige tips

  • Sprints er hverken fjenden eller en motivator. Forsøg ikke at få folk til at gøre ting på grund af selve sprintet. Motivér dem i stedet til at nå sprintmålet og levere et produktinkrement. 
  • Overvej, hvornår dit sprint skal starte og slutte. Et sprint bør starte lige efter, at det sidste sprint slutter, bogstaveligt talt inden for få timer. Tiden mellem sprintets afslutning og start bør blot bruges på din sprintgennemgang, retrospektiv og sprintplanlægning; derefter starter det hele igen! 

Er der andet?

Sprints kan ikke gøres længere eller kortere. Et sprint kan kun annulleres, hvis sprintmålet bliver forældet. Det er kun produktejeren, der kan annullere sprintet. 

Møde om sprintplanlægning

Sprintplanlægningsmødet er den Scrum-begivenhed, der er designet til at sikre, at teamet er klar til at få de rigtige ting gjort i det kommende sprint.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Formålet med sprintplanlægning

Sprintplanlægning giver produktejeren og udviklingsteamet mulighed for at gennemgå den prioriterede produktbacklog, som normalt findes i Scrum-software eller agil projektstyringssoftware. Gennem en række drøftelser og forhandlinger identificerer de de elementer, som de forpligter sig til at færdiggøre inden sprintets afslutning. Det er produktejeren, der er ansvarlig for dette.

Deltagere i sprintplanlægningen

Scrum-teamet – produktejeren, udviklingsteamet og Scrum-masteren.

Varighed af sprintplanlægningen

Varigheden af de fleste Scrum-begivenheder er relateret til sprintets længde. Hvad angår sprintplanlægning, bør den vare 2 gange sprintets længde (i timer).

Nyttige tips

  • Store brugerhistorier og brugerhistorier kan opdeles i mindre opgaver og tildeles under sprintplanlægningen, så alle ved, hvad de er ansvarlige for.
  • Tilskynd teamet til at skitsere opgaver, fejl og alle andre elementer, der kræver det, under dette Scrum-møde. Det bør være en yderst samarbejdsorienteret begivenhed.
  • Forsøg at have et mål for teamets hastighed, før sprintplanlægningen begynder, forudsat at I har arbejdet efter Scrum-metoden i et stykke tid.

Er der andet?

Sprintplanlægning hjælper Scrum-teamet med at besvare spørgsmålene: “Hvad kan leveres i dette næste sprint? Og hvordan vil vi udføre arbejdet?” Det bidrager til forudsigelighed og skaber et samarbejdsorienteret miljø.


Skabeloner til sprintplanlægning

Skærmbillede af handout til sprintplanlægningens dagsorden
Et eksempel på materialet til sprintplanlægningens dagsorden.

I DPM-medlemskabets skabelonbibliotek finder du en dagsorden, en tjekliste og en e-mail, som kan downloades og tilpasses, så de passer til dit teams behov for sprintplanlægning. Det giver dig et produktivt og nyttigt sprintplanlægningsmøde.


Daglig Scrum (dagligt stand-up-møde)

Den daglige Scrum er teamets mulighed for at fejre de seneste resultater, lægge en plan for dagen og identificere eventuelle blokeringer i Scrum-projektet.

Formålet med det daglige Scrum-møde

Dette Scrum-arrangement er en hyppig og regelmæssig mulighed, hvor teamet mødes for at kommunikere de individuelle fremskridt hen imod sprintmålet. Det er ikke en statusopdatering, men bør tydeliggøre eventuelle hindringer for teamet.

Deltagere ved det daglige Scrum-møde

Scrum-masteren og udviklingsteamet. Produktejeren er valgfri.

Varighed af det daglige Scrum-møde

Dette møde er kort! Det bør ikke vare mere end 15 minutter. Det er nemmere sagt end gjort.

Nyttige tips

  • Afhold mødet på samme tidspunkt hver dag (typisk om morgenen), og stræb efter at gøre det så rutinepræget som muligt for Scrum-teamet.
  • Det daglige standupmøde bør ikke aflyses, hvis en leder eller Scrum-master ikke kan deltage. Mødet er for teamet; afhold det daglige Scrum-møde. 

Er der andet?

Dette hurtige tjek, der også kaldes det daglige standupmøde eller Scrum-mødet, bør gøre teamet klar til dagen, så de kan være afstemt og opbygge tillid til hinanden. Lad teammedlemmerne holde hinanden ansvarlige for at indfri deres forpligtelser hver dag.

Møde om sprintgennemgang

Mødet om sprintgennemgangen er det Scrum-arrangement, hvor alt arbejde, der er afsluttet under det foregående sprint, kan præsenteres for interessenterne.

Formålet med sprintgennemgangen

Ved afslutningen af hvert sprint giver sprintgennemgangen udviklingsteamet en platform til at præsentere alt det arbejde, der er blevet afsluttet. Det giver interessenterne mulighed for at inspicere eller tilpasse produktet, efterhånden som det udvikler sig.

Sprintgennemgange kan gennemføres på en uformel måde, eller de kan være mere strukturerede. Det kan afhænge af produktets livscyklus og udgivelsesplanlægningen.

Deltagere ved sprintgennemgangen

Scrum-teamet – produktejeren, udviklingsteamet og Scrum-masteren. Det kan også omfatte en blanding af ledelsesrepræsentanter eller eksterne interessenter.

Varighed af sprintgennemgangen

1 time pr. sprintuge. Et 2-ugers sprint bør have en 2 timer lang sprintgennemgang.

Nyttige tips

  • Produktejeren bør stille interessenterne spørgsmål, indsamle feedback og også give svar på eventuelle spørgsmål, der opstår.
  • Feedback, der kan omsættes til handling, og som modtages under sprintgennemgangen, bør omdannes til nye elementer i produktbackloggen med henblik på senere prioritering og drøftelse.

Er der andet?

Dette Scrum-arrangement, der også kaldes en sprintdemonstration, hjælper med at opbygge tillid mellem interessenterne og Scrum-teamet. Det er den mest direkte måde at indsamle tidlig og hyppig feedback på og tilføje den til sprintbackloggen.

Møde om sprintretrospektiv

Sprintretrospektivet er det sidste Scrum-arrangement i sprintforløbet, som giver teamet mulighed for at se tilbage på det arbejde, der blev afsluttet, og identificere forhold, der kan forbedres i fremtidige sprints på baggrund af deres erfaringer.

Formålet med sprintretrospektivet

Efter at en sprintgennemgang er blevet gennemført, har Scrum-teamet brug for tid til at reflektere over det arbejde, der netop blev præsenteret, og drøfte måder at forbedre både resultatet og den agile arbejdsproces på. Al feedback bør indsamles og tildeles på samme måde som andre større funktionselementer eller brugerhistorier, så Scrum-teamet forstår, hvem der er ansvarlig for hvad, og hvornår ændringerne vil blive implementeret.

Deltagere ved sprintretrospektivet

Scrum-masteren og udviklingsteamet. Produktejeren er valgfri.

Varighed af sprintretrospektivet

Typisk bør sprintretrospektiver ikke vare mere end 1,5 time for et to-ugers sprint. Hvis jeres sprints varer en måned, bør det ikke vare længere end 3 timer. 

Nyttige tips

  • Når I arbejder med delvist fjernarbejdende eller fuldt distribuerede teams, kan I bruge aktive samarbejdsværktøjer som Mentimeter eller Confluence for at få folk til at deltage uden at skulle slå lyden til og dele deres stemme med alle.
  • Hvis der bliver fremsat et forslag til forbedring, så spørg de øvrige medlemmer af Scrum-teamet, om de alle er enige. Hvis de er det, skal I identificere, hvordan anbefalingen skal føres ud i livet.

Er der andet?

Sørg for at skabe et miljø med psykologisk tryghed. Dette er ikke et spørgsmål om at placere skyld. Disse møder tydeliggør ofte anbefalinger til, hvordan man kan blive bedre og reducere risici fremadrettet. Som Scrum-master skal du sørge for at coache teamet til at give ærlig feedback og være respektfuld under hele begivenheden.

Scrum-rollerne

Efter at have nævnt nogle få Scrum-roller, lad os gennemgå, hvad hver af dem er:

  1. Produktejeren: Denne rolle repræsenterer kunden og virksomheden generelt for det produkt, de arbejder på. De ejer backloggen og fastlægger prioriteringen af arbejdselementer for udviklingsteamet. De træffer dagligt overordnede produktbeslutninger. De omsætter kundernes behov til konkrete arbejdselementer for udviklingsteamet.
  2. Scrum-masteren: Scrum-mastere er ansvarlige for at sikre, at teamet har det, der skal til for at få succes, herunder en klar forståelse af Scrum-processen. De fungerer på én gang som coach, rådgiver, fortaler, forhindringsfjerner, facilitator og mægler.

    Scrum-mastere er ansvarlige for at etablere Scrum som defineret i Scrum-guiden, men de er ikke projektledere (pas på ledere, der tror, at det er den samme rolle!)—de er ikke ansvarlige for arbejdsproduktet. En Scrum-master er heller ikke nødvendigvis én bestemt person eller et fuldtidsjob! Læs mere om Scrum-mastere kontra projektledere her.
  3. Udviklingsteamet: Dette er en gruppe af tværfunktionelle teammedlemmer, som alle fokuserer på leveringen af fungerende software eller teamets ønskede resultat. Det omfatter produktudviklere, designere, QA-medarbejdere og andre tekniske roller, der skal samarbejde om den faktiske udvikling af et produkt.

    Ideelt set er denne gruppe på 5-9 personer fuldt dedikeret til ét Scrum-team. I virkeligheden, og hos bureauer, kan det se lidt anderledes ud. Udviklingsteamet bør være selvorganiserende og motiveret til at skabe værdi, og med den rette facilitering fra en Scrum-master og produktejer kan det lykkes.
illustration, der viser hver Scrum-rolle med en kort sætning om deres ansvarsområder
De tre Scrum-roller: produktejer, Scrum-master og udviklingsteam.

Hver af disse roller har en unik deltagelse i hver af Scrum-begivenhederne. Når Scrum-begivenhederne faciliteres effektivt, får hver person i sin rolle en god mulighed for at få succes. 

Hvorfor er Scrum-begivenheder vigtige?

Scrum-begivenhederne er hjertet i Scrum-metoden. Uden begivenhederne kan Scrum meget hurtigt udvikle sig til en meget svær og rodet proces at følge. Det er især vigtigt for nye teams. Jeg opfordrer folk til at implementere Scrum, som det er beskrevet i Scrum-guiden, gennemføre nogle sprintiterationer og derefter vurdere, hvad der skal tilpasses, så det passer bedst muligt til teamet. 

Bemærk: Du har sikkert lagt mærke til, at vi ikke talte om et sprintboard (nogle gange kaldet et Kanban-board) i denne artikel. Det skyldes, at det ikke er et kerneelement i nogen af Scrum-begivenhederne. Sprintboards er fremragende værktøjer at bruge i hver begivenhed, men de er ikke et påkrævet element. 

Praktisk sammenligningstabel

Har du travlt? Se denne korte tabel for at sammenligne og skelne mellem de enkelte Scrum-begivenheder.

sammenligningstabel over Scrum-begivenheder, der opsummerer oplysningerne i denne artikel
Denne tabel sammenligner de 5 Scrum-begivenheder med hensyn til formålet med hver begivenhed, deltagere og tips.

Hvad synes du?

Uanset hvilken projektstyringssoftware du bruger, eller hvilket produkt du arbejder på, er disse Scrum-begivenheder designet til at skabe resultater.

Jeg har oplevet, at disse møder skaber struktur og forløber godt, når hele teamet bakker op og har en fælles forståelse af formålet med hver Scrum-begivenhed. Igen er Scrum en ramme, der kan bruges til at hjælpe med at levere software på en agil måde.