Menu

Scrum-begivenheder: Time Boxing, Sprint Planning, Daily Stand-up og Backlog Refinement

  • Vigtigste
  • Andet
  • Scrum-begivenheder: Time Boxing, Sprint Planning, Daily Stand-up og Backlog Refinement

scrum events time boxing

Prøv Vores Instrument Til At Fjerne Problemer

Introduktion til Scrum-begivenheder:

I vores tidligere tutorials diskuterede vi Scrum, og hvordan er det struktureret.

Og vores tidligere tutorial forklarede alt om Scrum artefakter i detaljer.

Vi ved, hvem der udgør Scrum Team, og hvilke forskellige artefakter der er udviklet gennem hele processen. Vi har etableret en stærk baggrund nu. Lad os derfor tage et skridt foran på Scrum og diskutere de vigtigste begivenheder / ceremonier, der udgør Scrum-processen.

I denne vejledning vil vi forsøge at forstå, hvad hver af Scrum Event betyder, hvad der er de væsentligste funktioner, og hvordan organiserer vi dem detaljeret.

scrum begivenheder

Hvad du vil lære:

Oversigt

Mens man arbejder på et Scrum-baseret projekt, gennemgår scrum-teamet en række Scrum-ceremonier.

Nogle kalder dem måske Scrum-ceremonier eller begivenheder, og andre kalder dem måske for ritualer eller møder. Uanset de forskellige terminologier, der bruges her, forbliver målet for hver Scrum-begivenhed det samme. Hver af Scrum-begivenhederne hjælper i det væsentlige med at udføre og overvåge Sprint-arbejdet.

Typer af Scrum-begivenheder

Scrum begivenhedstyper

Hver Scrum-ceremoni er en personlig affære / samling arrangeret af Scrum Master for de dedikerede grupper. Bortset fra kerneteamet kan nogle af møderne involvere interessenter, leveringschefer eller endda kunden selv. Disse møder er tidsbokse og skal derfor gennemføres inden for den fastsatte tidsramme.

Målet med hvert møde er at samle deltagerne og lade dem diskutere det aktuelle arbejde. Forventningen fra enhver deltager er at forblive fokuseret, engageret og deltagende.

Det betragtes som en mulighed for at tale, undersøge og hente feedback fra det udførte arbejde. I modsætning til de almindelige møder er Scrum-begivenhederne resultatorienterede, tidsbokse, målgruppebaseret og har et specifikt mål tilpasset hver enkelt af dem.

Hvad er Time Boxing?

Timeboxing er en af ​​nøglefunktionerne knyttet til enhver Scrum-begivenhed. Deltagerne forventes at være opmærksomme og respektere den tid, der er afsat til hver af begivenhederne. Begivenhederne kan ikke udvides, men kan afkortes, hvis mødets mål allerede er nået.

Scrum Master, som også er en facilitator for alle Scrum-begivenheder, sørger for at alle forstår vigtigheden af ​​tidsboksning og minder dem også om at fokusere på mødets mål for at opnå de bedste resultater og i tidsresultater med afvigelser.

Timebox til en begivenhed bør ikke ideelt udvides, men da vi ved, at Scrum ikke handler om reglerne, kan tiden forlænges til en bestemt længde, hvis hver deltager er enig.

Hvordan bestemmer vi tidsboksen for hver af Scrum-begivenhederne?

Tidsboksen til Scrum Events er direkte proportional med længden af ​​Sprint. Den eneste undtagelse fra denne regel er dog Daily Standup, som har en fast tidsboks på 15 minutter uanset sprintlængden.

Der er standard tidsrammer for hver begivenhed baseret på Sprint-længden. Alligevel har holdet friheden til at bestemme tidsrammerne for disse begivenheder baseret på deres krav.

Lad os forstå flere af disse begreber ved at diskutere hver Scrum-begivenhed i detaljer.

Sprintplanlægningen

Som en forudsætning for denne ceremoni skal produktejeren have en stabil prioriteret produktbakke med brugerhistorier udarbejdet inden han kommer til mødet. Brugerhistorierne skal være velformede og klare nok til, at teamet kan forstå det.

Produktejeren kan søge hjælp fra interessenterne, kunden, designeren og Scrum Master til at udvikle produktforsinkelsen.

Det er obligatorisk at have acceptkriterier i en brugerhistorie. Holdet er autoriseret til at afvise en brugerhistorie uden acceptkriterierne.

Formål

