Grunderna i Scrum – roller, begrepp och aktiviteter

av | mar 9, 2018 | AGILE

Denna artikel går igenom grunderna i Scrum: den grundläggande metodiken, teorin och syftet med Scrums roller, aktiviteter och så kallade artefakter. Dessutom täcker vi in en hel del begrepp. Dels de som officiellt ingår i ramverket men också en del vanligt förekommande, inofficiella, som ofta används i praktiken.

Scrum är ett ramverk som implementerar det Agila tankesättet. Vill du putsa på dina kunskaper om Agile, kan det vara en idé att först läsa vår bloggpost Arbeta agilt – vad är agile? Det sätter mycket av det jag skriver här i ett sammanhang.

Scrum på 30 sekunder

  • Scrum är ett av flera ramverk som implementerar det Agila tankesättet.
  • Ramverket är lättviktigt och lätt att förstå.
  • Arbetet är uppdelat i korta iterationer, s.k. Sprintar.
  • Människorna inom ett Scrumteam är uppdelade i tre roller: Produktägare, Scrum Master och Utvecklingsteam.
  • Genom ett antal definierade artefakter kan Utvecklingsteamet strukturera, kommunicera och visualisera sitt arbete i realtid.
  • För att effektivisera processen, definierar Scrum de ceremonier och möten som behövs för att arbetet ska flöda.
  • Buzzwords för att verka insatt: Sprint, Scrum Master, riskminimering, backlog, snabb TTM, Daily standup, ceremonier.

Grunderna i Scrum

Det Agila manifestet i sig specificerar inte några direkt konkreta krokar att hänga upp sitt arbetssätt på. Däremot finns det ett antal konkretiseringar och implementationer som tillämpar den Agila filosofin, såsom Scrum, Kanban eller DevOps. En populär ingång till att få igång sitt Agila arbete är att man helt enkelt inför just Scrum som metodik, i stor eller liten skala.

Det finns många anledningar till att Scrum blivit så populärt. En av dem är att de praktiska delar som utgör ramverket är relativt okomplexa och konkreta, vilket vi kommer att se nedan.

Vidare är en av de stora skillnaderna från traditionell projektmetodik är att Scrums ramverk är uppbyggt på empirism. Det innebär att man tar beslut utifrån tidigare erfarenheter och information man faktiskt kan bekräfta. Inga “vi är helt säkra på att det här är det bästa sedan skivat bröd, så vi bygger allt på en gång”-projekt, alltså. Tvärtom vill vi skapa en kultur som inlemmar “vi tror att det här är en grym idé, men vi utvecklar lite i taget”.

Varför Scrum?

Alla vi som jobbat i den äldre skolans projekt känner igen att vi då redan i projektets inledningsfas lägger stora resurser på att definiera slutresultatet och den detaljerade vägen dit. Och vi känner nog också igen att den planen väldigt sällan håller hela vägen. Här kan Scrum erbjuda en minskad risk, snabbare time-to-market och en slutprodukt som är betydligt bättre anpassad till marknaden.

Scrums uppbyggnad består av tre roller, tre artefakter och fem ceremonier. Alla dessa delar hänger ihop och binder samman det faktiska arbetet som utförs till en Agil helhet. Det som är det fina här är att ramverket inte är stramt överallt. Det ger oss en hel del möjligheter att skräddarsy processen och ändå jobba enligt Scrum.

Roller som definieras i Scrum

Vi börjar med människorna. De roller som officiellt ingår i ett Scrumteam är:

Utvecklingsteamet

Om Scrum implementeras på en IT-funktion, så är ”Teamet” ofta just ett utvecklingsteam. Dock kan metodiken egentligen tillämpas på vilken grupp av tätt samarbetande människor som helst. Scrum följer den Agila tanken om teamsammansätting, men har i stort inga långtgående åsikter om hur teamet organiseras. Man förordar är att det till exempel ska bestå av kompetenser nog för att kunna skapa s.k. inkrement. Du läser mer om inkrement nedan, men begreppet symboliserar utveckling av slutprodukten i varje iterations slut. Dessutom bör teamet i sig vara en självorganiserande enhet.

