Ken Schwaber & Jeff Sutherland

Scrum GuidenDen definitive guide til Scrum: Spillets regler

November 2020

Formålet med Scrum Guiden
Vi utviklet Scrum tidlig på 1990‐tallet. Vi skrev den første versjonen av Scrum Guiden i 2010 for å hjelpe
mennesker verden over å forstå Scrum. Siden da har vi utviklet guiden gjennom små, funksjonelle
oppdateringer. Vi står samlet bak Scrum Guiden.
Scrum Guiden inneholder definisjonen av Scrum. Hvert element i rammeverket har et spesifikt formål
som er viktig for verdien og resultatene man får med Scrum. Endringer i kjernen av Scrum rammeverkets
design eller ideer, utelate elementer, eller ikke å følge reglene i Scrum dekker over problemer og
begrenser gevinstene ved bruk av Scrum. I sin ytterste konsekvens kan det gjøre Scrum verdiløst.
Vi følger den økende bruken av Scrum i en stadig mer kompleks verden. Vi er ydmyke når vi ser at Scrum
blir tatt i bruk i mange domener med komplekst arbeid utenfor softwareutvikling, hvor Scrum har sine
røtter. Ettersom bruken av Scrum øker, gjøres arbeidet av utviklere, forskere, analytikere og andre typer
spesialister. I Scrum bruker vi ordet “utvikler”, ikke for å ekskludere, men for å forenkle. Hvis du får verdi
fra Scrum, anse deg som inkludert.
Når man tar i bruk Scrum kan man finne rutiner, prosesser og innsikt som passer med Scrum
rammeverket slik det er beskrevet i dette dokumentet. Beskrivelsen av disse er utenfor formålet med
Scrum Guiden fordi de er kontekstavhengige og det er store variasjoner i bruken. Bruk av slike spesifikke
rutiner og prosesser innenfor Scrum rammeverket vil variere og er beskrevet andre steder.

Ken Schwaber & Jeff Sutherland November 2020

© 2020 Ken Schwaber og Jeff Sutherland
This publication is offered for license under the Attribution Share‐Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share‐Alike license of Creative Commons.
1Formålet med Scrum Guiden

1

Scrum Definisjon

3

Scrumteori

3

Synlighet

4

Inspeksjon

4

Tilpasning

4

Scrum Verdier

4

Scrum Teamet

5

Developers

5

Product Owner

6

Scrum Master6

Scrum Eventer

7

Sprinten

7

Sprint Planning

8

Daily Scrum

9

Sprint Review

9

Sprint Retrospective

10

Scrum Artefakter

10

Product Backlog

10

Forpliktelse: Produktmål
Sprint Backlog
Forpliktelse: Sprintmål
Increment
Forpliktelse: Definisjon av Ferdig
Sluttnote

11
11
11
12
12
13

Anerkjennelser

13

Menneskene

13

Scrum Guide historie

13

Oversettelse

13

Endringer fra 2017 Scrum Guide til 2020 Scrum Guide

14

2

Scrum Definisjon
Scrum er et lettvekts‐rammeverk som hjelper mennesker, team og organisasjoner å skape verdi
gjennom tilpassede løsninger for komplekse problemer
I et nøtteskall: Scrum krever en Scrum Master som skaper et miljø der:1. Product Owner ordner arbeidet for å løse et komplekst problem i en Product Backlog
2. Scrum Teamet tar en utvalgt del av arbeidet og omgjør dette til et Increment med tydelig verdi i
en Sprint.
3. Scrum Teamet og dets interessenter inspiserer resultatene og tilpasser med tanke på neste
Sprint.
4. Repeter

