Meny

Scrum-händelser: Time Boxing, Sprint Planning, Daily Stand-up och Backlog Refinement

  • Huvud
  • Övrig
  • Scrum-händelser: Time Boxing, Sprint Planning, Daily Stand-up och Backlog Refinement

scrum events time boxing

Prova Vårt Instrument För Att Eliminera Problem

Introduktion till Scrum-händelser:

I våra tidigare tutorials diskuterade vi Scrum och hur det är strukturerat.

Och vår tidigare handledning förklarade allt om Scrum-artefakter i detalj.

Vi vet vem som bildar Scrum Team och vilka olika artefakter som utvecklas under hela processen. Vi har etablerat en stark bakgrund nu. Låt oss därför ta ett steg framåt på Scrum och diskutera de viktigaste händelserna / ceremonierna som utgör Scrum-processen.

I den här handledningen kommer vi att försöka förstå vad var och en av Scrum Event betyder, vilka viktiga funktioner är och hur organiserar vi dem i detalj.

scrum-händelser

Vad du kommer att lära dig:

Översikt

Under arbetet med ett Scrum-baserat projekt går scrumteamet igenom en serie Scrum-ceremonier.

Vissa kan kalla dem Scrum-ceremonier eller händelser och andra kan kalla dem för ritualer eller möten. Oavsett olika terminologier som används här är målet för varje Scrum-händelse detsamma. Var och en av Scrum-händelserna hjälper i huvudsak till att uppnå och övervaka Sprint-arbetet.

Typer av Scrum-händelser

Scrum-händelsetyper

Varje Scrum-ceremoni är en personlig affär / samling som organiseras av Scrum Master för de dedikerade grupperna. Förutom kärnteamet kan några av mötena involvera intressenter, leveranschefer eller till och med kunden själv. Dessa möten är tidsinställda och måste därför slutföras inom den angivna tidsramen.

Målet med varje möte är att samla deltagarna och låta dem diskutera det aktuella arbetet. Förväntningarna från varje deltagare är att hålla sig fokuserad, engagerad och deltagande.

Det betraktas som en möjlighet att konversera, undersöka och hämta återkopplingen av det utförda arbetet. Till skillnad från de vanliga mötena är Scrum-händelserna resultatorienterade, tidsboxade, målgruppsbaserade och har ett specifikt mål i linje med var och en av dem.

Vad är tidsboxning?

Timeboxing är en av nyckelfunktionerna för varje Scrum-händelse. Deltagarna förväntas vara medvetna om och respektera den tid som tilldelats till varje evenemang. Händelserna kan inte förlängas men kan förkortas om mötets mål redan har uppnåtts.

Scrum Master som också är en facilitator för alla Scrum-evenemang ser till att alla förstår vikten av tidboxning och påminner dem också om att fokusera på målet för mötet för att få bästa resultat och i tidsresultat med avvikelser.

Tidslådan för ett evenemang bör inte helst förlängas men eftersom vi vet att Scrum inte handlar om reglerna kan tiden förlängas till en viss längd om varje deltagare instämmer.

Hur bestämmer vi tidsrutan för varje Scrum-händelse?

Tidsrutan för Scrum-evenemang är direkt proportionell mot längden på Sprint. Det enda undantaget från denna regel är dock Daily Standup som har en fast tidsruta på 15 minuter oavsett sprintlängd.

Det finns vanliga tidsramar för varje evenemang baserat på sprintlängden. Ändå har laget friheten att bestämma tidsramarna för dessa händelser baserat på deras krav.

Låt oss förstå mer av dessa begrepp genom att diskutera varje Scrum-händelse i detalj.

Sprintplaneringen

Som en förutsättning för denna ceremoni bör produktägaren ha en stabil prioriterad produktbacklogg med användarberättelser innan de kommer till mötet. Användarberättelserna bör vara välformerade och tydliga för att teamet ska förstå.

Produktägaren kan söka hjälp från intressenter, kund, designer och Scrum Master för att utveckla produktbackloggen.

Det är obligatoriskt att ha acceptanskriterier i en användarberättelse. Teamet har rätt att avvisa en användarberättelse utan acceptanskriterierna.

Ändamål

