Scrum events, ceremonier eller møder
Scrum definerer en række events, aktiviteter eller møder, der hver tjener sit specifikke formål og igen tilsammen udgør nogle af afgrænsningerne for, hvordan arbejdet forløber. Formålet med disse møder er, at Scrum teamet forbliver tro mod processen, holdes årvågne og holder udkig efter alle indikationer for forandringer, der måtte være på vej. På denne måde er der en fast rytme i et Scrum projekt. Dette hjælper alle med at finde ind i nogle gode vaner og derigennem udvikle en kultur, der passer til det komplekse domæne, hvor hyppige inspektioner er nødvendige.
Normalt er det Scrum Masteren, der faciliterer og er til stede ved alle disse møder.
Sprint Planning
Ikke overraskende starter et Sprint med planlægning, det kaldes Sprint Planning. Der foregår forskellige ting under Sprint Planning, der udvælges et sæt PBI’er til Sprintet, det besluttes hvordan de skal udføres og der vedtages et Sprint Mål. For forståelsens skyld vil vi gennemgå de to halvdele af Sprint Planning hver for sig.
Sprint Planning 1
Ved begyndelsen af hvert Sprint mødes hele Scrum Teamet for at udvælge det optimale sæt af PBI’er, der skal arbejdes på i Sprintet. Dette møde har en tidsramme på ca. en time for hver uge i Sprintet, vi kalder dette Sprint Planning 1.
Før mødet har Product Owneren ordnet og prioriteret Product Backloggen, og de relevante PBI’er er allerede blevet estimeret af Teamet. Han har også formuleret et forslag til et Sprint Mål – en enkelt sætning, der beskriver det forventede resultat af Sprintet. Teamet har inden mødet forholdt sig til deres egen kapacitet og har et bud på deres arbejdshastighed. De ved, om der f.eks. er nogen på ferie, eller der er andre grunde til, at Teamets arbejdshastighed skulle være anderledes end forventet. De har altså gjort sig klart, hvad de regner med at kunne yde.
Product Owneren gennemgår mundtligt de enkelte relevante PBI’er for Teamet. Om nødvendigt har Product Owneren medbragt andre folk, der kan svare på uddybende spørgsmål. Teamet stiller afklarende spørgsmål og viden opbygges, der afdækkes desuden, hvorvidt der er afhængigheder mellem PBI’er og Team-medlemmernes kompetencer. Måske ændrer estimater og prioriteringer sig under mødet, måske er der brug for at kontakte andre for at få svar.
Til sidst vil der være fundet et sæt PBI’er, som alle kan accepteres som værende det optimale, der kan opnås i det kommende Sprint i den timebox vi har til mødet. Teamet er overbeviste om, at de kan klare det, der er aftalt. Ved afslutningen af dette møde sker skiftet fra det strategiske til det taktiske område – fra “hvad der skal laves” til ”hvordan skal det laves”.
Sprint Planning 2
Umiddelbart derefter fortsætter Teamet og Scrum Masteren med anden halvdel af sprint planlægningen – Sprint Planning 2. Product Owneren kan tilkaldes, hvis der skulle dukke spørgsmål op, nogle Scrum Teams vælger også at have Product Owneren med til denne anden halvdel. Mødet har en tidsramme på omtrent samme længde som første halvdel.
Teamet færdiggør nu analyse og design af hvert enkelt PBI, så de ved i nødvendige og tilstrækkelige detaljer, hvordan de vil løse opgaven, gennemføre leverancen. Typisk resulterer det i, at de nedbryder hver enkelt PBI til en række arbejdsopgaver, som vi ofte kalder Tasks. Hovedprincippet er, at en sådan arbejdsopgave eller task kun skal være i gang i én dag – så skal den være færdig, men flere teammedlemmer må gerne arbejde på den.
Hvis nye spørgsmål dukker op, tilkaldes Product Owneren, som så uddyber eller finder svar. Teamet har jo set på tingene før, både under Product Backlog Refinement og under Sprint Planning 1. Hvis ny viden dukker op, kan sættet af udvalgte PBI’er selvfølgelig ændre sig. Teamet opbygger en Sprint Backlog med alt det arbejde, der skal udføres.
Når mødet er slut har hele Scrum Teamet et vedtaget Sprint Mål, en plan for Sprintet, en forpligtigelse – også kaldet en forudsigelse eller prognose – der specificerer hvad Teamet helt ærligt tror, det kan levere i det kommende Sprint. Teamet forpligter sig på at gøre deres bedste for at opnå dette mål og levere de PBI’er, de har forpligtet sig på. Teamet har desuden en rimelig god fornemmelse for, hvordan de skal gå i gang med arbejdet. Sprint Backloggen bliver gjort offentlig tilgængelig.
Daily Scrum
Hver dag i Sprintet mødes Teamet og Scrum Masteren på samme tid og sted for at følge op på fremdriften frem imod Sprint Målet, samt for at synkronisere de taktiske aktiviteter og planlægge den næste dag. Dette kaldes Daily Scrum. Det er god praksis (men ikke et krav) at alle – inklusive Scrum Masteren – besvarer tre spørgsmål:
- Hvad har jeg opnået siden i går?
- Hvad regner jeg med at opnå til i morgen?
- Er der nogle forhindringer, der gør, at jeg ikke kan udføre mit arbejde optimalt?
Daily Scrum varer maksimalt 15 minutter og er offentlig. Alle må gerne komme, det er en del af gennemsigtigheden, men alle må ikke tale. Hvis nogle har kommentarer eller spørgsmål, henvender de sig til Scrum Masteren efter Daily Scrum.
Under Daily Scrum sker det, at Teamet og Scrum Masteren opdager et behov for yderligere diskussion; i det tilfælde bliver andre små møder hurtigt aftalt. Daily Scrum er ikke til for at finde løsninger, men primært for at identificere forhindringer og blive enige om en plan for den næste dag.
Scrum Masteren fortæller også om sit arbejde. Nye forhindringer eller muligheder for forbedringer, der dukker op under mødet, bliver noteret af Scrum Masteren. Det er en god praksis, men ikke et krav, at Scrum Masteren vedligeholder en synlig liste kaldet Improvement Backlog. Umiddelbart efter Daily Scrum tager Scrum Masteren fat på de ting, der er blevet nævnt.
Sprint Review
Ved afslutningen af Sprintet afholdes der Sprint Review, hvor Scrum Teamet viser resultaterne – de afsluttede PBI’er – frem. Kun de ting, der er helt færdige vises frem. Scrum Teamet inviterer alle de tilstedeværende til at komme med feedback, det er det vigtigste for dette møde. Alle, der har interesse i initiativet, er velkomne på mødet og opfordres til at komme med tilbagemeldinger på det, de ser.
Product Owneren er naturligvis til stede og godkender formelt de færdige PBI’er. Hvis det skulle ske, at noget ikke godkendes eller skal ændres, sættes en nyt PBI på Product Backloggen. Product Owneren noterer sig alle nye ideer og kommentarer fra deltagerne.
Det er almen praksis under mødet, at diskutere Product Backloggen som den er og at forsøge at forudsige, hvornår forskellige leverancer kan være færdige baseret på den erhvervede erfaring. På samme måde bliver nye strømninger i forhold til brugerne, markedet, budgetter osv. vendt med det formål at opnå en fælles forståelse og at kunne give de bedst mulige input til den næste Sprint planlægning.
Sprint Review er timebokset ligesom alle andre Scrum møder med en anbefalet længde af max. 1 time per uge i Sprintet. Ofte holdes det dog lidt kort (f.eks. 90 min) for at tilpasse sig andre folk i organisationen og deres travle hverdag. Dette møde afslutter PDSA cirklen med hensyn til det produkt, der bliver leveret. Mødet giver også mening i lyset af Cynefin, da det er en invitation til mange med forskellig baggrund om at give feedback – ikke kun eksperterne.
Sprint Retrospective
Til allersidst i Sprintet mødes hele Scrum Teamet for at dele erfaringer fra det nyligt overståede Sprint såvel som ideer til yderligere forbedringer af Teamets arbejdsmetoder og processer.
Dette event kaldes Sprint Retrospective og er i Scrum Guide sat til max 3 timer for et 4 ugers Sprint. Ved kortere Sprints er mødet tilsvarende kortere. Erfaringsmæssigt kan dette dog opleves som for langt, så Teamet må selv finde en passende timebox.
Der er mange måder, hvorpå et Sprint Retrospective kan gennemføres. Det, der er vigtigt at opnå, er, at:
- Alle deler deres erfaringer fra Sprintet i forhold til menneskelige relationer, processer og værktøjer.
- Alle reflekterer over betydningen af disse erfaringer og beslutter, hvad der er positivt, og hvad der kunne forbedres.
- Alle prioriterer, hvad de gerne vil forbedre og tager en beslutning om at handle på det. Hvad skal Teamet gøre, hvad skal Product Owneren gøre og hvad skal Scrum Masteren gøre.
Dette møde afslutter PDSA cirklen i forhold til, hvordan arbejdet bliver udført – processen. Mødet er også i overensstemmelse med måden at tænke på i Cynefin. Vi anerkender, at vores arbejde typisk er komplekst og ikke et kompliceret ekspert domæne. Ved at lade de involverede selv vurdere samspillet og processen, opnås der en større indsigt.
Product Backlog Refinement
Der er endnu en vigtig aktivitet i Scrum, den kaldes Product Backlog Refinement. Det er nødvendigt at Product Backloggen bliver gennemarbejdet, forstået og forberedt, samt at relevante PBI’er bliver estimeret, før Backloggen er klar til Sprint Planlægningen. Dette er en aktivitet, der involverer Product Owneren og Teamet. Scrum Teamet beslutter hvor meget tid, der er brug for til denne aktivitet, man må føle sig lidt frem.
For at sikre sig at denne aktivitet faktisk finder sted, afholdes der typisk et eller flere møder Product Owneren og Teamet imellem, som ligger et sted i midten af det nuværende Sprint – med fokus på det kommende Sprint.
Mødet er en forberedelse til det næste Sprint Planning 1, så der er flere ting, der ligner hinanden, ved de to møder. Product Owneren og Teamet er til stede. Product Owneren gennemgår de PBI’er, han allerede har udvalgt som forslag til næste Sprint, og han gennemgår også nye PBI’er, samt PBI’er hvortil omstændighederne eller kravene af den ene eller anden grund har ændret sig. Der er igen dialog omkring det med henblik på at nå til en fælles forståelse.
Deltagerne bryder store Items (ofte kaldet Epics) ned i mere håndterbare størrelser (ofte kaldet Stories). De forbedrer derefter beskrivelserne, definerer acceptkriterier og estimerer omkostninger ved de forskellige PBI’er.
Forskellen på Product Backlog Refinement og Sprint Planning 1 er, at i stedet for at udvælge PBI’er bliver disse blot forbedret og estimeret i forhold til omkostninger (typisk i form af arbejde). Det er vigtigt at estimeringen udføres af de folk, der i sidste ende skal levere – nemlig Teamet.
Product Backlog Refinement er til stor gavn for Product Owneren, da det hjælper ham med at forbedre prioriteringen. Aktiviteten giver ham det bedst mulige overblik over sammenhængene samt et omkostningsestimat. Bagefter har han stadig tid til at færdiggøre prioriteringerne af backloggen frem til næste Sprint Planning.
