i den här artikeln på introduktionsnivå tittar vi på mekaniken i en Sprint och hur teammedlemmar förväntas samarbeta för att producera en ökning av släppkvaliteten.

den första dagen: sprintplanering

hela teamet, inklusive produktägaren, träffas på sprintens första dag och genomför en Sprintplaneringssession. Detta är det allra första som händer så snart sprinten börjar.

förberedelse

sprintplanering bör förberedas för. Den viktigaste förberedelsen är att säkerställa att produktbackloggen har förfinats till en lämplig detaljnivå, med uppskattningar och acceptanskriterier (detta är syftet med Produktbackloggförfining). Därefter borde produktägaren ha beställt arbetet med produktbackloggen och ha en allmän uppfattning om hur man förhandlar om ett värdefullt sprintmål med laget. Alternativen för att förhandla fram ett mål borde också ha beaktats under förfining och återspeglas i orderingången. Teamet bör också ha en uppfattning om deras kapacitet för denna Sprint, det vill säga hur mycket arbete de tror att de kan ta på sig. De kanske kan använda sin erfarenhet av tidigare Sprints för att hjälpa dem att fastställa storleken på denna budget.

planera först det värde som kommer att levereras

varje Sprint ska resultera i en värdefull ökning av avslutat arbete, passande och redo för omedelbar frisättning. Produktägaren är helt ansvarig för vad ”värde” betyder och borde ha beställt produktbackloggen på ett sådant sätt att värdet kan maximeras av laget, sprint-by-sprint. Det första laget måste göra är därför att planera vilka artiklar från produktbackloggen som ska arbetas med i denna Sprint, så att det bästa värdet kan levereras i slutet av det.

för att göra detta arbetar teamet med produktägaren för att välja de mest värdefulla artiklarna från produktbackloggen som passar deras beräknade kapacitet för sprinten. Tänk på att varje objekt på produktbackloggen borde ha fått en uppskattning av laget, så de vet ungefär hur mycket arbete som sannolikt kommer att vara involverat.

var noga med att komma överens om ett sprintmål

detta urval av arbete bör vara sammanhängande och inte bara en gruppering av orelaterade och olika objekt. Kom ihåg att en Sprint är en tidsboxad möjlighet att uppnå något betydande. Till exempel, i slutet av sprinten kan en sammanhängande funktion ha levererats, eller en betydande risk har mildrats. Sprintmålet är ett enkelt uttryck för detta syfte, den övergripande betydelsen av det valda arbetet och samstämmigheten bakom urvalet.

ett bra sprintmål gör det möjligt för teamet att visa fokus och engagemang och möjliggöra samarbete och omplanering av arbetet så att det uppfylls.

nästa plan hur arbetet ska göras

en Sprint Backlog är mer än bara ett urval av arbete med ett slutmål i åtanke. Det är också en plan för hur det målet ska uppnås och hur det tillhörande arbetet ska utföras. Detta kan göras genom att identifiera och beställa de tekniska uppgifter som sannolikt kommer att vara inblandade. I själva verket är sprintbackloggen en plan för att uppfylla sprintmålet och en prognos för det arbete som måste göras.

produktägaren behöver inte vara närvarande för denna del av Sprintplaneringen, eftersom det är upp till teamet att planera denna prognos på teknisk nivå. Produktägaren bör dock vara tillgänglig, även om den bara är på distans, för att svara på eventuella frågor som teamet kan ha och för att ge eventuella förtydliganden som kan behövas om omfattningen av arbetet. Om mer än en release förväntas under sprinten, bör detta överenskommas med PO och redovisas i sprintbackloggen.

i slutet av Sprintplaneringen bör ett team vara övertygat om att det har gjort en bra prognos för det arbete som kommer att behövas för att uppfylla sprintmålet. Det kommer att ha fångat den planen i sprintbackloggen som laget helt äger. Teamet ska kunna börja implementera den planen omedelbart och med en tydlig förståelse – till exempel en Sprintförbränning – av hur mycket arbete som återstår vid en viss punkt.