Sprintplanlægning er den første ceremoni, mens du starter en Sprint. Formålet med Sprint Planning-mødet er at oprette et Sprint Goal, vælge brugerhistorier fra Product Backlog til Sprint Backlog og diskutere dem i detaljer.

Holdet mødes i et mødelokale sammen med Produktejeren og Scrum Master, hvor Produktejeren præsenterer de brugerhistorier, der skal vælges til næste sprint.

Teamet stiller muligvis så mange spørgsmål, som de gerne vil vide mere om historien, og det er Produktsejerens ansvar at adressere forespørgslerne. Holdet kan også udfordre historien for dens fuldstændighed og egnethed.

Hvis der kræves yderligere oplysninger i historien eller har en ufuldstændig afhængighed eller viser sig at være ufuldstændige, har holdet beføjelse til at afvise historien.

Tvivlen er trods alt ryddet, og holdet kender den nøjagtige mængde arbejde, der skal udføres for at færdiggøre en historie, estimerer holdet og giver historien point til hver af brugerhistorien.

På lignende måde diskuteres og estimeres de andre historier. Holdet vælger nu historierne fra toppen af ​​det prioriterede produktforsinkelse i Sprint-efterslæbet, som de tror, ​​de vil være i stand til at begå og udfylde i Sprint i betragtning af deres tidligere hastighed.

Hastighed bestemmes af det samlede antal historiepoint afsluttet i en gennemsnitlig sprint. Hastigheden beregnes ud fra de historiske sprints og ved at beregne dem i gennemsnit. Jo flere sprints vi gennemfører, jo mere stabil er holdets hastighed.

Mange hold bruger Planning Poker-kort til Story Estimation. Den mest almindelige estimeringsteknik er historiepegning ved hjælp af Fibonacci-serien. Fibonacci-serien er en række numre, hvor hvert næste nummer i serien udgøres ved at sammenlægge de to foregående numre.

Fibonacci-serien - 1, 1, 2, 3, 5, 8, 13 og så videre.

Brugerhistorierne, der estimeres ud over 13 historiepunkter, betragtes som meget store til at blive afsluttet i en enkelt sprint og nedbrydes derfor i mindre logiske brugerhistorier, som kan estimeres individuelt.

Under et Sprint Planning-møde opretter teamet også opgaver under brugerhistorierne, der er valgt til Sprint. Holdet forventes ikke at udføre alle brugerhistorierne under Sprint Planning, men det er bare nok til at få dem i gang. Resten af ​​opgaven kan udføres under sprinten.

Det vigtigste resultat af et Sprint Planning-møde er Sprint Goal og Sprint Backlog, som består af de brugerhistorier, som holdet har forpligtet sig til at gennemføre.

Sprintplanlægningsmøde

Bortset fra brugerhistorierne kan der være en anden type ting, der kan blive en del af Sprint Backlog.

  • Spikes
  • Teknisk gæld
  • Bugs

Spikes er forskningsopgaverne til at finde en løsning, dvs. behovet udløses af selve brugerhistorien. Nogle af historierne er muligvis ikke ligetil eller er ikke i teknisk kapacitet og vil derfor kræve mere analyse og forskning omkring dem. Derfor oprettes en spids. Det kan også omfatte en POC, hvis behovet opstår.

Teknisk gæld er refactoring af den eksisterende kode. Mange gange er der situationer, hvor holdet skal omarbejde den kode, der blev udviklet tidligere for at imødekomme de nye krav.

Bugs i Scrum er normalt de ubesvarede eller nye krav, der kommer ud fra de accepterede brugerhistorier, men er relevante for de aktuelle arbejdsemner. Hvis ikke et krav, kan det faktisk være en fejl i systemet, der blev afdækket under de foregående sprints, men ikke blev løst og er blevet prioriteret i denne sprint.

Deltagere

Alle i Scrum-teamet er en del af Sprint Planning-mødet. Ingen andre end kerneteamet er inviteret til at deltage i mødet.

Sprint Planning-mødet er organiseret og faciliteret af Scrum Master, men produktejeren stjæler showet.

Time-box

Sprintplanlægningsmødet kan tage så lang tid som en halv dag i to uger Sprint. Tidsfeltet for et Sprint Planning-møde afhænger direkte af Sprintens længde. Kortere for en kort sprint og længere for en lang sprint.

Sprint Planning-møde spiller en meget vigtig rolle i den overordnede Scrum-arkitektur og påvirker direkte det produkt, der udvikles. Derfor skal holdet investere så meget tid, som de mener er nødvendigt for at diskutere alle brugerhistorierne i detaljer, og kan foreslå en alternativ tidsboks, der passer dem.

