Meny

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

  • Hoved
  • Annen
  • Scrum Events: Time Boxing, Sprint Planning, Daily Stand-up og Backlog Refinement

scrum events time boxing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Introduksjon til Scrum-hendelser:

I våre tidligere veiledninger diskuterte vi Scrum og hvordan er det strukturert.

Og vår forrige opplæring forklarte alt om Scrum-gjenstander i detalj.

Vi vet hvem som utgjør Scrum Team og hvilke forskjellige gjenstander som er utviklet gjennom hele prosessen. Vi har etablert en sterk bakgrunn nå. La oss derfor ta et skritt videre på Scrum og diskutere de viktigste hendelsene / seremoniene som utgjør Scrum-prosessen.

I denne veiledningen vil vi prøve å forstå hva hver av Scrum Event betyr, hva er de viktigste funksjonene og hvordan organiserer vi dem i detalj.

scrum hendelser

Hva du vil lære:

Oversikt

Mens du arbeider med et Scrum-basert prosjekt, gjennomgår scrumteamet en serie Scrum-seremonier.

Noen kan kalle dem Scrum-seremonier eller begivenheter, og andre kan kalle dem for ritualer eller møter. Uavhengig av de forskjellige terminologiene som brukes her, forblir målet for hver Scrum-hendelse det samme. Hver av Scrum-hendelsene hjelper i det vesentlige med å oppnå og overvåke Sprint-arbeidet.

Typer av Scrum-hendelser

Scrum hendelsestyper

Hver Scrum-seremoni er en personlig affære / samling organisert av Scrum Master for de dedikerte gruppene. Bortsett fra kjerneteamet, kan noen av møtene involvere interessenter, leveringsledere eller til og med kunden selv. Disse møtene er tidsbokset og må derfor fullføres innen den fastsatte tidsrammen.

Målet med hvert møte er å samle deltakerne og la dem diskutere det aktuelle arbeidet. Forventningen fra hver deltaker er å holde fokus, engasjert og deltakende.

Det blir sett på som en mulighet til å snakke, undersøke og hente tilbakemeldinger fra utført arbeid. I motsetning til de vanlige møtene, er Scrum-arrangementene resultatorienterte, tidsboksede, målgruppebaserte og har et spesifikt mål tilpasset hver enkelt av dem.

Hva er Time Boxing?

Timeboxing er en av nøkkelfunksjonene knyttet til alle Scrum-hendelser. Deltakerne forventes å være oppmerksomme og respektere tiden som er tildelt hver av arrangementene. Arrangementene kan ikke utvides, men kan forkortes hvis målene for møtet allerede er oppnådd.

Scrum Master, som også er en tilrettelegger for alle Scrum-arrangementene, sørger for at alle forstår viktigheten av tidsboksing og minner dem også om å fokusere på målet for møtet for å oppnå de beste resultatene og i tidsutfall med avvik.

Timebox for et arrangement bør ikke ideelt sett forlenges, men da vi vet at Scrum ikke handler om reglene, kan tiden utvides til en bestemt lengde hvis alle deltakere er enige.

Hvordan bestemmer vi tidsboksen for hvert av Scrum-arrangementet?

Tidsboksen for Scrum Events er direkte proporsjonal med lengden på Sprint. Imidlertid er det eneste unntaket fra denne regelen Daily Standup som har en fast tidsboks på 15 minutter uavhengig av sprintlengde.

Det er standard tidsrammer for hvert arrangement basert på Sprint-lengden. Likevel har teamet frihet til å bestemme tidsrammene for disse hendelsene basert på deres krav.

La oss forstå mer av disse konseptene ved å diskutere hver Scrum-hendelse i detalj.

Sprintplanleggingen

Som en forutsetning for denne seremonien, bør produkteieren ha en stabil prioritert produktforsinkelse av brukerhistorier utarbeidet før han kommer til møtet. Brukerhistoriene skal være velformede og klare nok til at teamet forstår.

Produkteieren kan søke hjelp fra interessentene, kunden, designeren og Scrum Master for å utvikle produktbackloggen.

Det er obligatorisk å ha akseptkriterier i en brukerhistorie. Teamet er autorisert til å avvise en brukerhistorie uten akseptkriteriene.

Hensikt

Sprintplanlegging er den første seremonien mens du starter en Sprint. Hensikten med Sprint Planning-møtet er å lage et Sprint Goal, velge brukerhistorier fra Product Backlog til Sprint Backlog og diskutere dem i detalj.

