Scrum och metodtips

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Planeringsmöten för sprint

Mycket av sprintplaneringen innebär en förhandling mellan produktägaren och teamet för att fastställa fokus och arbete att ta itu med i den kommande sprinten. Det är användbart att tidsbegränsa planeringsmötet och begränsa det till 4 timmar eller mindre.

I den första delen av mötet träffar produktägaren ditt team för att diskutera de användarberättelser som kan ingå i sprinten. Produktägaren delar information och svarar på eventuella frågor som ditt team har om dessa berättelser. Den här konversationen kan visa information som datakällor och användargränssnittslayout. Eller så kan det avslöja svarstidsförväntningar och överväganden för säkerhet och användbarhet. Ditt team bör samla in den här informationen i formuläret med kvarvarande uppgifter. Under den här delen av mötet lär sig ditt team vad det måste bygga.

När du planerar dina sprintar kan du upptäcka andra krav för att samla in och lägga till dina kvarvarande uppgifter. Kontrollera att den är väldefinierad och i prioritetsordning.

Att ange ett sprintmål som en del av planeringsarbetet kan också hjälpa teamet att fokusera på det som är viktigast för varje sprint.

När du har planerat din sprint kanske du vill dela planen med viktiga intressenter.

Du kan lära dig mer från dessa resurser:

• Vad är Scrum?
• Vitbok om sprintplanering
• Scrum-guiden
• Skapa och hantera vitboken om kvarvarande produkter

Ange sprintmål

Scrum-team använder sprintmål för att fokusera sina sprintaktiviteter. De sätter ofta detta mål under sitt sprintplaneringsmöte. Målet sammanfattar vad teamet vill åstadkomma i slutet av sprinten. Genom att uttryckligen ange målet skapar du delad förståelse inom teamet för kärnsyftet. Sprintmålet kan också hjälpa teamet när konflikter uppstår kring prioriteringar.

Tips från skyttegravarna: Definiera sprintmål

Sprintmålet definierar vad produktägaren och teamet anser vara det ultimata målet för att uppnå den sprinten. Det är inte ett slumpmässigt urval av kvarvarande objekt som egentligen inte har en relation, utan en kort text som fångar vad teamet bör försöka åstadkomma. Normalt kommer produktägaren upp med sprintmålet innan du väljer många objekt för nästa sprint. Objekten för den sprinten bör alla passa det gemensamma målet.

Sprintmål kan vara funktionsorienterade, men kan också ha en stor processkomponent, till exempel distributionsautomatisering eller testautomatisering.

Till exempel:

• Den här sprinten fokuserar vi på en enkel användarberättelse. Vi använder den för att bevisa att den föreslagna lösningen fungerar.
• Den här sprinten handlar om att implementera de säkerhetsfunktioner som skyddar administrationsavsnittet på webbplatsen korrekt.
• Den här sprinten handlar om att integrera de viktigaste betalningsgatewayerna så att vi kan börja samla in pengar.

Att ställa in sprintmålen hjälper teamet att hålla fokus. Det gör det enklare att definiera prioriteten för uppgifter i en sprint och det hjälper förmodligen till att begränsa antalet intressenter och slutanvändare som är inblandade.

Under sprintgranskningen är den viktigaste frågan du bör ställa dig själv om du lyckades uppnå sprintmålet. Hur många berättelser du har slutfört kommer i andra sekunden. Om målet uppnås lyckas sprinten, även om inte alla berättelser slutfördes.

Bidrog av Jesse Houwing, Visual Studio devops Ranger och en senior konsult som arbetar för Avanade Netherlands.

Tips för lyckade sorteringsmöten

Att åtgärda buggar representerar en kompromiss med annat arbete. Använd ditt prioriteringsmöte för att avgöra hur viktigt det är att åtgärda varje bugg mot andra prioriteringar som rör att uppfylla projektets omfattning, budget och schema.