Scrum er enkelt. Prøv det som det er, og vurder om filosofien, teorien og strukturen hjelper for å oppnå
målsettinger og å skape verdi. Scrum‐rammeverket er bevisst mangelfullt, og definere bare de delene
som er nødvendig for å implementere Scrum teorien. Scrum bygger på den kollektive intelligensen til desom bruker det. I stedet for å gi detaljerte instrukser, støtter reglene i Scrum opp under nødvendige
relasjoner og interaksjoner mellom mennesker.
En mengde prosesser, teknikker og metoder kan brukes innenfor rammeverket. Scrum kan fungere
sammen med eksisterende praksiser eller gjøre dem unødvendige. Scrum synliggjør den relative
effektiviteten av nåværende ledelse, miljø og arbeidsteknikker, slik at forbedringer kan gjøres.

Scrumteori
Scrum er basert på empirisme og lean tankegang. Empirisme baserer seg på at kunnskap kommer fra
erfaring og at belsutninger treffes basert på hva som er kjent. Lean reduserer sløsing og fokuserer på det
essensielle.
Scrum bruker en iterativ, inkrementell tilnærming for å optimalisere forutsigbarhet og styre risiko.
Scrum engasjerer grupper av mennesker som kollektivt har all kompetanse og ekspertise for å
gjennomføre arbeidet og dele eller lære seg den nødvendige kompetansen.
Scrum bruker fire formelle eventer for inspeksjon og tilpasning. Alle disse fire ligger i Sprinten som er en
kontainer‐event for de fire formelle eventene. Disse eventene er effektfulle fordi de bygger på deempiriske Scrum pilarene; synlighet, inspeksjon og tilpasning.

3

Synlighet
Prosessen og arbeidet utvikler seg over tid og må være synlig både for de som utfører og de som mottararbeidet. Med Scrum baseres viktige beslutninger på den oppfattede tilstanden til de tre formelle
artefaktene. Artefakter med liten synlighet kan lede til beslutninger som minsker verdi og øker risiko.
Synlighet muliggjør inspeksjon. Inspeksjon uten synlighet er misvisende og bortkastet.

Inspeksjon
Scrum‐artefaktene og fremdriften mot avtalte mål må inspiseres ofte og flittig for å oppdage potensielle
uønskede avvik eller problemer. Scrum gir rytme (kadens) i form av sine fem eventer for å hjelpe med
inspeksjon.
Inspeksjon muliggjør tilpasning. Inspeksjon uten tilpasning anses som meningsløst. Scrum‐eventer er
designet for å provosere fram endring.

Tilpasning
Hvis noe i en prosess avviker utenfor akseptable grenser, eller hvis det resulterende produktet er
uakseptabelt, må prosessen eller resultatet av arbeidet justeres. Justeringen må skje så raskt som mulig
for å minimere videre avvik.
Tilpasning blir vanskeligere når de involverte ikke er bemyndiget eller selvledende. Det forventes at etScrum Team tilpasser seg i det øyeblikk de lærer seg noe nytt gjennom inspeksjon.

Scrum Verdier
Vellykket bruk av Scrum avhenger av at mennesker blir flinkere til å etterleve fem verdier:
Forpliktelse, Fokus, Åpenhet, Respekt og Mot
Scrum teamet forplikter seg til å oppnå målene sine og å støtte hverandre. Deres primære fokus er påarbeidet i Sprinten for å sikre en best mulig progresjon mot målene. Scrum‐teamet og dets interessenterer åpne om arbeidet og utfordringene. Medlemmene av Scrum Teamet respekterer hverandre somkapable, uavhengige mennesker og blir respektert som sådan av menneskene de jobber med. Team‐
medlemmene har mot til å gjøre det rette og å jobbe med krevende problemer.
Disse verdiene gir retning til Scrum‐teamets arbeid, handlinger og atferd. Beslutninger og aksjoner somtas, samt måten Scrum brukes på bør forsterke disse verdiene, ikke redusere eller undergrave dem.
Medlemmene av Scrum Teamet lærer underveis og utforsker verdiene mens de jobber med Scrum sine
eventer og artefakter. Når Scrum Teamet og menneskene de jobber med etterlever verdiene, kommer
de empiriske Scrum‐pilarene synlighet, inspeksjon og tilpasning til sin rett og bygger tillit.
4