Teamet kommer sammen i et møterom sammen med Produkteieren og Scrum Master der Produkteieren presenterer brukerhistoriene som skal velges for neste sprint.

Teamet kan stille så mange spørsmål som de vil vite mer om historien, og det er produktseierens ansvar å løse spørsmålene. Teamet kan også utfordre historien for dens fullstendighet og egnethet.

Hvis det kreves tilleggsinformasjon i historien eller har en ufullstendig avhengighet eller blir funnet å være ufullstendig, har teamet makten til å avvise historien.

Tross alt er tvilen fjernet, og teamet vet nøyaktig hvor mye arbeid som må gjøres for å fullføre en historie, teamet estimerer og gir historien poeng til hver av brukerhistorien.

På en lignende måte blir de andre historiene diskutert og estimert. Teamet velger nå historiene fra toppen av det prioriterte produktetterslepet inn i Sprint-etterslaget som de tror de vil være i stand til å forplikte og fullføre i sprinten gitt sin tidligere hastighet.

Hastighet bestemmes av det totale antall historiepoeng fullført i en gjennomsnittlig sprint. Hastigheten beregnes ut fra de historiske Sprints og ved å beregne dem i gjennomsnitt. Jo flere sprints vi fullfører, jo mer stabil er hastigheten for et lag.

Mange lag bruker Planning Poker-kort til Story Estimation. Den vanligste estimeringsteknikken er historiepekende ved hjelp av Fibonacci-serien. Fibonacci-serien er en serie med tall hvor hvert neste tall i serien består av å legge sammen de to foregående tallene.

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

Brukerhistoriene estimert utover 13 historiepoeng anses å være veldig store for å bli fullført i en enkelt sprint og blir derfor spaltet i mindre logiske brukerhistorier som kan estimeres individuelt.

Under et sprintplanleggingsmøte vil teamet også opprette oppgaver under brukerhistoriene som er valgt for Sprint. Teamet forventes ikke å oppgi alle brukerhistoriene under Sprint Planning, men det er akkurat nok til å få dem i gang. Resten av oppgaven kan gjøres under sprinten.

Det viktigste utfallet av et Sprint Planning-møte er Sprint Goal og Sprint Backlog som består av brukerhistoriene som teamet har forpliktet seg til å fullføre.

Sprintplanleggingsmøte

Bortsett fra brukerhistoriene, kan det være noen andre typer varer som kan bli en del av Sprint Backlog.

  • Pigger
  • Teknisk gjeld
  • Feil

Pigger er forskningsoppgavene for å finne en løsning, dvs. behovet som utløses av selve brukerhistorien. Noen av historiene er kanskje ikke greie eller har ikke teknisk kapasitet, og vil derfor kreve mer analyse og forskning rundt dem. Derfor skapes en pigg. Det kan også inkludere en POC hvis behovet oppstår.

Teknisk gjeld er refactoring av eksisterende kode. Mange ganger er det situasjoner når teamet må bearbeide koden som ble utviklet tidligere for å imøtekomme de nye kravene.

Feil i Scrum er vanligvis de savnede eller nye kravene som kommer ut fra de aksepterte brukerhistoriene, men er relevante for gjeldende arbeidselementer. Hvis ikke et krav, kan det faktisk være en feil i systemet som ble avdekket under forrige sprint, men som ikke ble løst og har blitt prioritert i denne sprinten.

Deltakere

Alle i Scrum Team er en del av Sprint Planning-møtet. Ingen andre enn kjerneteamet er invitert til å delta på møtet.

Sprint Planning-møtet er organisert og tilrettelagt av Scrum Master, men produkteieren stjeler showet.

Time-box

Sprintplanleggingsmøtet kan ta så lang tid som en halv dag i to ukers Sprint. Tidsboksen for et Sprint Planning-møte avhenger direkte av lengden på Sprint. Kortere for en kort sprint og lenger for en lang sprint.

Sprint Planning-møte har en veldig viktig rolle i den samlede Scrum Architecture og påvirker direkte produktet som blir utviklet. Derfor bør teamet investere så mye tid som de mener er nødvendig for å diskutere alle brukerhistoriene i detalj, og kan foreslå en alternativ tidsrute som passer dem.

