Syftet med detta inlägg är att ge en överblick över Scrum i svensk terminologi samt att ta upp olika hjälpmedel för att stödja metoden. För några år sedan kom jag i kontakt med Scrum för första gången och jag minns att de engelska begreppen i Scrum var mer ett hinder än ett stöd för att lätt förstå metoden. Jag har letat efter helsvenska beskrivningar av Scrum men inte hitta några. De texter som finns är en form av svengelska där begreppen är på engelska men resten av innehållet på svenska. Jag har även genom åren observerat, och i vissa fall deltagit, i diskussioner där man försökt översätta vissa Scrum begrepp till svenska. Det verkar uppenbarligen finnas ett behov för ett ”svenskt Scrum” och följande text är mitt bidrag.

Scrum är en välbeprövad agil metod för att effektivt hantera förändringar och komplexitet i ett mjukvaruprojekt. Metoden grundades 1995 av Jeff Sutherland och Ken Schwaber. Deras ambition var att skapa en "projektstyrningsmetod" för hyperproduktiv mjukvaruutveckling. Scrum blev namnet på denna metod som kan öka produktiviteten fem till tio gånger jämfört med traditionell mjukvaruutveckling. Det finns många som lyckats med att uppnå detta men även de som misslyckats. Förklaringen till varför inte alla lyckats kan liknas med schack. Det går relativt snabbt att lära sig spelreglerna men det krävs mer för att bli en riktigt bra spelare (*).

Det som kännetecknar Scrum är att utvecklingen av systemet bryts ned till mindre greppbara delleveranser som benämns sprintar. En sprint är ett bestämt tidsintervall där ett mål ska uppnås på ett fokuserat sätt av utvecklingsteamet. Ett rekommenderat tidsintervall för en sprint är 30 dagar och detta intervall rekommenderas speciellt för utvecklingsteam som prövar på Scrum för första gången. Det är viktigt att en sprint alltid resulterar i en fullt fungerade produkt. Detta eftersom man aldrig kan förutse om det blir en sprint till, och även om det blir en sprint till så är det inte säkert att den ska påbörjas direkt efter (trots att man planererat för det).

Tre roller
1. Produktägaren (eng. Product Owner). Denna person representerar kunden och ansvarar för behovslistan för produkten samt hur denna lista ska prioriteras. Den som har ett önskemål kring produkten kontaktar produktägaren och argumenterar för hur önskemålet ska prioriteras. Produktägaren bör vara en person som kan verksamheten och som kan avgöra vilka behov som är viktiga utifrån verksamhetsnytta. Detta eftersom produktägaren ansvarar för avkastningen av produkten (eng. Return On Investment = ROI).

2. Scrum-mästare (eng. Scrum Master). Denna person har till uppgift att se till att produktiviteten är hög i utvecklingsteamet genom att eliminera eventuella hinder, flaskhalsar och störmoment för teamet. Scrum-mästaren är inte en projektledare som styr utvecklingsteamet utan en person som coachar och stimulerar till samarbete, överblick och produktivitet. Scrum-mästarrollen är oftast inte en heltidstjänst utan brukar varvas med en medlemsroll i utvecklingsteamet. Arbetsfördelningen mellan rollen som Scrum-mästare och teammedlem kan skilja mellan olika Scrum-projekt men även mellan sprintar. Fördelningen kan bero på saker som teamstorlek, teamets erfarenhet i att arbeta enligt Scrum m. m.

3. Utvecklingsteamet (eng. Scrum Team). Det är utvecklingsteamet som utför det som ska göras i en sprint. Den rekommenderade storleken på ett team är mellan 5-9 personer. En viktig sak med teamet är att det är självorganiserande, vilket innebär att det är teamet själv som bestämmer hur det ska utföra det som ska göras i en sprint. För att stimulera självorganiseringen ska det inte finnas några arbetstitlar i teamet, som tex arkitekt, testare, designer, projektledare eller något liknande. Det finns heller inga individuella prestationer utan allt handlar om team-prestationer. Allt som görs i teamet ansvaras av teamet. Detta innebär att om det går dåligt för någon i teamet så går det dåligt för teamet som helhet. Går det dåligt för någon i teamet är det teamets ansvar att se till att hjälpa denna person. Det är tillsammans som man ska ro i hamn sprinten och detta så effektivt som möjligt. För att stimulera teamkänsla och samarbete bör teamet arbeta tätt tillsammans och helst i ett och samma rum, ett så kallat teamrum.