Scrum Teamet
Den fundamentale enheten i Scrum er et lite team av mennesker, et Scrum Team. Scrum Teamet består
av en Scrum Master, en Product Owner og Developers. Innenfor et Scrum Team er det ingen
grupperinger eller hierarkier; Det er en samlet enhet av fagpersoner som er fokusert på ett mål om
gangen, Produktmålet.
Scrum Team er kryssfunksjonelle, noe som betyr at medlemmene har alle ferdighetene som er
nødvendige for å skape verdi i hver Sprint. De er også selvledende, noe som betyr at de internt
bestemmer hvem som gjør hva, når og hvordan.
Scrum Teamet er lite nok til å være lettbent og kjapt, og stort nok til å fullføre betydelig arbeid i en
Sprint, vanligvis 10 eller færre mennesker. Generelt har vi funnet at mindre team kommuniserer bedreog er mer produktive. Hvis teamene blir for store, bør de vurdere å omorganisere til fleresamarbeidende Scrum Team, alle med fokus på det samme produktet. Derfor skal de ha felles
produktmål, Product Backlog og Product Owner.
Scrum Teamet er ansvarlig for alle produktrelaterte aktiviteter ‐ fra samarbeid med interessenter,
verifisering, vedlikehold, drift, eksperimentering, forskning og utvikling, og alt annet som måtte værenødvendig. De er strukturert og bemyndiget av organisasjonen til å styre sitt eget arbeid. Scrum
Teamets fokus og samhandling styrkes ved at de jobber i Sprinter i et bærekraftig tempo.
Hele Scrum‐teamet er ansvarlig for å skape et verdifullt, nyttig Increment i hver Sprint. Scrum definerertre spesifikke ansvarsforhold innen Scrum Team: Developers, Product Owner og Scrum Master.

Developers
Developers er de i Scrum Teamet som er dedikerte til å lage alt som er nødvendig for å sluttføre et ferdig
Increment i hver Sprint.
Den spesifikke kompetansen som Developers trenger er ofte brede og vil variere med arbeidsområdet.
Imidlertid er Developers alltid ansvarlige for å:●●●●

Lage en plan for Sprinten, Sprint Backlog;
Levere kvalitet ved å følge en definisjon av Ferdig;
Tilpasse planen hver dag mot Sprint‐målet og;
Holde hverandre ansvarlige som profesjonelle utviklere.

5

Product Owner
Product Owner er ansvarlig for å maksimere verdien av produktet som følge av arbeidet til Scrum
Teamet. Hvordan dette gjøres kan variere mye mellom ulike organisasjoner, Scrum Team og personer.
Product Owner er også ansvarlig for effektiv styring av Product Backlog, som inkluderer:● Utarbeide og klart kommunisere produktmålet;● Opprette og tydelig kommunisere Product Backlog elementer;● Ordne Product Backlog elementer i prioritert rekkefølge, og;● Sikre at Product Backlog er synlig, tilgjengelig og forstått.
Product Owner kan utføre det overnevnte arbeidet selv, eller delegere til andre. Uansett så forblir
Product Owner ansvarlig.
For at Product Owner skal lykkes må hele organisasjonen respektere deres beslutninger. Disse
beslutningene er synlige gjennom innholdet og rekkefølgen i Product Backlog, og gjennom det
inspiserbare Incrementet på Sprint Review.
Product Owner er en person, ikke en komité. Product Owner kan uttrykke behovene til mange
interessenter i Product Backlog. De som ønsker å endre Product Backlog, kan gjøre det ved å prøve å
overbevise Product Owner.