Når tidsboksen er bestemt og avtalt, er det Scrum Master sitt ansvar å holde laget fokusert på målet og samtidig holde oversikt over tiden.

The Daily Standup

Hensikt

Daily Standup er et møte som gir en mulighet til å illustrere et helhetsbilde av Sprints helse. Det er også en plattform for å diskutere hva de andre teammedlemmene jobber med, og om det er noe som stopper for å nå Sprints mål.

Under et daglig standupmøte deler hvert teammedlem statusen på fremdriften på arbeidsproduktene de jobber med. De vil også dele og søke hjelp fra de andre teammedlemmene hvis det er noen sperringer som blokkerer deres fremgang.

The Daily Standup

Under et daglig standup-møte svarer hvert teammedlem rundt bordet på følgende tre viktige spørsmål en etter en:

‘Hva har du gjort siden forrige Daily Standup Meeting? '

‘Hva har du tenkt å gjøre i dag?’

pl sql scenariobaserte intervjuspørsmål

‘Er det noen hindring som blokkerer arbeidet ditt?’

Det forventes at de andre teammedlemmene tar hensyn når noen deler statusen og tilbyr hjelp hvis behovet oppstår. Så snart det siste teammedlemmet har svart på alle de tre spørsmålene, avsluttes møtet der.

Daglig standup-møte gir et overordnet bilde av hva som er nåværende og generelle fullføringsstatus for iterasjonen de for tiden jobber med. Scrum Master spiller en veldig viktig rolle for å holde Daily Standup-møtet fokusert og tidsbestemt. Han er også ansvarlig for å løse hindringene som hindrer teamet i å komme videre med sine brukerhistorier.

Scrum Master må også sørge for at ingen andre enn kjerneteamet stiller spørsmål og presenterer status. Han kan tillate raske diskusjoner rundt brukerhistoriene om nødvendig, men må være oppmerksom på tiden hele tiden og kan når som helst gå inn og be teammedlemmene om å ha en diskusjon offline.

Deltakere

Alle kan delta på et daglig standup-møte. Imidlertid er det obligatorisk for kjerneteamet å delta på møtet og presentere status for sitt arbeid.

Alle andre selv fra utsiden av teamet som er interessert i å vite om Sprint-fremgangen, kan delta på Daily Standup Meeting, men har ikke lov til å presentere status for sitt arbeid eller stille spørsmål til medlemmene i Development Team om deres arbeid.

Bare kjernelagmedlemmene har lov til å dele arbeidsframgangen, og det forventes at alle andre lytter stille.

Daily Standup-møtet skal gjennomføres selv om det er et enkelt teammedlem til stede.

Teamet kan gjennomføre Daily Standup Meeting alene eller kan be Scrum Master om å legge til rette for det for dem.

Time-box

Som navnet antyder, skjer et daglig standupmøte daglig, og det forventes at deltakerne skal stå ettersom det kun er et kort møte på 15 minutter. Tanken er å holde seg til dagsordenen og ikke å avvike fokuset, derfor holdes møtet kort. Å holde møtet hjelper også folket til enkelt å forplikte seg til det ettersom det bare krever 15 minutter.

Daglig standup-møte holdes også samtidig og på samme sted daglig for å redusere forvirringen blant deltakerne og overhead for å bestille møterommene daglig. Bruk av bærbare datamaskiner, stasjonære datamaskiner eller mobiltelefoner frarådes sterkt under møtet.

Lagene kan bestemme når de skal ha Daily Standup-møtet og holde seg til det. Den normale tendensen er imidlertid å holde møtene det første om morgenen. For lagene som arbeider i forskjellige tidssoner, fungerer ikke morgensamtalen muligens, og dermed kan de ha samtalen om ettermiddagen eller det som passer dem best.

Scrum Master kan også dele viktige nyheter eller oppdateringer på slutten av møtet med teamet hvis tiden tillater det, men ikke får lov til å forlenge møtet for enhver pris.

The Sprint Review

Hensikt

Sprint Review Meeting handler om å demonstrere arbeidet og samle tilbakemeldinger og buy-in. Noen steder er Sprint Review-møtet også kjent som Sprint Demo. Sprint Review Meeting blir vanligvis gjort på slutten av sprinten, men før Sprint Retrospective-møtet.

Den valgte representanten (e) fra teamet demonstrerer gjeldende sprintarbeidselementer. Vanligvis demonstrerer utvikleren som arbeider med brukerhistorien arbeidet og svarer på spørsmålene som reises av alle i publikum.