Fem möten
1. Tidsuppskattningsmöte av behovslistan för produkten (eng. Backlog Estimation), ca 2 timmar åt gången. I detta möte görs grova tidsuppskattningar i dagar. Syftet med tidsuppskattningarna är att underlätta för produktägaren att prioritera behovslistan för produkten. Man bör tidsuppskatta tills man har estimerat ungefär tre sprintar framåt så att det alltid finns saker att göra. På mötet bör diskussioner hållas korta genom att man undviker detaljer.

2. Planeringsmöte av sprint (eng. Sprint Planning), ca 4 timmar långt. Detta möte hålls på den första dagen i sprinten och kan delas in i två delar. I den första delen planerar produktägaren, kunden, användare och utvecklingsteamet VAD som ska göras från produktbehovslistan samt var fokus ska ligga i sprinten genom att fastställa ett sprintmål (eng. Sprint Goal). I den andra delen planerar utvecklingsteamet mer konkret HUR sprinten ska göras genom att teamet försöker bryta ned behoven till mindre uppgifter på cirka 4-16 timmar. Dessa uppgifter hamnar i utvecklingsteamets uppgiftslista för sprinten (ej att förväxlas med produktägarens behovslista för produkten). I den andra delen av mötet behöver inte produktägaren vara med eftersom mötet är mer av teknisk karaktär. Om det visar sig att teamet åtagit sig för mycket att göra då får produktägaren avgöra vad som ska tas bort. Efter det åtar sig utvecklingsteamet ansvaret för sprinten.

3. Dagliga avstämningsmöten (eng. Daily Scrum), ca 15 minuter långa. Dessa möten äger  alltid rum på samma plats och vid samma tid (oavsett om alla kommer). Kunder, användare och produktägaren är välkomna på dessa möten men dessa personer får enbart lyssna. Scrum-mästaren håller i mötet och syftet är att stimulera interaktion, överblick samt att tidigt identifiera eventuella problem eller hinder i sprinten. På dessa möten försöker man dock inte lösa problem utan mötet är endast ett informationsmöte. Finns det behov av problemdiskussion eller liknande så ordnar teamet ett nytt möte med berörda parter. På det dagliga mötet ska alla i utvecklingsteamet kort svara på nedanstående tre frågor.
- Vad har jag gjort sedan förra mötet?
- Vad ska jag göra fram till nästa möte?
- Finns det något hinder i min väg?

4. Demonstrationsmöte av sprint (eng. Sprint Demonstration), ca 4 timmar långt. Detta möte hålls på den sista dagen i sprinten där kunder, användare och produktägare informeras om vad teamet utvecklat. Scrum-mästaren leder mötet och det bör var så informellt som möjligt, dvs inte kräva större förberedelser. Syftet med mötet är att det är ett arbetsmöte där frågor, diskussioner och förslag uppmuntras. Fokus ligger dock i att informera vad teamet gjort i sprinten. På detta möte bestäms även när nästa planeringsmöte ska hållas.

5. Återblicksmöte av sprint (eng. Sprint Retrospective), ca 3 timmar långt. Detta möte är det sista mötet i sprinten och på detta mötet går scrum-mästaren, produktägaren och teamet igenom vad som gått bra respektive mindre bra så att man kan förbättra sig till nästa sprint. Nedanstående tre frågor besvaras.
- Vad bör vi fortsätta att göra (bevara)?
- Vad bör vi sluta att göra (undvika)?
- Vad bör vi pröva att göra (pröva)?

Olika hjälpmedel
1. Behovslista för produkt (eng. Product Backlog). Denna lista är föränderlig och ansvaras av produktägaren. Det är produktägaren som ser till att listan är prioriterad utifrån verksamhetsnytta. Listan kan tänkas bestå av önskemål kring ny funktionalitet, buggfixar, systemunderhåll etc. Den ska också vara synlig för alla intressenter.

2. Uppgiftslista för sprint (eng. Sprint Backlog). Detta är en lista med uppgifter på hur olika behov ska uppfyllas inom en viss specifik sprint. Det är utvecklingsteamet som ansvarar för denna lista och det är enbart de som får administrera den.

3. Problemlista för sprint (eng. Impediment Backlog). Detta är en prioriterad uppgiftslista med problem och hinder som utvecklingsteamet har i sprinten. Scrum-mästaren ansvarar för att problem löses så fort som möjligt. Idealet är att de undanröjs direkt när de uppkommer. Krävs det att beslut ska fattas så bör man sträva efter att fatta snabba beslut och korrigera under sprintens gång om beslutet visade sig vara mindre bra.