Når tidsboksen er besluttet og aftalt, er det Scrum Master's ansvar at holde holdet fokuseret på målet og samtidig holde styr på tiden.

Den daglige standup

Formål

Daily Standup er et møde, der giver mulighed for at illustrere et samlet overblik over Sprints helbred. Det er også en platform til at diskutere, hvad de andre teammedlemmer arbejder på, og om der er noget, der stopper for at nå Sprints mål.

Under et dagligt standup-møde deler hvert teammedlem status på hans / hendes fremskridt med de arbejdsemner, de arbejder på. De vil også dele og søge hjælp fra de andre holdmedlemmer, hvis der er nogen blokeringer, der blokerer deres fremskridt.

Den daglige standup

Under et dagligt standupmøde besvarer hvert teammedlem omkring bordet følgende tre nøglespørgsmål en efter en:

'Hvad har du gjort siden det sidste Daily Standup Meeting?'

'Hvad planlægger du at gøre i dag?'

b træ og b + træ

'Er der nogen hindring, der blokerer for dit arbejde?'

De øvrige holdmedlemmer forventes at være opmærksomme, når nogen deler status og tilbyder hjælp, hvis behovet opstår. Så snart det sidste teammedlem har besvaret alle de tre spørgsmål, slutter mødet der.

Dagligt standup-møde giver et overordnet billede af, hvad der er den nuværende og samlede færdiggørelsesstatus for den iteration, de i øjeblikket arbejder på. Scrum Master spiller en meget vigtig rolle for at holde det daglige standup-møde fokuseret og tidsbegrænset. Han er også ansvarlig for at løse hindringerne, der blokerer for holdet fra at komme videre med deres brugerhistorier.

Scrum Master skal også sørge for, at ingen andre end kerneteamet stiller spørgsmål og præsenterer status. Han tillader muligvis hurtige diskussioner omkring brugerhistorierne, hvis det kræves, men skal være opmærksom på tiden hele tiden og kan når som helst træde ind og bede teammedlemmerne om at have en diskussion offline.

Deltagere

Alle kan deltage i et Daily Standup-møde. Det er dog obligatorisk for kerneteamet at deltage i mødet og præsentere status for deres arbejde.

Enhver anden, selv udefra, holdet, der er interesseret i at vide om Sprint-fremskridt, kan deltage i Daily Standup Meeting, men har ikke lov til at præsentere status for sit arbejde eller stille spørgsmål til udviklingsholdets medlemmer om deres arbejde.

Det er kun kernemedlemmerne, der har lov til at dele deres arbejde, og det forventes, at alle andre lytter lydløst.

Det daglige standup-møde skal afholdes, selvom der er et enkelt teammedlem til stede.

Holdet kan gennemføre det daglige standupmøde alene eller kan bede Scrum Master om at lette det for dem.

Time-box

Som navnet antyder, sker der et dagligt standupmøde dagligt, og deltagerne forventes at stå, da det kun er et kort møde på 15 minutter. Ideen er at holde sig til dagsordenen og ikke afvige fokus, derfor holdes mødet kort. At holde mødet hjælper også folket med let at forpligte sig til det, da det kun kræver 15 minutter.

Dagligt standup-møde holdes også på samme tid og på samme sted dagligt for at reducere forvirringen blandt deltagerne og overhead for at reservere mødelokalerne dagligt. Brugen af ​​laptops, desktops eller mobiltelefoner frarådes meget under mødet.

bedste gratis dvd ripper til windows

Holdene kan beslutte, hvornår de skal have Daily Standup-mødet og holde sig til det. Den normale tendens er imidlertid at holde møderne det første om morgenen. For holdene, der arbejder i forskellige tidszoner, fungerer morgenopkaldet muligvis ikke, og de kan således have opkaldet om eftermiddagen eller hvad der passer dem bedst.

Scrum Master deler muligvis også de vigtige nyheder eller opdateringer i slutningen af ​​mødet med holdet, hvis tiden tillader det, men har ikke tilladelse til at forlænge mødet for enhver pris.

Sprint-gennemgangen

Formål

Sprint Review Meeting handler om at demonstrere det udførte arbejde og samle feedback og buy-in. Nogle steder er Sprint Review-mødet også kendt som Sprint Demo. Sprint Review Meeting afholdes normalt i slutningen af ​​sprinten, men før Sprint Retrospective-mødet.

