Sprint Retrospective är en avslutande händelse för Sprinten som endast Scrum Team-medlemmar kan delta i. Detta gör att den kan ägnas helt åt teamets interna angelägenheter. Anledningen är att Sprint Retrospective främst används för att reflektera över nuvarande arbetsmetoder, samt för att diskutera förslag på hur de kan förbättras.
Vad är en Sprint Retrospective? – innehållsförteckning:
- Introduktion
- Mål och ämnen för Sprint Retrospective
- Hur genomför man en effektiv Sprint Retrospective?
- Problem som ska diskuteras
- Diskussion och åtagande
- Sammanfattning
Introduktion
Sprint Retrospective är mötet som avslutar varje Sprint. Det är en av Scrum-händelserna, som vi skrev om i en översikt i en separat artikel.
Enligt den officiella Scrum-guiden tar en Sprint Retrospective högst tre timmar för en månatlig Sprint. Eller motsvarande kortare om Scrum Teamet arbetar i kortare cykler.
Mål och ämnen för Sprint Retrospective
Alla medlemmar i Scrum Teamet deltar i Sprint Retrospective. Syftet med mötet är att diskutera problem relaterade till Scrum Teamets arbete och hur det hanterar dem. Dessa är dock inte problem relaterade till produkten som utvecklas av Scrum Teamet, utan frågor relaterade till naturen och förloppet av samarbetet mellan Scrum Team-medlemmarna.
Eftersom de frågor som tas upp ofta är känsliga och svåra, är Sprint Retrospective en sluten händelse. Vi kan formulera dess mål på följande sätt:
- att sammanfatta de nuvarande sätten att samarbeta
- att identifiera de problem och brister som kräver förbättring
- att föreslå lösningar och modifieringar
Målen för Sprint Retrospective är nära relaterade till pelarna av empirism som Scrum stöder. De första två punkterna är relaterade till inspektion. Medan den sista är relaterad till anpassning. Vi skrev mer om pelarna av empirism och deras roll i Scrum i denna artikel.
Resultatet av svaren på ovanstående möten är inte bara en tydlig bild av Scrum Teamets principer för samarbete som är tillgängliga för alla dess medlemmar. Teamet gör också åtaganden för att förbättra samarbetet och teamets beteende, som kommer att genomföras i nästa Sprint.
Hur genomför man en effektiv Sprint Retrospective?
Eftersom Sprint Retrospective är ett svårt möte, är rollen som Scrum Master som modererar diskussionen avgörande. Idealiskt sett bör han eller hon föreslå för Scrum Team-medlemmarna vem som ska tala härnäst. Till exempel kan han be alla att ge en sammanfattning av den avslutande Sprinten i en mening.
Problem som ska diskuteras
Eftersom det kan väcka mycket känslor att prata om problem i teamet, är en vanlig lösning att skriva ner de frågor som ska diskuteras på separata papper. Detta gör det lättare att uttrycka sin åsikt. Det är också lättare att upptäcka större problemområden och frågor som fler personer har bekymmer över.
Om det finns för många frågor som Scrum Teamet tar upp, kan ni börja med att diskutera de största. Eller välja gemensamt vilka frågor som är de viktigaste enligt Scrum Teamet.
Ni kan skjuta upp problem för vilka det inte fanns tillräckligt med tid under Sprint Retrospective till nästa retrospektiv. Självklart endast om de fortfarande förekommer.
Diskussion och åtagande
De viktigaste delarna av Sprint Retrospective är dock diskussion och åtagande.
Diskussionen bör fokusera på orsakerna till problemen, de ögonblick när de uppstår, och deras påverkan på Scrum Teamets funktion. Det är värt att överväga om deras uppkomst kan undvikas och med vem man ska diskutera deras lösning.
Att göra åtaganden är lika viktigt som att diagnostisera problemen, eftersom bara att veta att de finns och orsakerna inte översätts till att lösa dem. Resultatet av en Sprint Retrospective är vanligtvis flera åtaganden. Om problemet påverkar hela teamet, åtar sig ofta en av teammedlemmarna att ge särskild uppmärksamhet åt ett visst problem i nästa Sprint. Och att föreslå dess lösning, eller till och med att lösa problemet själv. Om å sin sida problemet rör en specifik persons agerande, åtar han eller hon sig att ändra sitt beteende redan i nästa Sprint.
Sammanfattning
Sprint Retrospective är en sammanfattning av en Sprint ur perspektivet av samarbetet mellan Scrum Team-medlemmarna. Dess syfte är att förbättra effektiviteten och vårda de tre pelarna av empirism: transparens, inspektion och anpassning. Transparens, där alla samarbetare pratar öppet med varandra om både framgångar och problem som uppstår i teamet. Inspektion, som innebär frekvent och pålitlig diagnos av situationen i teamet, och anpassning, dvs. att korrigera fel som uppstår löpande.
Om du gillar vårt innehåll, gå med i vår aktiva community av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektledare är Caroline en expert på att hitta nya metoder för att utforma de bästa arbetsflödena och optimera processer. Hennes organisatoriska färdigheter och förmåga att arbeta under tidspress gör henne till den bästa personen att förvandla komplicerade projekt till verklighet.
Scrum Guide:
- Ordlista över grundläggande termer, roller och begrepp
- Vad är Scrum?
- Scrum-värden
- Hur implementerar man Scrum i ditt företag?
- Scrum-team - vad är det och hur fungerar det?
- Vem är en produktägare?
- De vanligaste misstagen hos en produktägare
- Vem är Scrum Master?
- De vanligaste misstagen av Scrum Master
- Vilka statistik och mätvärden bör Scrum Mastern följa?
- Utvecklingsteam i Scrum
- De vanligaste misstagen hos utvecklare
- Scrumartefakter
- Skalning av Scrum
- Sprint Backlog
- Vad är produktbackloggen?
- Vad är användarberättelser?
- Skapa den bästa användarberättelsen med INVEST
- De vanligaste misstagen i User Stories
- Användarberättelse Acceptanskriterier
- Uppskattning och Story Points i Scrum
- Planeringspoker
- Team Estimation Game
- Definiera inkrement
- Scrum-evenemang
- Vad är en Burndown-diagram?
- Fördelar och nackdelar med burndown-diagrammet
- Kanban-tavlor i Scrum och Scrumban
- Hastighet i Scrum - Utvecklingsteamets hastighet
- Daglig Scrum
- Sprintplanering
- Sprintgranskning
- Vad är en Sprint Retrospektiv?
- Vanliga misstag under en Sprint Retrospektiv
- Produktbacklogg vård
- Hur man skapar och tolkar ett burndown-diagram?