4. Progressdiagram för sprint (eng. Sprint Burndown chart). Diagrammet visar hur mycket arbete teamet gjort samt hur mycket det är kvar att göra i sprinten. Det är inte ovanligt att det tillkommer oförutsägbara uppgifter under en sprint eller att vissa uppgifter tar kortare eller längre tid än man planerat. Alla sådana avvikelser synliggörs i diagrammet genom att planerat utfall dagligen jämförs mot verkligt utfall. På detta sätt kan man tidigt upptäcka och lösa eventuella problem eller få en indikation på om teamet har för mycket eller för lite att göra. Det blir enklare att vidta olika justerande åtgärder när det tydligt visualiseras och man kan tidigt undvika att utsätta teamet för onödig stress eller för att de har för lite att göra. Scrum-mästaren uppdaterar detta diagram innan det dagliga mötet samt när alla i teamet uppdaterat sina uppgifter.

5. Progressdiagram för release (eng Release Burndown chart). Detta diagram ger en grov plan över alla potentiella och klara sprintar. Efter varje sprint så uppdaterar Scrum-mästaren detta diagram genom att kontrollera hur mycket som finns kvar i behovslistan för produkten.

6. Sprint-tavla (eng. Task Board). Denna tavla är oftast en whiteboard i teamrummet och den bör vara synlig för alla i utvecklingsteamet. Tavlan består till stor del av en uppgiftshanteringssektion med olika status som en uppgift kan ha. Status kan skilja sig mellan olika Scrum-projekt men klassiska exempel på status är: “Ej påbörjad”, “Startad”, “Klar för test” och “Klar”. Uppgifterna skrivs på tex Post-It-lappar som teammedlemmen flyttar på tavlan och innan det dagliga mötet ska alla i utvecklingsteamet se till att uppgifterna har korrekt status samt att kvarvarande tid är uppdaterat. Andra delar på sprint-tavlan kan vara progressdiagram för sprint, problemlista för sprint, sprintmål m.m.

7. Virtuella verktyg. Det som bör tas i beaktande när man börjar fundera på att använda virtuella verktyg istället för fysiska verktyg är att samarbete och annan interaktion inom teamet kan bli lidande. Något av nedanstående virtuella verktyg kan användas för att integrera Scrum med Team Foundation Server (TFS).

- Scrum for Team System
- Microsoft eScrum
- VSTS Scrum Process Template
- Scrum Dashboard

På denna sida finns en utvärdering av de tre ovanstående virtuella verktygen: Utvärdering av virtuella verktyg.

Övrigt
1. Scrum kan kombineras med andra lättrörliga metoder. Det är tex inte ovanligt att Scrum kombineras med eXtreme Programming (XP) för att uppnå en ännu högre produktivitet. Här nedan finns mer information kring att kombinera Scrum och XP.
- Scrum and XP from the Trenches, gratis bok skriven av Henrik Kniberg
- Xbreed är Mike Beedles sätt att kombinera bland annat Scrum och XP.

2. Scrum kan används för större team än 5-9 personer. Det finns väldigt stora projekt som använt sig av Scrum på ett framgångsrikt sätt. Detta har gjorts genom att dela upp projektet i flera utvecklingsteam istället för att ha ett enda stort team (eng. Scrum of Scrums).

3. Tillägg av frågor till det dagliga avstämningsmötet. I boken "Agile & Iterative Development - A managers guide" rekommenderar författaren, Craig Larman, att nedanstående två frågor läggs till i det dagliga avstämningsmötet. Detta för att stimulera interaktion, överblick och lärande.
- Finns det några uppgifter som ska läggas till i sprint uppgiftslistan, dvs uppgifter som vi inte förutsett?
- Har du lärt dig något eller fattat något beslut som kan vara bra för de andra i teamet att få reda på?

4. Läs mer om Scrum.
- Scrum på fem minuter är en informationsbroschyr som SoftHouse har gett ut.
- What is Scrum? är en presentation gjord av Scrum Alliance.

5. Företag som utbildar i Scrum.
- Citerus
- SoftHouse
- Crisp

6. Alla fasta värden i Scrum såsom 15 minuter för dagliga avstämningsmöten, 4 timmar för planeringsmöten m.m. är bra startvärden om man aldrig tidigare arbetat med Scrum. Dessa värden kan förändras och bör förändras om det går att finna bättre värden. Detta eftersom Scrum inte är en låst metod utan stimulerar till kontinuerlig förbättring av arbetssättet. Så den Scrum vi ser idag är nödvändigtvis inte densamma som den vi ser om 10 år, men grundvärderingarna metoden baseras på kommer sannolikt att leva vidare.

*) Jämförelsen med schack gjordes av Henrik Kniberg i en artikeln i Computer Sweden, "Scrum är som schack".