Brukerhistoriene som er gjort basert på definisjonen av ferdig er de eneste kandidatene til demonstrasjonen på Sprint Review Meeting.

Produkteieren spiller en veldig viktig rolle under Sprint Review Meeting. Det er han som er ansvarlig for å evaluere hver av brukerhistoriene som blir demonstrert mot akseptkriteriene og aksepterer eller avviser historien.

De aksepterte historiene blir deretter integrert med Done Increment som er en potensielt leverbar leveranse. Hvor vil en avvist eller ufullstendig historie gå, er produktinnehaverens samtale. De avviste historiene kan bli en del av neste sprint, eller de kan flytte til Product Backlog der de vil bli prioritert igjen.

Det viktigste resultatet av Sprint Review-møtet er et samlet bilde av prosjektets fullføringsdato. Produkteieren aksepterer / avviser historien, og de aksepterte historiene blir deretter integrert med Inkrement (opprettet under tidligere sprints) som en helhet for å gi et bedre bilde av hvor vi står i å fullføre hele produktet.

Et annet viktig resultat av Sprint Review-møtet er at teammedlemmene lærer noe om estimering. Antall aksepterte brukerhistorier bestemmer antall historiepoeng oppnådd i en sprint.

Dermed gradvis sprint for sprint, kan teamet utvikle evnen til å estimere riktig og ta en informert beslutning om historiepoengene som er mulig å oppnå.

Det observeres ofte at slike møter belyser de ufullstendige kriteriene for aksept eller de nye kravene som dukker opp. Den beste måten å håndtere denne situasjonen på er å lukke historiene og merke dem ferdig hvis de oppfyller alle akseptkriteriene som opprinnelig ble avtalt under Sprint Planning Meeting.

Alt utover det er å betrakte som et nytt krav, og produkteieren er ansvarlig for disse kravene for den fremtidige sprinten.

Sprint gjennomgangsmøte

Deltakere

Sprint Review Meeting møtes av teammedlemmene, inkludert Scrum Master og Produkteieren. Andre deltakere i Sprint Review Meeting er interessenter, leveringssjefer, kunder / sluttbrukere eller alle som er interessert i å være en del av Sprint Review.

Time-box

I et ideelt scenario for en to ukers sprint, bruker vi omtrent 2 timer i Sprint Review-møtet. Dette kan variere avhengig av lengden på Sprint. For en kortere sprint kortere Sprint Review og for en lengre sprint lengre Sprint Review.

Som andre møter er Scrum Master ansvarlig for å holde fremdriften i møtet og sørge for at aktivitetene (demonstrerer historiene, svarer på spørsmålene, godtar historiene, tilbakemeldinger osv.) Passer innenfor den fastsatte tidsrammen.

Sprint Retrospective

Hensikt

Sprint Retrospective handler om å legemliggjøre det Agile sier - ‘ Regelmessige refleksjoner om hvordan du kan bli mer effektive '. Sprint Retrospective gir en mulighet for hele teamet til å reflektere og tenke på hvordan sprinten gikk og hva som må gjøres for å improvisere prosessene? Sprint Retrospective utføres på slutten av hver sprint.

Under et Sprint Retrospective-møte kommer hele teamet sammen og diskuterer Sprint som nettopp ble fullført. Teamet forventes å være gjennomsiktig og gi ærlige meninger, men ingen skyldspill er rundt.

Husk målet med møtet om å ta et skritt foran på området improvisasjon og ikke å holde teamet ved å øke spenningen blant medlemmene.

Alle sammen i teamet forventes å svare på de fire grunnleggende spørsmålene:

Sprint Retrospective

Scrum Master ber teammedlemmene om å skrive poengene sine for hver av kvadrantene som vist ovenfor i klistrelapper. Noen steder brukes verktøy til samme formål.

Hva gikk bra?

Lagmedlemmene gir ett eller flere poeng på det som gikk bra i den siste sprinten. Denne delen kan også tas som en anledning til å sette pris på og anerkjenne de andre teammedlemmene for deres gode arbeid.

Hva har du lært?

Scrum blir sett på som en mulighet til å lære noe nytt i hver sprint. Dette området av en kvadrant er å diskutere viktige takeaways og lærdommer fra den siste sprinten.

Hva gikk ikke bra?