Läs om våra tips för att sätta ihop ett agilt team. 

Scrum Master

En Scrum Master faciliterar att ramverket för Scrum följs och driver teamets ständiga förbättring och utveckling. Det innebär åtaganden både mot ett eller flera utvecklingsteam, men också mot Produktägarna. Detta kan låta trivialt, men rollen är både vital och djup.

Produktägaren

Om man kokar ned produktägarens egentliga uppdrag, så är det att maximera det värde som utkommer av det utvecklingsteamet levererar. Detta görs genom att prioritera rätt saker i rätt tid, genom en s.k. Produktbacklog. Mer om den nedan. Eftersom Utvecklingsteamet är autonomt är det extremt viktigt att Produktägaren kan motstå frestelsen att detaljstyra. Dessutom behöver hon vara villig att släppa ifrån sig visst ansvar och mandat till Teamet. Läs mer om rollen produktägare.

Aktiviteter enligt Scrum

För att definiera att rätt saker görs vid rätt tidpunkt, definierar Scrum fem stycken aktiviteter eller ceremonier. Dessa ingår alla inom varje iteration:

Sprint

Det den Agila filosofin kallar iteration, kallas inom Scrum för Sprint. En Sprint är alltid tidsbestämd (t ex tre veckor) och inom den ryms planering, utveckling och utvärdering.

Fördelen med korta iterationer är att en tidsrymd mindre än fyra veckor ofta är lättare att överblicka än en längre. Det gör både planering lättare och möjligheten att förändra större. Dessutom blir den finansiella risken mindre, eftersom man kan välja att avbryta eller byta inriktning inom ramen för nästa Sprint. Sprintar avlöser varandra och efter varje Sprint skall en ny och fungerande version av produkten finnas tillgänglig.

Sprintplanering

En Sprint inleds alltid med en tidsbestämd Sprintplanering. Här går Utvecklingsteamet igenom Produktbacklogen tillsammans med Produktägaren. Utifrån denna dialog beslutas vad som kan genomföras och hur. Viktigt att påpeka är att det är Utvecklingsteamet som besvarar frågorna om vad och hur. Produktägarens roll är att svara på eventuella frågor som kan uppstå kring specifika uppgifter i Produktbacklogen.

Under Sprintplaneringen skapas även ett Sprintmål. Sprintmålet är vad utvecklingsarbetet i denna Sprint ska leda till. Ett exempel är ”Efter denna Sprint skall användare kunna betala i vår webshop med sitt kreditkort”. Utkomsten av en Sprintplanering är en prognos för hur mycket man tror sig kunna hinna. Detta blir dokumenterat till en Sprintbacklog, se längre ned.

Daily Scrum

Daily Scrum är ett dagligt återkommande planeringsmöte för Utvecklingsteamet. Mötet får inte överstiga 15 minuter i längd. För att ingen ska bli för bekväm och dra ut på tiden måste deltagarna stå upp under hela mötets längd.

Varje deltagare svarar under mötet på tre frågor. “Vad har jag gjort sedan senaste mötet?”, “Vad planerar jag att göra idag?” och “Har jag några hinder?”. Baserat på detta kan Teamet planera tiden till nästa Daily Scrum. Man kan också snabbt och gemensamt identifiera hinder och hur man tillsammans ska hantera dessa. Observera att Scrum Master och Produktägare är välkomna på mötet, men att ingen av dem bör ha en aktiv roll.

Daily Scrum görs med fördel vid en visualisering av Sprintbackloggen, en s.k. scrumtavla.

Sprint Review/Sprint Demo