Sprintplanering är den första ceremonin när du startar en Sprint. Syftet med Sprint Planning-mötet är att skapa ett Sprint Goal, välja användarberättelser från Product Backlog till Sprint Backlog och diskutera dem i detalj.

Teamet samlas i ett mötesrum tillsammans med produktägaren och Scrum Master där produktägaren presenterar de användarberättelser som ska väljas för nästa sprint.

Teamet kan ställa så många frågor som de vill veta mer om historien och det är produktägarens ansvar att ta itu med frågorna. Teamet kan också utmana historien för dess fullständighet och lämplighet.

Om ytterligare information krävs inom berättelsen eller har ett ofullständigt beroende eller visar sig vara ofullständigt har laget befogenhet att avvisa den berättelsen.

När allt kommer omkring har tvivlen rensats och teamet vet den exakta mängden arbete som behöver göras för att slutföra en historia, teamet uppskattar sedan och ger Storypoängen till var och en av User Story.

På liknande sätt diskuteras och uppskattas de andra berättelserna. Teamet väljer nu Berättelser från toppen av den prioriterade produktbackloggen till Sprint-backloggen som de tror att de kommer att kunna begå och slutföra i Sprint med tanke på deras tidigare hastighet.

Hastighet bestäms av det totala antalet berättelsespoäng som slutförts i en genomsnittlig sprint. Hastigheten beräknas utifrån de historiska sprintarna och genom att göra dem genomsnittliga. Ju fler sprint vi fullbordar desto stabilare är lagets hastighet.

Många lag använder Planning Poker-kort för beräkning av berättelser. Den vanligaste uppskattningstekniken är story-pointing med hjälp av Fibonacci-serien. Fibonacci-serien är en serie med siffror där varje nästa nummer i serien består av att lägga till de två föregående siffrorna.

Fibonacci-serien - 1, 1, 2, 3, 5, 8, 13 och så vidare.

Användarberättelserna som uppskattas utöver 13 berättelsepoäng anses vara mycket stora för att slutföras i en enda sprint och bryts därför ner i mindre logiska användarberättelser som kan uppskattas individuellt.

Under ett sprintplaneringsmöte skapar teamet också uppgifter under användarberättelserna som har valts för Sprint. Teamet förväntas inte utföra alla användarberättelser under Sprint Planning, men det räcker bara för att få dem igång. Resten av uppgiften kan göras under sprinten.

Det viktigaste resultatet av ett Sprint Planning-möte är Sprint Goal och Sprint Backlog som består av användarberättelser som teamet har åtagit sig att slutföra.

Sprintplaneringsmöte

Förutom användarberättelserna kan det finnas några andra typer av objekt som kan bli en del av Sprint Backlog.

  • Spikar
  • Tekniska skulder
  • Fel

Spikar är forskningsuppgifterna för att hitta en lösning, dvs behovet utlöses av själva användarberättelsen. Vissa av berättelserna kanske inte är enkla eller inte har den tekniska förmågan och skulle därför kräva mer analys och forskning kring dem. Därför skapas en spik. Det kan också innehålla en POC om behov uppstår.

Tekniska skulder är refactoring av den befintliga koden. Många gånger finns det situationer då teamet måste bearbeta koden som utvecklats tidigare för att tillgodose de nya kraven.

Fel i Scrum är vanligtvis de missade eller nya kraven som kommer från de accepterade användarberättelserna men är relevanta för de aktuella arbetsobjekten. Om inte ett krav kan det faktiskt vara ett fel i systemet som grävdes upp under de föregående sprintarna men inte fixades och har prioriterats i denna sprint.

Deltagare

Alla i Scrum Team är en del av Sprint Planning-mötet. Ingen annan än kärngruppen är inbjuden att delta i mötet.

Sprint Planning-mötet organiseras och underlättas av Scrum Master men produktägaren stjäl showen.

Time-box

Sprintplaneringsmötet kan ta så lång tid som en halv dag i två veckors Sprint. Tidsrutan för ett Sprint Planning-möte beror direkt på Sprintlängden. Kortare för en kort sprint och längre för en lång sprint.

Sprint Planning-mötet har en mycket viktig roll i den övergripande Scrum Architecture och påverkar direkt den produkt som utvecklas. Därför bör teamet investera så mycket tid som de tror krävs för att diskutera alla användarberättelser i detalj och kan föreslå en alternativ tidsram som passar dem.