• Upprätta teamets kriterier för att utvärdera vilka buggar som ska åtgärdas och hur du tilldelar prioritet och allvarlighetsgrad. Buggar som är associerade med funktioner med betydande värde (eller betydande kostnader för fördröjning) eller andra projektrisker bör tilldelas högre prioritet och allvarlighetsgrad. Lagra dina sorteringsvillkor med andra teamdokument och uppdatera efter behov.
• Använd dina sorteringsvillkor för att avgöra vilka buggar som ska åtgärdas och hur de ska ställas in för tillstånd, prioritet, allvarlighetsgrad och andra fält.
• Justera dina triagekriterier baserat på var du befinner dig i utvecklingscykeln. Tidigt kan du bestämma dig för att åtgärda de flesta buggar som du sorterar. Senare i cykeln kan du dock höja prioriteringskriterierna för att minska antalet buggar som du behöver åtgärda.
• När du har sorterat en bugg tilldelar du den till en utvecklare. Utvecklaren kan sedan undersöka och fastställa hur en korrigering ska implementeras.

Hantera din tekniska skuld

Överväg att hantera din felindikator och tekniska skuld som en del av teamets övergripande uppsättning kontinuerliga förbättringsaktiviteter. Du kan hitta följande resurser av intresse:

• Bra och dålig teknisk skuld (och hur TDD hjälper) av Henrik Kniberg
• Managing Technical Debt postat av Sven Johann & Eberhard Wolff

Tips från skyttegravarna: Bugghantering

Agil bugghantering: Inte en Oxymoron
av Gregg Boer, Principal Program Manager, Visual Studio Cloud Services på Microsoft

Åtgärda alla kända buggskulder varje sprint

Varje sprint tittar teamet på eventuella buggar som finns kvar i buggens kvarvarande uppgifter och ägnar kapacitet för att få ner den kända uppsättningen buggar till noll eller nära noll. Oavsett om det är en dag, en vecka eller hela sprinten, så löser de buggarna först. Buggar som hittas senare, inom sprinten, anses inte vara en del av det första åtagandet. Om de inte har hög prioritet läggs de på fellistan för nästa sprint.

Många team arbetar i en åtagandebaserad organisation. Ofta lägger ledningen ett högt värde på ett teams förmåga att uppfylla sina åtaganden. Att göra kapacitetsplanering mot en känd uppsättning buggar gör sprintplaneringen mer deterministisk, vilket ökar deras chans att uppfylla åtagandena. Alla nya buggar som upptäcks under sprinten är inte en del av det första åtagandet och kan åtgärdas nästa sprint.

Hantera buggskulder i ett företag

En organisation som övergår till en kultur där skulder kontinuerligt elimineras hanterar sannolikt följande fråga: Hur får du team att minska antalet buggar utan att berätta exakt vad de ska göra? Ledningen vill att teamet ska förändras, men ger teamet autonomi att avgöra hur de förändras. Ett alternativ är att använda en bugggräns.

Överväg till exempel ett buggtak på tre buggar per tekniker. Därför bör ett team på 10 personer inte ha fler än 30 buggar i sin buggeftersläpning. Om teamet är över sin gräns förväntas det sluta arbeta med nya funktioner och komma under buggtaket. Ett team förväntas alltid vara under sitt tak, men teamet bestämmer hur det vill göra det. Buggtaket säkerställer att teamen inte bär på buggskulder för länge. Teamet kan lära sig av de misstag som gör att buggarna matas in från början.

Kom ihåg att buggtaket representerar buggarna i kvarvarande buggar. Den innehåller inte buggar som hittas och åtgärdas i sprinten där en funktion utvecklas. Dessa buggar anses vara ogjort arbete, inte skuld.

Även om buggar bidrar till teknisk skuld, kanske de inte representerar alla skulder.

Dålig programvarudesign, dåligt skriven kod eller kortsiktiga korrigeringar kan alla bidra till teknisk skuld. Den tekniska skulden återspeglar det extra utvecklingsarbete som uppstår på grund av alla dessa problem.

Spåra arbete för att hantera tekniska skulder som PBI:er, användarberättelser eller buggar. Om du vill spåra ett teams framsteg när det gäller att ådra sig och hantera tekniska skulder bör du överväga hur du kategoriserar arbetsobjektet och den information som du vill spåra. Du kan lägga till taggar i valfritt arbetsobjekt för att gruppera det i en kategori som du väljer.

