Planning Poker

Denne øvelse træner estimering af user stories med brug af planning poker.

User Story 1: Studenterlogin.

Som studerende vil jeg kunne logge ind i systemet, så jeg kan tilgå mine personlige data.

Accepteret når: Systemet validerer brugerens oplysninger, og der vises en tydelig fejlmeddelelse ved forkert adgangskode.

User Story 2: Booking af studierum

Som studerende vil jeg kunne se en oversigt over ledige grupperum på skolen og booke et rum i op til fire timer.

Accepteret når: Kalenderen opdateres med det samme, og det er umuligt at booke et rum, der allerede er optaget af andre.

User Story 3: Karakteroversigt

Som studerende vil jeg kunne se en samlet liste over mine beståede karakterer.

Accepteret når: Data hentes fra skolens database og præsenteres i en læsevenlig tabel sorteret efter semester.

User Story 4: Notifikationer ved ændringer

Som studerende vil jeg modtage en e-mail, når skemaet for undervisning ændres mindre end 24 timer før start.

Accepteret når: Systemet automatisk sender en mail via en ekstern e-mail-tjeneste, så snart ændringen gemmes i databasen.

Når man ikke har estimeret før, har man brug for en opgave, som man allerede kender sværhedsgraden på, fordi planning poker gør brug af relativ estimering.

Anvend Silent Sizing metoden med de 4 user stories.

Forestil jer, at vi lægger de fire historier ud på et bord og flytter rundt på dem baseret på ren logik om kompleksitet, usikkerhed og mængden af kode, der skal skrives.

Læg dem nu i rækkefølgen fra lettest (venstre) til sværest (højre) uden for meget snak. Den user story som bliver den absolut mindste, bliver jeres reference som en 1’er eller 2’er, og så tæller I opad derfra.

Inddel jer i grupper på 3-5 personer. Brug jeres baseline og kortskalaen 1, 2, 3, 5, 8, 13 til at estimere de to efterfølgende user stories.

Som studievejleder vil jeg have systemet til at beregne en studerendes vægtede karaktergennemsnit baseret på ECTS-point, så jeg hurtigt kan vurdere deres studieaktivitet.

Acceptkriterier:

• Alle beståede karakterer (02 til 12) og de tilhørende eksaminers ECTS-point for et specifikt studieNummerhentes fra databasen.
• Logikken skal vægte karaktererne (f.eks. tæller et 10-ECTS fag dobbelt så meget som et 5-ECTS fag i gennemsnittet).
• Resultatet vises afrundet til én decimal (f.eks. 7.4). Hvis den studerende ingen karakterer har, vises 0.0.

Som underviser vil jeg have systemet til automatisk at inddele et hold af studerende i nye studiegrupper på 4 personer, så jeg slipper for at gøre det manuelt.

Acceptkriterier:

• Alle holdets studerende skal blandes tilfældigt.
• Systemet skal håndtere “resten”, hvis holdets antal ikke går op i 4 (f.eks. ved at lave et par grupper med 3 eller 5 personer – ingen må sidde alene i en gruppe).
• Processen skal køre som en samlet transaktion, så vi ikke risikerer fejlbehæftede, halve grupper i databasen, hvis programmet crasher undervejs.

• Har vi forstået målet? Ved vi nøjagtigt, hvad formålet er med denne User Story?
• Er acceptkriterierne klare? Ved vi præcis, hvornår opgaven er godkendt?
• Husk værktøjskassen: Vi løser som udgangspunkt opgaven med Java og SQL. Ingen web eller eksterne API’er medmindre I kender til dette.

• Kig på jeres baseline: Er denne user story sværere eller lettere end de user stories I tidligere har estimeret (relativ estimering)?
• Tænk på parametrene: Vurder ud fra Indsats (mængde kode), Kompleksitet (svær logik/algoritmer) og Usikkerhed (ting vi ikke har prøvet før).
• Glem uret! Du estimerer ikke i timer. Det handler om opgavens størrelse.

• Vis samtidigt: Hold kortet hemmeligt, indtil alle er klar. Vis på tællingen: 3, 2, 1, vend!
• Lyt til yderpunkterne: Hvis der er spredning i tallene (f.eks. en 3’er og en 13’er), skal den laveste og højeste stemme kort forklare deres argumenter.
• Undgå kodemudder: Diskuter forretningslogik og usikkerhed – ikke om I skal bruge en while-løkke eller en for-løkke.
• Find kompromiset: Stem igen. Svinger I mellem to nabotal (f.eks. 5 og 8), så vælg det højeste tal for en sikkerheds skyld, og kom videre.

Når alle grupper er færdige, samles klassen til en kort fælles opsamling:

1. Videndeling: Ændrede dit personlige estimat sig undervejs, efter du hørte dine gruppemedlemmers argumenter? Hvorfor?
2. Tidsfælden: Var det svært at lade være med at tænke i “timer”, og kom I til at diskutere specifikke kodelinjer i stedet for det overordnede mål?
3. Anvendelse: Hvordan vil I bruge denne teknik og en baseline på jeres kommende pet projekt og eksamensprojekt?