varje dag, varje dag

när laget har planerat sin sprintbacklog kan de börja arbeta. Om de har planerat saker som uppgifter kommer de att samarbeta med varandra, som ett team, för att se till att dessa uppgifter är slutförda. De kommer att kunna spåra sina framsteg genom att använda sin uppgift ombord och deras Sprint Burndown av arbete kvar.

varje teammedlem kommer att vara säker på att hålla Scrum Task Board och Sprint Burndown uppdaterad, så informationen kan åberopas av andra. En informationsradiator bör alltid berätta sanningen.

Håll en daglig Scrum

varje arbetsdag, samtidigt kommer utvecklingsteamet att träffas och planera vad de ska göra för att föra dem närmare sprintmålet. Detta möte kallas Daily Scrum och det bör aldrig ta mer än 15 minuter.

Endast medlemmar i utvecklingsteamet bör delta, eftersom arbetsplanen helt och hållet tillhör dem. Det är en tidsinställd möjlighet att planera om sprintbackloggen till följd av nya upptäckter och lärdomar under sprinten. Hela laget bör delta. Varje teammedlem ska kunna redogöra för:

• vad de gjorde igår för att hjälpa laget att uppfylla sprintmålet
• vad de tänker göra idag för att hjälpa laget att uppfylla sprintmålet
• eventuella hinder som kommer i vägen

i slutet av den dagliga Scrum bör laget ha en tydlig plan för de kommande 24 timmarna och en förståelse för hur de kommer att behöva samarbeta för att uppnå det. De bör också ha en lista över eventuella hinder som kräver Scrum Master uppmärksamhet.

förfina produktbackloggen

I Scrum är Produktbackloggförfining inte en formell händelse utan en pågående aktivitet – processen att lägga till detaljer, ordning och uppskattningar till Produktbackloggposter som användarhistorier. Det är upp till Scrum-Team själva att bestämma hur ofta de ska göra detta, även om det verkligen är en bra ide för dem att bygga förfining i sin dagliga rutin. Förfining bör inte ta mer än 10% av ett lags totala tid under en Sprint. För de flesta lag kan en halvtimme om dagen vara tillräcklig även om vissa kanske föredrar att spendera en timme eller två ett par gånger i veckan. Det viktiga är att se till att produktbackloggen förfinas i tid så att sprintplanering kan ske utan hinder. Hela teamet, inklusive produktägaren, bör delta.

en förfiningssession börjar vanligtvis med att produktägaren presenterar den aktuella produktbackloggen för teamet. Eftersläpningen kan hållas i ett antal former, såsom en elektronisk Scrum styrelse eller annat samarbetsverktyg, eller det kan helt enkelt vara ett kalkylblad. En projektor eller delad skärm kan vara mycket användbar.

teamet börjar högst upp i produktbackloggen och arbetar sig nedåt och förfinar varje artikel i tur och ordning. De kommer att undersöka var och en och diskutera dess omfattning och de acceptanskriterier som kommer att vara nödvändiga för att den ska kunna slutföras. Varje objekt kommer då att uppskattas med hjälp av en teknik som planering Poker. Ett stort objekt kan delas upp i mindre som fångar större detalj. Epics kan till exempel sönderdelas i användarhistorier.

laget slutar när sessionens tidsruta tar slut. De kommer att återuppta där de slutade nästa gång, så småningom börjar på toppen igen så att eftersläpningen hålls uppdaterad.

samarbeta alltid

i agil praxis arbetar teammedlemmar aldrig isolerat – om de gjorde det skulle de inte vara ett team. I själva verket är lagarbete så viktigt att rollen är utvecklingsteam snarare än Utvecklare.

detta innebär att varje Utvecklingsteammedlem måste samarbeta med sina kamrater hela dagen, eftersom de är gemensamt ansvariga för arbetets framsteg. Eventuella problem eller misslyckanden ägs gemensamt av laget, liksom deras framgångar. Samarbete är inte något som är begränsat till evenemang som Daily Scrum, men gäller allt som laget gör under varje Sprint.