Under denne delen diskuterer teamet problemene og hindringene de hadde møtt i løpet av den siste sprinten. Denne delen av møtet har en tendens til å være den mest skjøre siden folk kan ta opp spørsmål som kan gjøre de andre ubehagelige.

Det er Scrum Master sitt ansvar å berolige atmosfæren hvis behovet er og lære folk å løfte problemene sine på en konstruktiv måte i stedet for å gå gjennom rundene med personlige angrep.

Hvis noen av medlemmene er ukomfortable med å konfrontere problemene foran de andre lagkameratene, kan han senere gå til Scrum Master og diskutere problemene.

Hva kan gjøres bedre?

Denne delen av møtet gir alle teammedlemmene mulighet til å diskutere alle spørsmålene som ble reist tidligere og finne måter å løse dem på. Alle i teamet er velkomne til å foreslå løsninger på problemet. Teamet bestemmer deretter i enhet de beste egnede løsningene.

Teamet bør også vurdere å holde seg til de tingene som ble diskutert under delen som gikk bra for fremtidige spurter, og fremover kan disse tingene legges til som en integrert del av prosessen.

Resultatet av Sprint Retrospective-møtet er en liste over tiltak som deltakerne ble enige om å forbedre prosessen for den kommende sprinten.

Deltakere

hvordan du tester klientserverapplikasjon

Hele Scrum Teamet inkludert Scrum Master og Produkteieren. Men i motsetning til et daglig standup-møte, deltar Scrum Master og Product også i å gi sine innspill og tilbakevirkende poeng.

I likhet med Daily Standup-møte blir Sprint Retrospective-møte også tilrettelagt av Scrum Master. Scrum Master sørger for at alle i teamet inkludert ham selv får en mulighet til å åpne seg og snakke både det positive og det negative.

Legg merke til at deltakere utenfor teamet ikke er invitert til Sprint Retrospective Meeting. Sprint Retrospective regnes som et lite personlig og følelsesmessig miljø som gjør at teammedlemmene kan åpne seg uten å nøle og diskutere problemene de har møtt i løpet av den siste sprinten.

Time-box

Det sies med rette at alle Scrum-seremoniene er tidsbokse, og deres tidsramme avhenger av lengden på Sprint. Når det er sagt, i en to ukers sprint, er det ideelt å ha et Sprint Retrospective-møte i 2 timer.

Imidlertid, hvis vi ser på Sprint Retrospective som en mulighet til å kommunisere, retrospekt og forplikte oss til forbedringene, er det veldig rettferdiggjort å gi nok tid til møtet for å unngå å miste de viktige synspunktene og innsiktene.

Dermed er det bra å sette boksen på møtet, men det bør ikke gjøres på bekostning av kommunikasjon og progresjon. En annen veldig viktig begivenhet i Scrum er Backlog Refinement. La oss ta et raskt øyeblikk for å belyse det.

Avstandsforbedring

Backlog Refinement, også kjent som Backlog grooming, er et møte for å diskutere brukerhistoriene i Product Backlog som kan være en del av neste Sprint. I et etterbehandlingsmøte sitter hele teamet sammen og diskuterer brukerhistoriene og gir dermed sine innspill.

Den overordnede ideen er å forberede Product Backlog for den kommende Sprint og å sørge for at brukerhistoriene er klare til å bli plukket. Backlog Refinement-møtet er organisert under ‘n-1’-sprinten for å forberede seg på elementene som skal plukkes i‘ n ’sprint.

Konklusjon

Med dette har vi kommet til slutten av denne veiledningen om ‘Scrum Events’ som er et must å lese en. Scrum Events er det viktigste og viktigste temaet i Scrum Series.

I denne opplæringen har vi diskutert alle de fem Scrum-hendelsene, dvs. Sprint, Sprint Planning, Daily Standup, Sprint Review og Sprint Retrospective . Hver annen begivenhet enn den daglige standupen har en vanlig syklus per sprint, dvs. utført en gang i hver sprint.

Arrangementene gir et innblikk i hvordan oppgavene blir utført i et Scrum-miljø. Alle Scrum-hendelsene er muligheter for forbedring, tilpasning og inspeksjon.

Neste kommer opplæringen om ‘Defect Triaging’ som er et formelt møte der alle defektene i den nåværende Sprint blir diskutert og triaged, dvs. prioritert.

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^