När tidslådan är bestämd och överenskommen är det Scrummästarens ansvar att hålla laget fokuserat på målet och samtidigt hålla koll på tiden.

The Daily Standup

Ändamål

Daily Standup är ett möte som ger en möjlighet att illustrera en helhetsbild av Sprints hälsa. Det är också en plattform för att diskutera vad de andra gruppmedlemmarna arbetar med och om det är något som stoppar för att uppnå Sprints mål.

Under ett dagligt standup-möte delar varje lagmedlem statusen för sina framsteg på de arbetsobjekt som de arbetar med. De skulle också dela och söka hjälp från de andra gruppmedlemmarna om det finns några spärrar som blockerar deras framsteg.

The Daily Standup

Under ett dagligt standup-möte besvarar varje lagmedlem runt bordet följande tre nyckelfrågor en efter en:

”Vad har du gjort sedan det senaste Daily Standup Meeting?”

'Vad planerar du att göra idag?'

c ++ - intervju kodande frågor

”Finns det något hinder för ditt arbete?”

De andra gruppmedlemmarna förväntas vara uppmärksamma när någon delar status och erbjuder hjälp om behov uppstår. Så snart den sista teammedlemmen har svarat på alla de tre frågorna avslutas mötet där.

Daily Standup-mötet ger en övergripande bild av vad som är nuvarande och övergripande slutförandestatus för iterationen de för närvarande arbetar med. Scrum Master spelar en mycket viktig roll för att hålla Daily Standup-mötet fokuserat och tidsbegränsat. Han är också ansvarig för att lösa hindren som hindrar laget från att gå vidare med sina användarberättelser.

Scrum Master måste också se till att ingen annan än kärnteamet ställer frågor och presenterar status. Han kan tillåta snabba diskussioner kring användarberättelserna om det behövs men måste vara medveten om tiden hela tiden och kan när som helst gå in och be teammedlemmarna att ha en diskussion offline.

Deltagare

Vem som helst kan delta i ett Daily Standup-möte. Det är dock obligatoriskt för kärnteamet att delta i mötet och presentera status för sitt arbete.

Någon annan även utanför teamet som är intresserad av att veta om Sprint-framstegen kan delta i Daily Standup Meeting men får inte presentera status för sitt arbete eller ifrågasätta medlemmarna i Development Team om deras arbete.

Det är bara kärnmedlemmarna som får dela sitt arbete och alla andra förväntas lyssna tyst.

Daily Standup-mötet bör genomföras även om det finns en enda lagmedlem närvarande.

Teamet kan genomföra Daily Standup Meeting på egen hand eller kan be Scrum Master att underlätta det för dem.

Time-box

Som namnet antyder sker ett dagligt standup-möte dagligen och deltagarna förväntas stå eftersom det bara är ett kort möte på 15 minuter. Tanken är att hålla sig till dagordningen och inte avvika från fokus, därför hålls mötet kort. Att hålla mötet hjälper också folket att enkelt förbinda sig till det eftersom det bara kräver 15 minuter.

Dagligt standup-möte hålls också vid samma tidpunkt och på samma plats dagligen för att minska förvirringen bland deltagarna och överhead för att boka mötesrummen dagligen. Användningen av bärbara datorer, stationära datorer eller mobiltelefoner är mycket avskräckt under mötet.

Lagen kan bestämma när de ska ha Daily Standup-mötet och hålla fast vid det. Den normala tendensen är dock att hålla mötena det första på morgonen. För lag som arbetar i olika tidszoner kanske morgonsamtalet inte fungerar och därmed kan de ha samtalet på eftermiddagen eller vad som helst som passar dem bäst.

Scrum Master kan också dela viktiga nyheter eller uppdateringar i slutet av mötet med teamet om tiden tillåter, men får inte förlänga mötet till någon kostnad.

Sprintrecensionen

Ändamål

Sprint Review Meeting handlar om att demonstrera det utförda arbetet och samla in feedback och buy-in. På vissa ställen är Sprint Review-mötet också känt som Sprint Demo. Sprint Review Meeting görs vanligtvis i slutet av sprinten men före Sprint Retrospective-mötet.