Den valgte repræsentant (er) fra holdet demonstrerer de aktuelle emner i sprintarbejde. Normalt demonstrerer udvikleren, der arbejder med brugerhistorien, arbejdet og reagerer på de spørgsmål, der er rejst af alle i publikum.

Brugerhistorierne, der udføres på baggrund af definitionen af ​​udført, er de eneste kandidater til demonstrationen på Sprint Review Meeting.

Produktejeren spiller en meget vigtig rolle under Sprint Review Meeting. Det er ham, der er ansvarlig for at evaluere hver af de brugerhistorier, der demonstreres mod dens acceptkriterier, og accepterer eller afviser historien.

De accepterede historier integreres derefter med Done Increment, som er en potentielt leverbar. Hvor går en afvist eller ufuldstændig historie hen, er produktejerens opkald. De afviste historier kan blive en del af den næste sprint eller kan flytte til Product Backlog, hvorfra de vil blive prioriteret igen.

Det vigtigste resultat af Sprint Review-mødet er et samlet billede af projektets afslutningsdato. Produktejeren accepterer / afviser historien, og de accepterede historier integreres derefter med inkrementet (oprettet under tidligere sprints) som en helhed for at give et bedre billede af, hvor vi står i at færdiggøre hele produktet.

Et andet vigtigt resultat af Sprint Review-mødet er, at teammedlemmerne lærer noget om estimering. Antallet af accepterede brugerhistorier bestemmer antallet af opnåede point i en sprint.

Således gradvist sprint for sprint kan holdet udvikle evnen til at estimere korrekt og træffe en informeret beslutning om de historiepoint, der er mulige at opnå.

Det bemærkes ofte, at sådanne møder kaster lys over de ufuldstændige acceptkriterier eller de 'nye krav, der dukker op. Den bedste måde at komme ud af denne situation er at lukke historierne og markere dem færdige, hvis de opfylder alle acceptkriterier, der oprindeligt blev aftalt under Sprint Planning Meeting.

Alt ud over dette skal betragtes som et nyt krav, og Produktejeren er ansvarlig for disse krav til den fremtidige sprint.

Sprint-gennemgangsmøde

Deltagere

Sprint Review Meeting deltager af teammedlemmerne inklusive Scrum Master og Product Owner. Andre deltagere i Sprint Review Meeting er interessenter, leveringschefer, kunder / slutbrugere eller enhver, der er interesseret i at være en del af Sprint Review.

Time-box

I et ideelt scenario i en to ugers sprint bruger vi cirka 2 timer i Sprint Review-mødet. Dette kan variere afhængigt af Sprint-længden. For en kortere sprint kortere Sprint Review og for en længere sprint længere Sprint Review.

Ligesom andre møder er Scrum Master ansvarlig for at holde dynamikken i mødet og sørge for, at aktiviteterne (demonstration af historierne, besvarelse af forespørgsler, accept af historierne, feedback noteret osv.) Passer inden for den fastsatte tidsramme.

Sprint Retrospective

Formål

Sprint Retrospective handler om at legemliggøre, hvad Agile siger - ' Regelmæssige overvejelser om, hvordan man bliver mere effektiv '. Sprint Retrospective giver mulighed for hele teamet til at reflektere og overveje, hvordan sprinten gik, og hvad skal der gøres for at improvisere processerne? Sprint Retrospective udføres i slutningen af ​​hver sprint.

Under et Sprint Retrospective-møde mødes hele holdet og diskuterer den Sprint, der lige var afsluttet. Holdet forventes at være gennemsigtigt og give ærlige meninger, men der er ingen skyld i spil.

Husk målet med mødet om at tage et skridt foran inden for improvisation og ikke holde holdet ved at øge spændingen blandt medlemmerne.

Alle sammen i holdet forventes at besvare de fire grundlæggende spørgsmål:

Sprint Retrospective

Scrum Master beder holdmedlemmerne om at skrive deres point for hver af kvadranterne som vist ovenfor i sticky notes. Nogle steder bruges værktøjer til samme formål.

Hvad gik godt?

Holdmedlemmerne giver et eller flere point på, hvad der gik godt i den sidste sprint. Dette afsnit kan også benyttes som en lejlighed til at værdsætte og anerkende de andre teammedlemmer for deres gode arbejde.

Hvad har du lært?

Scrum betragtes som en mulighed for at lære noget nyt i hver sprint. Dette område af en kvadrant er at diskutere de vigtigste afhentninger og lærdomme fra den sidste sprint.