Rollen som Scrum Master

Scrum Masters hjälper till att bygga och underhålla sunda team genom att använda Scrum-processer. De vägleder, coachar, undervisar och hjälper Scrum-team i rätt anställning av Scrum-metoder. Scrum Masters fungerar också som förändringsagenter för att hjälpa team att övervinna hinder och för att driva teamet mot betydande produktivitetsökningar.

Huvudansvaret för Scrum Masters är:

• Ge teamet stöd för att anta och följa Scrum-processer. Du bör till exempel inte låta det dagliga Scrum-mötet bli en öppen diskussion som varar i 45 minuter.

• Skydda produktägaren eller teammedlemmarna från att lägga till arbete när sprinten börjar.

• Rensa blockeringsproblem som hindrar teamet från att gå vidare. Det här arbetet kan kräva att du utför små uppgifter, till exempel att godkänna en inköpsorder för en ny byggdator eller lösa en konflikt inom ditt team.

• Hjälp teamet att lösa konflikter och problem som uppstår och lära sig av processen.

• Ställ frågor som avslöjar dolda problem och bekräfta att det som personer kommunicerar är väl förstått av hela teamet.

• Identifiera och skydda teamet från att potentiella problem blir stora problem. Precis som det är billigare att åtgärda en bugg strax efter att den har upptäckts är det också enklare och mindre störande att åtgärda ett teamproblem när det är litet och hanterbart.

• Förhindra att teamet presenterar ofullständiga användarberättelser under ett sprintgranskningsmöte.

• Samla in, analysera och presentera data för affärsintressenter för att visa hur teamet förbättras och växer. Om ditt team till exempel har ökat mängden värde som det har levererat samtidigt som färre buggar genereras, gör du värdet synligt genom regelbunden kommunikation till affärsintressenter.

Good Scrum Masters har eller utvecklar utmärkta kunskaper om kommunikation, förhandling och konfliktlösning. De lyssnar aktivt på de ord som människor säger och skriver. De lyssnar också på hur de levererar sina meddelanden, till exempel deras kroppsspråk, ansiktsuttryck, rösttempo och annan icke-verbal kommunikation.

Precis som det är billigare att åtgärda en bugg strax efter att den har upptäckts är det också enklare och mindre störande att åtgärda ett teamproblem när det är litet och hanterbart innan det växer till ett stort problem.

Dagliga Scrum-möten

Dagliga Scrum-möten hjälper till att hålla ett team fokuserat på vad det behöver göra nästa dag. Att hålla fokus hjälper teamet att maximera sin förmåga att uppfylla sprintåtaganden. Din Scrum Master bör framtvinga mötets struktur och se till att det börjar i tid och avslutas om 15 minuter eller mindre.

Tre aspekter av lyckade Scrum-möten är:

• Alla står upp. Att stå upp hjälper till att hålla mötena fokuserade och korta.
• De börjar och slutar i tid och inträffar samtidigt på samma plats varje dag
• Alla deltar, varje teammedlem svarar på de tre Scrum-frågorna:
  • Vad har jag åstadkommit sedan den senaste Scrum?
  • Vad kan jag åstadkomma innan nästa Scrum?
  • Vilka blockeringsproblem eller hinder kan påverka mitt arbete?

Teammedlemmar bör sträva efter att besvara sina frågor snabbt och koncist. Till exempel:

"I går uppdaterade jag klassen för att återspegla det nya dataelementet som vi hämtar från databasen, och jag fick det att visas i gränssnittet. Den här uppgiften är klar. Idag ser jag till att det nya dataelementet beräknas korrekt med den lagrade proceduren och de andra dataelementen i tabellen. Jag tror att jag kan utföra den här uppgiften i dag. Jag behöver någon som granskar mina beräkningar. Jag har inga hinder eller blockeringsproblem."

Det här svaret förmedlar vad teammedlemmen åstadkom, vad gruppmedlemmen planerar att utföra och att gruppmedlemmen vill ha hjälp med att titta på koden.

Jämför med nästa exempel:

" Igår jobbade jag på klassen, och det fungerar. Idag arbetar jag med gränssnittet. Inga blockeringsproblem."