Den eller de valda representanterna från teamet visar de aktuella artiklarna i sprintarbetet. Vanligtvis demonstrerar utvecklaren som arbetar med användarberättelsen arbetet och svarar på frågorna från alla i publiken.

Användarberättelserna som görs baserat på Definition of Done är de enda kandidaterna för demonstrationen vid Sprint Review Meeting.

Produktägaren spelar en mycket viktig roll under Sprint Review Meeting. Det är han som är ansvarig för att utvärdera varje användarberättelse som demonstreras mot dess acceptanskriterier och accepterar eller avvisar berättelsen.

De accepterade berättelserna integreras sedan med Done Increment som är en leverans som kan levereras. Var skulle en avvisad eller oavslutad berättelse gå är produktägaren. De avvisade berättelserna kan bli en del av nästa sprint eller kan flytta till produktbackloggen där de kommer att prioriteras igen.

Det viktigaste resultatet av Sprint Review-mötet är en helhetsbild av projektets slutdatum. Produktägaren accepterar / avvisar berättelsen och de accepterade berättelserna integreras sedan med Inkrementet (skapat under tidigare sprints) som en helhet för att ge en bättre bild av var vi står för att komplettera hela produkten.

Ett annat viktigt resultat av Sprint Review-mötet är att teammedlemmarna lär sig något om uppskattning. Antalet accepterade användarberättelser avgör antalet berättelsespoäng som uppnåtts i en sprint.

Således gradvis sprint för sprint, kan teamet utveckla förmågan att uppskatta korrekt och fatta ett välgrundat beslut angående de historiska poäng som är möjliga att uppnå.

Det observeras ofta att sådana möten belyser de ofullständiga acceptanskriterierna eller de nya kraven som dyker upp. Det bästa sättet att ta sig ur denna situation är att stänga berättelserna och markera dem som klara om de uppfyller alla acceptanskriterier som ursprungligen enades om under Sprint Planning Meeting.

Allt utöver detta ska betraktas som ett nytt krav och produktägaren ansvarar för dessa krav för den framtida sprinten.

Sprintgranskningsmöte

Deltagare

Sprint Review Meeting deltar av teammedlemmarna inklusive Scrum Master och Product Owner. Andra deltagare i Sprint Review Meeting är intressenter, leveranschefer, kunder / slutanvändare eller någon som är intresserad av att vara en del av Sprint Review.

Time-box

I ett idealiskt scenario för två veckors sprint tillbringar vi cirka 2 timmar i Sprint Review-mötet. Detta kan variera beroende på längden på Sprint. För en kortare sprint kortare Sprint Review och för en längre sprint längre Sprint Review.

Liksom andra möten är Scrum Master ansvarig för att hålla fart på mötet och se till att aktiviteterna (demonstrera berättelserna, svara på frågorna, acceptera berättelserna, feedback noteras etc.) passar inom den angivna tidsramen.

Sprint Retrospective

Ändamål

Sprint Retrospective handlar om att förkroppsliga vad Agile säger - ' Regelbundna reflektioner om hur man blir effektivare ”. Sprint Retrospective ger en möjlighet för hela teamet att reflektera och fundera över hur sprinten gick och vad som behöver göras för att improvisera processerna? Sprint Retrospective utförs i slutet av varje sprint.

Under ett Sprint Retrospective-möte träffas hela teamet och diskuterar Sprint som just avslutats. Teamet förväntas vara öppet och ge ärliga åsikter men det finns inga skuldspel.

Kom ihåg målet för mötet att ta ett steg framåt inom området improvisation och inte hålla teamet genom att öka spänningen bland medlemmarna.

Alla i teamet förväntas svara på de fyra grundläggande frågorna:

Sprint Retrospective

Scrum Master ber teammedlemmarna att skriva sina poäng för var och en av kvadranten som visas ovan i klisterlappar. På vissa ställen används verktyg för samma ändamål.

Vad gick bra?

Teammedlemmarna ger en eller flera poäng på vad som gick bra under den senaste sprinten. Detta avsnitt kan också tas som ett tillfälle att uppskatta och erkänna de andra gruppmedlemmarna för deras goda arbete.

Vad har du lärt dig?

Scrum betraktas som en möjlighet att lära sig något nytt i varje sprint. Detta område i en kvadrant är att diskutera nyckelupptagningar och lärdomar från den senaste sprinten.