Scrum MasterScrum Master er ansvarlig for å etablere Scrum som definert i Scrum Guiden. De gjør dette ved å hjelpealle med å forstå Scrum‐teori og praksis, både innenfor Scrum Teamet og i organisasjonen.
Scrum Master er ansvarlig for Scrum Teamets effektivitet. De gjør dette ved å stimulere Scrum‐teamet
til å forbedre sin praksis, innenfor Scrum rammeverket.
Scrum Mastere er sanne ledere som støtter Scrum Teamene og den større organisasjonen de er en delav.
Scrum Master støtter Scrum Team på flere måter, inkludert:● Coaching av teammedlemmene i selvledelse og kryssfunksjonelt samarbeid;● Hjelpe Scrum Teamet med å fokusere på å skape Incrementer av høy kvalitet som tilfredsstiller
definisjonen av Ferdig;● Sørger for å fjerne hindringer for Scrum Teams støter på og;● Sikre at alle Scrum‐eventene finner sted og er positive, produktive og holdes innenfor tidboksen.
Scrum Master støtter Product Owner på flere måter, inkludert:

6

●
●
●
●

Hjelpe med å finne teknikker for effektiv definisjon av produktmålet og styring av ProductBacklog;
Hjelpe Scrum Teamet med å forstå behovet for klare og konsise Product Backlog elementer;
Hjelpe med å etablere empirisk produktplanlegging i et komplekst miljø og;
Tilrettelegge for samarbeid med interessenter på forespørsel eller ved behov.

Scrum Master støtter organisasjonen på flere måter, inkludert:● Ledelse, opplæring og coaching av organisasjonen i sin Scrum‐adopsjonen;● Planlegging og veiledning av Scrum‐implementasjonen i organisasjonen;● Hjelpe ansatte og interessenter med å forstå og etterleve en empirisk tilnærming til komplekstarbeid og;● Fjerne barrierer mellom interessenter og Scrum Team.

Scrum Eventer
Sprinten er en container for alle de andre eventene. Hver event i Scrum er en formell mulighet til å
inspisere og tilpasse Scrum‐artefakter. Disse eventene er spesielt designet for å skape den synligheten
som kreves. Dersom man ikke gjennomfører eventer som foreskrevet resulterer dette i tapte muligheter
til inspeksjon og tilpasning. Eventene brukes for å skape regelmessighet og for å minimere behovet formøter som ikke er definert i Scrum. Det er optimalt at alle eventene avholdes samme tid og sted hvergang for å redusere kompleksiteten.

Sprinten
Sprintene er hjerterytmen i Scrum, der ideer omdannes til verdi.
De er eventer med fast lengde på en måned eller mindre for å skape konsistens. En ny Sprint starter
umiddelbart etter avslutningen av forrige Sprint.
Alt arbeid som kreves for å oppnå produktmålet, inkludert Sprint Planning, Daily Scrums, Sprint Review
og Sprint Retrospective, skjer i Sprintene.
Underveis i Sprinten:● Det blir ikke gjort endringer som vil sette Sprint‐målet i fare;● Kvaliteten senkes ikke;● Product Backlog blir raffinert etter behov og;● Omfanget kan avklares og reforhandles med Product Owner etter hvert som man lærer.
Sprintene skaper forutsigbarhet ved å sikre inspeksjon og tilpasning av progresjon mot et Produkt mål
minimum hver kalendermåned. Hvis Sprintens horisont er for lang kan Sprint‐målet bli ugyldig,
kompleksiteten og risikoen kan øke. Kortere Sprinter kan brukes til å generere flere læringssykluser og
begrense risiko, kost og innsats til en mindre tidsramme. Hver Sprint kan betraktes som et kort prosjekt.
7

Det finnes mange ulike praksiser for å gi fremdriftsprognoser, slik som “burn‐downs”, “burn‐ups” eller
kumulativ flyt. Selv om de kan er nyttige, erstatter de ikke viktigheten av empiri. I komplekse miljøer kan
man aldri være sikker på hva som vil skje. Bare det som allerede har skjedd kan brukes til fremtidig
beslutningstaking.
En Sprint kan bli kansellert hvis Sprint‐målet blir verdiløst. Bare Product Owner har fullmakt til å avbryteen Sprint.