För att kommunicera den utveckling som skett under en Sprint, anordnar teamet en Sprint Review i slutet av Sprinten. Ibland kallas denna ceremoni även för Sprint Demo. Närvarande, förutom Utvecklingsteamet, Scrum Master och Produktägare är alla andra intressenter till arbetet som teamet utfört. Detta är ett informellt möte med syfte att förklara vad som teamet gör, vad man inte gör och hur resultatet påverkar nästa Sprint. Detta är även ett bra tillfälle för övriga intressenter att komma med input till hur vi bör planera nästa Sprint.

Sprint Retrospective

Ingen Agil metod utan retrospektiv! I detta möte samlar vi enbart det agila teamet (dvs Utvecklingsteamet, Scrum Master och Produktägare). Tillsammans utvärderar vi den senaste Sprinten utifrån arbetssätt, verktyg, relationer och annat värdefullt. Detta är ett bra sätt att tidigt upptäcka och åtgärda problem innan de blivit för stora, men också ett utmärkt tillfälle att uppmärksamma och förstärka positiva erfarenheter inom Scrumteamet. Retrospektiv kan tendera att hamna i skymundan, men är väldigt viktiga möten för att kunna utveckla och förstärka arbetssätt, kvalitet och effektivitet. Resultatet från ett retrospektiv bör vara små och konkreta förändringar.

Artefakter inom Scrum

För att de inblandande ska kunna dokumentera och visualisera arbetet, så finns inom Scrum tre stycken artefakter:

Produktbacklog

Produktbacklogen är en ordnad lista som innehåller alla utvecklingspunkter som vi i nuläget vet att vi vill förändra på vår produkt. Det är ett levande dokument och Produktägaren håller ansvaret för dess innehåll och ordning. Både prioritering och innehåll kan och bör skifta över tid, men det är alltså enbart Produktägaren som tillåter dessa ändringar.

Sprintbacklog

Innehållet i en Sprintbacklog är de uppgifter som Utvecklingsteamet bedömt att de kommer att leverera inom ramen för en Sprint. Varje enskild uppgift måste vara tydligt definierad. Detta både i vilka förväntningar finns på uppgiftens utkomst, men också hur teamet själva definierar den som färdig. Genom att följa Sprintbacklogen under Sprintens gång, visar vi hur Utvecklingsteamet gör framsteg. Den visar också vilka problem som uppstår och när.

Inkrement

Ett inkrement är den samlade produkt som uppstår efter en Sprint, då vi uppdaterar produkten med Sprintens uppgifter.

Andra vanliga roller och begrepp inom Scrum

Utöver de officiellt definierade rollerna, ceremonierna och artefakterna finns även en hel del annat som inte ingår officiellt i Scrums ramverk. Det är saker som blivit mer eller mindre standard att ha med i sin implementation. Några blandade sådana begrepp listas nedan:

Agil coach

En organisation med många Scrumteam har troligtvis intresse av följa Scrum under liknande former över flera team. En Agil coach kan då gå in för att stödja och synkronisera teamen och teamens Scrum Masters i sitt Agila arbete.

Definition of Done

För att hålla en jämn kvalitet i leverans enas Scrumteamet om en s.k. Defintion of Done. Denna definition ser till vad som måste vara uppfyllt för att en uppgift ska kunna definieras som ”klar”. Ett exempel ur IT-perspektiv kan vara att koden måste vara skriven på ett korrekt sätt och att vissa typer av tester måste vara genomförda och godkända innan uppgiften får kallas klar.

Backlog Refinement (även kallat Backlog Grooming)

För att effektivisera Sprintplaneringen träffas Scrumteamet under Sprintens gång och ser över uppgifter inför kommande Sprint. Man ser då till att uppgifterna är tillräckligt definierade och klara att startas. Detta för att slippa ha några frågetecken när Sprinten efter ska planeras.

Burndown Chart

Vissa ser detta som ett bra verktyg för att visualisera hur arbetet fortlöper i Sprinten. Det handlar helt enkelt om att skapa en graf som visar om utvecklingstempot följer planen. Om inte, kan man på ett tidigt stadium prioritera bort arbete. 