Teammedlemmen ger inte tillräckligt med information om vilken klass de arbetade med eller om de gränssnittskomponenter som de kommer att slutföra. Faktum är att ordet fulländat aldrig kom upp.

Det är viktigt att ingen avbryter rapporten. Varje person måste ha tillräckligt med tid för att besvara de tre frågorna.

Mer djupgående och uppföljande diskussioner bör äga rum efter mötet, när människor återvänder till sina skrivbord eller, om en betydande mängd samtal behövs, i ett uppföljningsmöte.

Många team fördröjer diskussionerna med hjälp av metoden "virtuell parkeringsplats". När ämnen kommer upp som en teammedlem tycker behöver ytterligare diskussion, kan de tyst gå till en whiteboard eller bläddringsdiagram och lista ämnet på parkeringsplatsen. I slutet av mötet bestämmer teamet hur de ska hantera de listade objekten.

Sprintgranskningsmöten

Genomför dina sprintgranskningsmöten den sista dagen av sprinten. Ditt team demonstrerar varje produktpost som den slutförde i sprinten. Produktägaren, kunderna och intressenterna accepterar de användarberättelser som uppfyller deras förväntningar och identifierar eventuella nya krav. Kunder förstår ofta sina behov mer fullständigt efter att ha sett demonstrationerna och kan identifiera ändringar som de vill se.

Baserat på det här mötet godkänns vissa användarberättelser som slutförda. Ofullständiga användarberättelser finns kvar i produktinformationen. Nya användarberättelser läggs till i kvarvarande uppgifter. Båda uppsättningarna av berättelser rangordnas och antingen uppskattas eller beräknas om i nästa sprintplaneringsmöte.

Efter det här mötet och det retrospektiva mötet planerar ditt team nästa sprint. Eftersom affärsbehoven ändras snabbt kan du dra nytta av det här mötet med produktägaren, kunderna och intressenterna för att granska prioriteringarna för kvarvarande produkter igen.

Sprinta retrospektiva möten

Retrospektiv, när de utförs väl och med jämna mellanrum, stöder kontinuerlig förbättring.

Sprintens retrospektiva möte inträffar vanligtvis på sprintens sista dag, efter sprintgranskningsmötet. I det här mötet utforskar ditt team sin körning av Scrum och vad som kan behöva justeras.

Baserat på diskussioner kan ditt team ändra en eller flera processer för att förbättra sin egen effektivitet, produktivitet, kvalitet och tillfredsställelse. Det här mötet och de resulterande förbättringarna är avgörande för den flexibla principen om självorganisering.

Se till att ta itu med dessa områden under din team sprint retrospektiv:

• Problem som påverkar teamets allmänna effektivitet, produktivitet och kvalitet.

• Element som påverkade teamets övergripande nöjdhet och projektflöde.

• Vad hände med ofullständiga kvarvarande uppgifter? Vilka åtgärder kan teamet vidta för att förhindra dessa problem i framtiden?

  Tänk dig till exempel ett team som hade flera uppgifter som bara en person i teamet kunde utföra. Den isolerade expertisen skapade en kritisk väg som hotade sprintens framgång. Den enskilda teammedlemmen lade ner extra timmar medan andra teammedlemmar var frustrerade över att de inte kunde göra mer för att hjälpa till. Framöver bestämde sig teamet för att öva eXtreme Programming för att åtgärda problemet över tid.

Som team arbetar du med att avgöra om du vill anpassa en eller flera processer för att minimera förekomsten av problem under sprinten.

Ditt team kan behöva utföra en del arbete för att implementera en förbättring. Ett team som till exempel påverkades negativt av för många misslyckade versioner bestämde sig för att implementera kontinuerlig integrering. Eftersom de inte ville störa processen tog det några timmar att konfigurera en utvärderingsversion innan den aktiveras i produktionsversionen. För att representera det här arbetet skapade de en topp och organiserade det mot resten av produktloggen.

Relaterade artiklar

• Slut på sprintaktiviteter
• Vad är Scrum?
• Flexibla retrospektiv: Göra bra lag bra