Sprint Planning
Sprint Planning starter Sprinten gjennom å detaljere arbeidet som skal gjøres i Sprinten. Hele Scrum
teamet samarbeider for å lage en plan for Sprinten.
Product Owner sørger for at deltakerne er forberedt på å diskutere de viktigste Product Backlog
elementene og hvordan de støtter opp om Produkt Målet. Scrum Teamet kan også invitere andre til ådelta på Sprint Planning for å gi råd om nødvendig.
Sprint Planning svarer på:

Del 1: Hvorfor er denne Sprinten verdiskapende?
Product Owner foreslår hvordan produktet kan øke sin verdi og nytte i Sprinten. Hele Scrum Teamet
samarbeider så for å definere Sprint målet. Sprint målet skal kommunisere hvorfor Sprinten er verdifulltil interessenter. Sprint målet må være bestemt før Sprint Planning er ferdig.

Del 2: Hva kan bli Ferdig i Sprinten?
Gjennom diskusjoner med Product Owner velger Developers elementer fra Product Backlog som skal
inkluderes i Sprinten. Scrum Teamet kan avgrense (raffinere) elementer gjennom denne prosessen, noe
som gir økt felles forståelse og tillit.
Det kan være utfordrende å beslutte hvor mye som kan gjøres i en Sprint. Jo mer Developers vet om sin
tidligere ytelse, tilgjengelig kapasitet og Definisjonen av Ferdig, desto tryggere vil de være i sin prognose
for Sprinten.
Del 3: Hvordan vil det valgte arbeidet bli utført?
For hvert valgte Product Backlog element planlegger Developers arbeidet som er nødvendig for å lage etIncrement som oppfyller Definisjonen av Ferdig. Dette gjøres ofte ved å nedbryte Product Backlog
elementer i mindre oppgaver på en dag eller mindre. Hvordan dette gjøres bestemmes av Developers.
Ingen andre forteller dem hvordan de kan gjøre om elementene til verdifullt Increment.

8

Sprint‐målet, Product Backlog elementene som er valgt for Sprinten og planen for å levere dem blir
sammen referert til som Sprint Backlog.
Sprint Planning har en maksimalt tidsboks på åtte timer for en måned Sprint. For kortere Sprinter er
eventet kortere.

Daily Scrum
Hensikten med Daily Scrum er å inspisere fremdriften mot Sprint‐målet og tilpasse Sprint Backlog etterbehov, og justere det videre planlagte arbeidet.
Daily Scrum er et 15‐minutters event for Developers i Scrum Teamet. For å redusere kompleksiteten
holdes det på samme tid og sted hver dag gjennom Sprinten. Hvis Product Owner eller Scrum Masterjobber aktivt med elementer i Sprint Backlog, deltar de som utviklere.
Developers kan velge hvilken struktur og teknikker de vil, så lenge deres Daily Scrum fokuserer på
fremgang mot Sprint‐målet og resulterer i en handlingsplan for neste arbeidsdag. Dette skaper fokus og
forbedrer selvledelsen.
Daily Scrum forbedrer kommunikasjonen, identifiserer hindringer, fremmer raske beslutninger og
eliminerer behovet for andre møter.
Daily Scrum er ikke den eneste gangen utviklere har anledning til å justere planen. De møtes ofte
gjennom dagen for mer detaljerte diskusjoner om tilpasning og planlegging av resten av Sprintens
arbeid.

Sprint Review
Hensikten med Sprint Review er å inspisere resultatet av Sprinten og bestemme fremtidige tilpasninger.
Scrum Teamet presenterer resultatene av sitt arbeid for viktige interessenter og fremdriften mot
produktmålet blir diskutert.
Scrum Teamet gjennomgår med interessentene hva som ble oppnådd i Sprinten og hva som har endret
seg i omgivelsene. Basert på denne informasjonen samarbeider deltakerne om hva de skal gjøre videre.
Product Backlog kan også bli justert for å møte nye muligheter. Sprint Review er en arbeidsøkt, og Scrum
Teamet bør unngå å begrense det til en presentasjon.
Sprint Review er den nest siste hendelsen i Sprinten og har en tidsboks på maksimalt fire timer for enmåneds Sprint. For kortere Sprinter er eventet kortere.