exempel på samarbete är:

• hjälpa kamrater att slutföra pågående arbete innan de tar in nytt arbete från en backlog
• parprogrammering, som att ta det i tur och ordning för att använda tangentbordet och hjälpa och kontrollera varandras arbete
• Peer review
• be om hjälp och vara angelägen om att ge det
• gå till där arbetet är och hjälpa, istället för att vänta på att arbetet ska överföras till dem
• se till att allt arbete faktiskt uppfyller definitionen klar
• ringa en Scrum för att lösa problem som behöver lagets omedelbara uppmärksamhet
• höja hinder för Scrum Master så att de kan hanteras i rätt tid
• uppdatera en Scrum Task board och burndown diagram så att informationen är aktuell och kan lita på
• Skill and knowledge sharing

den sista dagen: granskning och retrospektiv

Håll en Sprint Review

om ett team har samarbetat effektivt, de har arbetat tillsammans för att möta sprintmålet, hantera eventuella risker och justera sina planer efter behov. De kommer att ha visat kontroll under hela sprinten genom en jämn nedbrändhet av återstående arbete, där varje medlem såg det som sitt personliga ansvar att hjälpa till att slutföra pågående arbete. De kommer att ha en värdefull ökning för att visa för produktägaren och alla inbjudna intressenter. En recension är något som ett team bör se fram emot.

det är också något som ett lag måste förbereda sig för. Tillräckligt med tid måste ges för en demonstration av det arbete som har utförts. Uppgifter kan planeras på en sprintbacklog för detta ändamål, för att se till att översynen gör rättvisa åt det arbete som utförts och det värde som nu är tillgängligt. Om produktägaren anser att det skulle vara bra att bjuda in intressenter, borde dessa inbjudningar ha skickats. Översynen är en möjlighet att fira det arbete som har gjorts och att visa upp sina prestationer, så förtroende är inspirerad och en fortsatt investering i laget kan motiveras.

en Sprint Review är också en inspektera-och-anpassa möjlighet. Det är en bra tid för produktägaren att förklara hur bra produkten presterar, att få feedback från första hand från alla inbjudna parter och att dra några lektioner som kan användas för att förbättra produktbackloggen ytterligare. Om något arbete inte har slutförts, av någon anledning, kommer detta också att ses över och omvärderas på produktbackloggen för eventuell planering i framtida sprintar.

gör sedan en Sprint retrospektiv

sprintgranskningen tittade på produkten och det levererade värdet, på det arbete som har gjorts, och ärligt och uppriktigt vid något arbete som inte gjordes, oavsett anledning.
Nästa sak att göra är att genomföra en Sprint retrospektiv. En retrospektiv anser processen som laget följer. Arbetar de så effektivt som möjligt? Det är i allmänhet bäst att hålla retrospektivet omedelbart efter granskningen, eftersom den förra kan införa tankar för övervägande i den senare.

hela utvecklingsteamet, produktägaren och Scrum Master måste alla delta i retrospektivet, eftersom alla är gemensamt ansvariga för framgången för lagets arbete. Det är verkligen viktigt att ha en fri och öppen session som kommer till hjärtat av eventuella problem och identifierar åtgärder som hjälper till att lösa dem. En retrospektiv kan börja med följande förklaring:

”oavsett vad vi upptäcker förstår vi och tror verkligen att alla gjorde det bästa jobbet de kunde, med tanke på vad de visste då, deras färdigheter och förmågor, tillgängliga resurser och situationen.”

I en ”Retro” har alla en lika röst. Ett tillvägagångssätt, som Scrum Master kan underlätta, är att identifiera:

• saker som gick bra
• saker som inte gick så bra
• ideas for improvement
• Shout-outs för teammedlemmar som gjorde något exceptionellt

att skapa en tidslinje kan hjälpa till att jogga deltagarnas minnen om viktiga händelser under sprinten.