Hvad gik ikke godt?

Under dette afsnit diskuterer holdet de problemer og forhindringer, de havde haft i løbet af den sidste sprint. Denne del af mødet har tendens til at være den mest skrøbelige, da folk måske rejser spørgsmål, der kan gøre de andre ubehagelige.

Det er Scrum Master's ansvar at berolige atmosfæren, hvis behovet er og lære folk at rejse deres problemer på en konstruktiv måde i stedet for at gennemgå runderne med personlige angreb.

Hvis nogen af ​​medlemmerne er ubehagelige med at konfrontere problemerne foran de andre holdkammerater, kan han senere gå til Scrum Master og diskutere problemerne.

Hvad kunne man gøre bedre?

Denne del af mødet giver alle teammedlemmerne mulighed for at diskutere alle de spørgsmål, der er rejst tidligere og finde måder at løse dem på. Alle i teamet er velkomne til at foreslå løsninger på det aktuelle problem. Holdet beslutter derefter i enhed om de bedst egnede løsninger.

Holdet bør også overveje at holde sig til de ting, der blev diskuteret under afsnittet om hvad der gik godt, også for de fremtidige sprints, og fremadrettet kan disse ting tilføjes som en integreret del af processen.

Resultatet af Sprint Retrospective-mødet er en liste over handlingspunkter, som deltagerne er enige om at forbedre processen til den kommende sprint.

Deltagere

Hele Scrum-teamet inklusive Scrum Master og Produktejeren. Men i modsætning til et dagligt standup-møde deltager Scrum Master og produktet også i at levere deres input og retrospektive point.

Ligesom Daily Standup-møde letter Sprint Retrospective-møde også af Scrum Master. Scrum Master sørger for, at alle i teamet inklusive ham selv får mulighed for at åbne op og tale både det positive og det negative.

Vær opmærksom på, at deltagere uden for holdet ikke er inviteret til Sprint Retrospective Meeting. Sprint Retrospective betragtes som et lidt personligt og følelsesmæssigt miljø, der giver holdmedlemmerne mulighed for at åbne sig uden tøven og diskutere de problemer, de har haft i løbet af den sidste sprint.

Time-box

Det siges med rette, at alle Scrum-ceremonierne er tidsbokse, og deres tidsboks afhænger af Sprint-længden. Når det er sagt, er det ideelt at have et Sprint Retrospective-møde i 2 timer i en to ugers sprint.

Men hvis vi ser på Sprint Retrospective som en mulighed for at kommunikere, se tilbage og forpligte os til forbedringerne, er det meget berettiget at give tilstrækkelig tid til mødet for at undgå at miste på de vigtige synspunkter og indsigter.

Det er således godt at afkrydse mødet, men det bør ikke ske på bekostning af kommunikation og progression. En anden meget vigtig begivenhed i Scrum er Backlog Refinement. Lad os bare tage et øjeblik til at kaste lys over det.

Forbedring af efterslæb

Backlog Refinement, som også er kendt som Backlog grooming, er et møde for at diskutere brugerhistorierne i Product Backlog, der muligvis er en del af den næste Sprint. I et efterbehandlingsforfiningsmøde sidder hele teamet sammen og diskuterer brugerhistorierne og leverer dermed deres input.

Den overordnede idé er at forberede Product Backlog til den kommende Sprint og sørge for, at brugerhistorierne er klar til at blive plukket. Backlog Refinement-mødet er organiseret under 'n-1' sprinten for at forberede de emner, der skal plukkes i 'n' sprint.

Konklusion

Med dette er vi kommet til slutningen af ​​denne tutorial om 'Scrum Events', som er et must at læse en. Scrum Events er langt det vigtigste og mest betydningsfulde emne i Scrum Series.

I denne vejledning har vi diskuteret alle fem Scrum-begivenheder, dvs. Sprint, Sprint Planning, Daily Standup, Sprint Review og Sprint Retrospective . Hver anden begivenhed end den daglige standup har en regelmæssig cyklus pr. Sprint, dvs. udføres en gang i hver sprint.

Begivenhederne giver et indblik i, hvordan opgaverne udføres i et Scrum-miljø. Alle Scrum-begivenheder er muligheder for forbedring, tilpasning og inspektion.

Herefter kommer tutorial om 'Defect Triaging', som er et formelt møde, hvor alle defekterne i den aktuelle Sprint diskuteres og triages, dvs. prioriteres.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^