Produktvision

Ur ett långsiktigt perspektiv, är det förstås viktigt att Produktägaren har en vision om varthän dennes produkt skall utvecklas. En väl definierad Produktvision hjälper till i prioritering, både för Produktägaren själv, men även i hur hon kommunicerar till Utvecklingsteamet.

User stories

Det finns hur mycket som helst att säga om User Stories. Den korta versionen är att man helt enkelt definierar en önskad funktion utifrån affärs- eller kundvärde. User Stories är ett bra format att bygga upp uppgifter i sin Produkt- eller Sprintbacklog.

Estimering

När teamet planerar en Sprint måste det finnas en gemensam uppfattning om hur mycket teamet kan prestera under kommande iteration. För att kunna ge en sådan uppfattning, bör man för varje uppgift kunna Estimera hur pass komplex uppgiften är. Team som har jobbat mycket länge tillsammans inom samma område skapar hyfsade Estimat på känn. Detta är dock en våt dröm för de flesta. För oss dödliga finns det många olika sätt att bäst strukturera uppskattningsförmågan, såsom Planning Poker och Velocity.

Intressenter (eng. Stakeholders)

I de allra flesta organisationer är det inte bara Produktägaren som har intresse i vad Teamet gör. Eftersom Produktägaren är ansvarig för att maximera utfallet av arbetet, behöver denne ibland input från intressenter runt omkring. Det kan vara andra, närliggande, Produktägare som har beroenden till Teamet. Men likväl helt andra funktioner inom och utanför organisationen. Här är förstås användarna eller kunderna otroligt viktiga intressenter. Ett av Produktägarens ansvarsområden är att kommunicera med intressenterna för att hitta det maximala värdet i det man levererar och i det ingår konsten att faktiskt kunna säga nej till det som inte är det viktigaste just nu.

Men om vi är många och behöver skala Scrum?

Scrum fokuserar mest på det enskilda teamet och hur man optimerar för lättrörlighet och produktfokus. Många befinner sig dock i ett sammanhang större än så. Befinner du dig i en organisation där det finns många team som behöver samverka för en produkt? Eller där det kanske till och med finns behov av Agil portföljhantering? Då kan du komma att behöva skala upp din Scrum-implementation.

Scrum har, över tid, anammats av större och större organisationer. I takt med den förändringen har man försökt att tillfredsställa behovet av uppskalad Agilitet. Detta på flera håll och med flera olika anslagsvinklar. Vissa har utgått ifrån konceptet Agilitet i sig och fokuserat på att behålla den i så hög grad som möjligt. Andra har valt en approach som även respekterar organisationers inbyggda komplexitet ur andra aspekter.

Det finns några områden som är extra viktiga att hålla ett öga på vid skalning av Scrum. Dessa är hur man tänker sig att arbeta med beroenden, samarbetsformer och beslutsprocesser. Det är lätt att gå bort sig i ramverket och att falla tillbaka på sina gamla, invanda mönster.

Här kommer en superkort genomgång av några av de vanligast förekommande och största ramverken för skalad Agilitet just nu:

Nexus

Nexus skapades av scrum.org för att synkronisera utvecklingen inom flera team. Man utgick ifrån att kunna leverera helhetsvärdet i en produkt, utan att behöva kompromissa alltför mycket på den Agila filosofin. Ramverket bygger på att man synkroniserar ett antal (< 9) team i en s.k. “Nexus”, som har gemensamma Scrum-ceremonier. Detta innebär bl.a. delad Produktbacklog och gemensamma iterationsdemos. Inställningen är att om Nexusen behöver vara större än nio team, behöver  produkten brytas i mindre bitar. På detta sätt kan man behålla småskaligheten och styrkan som en liten gruppering har. Samtidigt kan man hantera lättrörligheten och det gemensamma fokuset i en större produkt.