9

Sprint Retrospective
Hensikten med Sprint Retrospective er å lage en plan for å øke kvalitet og effektivitet.
Scrum Teamet inspiserer hvordan den siste Sprinten gikk med hensyn til personer, interaksjoner,
prosesser, verktøy og deres Definisjon av Ferdig. Inspiserte elementer varierer ofte medarbeidsdomenet. Antagelser som førte dem på villspor identifiseres og utforskes. Scrum‐teamet
diskuterer hva som gikk bra under Sprinten, hvilke problemer de opplevde og hvordan disse problemene
ble løst (eller ikke).
Scrum Teamet identifiserer hvilke endringene som må til for å forbedre effektiviteten. De mest effektive
forbedringene blir iverksatt så snart som mulig. De kan gjerne legges til Sprint Backlogen for neste
Sprint.
Sprint Retrospective avslutter Sprinten. Det er tidsbokset til maksimalt tre timer for en en‐måneders
Sprint. For kortere Sprinter er eventet kortere.

Scrum Artefakter
Scrums artefakter representerer arbeid eller verdi. De er designet for å maksimere synlighet av viktig
informasjon. Dermed har alle som inspiserer artefaktene samme grunnlag for tilpasning.
Hver artefakt er en forpliktelse til å sikre synlighet av viktig informasjon og sette fokus slik at vi kan målefremdrift:● For Product Backlog er det produktmålet.
● For Sprint Backlog er det Sprint‐målet.
● For Increment er det Definisjonen av Ferdig.
Disse forpliktelsene forsterker empiri og Scrum‐verdiene for både Scrum Teamet og interessentene.

Product Backlog
Product Backlog utvikles over tid og er en ordnet liste over hva som er nødvendig for å forbedre
produktet. Det er den eneste kilden til arbeid som Scrum Team utfører.
Product Backlog elementer som kan gjøres Ferdig av Scrum Teamet innenfor en Sprint, anses å væreklare for Sprint Planning. De får vanligvis denne klarheten etter raffineringsaktiviteter. Product Backlog
raffinering er å bryte ned og ytterligere definere Product Backlog elementene i mindre og mer presise
elementer. Dette er en pågående aktivitet for å legge til detaljer, slik som en beskrivelse, rekkefølge og
størrelse. Hvilke attributter som er nødvendig varierer med arbeidsdomenet.

10Developers som skal utføre arbeidet er ansvarlige for å anslå størrelsen. Product Owner kan støtte
Developers ved å hjelpe dem med å forstå og å gjøre ulike avveininger.

Forpliktelse: Produktmål
Produktmålet beskriver en fremtidig tilstand for produktet som kan tjene som et mål for Scrum Teamet
å planlegge mot. Produktmålet er en del av Product Backlog. Resten av Product Backlog utvikler seg overtid for å definere “hva” som vil oppfylle produktmålet.
Et produkt er et verktøy for å levere verdi. Det har en klar grense, kjente interessenter ogveldefinerte brukere eller kunder. Et produkt kan være en tjeneste, et fysisk produkt eller noe mer
abstrakt.
Produktmålet er det langsiktige målet for Scrum Teamet. De må oppfylle (eller forlate) et mål før desetter i gang med det neste.

