Grunderna i Scrum – roller, begrepp och aktiviteter

av | mar 9, 2018 | AGILE

Denna artikel går igenom grunderna i Scrum, det vill säga den grundläggande metodiken, teorin och syftet med Scrums roller, aktiviteter och så kallade artefakter samt en 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 dokument kan Utvecklingsteamets arbete struktureras, kommuniceras och visualiseras 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 av hur den Agila filosofin kan tillämpas, såsom Scrum, Kanban eller DevOps. En populär ingång till att få igång sitt Agila arbete är att helt enkelt införa just Scrum som metodik, i stor eller liten skala.

Det finns många anledningar till att Scrum blivit så populärt, men 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 vill säga att beslut tas utifrån tidigare erfarenheter och information man faktiskt vet. 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å. Snarare en kultur av att “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 lite äldre skolans projekt känner nog igen att vi redan i projektets inledningsfas lägger stora resurser på att definiera slutresultatet och en detaljerad väg 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 eftersom ramverket inte är stramt överallt, så finns det en hel del möjligheter att skräddarsy sin process 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, men kan 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, förutom att det till exempel ska bestå av kompetenser nog för att kunna skapa s.k. inkrement, dvs utveckling av slutprodukten i varje iterations slut. Teamet i sig är en självorganiserande enhet.

Scrum Master

En Scrum Masters roll handlar om att facilitera att ramverket för Scrum följs och att driva teamets ständiga förbättring och utveckling. Det innebär åtaganden både mot ett eller flera utvecklingsteam, men också mot Produktägarna.

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, och dessutom är villig att släppa ifrån sig visst ansvar och mandat till Teamet.

Aktiviteter enligt Scrum

För att definiera att rätt saker görs vid rätt tidpunkt, definierar Scrum fem stycken aktiviteter eller ceremonier, som alla ingår inom samma 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 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 helt 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 och utifrån detta beslutas vad som kan genomföras och hur. Viktigt att påpeka är att det är Utvecklingsteamet som besvarar dessa frågor, 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 och 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 och 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 redogör för vad som gjorts sedan senaste mötet, vad deltagaren ämnar göra idag och om det finns några hinder i vägen. Baserat på detta kan Teamet planera de närmaste 24 timmarna och kan 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 (eller inte skett) under en Sprint, anordnas en Sprint Review i slutet av varje Sprint. Närvarande, förutom Utvecklingsteamet, Scrum Master och Produktägare är andra intressenter till arbetet som gjorts. Detta är ett informellt möte, med syfte att förklara vad som gjorts, vad som inte gjorts och hur detta påverkar nästa Sprint. Detta är även ett bra tillfälle för övriga intressenter att komma med input till hur nästa Sprint ska planeras.

Sprint Retrospective

Ingen Agil metod utan retrospektiv! I detta möte samlas Scrumteamet (dvs Utvecklingsteamet, Scrum Master och Produktägare) och utvärderar 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.

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 innehållandes alla utvecklingspunkter som krävs för att uppnå en slutgiltig produkt. Detta är ett levande dokument och ansvaret för dess innehåll och ordning är Produktägarens. 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, både i vad som förväntas av uppgiften, men också hur den definieras som färdig. Detta dokument visar hur Utvecklingsteamet gör framsteg under Sprintens gång, men också vilka problem som uppstår och när.

Inkrement

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

Andra vanliga roller och begrepp inom Scrum

Självklart finns det utöver de officiellt definierade rollerna, ceremonierna och artefakterna även en hel del annat som inte ingår officiellt i Scrums ramverk, men som blivit 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 att se till att Scrum följs 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 kan man, inom Scrumteamet, enas om en s.k. Defintion of Done. I denna definition ses 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 vissa typer av tester måste vara genomförda och godkända för att uppgiften ska få kallas klar.

Backlog Refinement (även kallat Backlog Grooming)

För att effektivisera Sprintplaneringsmötet kan hela eller delar av Scrumteamet träffas under Sprintens gång och se ö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, i takt med att utvecklingstimmar avverkas, visar om utvecklingstempot är bra eller om man kommer att behöva omestimera aktuell Sprintbacklog.

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 lagom hårt definierad Produktvision kan då hjälpa till i prioritering, både för Produktägaren själv, men även i hur det ska kommuniceras till Utvecklingsteamet.

User stories

Det finns hur mycket som helst att säga om User Stories, men 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 en Sprint ska planeras måste det finnas en gemensam uppfattning om hur mycket ett Utvecklingsteam tror sig kunna 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. Vissa team som har jobbat mycket länge tillsammans inom samma område kan skapa hyfsade Estimat på känn, men få team når dit. 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 vad som utförs, behöver denne ibland input från intressenter runt omkring. Dessa kan vara andra, närliggande, Produktägare som har beroenden till Teamet, likväl som helt andra funktioner inom och utanför organisationen. Ett av Produktägarens ansvarsområden är att kommunicera med intressenterna för att hitta det maximala värdet i det som levereras 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?

Som ramverk fokuserar Scrum, som du säkert sett och hört, mest på det enskilda teamet och hur man optimerar för lättrörlighet och produktfokus där. Om du befinner 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.

I takt med att Scrum har anammats av större och större organisationer, har man försökt att tillfredsställa behovet av uppskalad Agilitet 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, medan andra har valt en approach som även respekterar organisationers inbyggda komplexitet i andra aspekter. 

De områden som är extra viktiga att hålla ett öga på vid skalning av Scrum ä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 just nu:

Nexus

Nexus skapades av scrum.org för att hantera faktumet att man kan behöva synkronisera utvecklingen inom flera team för 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 man bryta upp produkten i mindre bitar. På detta sätt kan man behålla småskaligheten och styrkan som en liten gruppering har, samtidigt som man kan 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. Denna modell uppfanns inte på Spotify utan bygger i delar på Scrum@Scale, men har spridit sig mycket tack vare dem och används av vissa som alternativ till de andra ramverken vi nämner här.

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

  • Squads är de minsta grupperingarna och motsvaras av 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 Realeasetå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 styrs tåget på samma sätt som teamen. 

Beroende på hur stor din organisation är, kan SAFe skalas 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 för att få kallas Scrum, måste innehålla alla delar. Om organisationen är ovan vid Agilt arbete så är min varma rekommendation att man väljer 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 kanske skall tas bort eller ändras; 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!

AGILE
Onbird 100% Safe v5
100% SAFe på Onbird!

100% SAFe på Onbird!

Välkommen tillbaka efter sommaren! På Onbird har vi varvat semester med förkovran och vi kan nu stolt meddela att 100% av Onbirds konsulter är certifierade SPC:er för SAFe version 5! Fler och fler företag som kommit en bit på väg i sin Agila resa kommer till...

Share This