Vad gick inte bra?

Under detta avsnitt diskuterar teamet de problem och hinder som de mött under den senaste sprinten. Denna del av mötet tenderar att vara den mest ömtåliga eftersom människor kan ta upp frågor som kan göra de andra obekväma.

Det är Scrummästarens ansvar att lugna atmosfären om behovet är och lära människor att ta upp sina frågor på ett konstruktivt sätt i stället för att gå igenom personliga attacker.

Om någon av medlemmarna är obekväma med att konfrontera problemen framför de andra lagkamraterna kan han gå till Scrum Master senare och diskutera problemen.

Vad kan man göra bättre?

Denna del av mötet ger alla teammedlemmar möjlighet att diskutera alla frågor som tagits upp tidigare och hitta sätt att lösa dem. Alla i teamet är välkomna att föreslå lösningar på det aktuella problemet. Teamet beslutar sedan i enhet över de bästa lösningarna.

Teamet bör också överväga att hålla sig till de saker som diskuterades under avsnittet om vad som gick bra för de framtida sprintarna och framöver kan dessa saker läggas till som en integrerad del av processen.

Resultatet av Sprint Retrospective-mötet är en lista över åtgärder som deltagarna enats om för att förbättra processen för den kommande sprinten.

Deltagare

Hela Scrum-teamet inklusive Scrum Master och produktägaren. Men till skillnad från ett dagligt standupmöte deltar Scrum Master och Product också i att tillhandahålla sina insatser och retrospektiva poäng.

Liksom Daily Standup-mötet underlättas också Sprint Retrospective-möte av Scrum Master. Scrum Master ser till att alla i teamet inklusive honom själv ges möjlighet att öppna sig och tala både det positiva och det negativa.

Notera att deltagare utanför laget inte är inbjudna till Sprint Retrospective Meeting. Sprint Retrospective anses vara en liten personlig och känslomässig miljö som gör att teammedlemmarna kan öppna sig utan att tveka och diskutera de frågor de har mött under den senaste sprinten.

bästa systemrenaren för Windows 10

Time-box

Det sägs med rätta att alla Scrum-ceremonier är tidsboxade och deras tidsruta beror på längden på Sprint. Med detta sagt, för en två veckors sprint, är det perfekt att ha ett Sprint Retrospective-möte i 2 timmar.

Men om vi ser på Sprint Retrospective som ett tillfälle att kommunicera, retrospekt och engagera sig för förbättringarna, är det mycket berättigat att ge tillräckligt med tid för mötet för att undvika att förlora på de viktiga synpunkter och insikter.

Det är alltså bra att tidsfacka mötet men det bör inte göras på bekostnad av kommunikation och progression. En annan mycket viktig händelse i Scrum är Backlog Refinement. Låt oss bara ta en liten stund för att belysa det.

Fördröjning av eftersläp

Backlog Refinement som också kallas Backlog grooming är ett möte för att diskutera användarberättelserna i Product Backlog som kan vara en del av nästa Sprint. I ett förseningsmöte med eftersläpning sitter hela teamet tillsammans och diskuterar användarberättelserna och ger därmed sina insatser.

Den övergripande idén är att förbereda produktbackloggen för den kommande sprinten och se till att användarberättelserna är redo att plockas ut. Backlog Refinement-mötet organiseras under 'n-1'-sprinten för att förbereda för föremål som ska plockas i' n 'sprint.

Slutsats

Med detta har vi kommit till slutet av denna handledning om ”Scrum Events” som är ett måste att läsa. Scrum-händelser är det absolut viktigaste och viktigaste ämnet i Scrum-serien.

I denna handledning har vi diskuterat alla fem Scrum-händelser, dvs. Sprint, Sprint Planning, Daily Standup, Sprint Review och Sprint Retrospective . Varje händelse förutom den dagliga standupen har en regelbunden cykel per sprint, dvs. utförs en gång i varje sprint.

Händelserna ger en inblick i hur uppgifterna utförs i en Scrum-miljö. Alla Scrum-evenemang är möjligheter till förbättringar, anpassningar och inspektioner.

Nästa gång är handledning om 'Defect Triaging' som är ett formellt möte där alla defekterna i den aktuella Sprint diskuteras och triages, dvs. prioriteras.

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^