Sprint Backlog
Sprint Backlog består av Sprintmål (hvorfor), settet med Product Backlog‐elementer valgt for Sprinten(hva), samt en handlingsplan for å levere Incrementet (hvordan).
Sprint Backlog er en plan av og for Developers. Den er et veldig synlig sanntidsbilde av arbeidet som
Developers planlegger å utføre under Sprinten for å oppnå Sprint‐målet. Følgelig oppdateres Sprint
Backlogen gjennom Sprinten etter hvert som mer læres. Sprint Backlog skal ha nok detaljer til at
Developers kan inspisere fremdriften sin i Daily Scrum.

Forpliktelse: Sprintmål
Sprintmålet er det eneste målet for en Sprint. Sprintmålet er en forpliktelse for Developers, men gir ogsåfleksibilitet når det gjelder å definere det nøyaktige arbeidet som må gjøres for å oppnå det. Sprintmålet
skaper sammenheng og fokus, og oppfordrer Scrum Teamet til å jobbe sammen fremfor individuelt.
Sprintmålet formuleres under Sprint Planning og legges deretter til Sprint Backlog. Mens Developers
jobber i en Sprint, har de Sprint‐målet i fokus. Hvis arbeidet viser seg å være annerledes enn deforventet, samarbeider de med Product Owner for å justere omfanget av Sprint Backlog uten å påvirke
Sprintmålet.

11

Increment
Et Increment er en konkret byggesten på vei mot produktmålet. Hvert Increment legges til alle tidligere
Incrementer og blir grundig verifisert, slik at alle Incrementer fungerer sammen. For å gi verdi måIncrementet være brukbart.
Det er mulig å lage flere Incrementer i en Sprint. Summen av Incrementene presenteres på Sprint
Review, for å få tilbakemeldinger og støtter dermed empiri. Incrementer kan leveres til interessenter før
Sprintens slutt. Sprint Review bør aldri sees som en milepæl for å kunne levere verdi.
Arbeid som ikke oppfyller Definisjonen av Ferdig kan ikke betraktes som en del av et Incrementet.

Forpliktelse: Definisjon av Ferdig
Definisjonen av Ferdig er en formell beskrivelse av Incrementets tilstand når det oppfyller den
kvalitetsstandarden som kreves for produktet.
I det øyeblikket et Product Backlog element oppfyller Definisjonen av Ferdig, blir et Increment skapt.
Definisjonen av Ferdig skaper synlighet ved å gi alle en felles forståelse av hvilket arbeid som ble fullført
som en del av Incrementet. Hvis et Product Backlog element ikke oppfyller Definisjonen av Ferdig, kan
det verken leveres eller presenteres på Sprint Review. I stedet går den tilbake til Product Backlog for
fremtidig vurdering.
Hvis definisjonen av Ferdig for et Increment er en del av organisasjonens standarder, må alle Scrum
Teamene følge den som et minimum. Hvis det ikke finnes en standard i organisasjonen, må Scrum
Teamene lage en Definisjon av Ferdig som er passende for produktet.
Developers er pålagt å overholde Definisjonen av Ferdig. Hvis det er flere Scrum‐team som jobber
sammen om et produkt, må de gjensidig definere og overholde den samme Definisjonen av Ferdig.

12

Sluttnote
Scrum er gratis og tilbys gjennom denne guiden. Scrum sine roller, møter, artefakter og regler er
uforanderlige. Selv om det er mulig å kun implementere deler av Scrum så vil ikke resultatet væreScrum. Scrum eksisterer bare som en helhet og fungerer som en beholder for andre teknikker, metoderog praksiser.

Anerkjennelser
Menneskene
Av de mange tusen menneskene som har bidratt til Scrum ønsker vi å fremheve de som var
betydningsfulle i starten: Jeff Sutherland som arbeidet sammen med Jeff McKenna og John
Scumniotales, Ken Schwaber som arbeidet med Mike Smith og Chris Martin, og de jobbet også sammen.
Mange andre har bidratt i påfølgende år og Scrum ville ikke vært så raffinert som det er i dag uten deres
hjelp.