Squads-tribes-chapter-guilds (a.k.a “Spotifymodellen”)

Spotify har, som bolag, satt sitt avtryck i många hänseenden, inte minst i den Agila världen. Man såg tidigt problematiken i att behöva skala sin Agila process och byggde förstås sin egen modell för att hantera det. Spotify uppfann inte denna modell själva, utan bygger i delar på Scrum@Scale. Dock har Spotify varit en stor faktor till spridningen och den används av vissa som alternativ till de andra ramverken vi nämner här.

Konceptet bygger på att man ger de olika grupperingarna olika namn för att förklara vilken del av sammanhanget de tillhör:

  • Squads är de minsta grupperingarna och motsvarar det vi andra brukar kalla Scrumteam, med allt och alla som kommer med det.
  • Tribes är en grupp av Squads med ett gemensamt uppdrag och mål. Det finns en Tribeledare och alla Squads sitter på samma ställe.
  • För att undvika isolering i arbetet med autonoma team, använder man sig i denna modell av något som kallas Chapters. Ett Chapter består av de som har liknande kompetens inom en Tribe såsom alla testare, javautvecklare eller front-endutvecklare.
  • Guilds är mjukare indelade intressegrupperingar, även mellan Tribes. Temat för olika Guilds kan vara testning, arkitektur eller annat som man vill och behöver diskutera i stort.

SAFe

I många fall är organisationen större än att man lätt ska kunna använda sig av de två tidigare nämnda ramverken. SAFe är anpassat för att stödja stora organisationer och har inkluderat exempelvis både portföljhantering och budgetering i ramverket.

De flesta förknippar SAFe med begreppet “tåg”, närmare bestämt det man kallar för Agila Releasetåg. Ett tåg består av ett antal team som alla försörjer samma operativa värdeström med värde. Varje team i ett tåg jobbar enligt Scrums principer, med Produktägare, Scrum Master och utvecklingsteam.

Varje tåg har i sin tur en Scrum Master, kallad RTE (Release Train Engineer), en eller flera Product Managers och Systemarkitekter. På så sätt styr tåget sin väg på samma sätt som teamen.

Beroende på hur stor din organisation är, kan du skala SAFe till den nivå som behövs, såsom enbart tågnivå eller portföljnivå.

Hur gör man sin skalning?

Först och främst: börja inte med att skala. Se till att du har en fungerande Agil process i det lilla och konkretisera de problem som uppstår utifrån det. Eventuellt kommer du då på att du behöver skala upp och då finns ovan ramverk att tillgå. Om du ska välja något av dem eller göra något annat behöver du avgöra själv. Observera att även skalningen helst görs i etapper och inte allt på en gång. I sann Agil anda.

Måste man följa ramverket?

Både ja och nej. Scrum är ett ramverk som måste innehålla alla delar för att du ska kunna kalla det Scrum. Om organisationen är ovan vid Agilt arbete så är min varma rekommendation att välja att följa hela ramverket så noggrant som möjligt. Efterhand kommer Retrospektiv och andra utvärderingar att forma processen och eventuellt minska, ändra eller lägga till moment. Kruxet är att du inte kan veta från början vilka moment eller företeelser som du kanske skall ta bort eller ändra; det kan du bara ta reda på genom att använda processen och regelbundet utvärdera. Och det är ju Agilt i sig.

På Onbird har vi gedigen erfarenhet av att coacha och medverka i såväl helheten i en Agil transformation, men även detaljkunskaper om de praktiska delarna, såsom Scrum, Kanban och DevOps. Kontakta oss gärna om du behöver bolla idéer, få stöd eller bara prata Scrum i allmänhet.

Förslag på fortsatt läsning

Upplev styrkan i Agila metoder!

På en halvdag tar vi er igenom det korta, fartfyllda och roliga Agile-spelet Birdville där ni genom praktiskt teamarbete får insikter om styrkan hos korta iterationer och ständig utveckling!

Share This