ScrumLite

ScrumLite er en tilpasset udgave af den agile projektmetode Scrum. Projektmetoden er tilpasset undervisningsprojekter og elevteams.
ScrumLite hjælper med at arbejde struktureret, iterativt og samarbejdsorienteret – uden at gøre processen for kompleks.

Scrum hviler på tre grundlæggende principper:

• Transparens – alle i teamet har indsigt i status og fremdrift
• Inspektion – arbejdet evalueres løbende af teamet
• Tilpasning – justeringer sker løbende baseret på feedback og læring

Disse principper understøttes konkret i ScrumLite ved hjælp af faste scrum-møder, et digitalt scrum board og simple værktøjer til planlægning og opfølgning.

Hver dag (eller ved hver projektdag) holder teamet et kort scrum-møde, hvor hvert medlem besvarer tre spørgsmål:

1. Hvad lavede jeg sidst?
2. Hvad skal jeg lave nu?
3. Er der noget, der blokerer mig?

Formålet er at skabe overblik, ansvarlighed og hurtig afklaring af udfordringer. Koordinere arbejdet for dagen

• Varighed: Max. 15 minutter (kort og effektivt)
• Hvornår: Hver dag, helst samme tidspunkt og sted
• Hold mødet stående: For at holde det kort og fokuseret
• Formål:
  • Sikre, at alle i teamet ved, hvad der sker og skal ske. (synlighed)
• Identificere forhindringer hurtigt

Stories og Tasks (opgaver) er ikke det samme, men de hænger sammen .

User stories beskriver hvad brugeren har brug for, og hvorfor det er vigtigt. De er skrevet fra brugerens perspektiv.

Eksempel:

Opgaver (tasks) er de konkrete ting, teamet skal gøre for at bygge user story’en.

Eksempler på opgaver:

• Design betalingsknap
• Kode integration med MobilePay
• Test betalingen

Et andet eksempel kunne være at du har fået nedenstående feedback fra en bruger ifm. en test af dit spil.

Brugeren har noteret:

Det er en story som brugeren fortæller den.

Det tekniske team (jer) skal omsætte en story til én, eller typisk flere opgaver.

Mulige opgaver (tasks) for teamet:

1. Undersøg hvordan autosave kan implementeres teknisk
2. Design et autosave-system (f.eks. hvert 5. minut eller efter hver mission)
3. Implementér autosave-funktionen
4. Test, at data bliver gemt korrekt og genindlæst ved opstart
5. Tilføj en besked til spilleren om, at spillet autosaves

• User story = hvad brugeren vil have. (formuleret af bruger)
• Tasks = hvad vi skal gøre for at levere det

• Scrum Board viser typisk begge, men tasks flyttes oftere mellem kolonner i daglig brug (To Do → Doing → Done).

ScrumLite anvender et Scrum Board, som visualiserer arbejdet. (Her kan et værktøj som Trello anvendes)

Boardet består af følgende kolonner:

• Backlog: Alle opgaver i projektet – en slags idébank
• To Do: Udvalgte opgaver, teamet har planlagt at løse i den aktuelle sprint
• In Progress: Opgaver, der er i gang
• Review: Opgaver, som et teammedlem mener er færdige og klar til gennemgang
• Done: Opgaver, som er godkendt af et andet teammedlem

Review-processen sikrer, at opgaver bliver inspiceret og godkendt, før de betragtes som færdige – dette understøtter inspektionsprincippet i Scrum, dette tillader at fange evt. fejl tidligt, og højner kvaliteten af jeres arbejde/produkt.

Et sprint er en afgrænset periode – typisk 1 til 3 uger – hvor teamet arbejder fokuseret på at færdiggøre et antal udvalgte opgaver fra backloggen.
Sprinten starter med en planlægning, hvor teamet vælger hvilke stories/opgaver der skal løses, og slutter med en evaluering, hvor resultatet vurderes.

Sprintens faste rammer hjælper jeres team med at holde fokus, prioritere opgaver og sikre løbende fremdrift.

I skal tilpasse sprintlængden efter projektets varighed, og gerne kunne foretage 2-4 sprints. (dvs. iterationer)

Første sprint startes med at definere MVP. :)

MVP står for Minimum Viable Product, på dansk „mindst levedygtige produkt“. MVP indeholder kun de absolut vigtigste funktioner, så det kan bruges og testes af rigtige brugere så tidligt som muligt.

• I det første sprint arbejder i på at bygge denne MVP.
• Det betyder, at vigtigste funktioner laves først – ikke alt på én gang!
• Når første sprint er slut, har i en simpel version, som i kan vise frem og få feedback på.
• Herefter bruges feedback til at forbedre og bygge videre i de næste sprints.

I Scrum bruges MVP som et mål for, hvad der er „godt nok“ til at blive lanceret eller vist til brugere – uden at vente på, at hele det færdige produkt er bygget. Ideen er at lære hurtigt: Når man får feedback tidligt, kan man forbedre produktet i de næste iterationer (sprints).

Eksempel: Hvis man laver en app til at bestille mad, kunne en MVP være en simpel version, hvor man kun kan vælge én ret og betale med MobilePay. Senere kan man så tilføje flere funktioner som menuer, anmeldelser og kortbetaling.

Fordelen: Man sparer tid, minimerer spild, og bygger noget, som brugerne rent faktisk har brug for – fordi man lytter til deres feedback undervejs.

Et Burn Down Chart bruges til at holde styr på fremdriften i projektet. Diagrammet viser, hvor mange opgaver (eller story points) der mangler i sprinten ift. tiden. Hvis kurven ikke falder som forventet, kan teamet nå at tilpasse deres plan.

Når en opgave eller story skal estimeres, kan i anvende Planning Poker. Hvert medlem vurderer, hvor omfattende en opgave er (fx i story points), og fremlægger sit bud. Ved uenighed diskuteres opgaven, indtil teamet når frem til en fælles vurdering. Det sikrer både realistiske tidsestimater og fælles forståelse af opgaven.

• Scrum (generelt)
• Synlighed (Princip)
• Inspicering (Princip)
• Tilpasning (Princip)
• Sprint
• MVP (Minimal Viable Product)
• Stories vs Tasks (Opgaver)
• Scrum Board
• Burn Down Chart (BDC)
• Planning Poker