Scrum Guide historie
Ken Schwaber og Jeff Sutherland jobbet med å forme Scrum frem til 1995 da de co‐presenterte Scrumpå OOPSLA konferansen i 1995. Denne presentasjonen dokumenterte den læring som Ken og Jeff
tilegnet seg i de første årene de brukte Scrum og var den første formelle definisjonen av Scrum.
Scrum Guiden dokumenterer Scrum slik det er utviklet og videreutviklet over 30+ år av Jeff Sutherlandog Ken Schwaber. Andre kilder gir deg informasjon om mønstre, prosesser og innsikt som
komplementerer Scrum rammeverket. Disse kan øke produktivitet, verdi, kreativitet og tilfredshet med
resultatene man oppnår.
Scrum sin fulle historie er beskrevet andre steder. Scrum ble først brukt ved Individual Inc., Fidelity
Investments, og IDX (nå GE Medical).

Oversettelse
Denne guiden har blitt oversatt til norsk fra den originale versjonen på engelsk som utarbeidet av Ken
Schwaber og Jeff Sutherland. Den norske oversettelse er gjort av Benjamin Sommer og Geir Amsjø.
Translator Name(s) : Benjamin Sommer og Geir Amsjø
Translation Group Name: Lean Venture
Primary Contact Email: benjamin@leanventure.com
Website : www.leanventure.com / www.smidigkurs.no13

Endringer fra 2017 Scrum Guide til 2020 Scrum Guide
Enda mindre normativ
Over årene har Scrum Guiden blitt noe mer normativ. 2020 versjonen har som mål å bringe Scrum Guiden tilbake
til å være et minimalt, men tilstrekkelig rammeverk ved å fjerne eller myke opp normativt språk. F.eks så er
spørsmålene i Daily Scrum fjernet, språket rundt PBI attributer er myket opp, det samme er gjort rundt retroelementer i Sprint Backlog, kortet ned Sprint cancellation avsnittet med mer.

Ett team, fokusert på ett produktMålet med dette er å fjerne konseptet med et eget team inne i teamet, noe som har ført til “proxy” or "oss ogdem” atferd mellom PO og Dev Team. Det er nå ett Scrum Team fokusert på det samme målet, med tre forskjellige
sett av ansvarsområder: PO, SM, og Developers.

Introduksjon av produktmål
Scrum Guiden 2020 introduserer konseptet med produktmål for å skape fokus for Scrum Teamet mot et større
verdiskapende mål. Hver Sprint skal ta produktet nærmere produktmålet.

Ett hjem for Sprintmål, Definisjon av Ferdig og Produktmål
Tidligere Scrum Guider beskriver sprintmål og definisjon av Ferdig uten å knytte dem direkte til noe. De var ikke
artefakter, men var løst knyttet til artefaktene. Med introduksjonen av produktmål bidrar 2020 versjonen til større
klarhet rundt dette. Hver av de tre artefaktene har nå en forpliktelse knyttet til seg. For Product Backlog er det
produktmålet, Sprint Backlog har et sprintmål, og Incrementet har Definisjon av Ferdig. De er tilstede for å skape
synlighet og fokus når det gjelder fremdriften mot hvert artefakt.

Selv‐ledelse over selv‐organiserende
Tidligere Scrum Guider refererer til Development Teams som selv‐organiserende, de kan velge hvem og hvordan
arbeidet skal gjøres. Med mer fokus på Scrum Teamet, fremhever 2020 versjonen et selv‐ledende Scrum Team,som velger hvem, hvordan og hva det skal jobbes med.

Tre deler i Sprint Planning
I tillegg til Sprint Planning delene “Hva” og “Hvordan” er det i 2020 Scrum Guiden fokusert på en tredje del,«Hvorfor», med referanse til sprintmålet.

Forenklet språk for et bredere publikum
I 2020 versjonen av Scrum Guiden har vi fjernet overflødig og vanskelig språk, og samtidig tatt bort referanser til IT(f.eks. testing, system, design, krav, etc). Scrum Guiden er nå kortere enn 13 sider.

14