Ken Schwaber & Jeff Sutherland

Scrum Guide
Den ultimative guide til Scrum:
Spillets regler

November 2020

Formålet med Scrum Guide
Vi udviklede Scrum i begyndelsen af 1990’erne. Vi skrev den første version af Scrum Guide i 2010 for athjælpe folk over hele kloden med at forstå Scrum. Vi har siden da udviklet guiden med små funktionelle
opdateringer. Vi står sammen om guiden.
Scrum Guide indeholder definitionen af Scrum. Hvert element i frameworket tjener et specifikt formål,der er afgørende for den samlede værdi og de resultater, der opnås med Scrum. Hvis man ændrer det
grundlæggende design eller idéen i Scrum, hvis man udelader elementer eller ikke følger reglerne i
Scrum, skjuler det problemer og begrænser fordelene ved Scrum, hvilket muligvis gør Scrum ubrugelig.
Vi følger den voksende brug af Scrum i en stadigt voksende kompleks verden. Vi er ydmyge over at se
Scrum blive adopteret i mange domæner, der i det væsentlige har komplekst arbejde, ud oversoftwareudvikling, hvor Scrum har sine rødder. Idet Scrums anvendelse spreder sig, gør udviklere,researchere, analytikere, forskere og andre specialister arbejdet. Vi bruger ordet "udviklere" i Scrum
ikke for at udelukke, men for at forenkle. Hvis du får værdi fra Scrum, er du naturligvis inkluderet.
Når Scrum bruges, kan mønstre, processer og indsigter, der passer til Scrum framework, som beskrevet i
dette dokument, findes, anvendes og udtænkes. Disse beskrivelser er ud over formålet med Scrum
Guide, fordi de afhænger af kontekst og varierer meget mellem Scrum‐anvendelser. Specifikke taktikker
for at anvende Scrum frameworket i forskellige situationer varierer meget og er beskrevet andetsteds.

Ken Schwaber & Jeff Sutherland, november 2020

© 2020 Ken Schwaber og Jeff Sutherland
Denne publikation er licenseret under Attribution Share‐Alike license fra Creative Commons, tilgængelig
på http://creativecommons.org/licenses/by‐sa/4.0/legalcode og endvidere beskrevet på kort form på
http://creativecommons.org/licenses/by‐sa/4.0/. Ved at bruge denne Scrum Guide, anerkende og
accepterer du, at du har læst og accepterer at være bundet af vilkårerne i Attribution Share‐Alike license
fra Creative Commons.

1Formålet med Scrum Guide .......................................................................................................................... 1
Definition af Scrum ....................................................................................................................................... 3
Scrum teori .................................................................................................................................................... 3
Gennemsigtighed ...................................................................................................................................... 3
Inspektion ................................................................................................................................................. 4
Tilpasning .................................................................................................................................................. 4
Scrum værdier ............................................................................................................................................... 4
Scrum Team .................................................................................................................................................. 5
Developers ................................................................................................................................................ 5
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 6
Scrum Events ................................................................................................................................................. 7
Sprint ......................................................................................................................................................... 7
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 9
Sprint Review ............................................................................................................................................ 9
Sprint Retrospective................................................................................................................................ 10
Scrum Artifacts ............................................................................................................................................ 10
Product Backlog ...................................................................................................................................... 10
Engagement: Product Goal ................................................................................................................. 11
Sprint Backlog ......................................................................................................................................... 11
Engagement: Sprint Goal .................................................................................................................... 11
Increment ................................................................................................................................................ 12
Engagement: Definition of Done ........................................................................................................ 12
Konklusion ................................................................................................................................................... 13
Anerkendelser ......................................................................................................................................... 13
Individer .............................................................................................................................................. 13
Scrum Guide historie........................................................................................................................... 13
Oversætter erkendelse ........................................................................................................................... 13
Kontaktinformation............................................................................................................................. 13Ændringer fra 2017 Scrum Guide til 2020 Scrum Guide ......................................................................... 14

2

Definition af Scrum
Scrum er et letvægts framework, som hjælper mennesker, teams og organisationer med at generereværdi gennem tilpassede løsninger til komplekse problemstillinger.
Kort sagt kræver Scrum, at en Scrum Master fremmer et miljø, hvor:
1.
2.
3.
4.

En Product Owner beskriver arbejdet for et komplekst problem i en Product Backlog.
Scrum Team forvandler et udvalg af arbejdet til et Increment under et Sprint.
Scrum Team og dets interessenter inspicerer resultaterne og justerer til næste Sprint.
GentagScrum er simpelt. Prøv frameworket som det er beskrevet og vurder om dets filosofi, teori og strukturhjælper med at nå mål og skabe værdi. Scrum framework er med vilje beskrevet ufuldstændigt og
definerer kun de dele, der kræves for at implementere Scrum teorien. Scrum er bygget på af denkollektive intelligens hos de mennesker, der bruger den. I stedet for at give folk detaljerede instruktioner
styrer reglerne i Scrum deres forhold og interaktioner.
Forskellige processer, teknikker og metoder kan anvendes inden for rammerne. Scrum omfavner
eksisterende praksis eller gør dem unødvendige. Scrum synliggør den relative effektivitet af nuværende
ledelse, miljø og arbejdsteknikker, så forbedringer kan foretages.

Scrum teori
Scrum er baseret på teorien bag empirisk proceskontrol og lean tankegang. Empiri hævder, at viden
kommer fra erfaring og at man tage beslutninger baseret på det, der observeres. Lean tankegang
reducerer spild og fokuserer på det væsentlige.
Scrum implementerer en iterativ, trinvis tilgang til at optimere forudsigeligheden og at kontrollere risici.
Scrum engagerer grupper af mennesker, der samlet har alle de færdigheder og ekspertiser til at udføre
arbejdet og dele eller tilegne sig sådanne færdigheder efter behov.
Scrum kombinerer fire formelle events til inspektion og tilpasning indenfor et omsluttende event, kaldet
Sprint. Disse events fungerer, fordi de implementerer de empiriske Scrum‐søjler for gennemsigtighed,inspektion og tilpasning.

Gennemsigtighed
Den anvendte proces og resultatet skal være synligt for dem, der frembringer resultatet, såvel som
dem, der modtager resultatet. Med Scrum er vigtige beslutninger baseret på den opfattede tilstand af
dets tre formelle artefakter. Artefakter, der har lav gennemsigtighed, kan føre til beslutninger, dermindsker værdi og øger risikoen.

3Gennemsigtighed muliggør inspektion. Inspektion uden gennemsigtighed er vildledende og spild af
tid.

Inspektion
Scrum artifacts og fremskridt mod aftalte mål skal inspiceres ofte og flittigt for at opdage potentielt
uønskede afvigelser eller problemer. For at hjælpe med inspektion giver Scrum kadence i form af sine
fem events.
Inspektion muliggør tilpasning. Inspektion uden tilpasning betragtes som meningsløs. Scrum events er
designet til at fremprovokere forandring.

Tilpasning
Hvis nogle af aspekterne ved en proces afviger uden for de acceptable grænser, eller hvis det
resulterende produkt er uacceptabelt, skal den anvendte proces eller de materialer, der produceres,
justeres. Justeringen skal foretages hurtigst muligt for at minimere yderligere afvigelser.
Tilpasning bliver vanskeligere, når de involverede, ikke er bemyndiget eller selvstyrende. Et Scrum Team
forventes at tilpasse sig det øjeblik det lærer noget nyt gennem inspektion.

Scrum værdier
Vellykket brug af Scrum afhænger af, at folk bliver mere dygtige til at efterleve fem værdier:
Engagement, fokus, åbenhed, respekt og mod
Scrum Teamet forpligter sig til at nå sine mål og støtte hinanden. Deres primære fokus er på arbejdet i
Sprint for at opnå bedst mulige fremdrift mod disse mål. Scrum Teamet og dets interessenter er åbneom arbejdet og udfordringerne. Scrum Team‐medlemmer respekterer hinanden for at være dygtige,uafhængige mennesker og respekteres som sådan af de mennesker, som de arbejder sammen med.
Scrum Team‐medlemmerne har modet til at gøre det rigtige og arbejde på svære problemer.
Disse værdier giver retning til Scrum Teamet med hensyn til deres arbejde, handlinger og adfærd. De
beslutninger, der træffes, de skridt, der tages, og den måde, Scrum bruges på, bør forstærke disseværdier, ikke mindske eller underminere dem. Scrum Team‐medlemmerne lærer og udforsker
værdierne, når de arbejder med Scrum events og artifacts. Når disse værdier efterleves af Scrum Teamet
og de mennesker, de arbejder med, kommer de empiriske Scrum‐søjler; gennemsigtighed, inspektion og
tilpasning til live og der bygger tillid.

4

Scrum TeamDen grundlæggende enhed i Scrum er et lille team af mennesker, et Scrum Team. Scrum Teamet består
af en Scrum Master, Product Owner og Developers. Inden for et Scrum Team er der ingen delteams eller
hierarkier. Det er en sammenhængende enhed af fagfolk, der fokuserer på et mål ad gangen, Product
Goal.
Scrum Teams er tværfunktionelle, hvilket betyder, at medlemmerne har alle de nødvendige færdigheder
til at skabe værdi i hvert Sprint. De er også selvstyrende, hvilket betyder at de internt beslutter, hvem
der gør hvad, hvornår og hvordan.
Scrum Teamet er lille nok til at forblive adræt og stort nok til at udføre et betydeligt stykke arbejde
indenfor et Sprint, typisk 10 eller færre mennesker. Generelt har vi fundet ud af, at mindre teams
kommunikerer bedre og er mere produktive. Hvis Scrum Teams bliver for store, bør de overveje atomorganisere til flere sammenhængende Scrum Teams, der hver især har fokus på det samme produkt.
Derfor skal de dele samme Product Goal, Product Backlog og Product Owner.
Scrum Teamet er ansvarligt for alle produktrelaterede aktiviteter fra interessenters samarbejde,
verifikation, vedligeholdelse, drift, eksperimentering, forskning og udvikling samt alt andet, der måtte
være påkrævet. De er struktureret og bemyndiget af organisationen til at styre deres eget arbejde.
Arbejde i Sprints i et holdbart tempo forbedrer Scrum Teamets fokus og konsistens.
Hele Scrum Teamet er ansvarligt for at skabe et værdifuld og nyttigt Increment i hver Sprint. Scrum
definerer tre specifikke ansvar i et Scrum Team: Developers, Product Owner og Scrum Master.

Developers
Developers er de individer i Scrum Teamet, der er forpligtet til at skabe ethvert aspekt af et brugbart
Increment for hvert Sprint.
De specifikke færdigheder, som Developers har brug for, er ofte brede og varierer afhængigt af
arbejdsdomænet. Developers er dog altid ansvarlige for:●●●●Udarbejde en plan for hvert Sprint, kaldet Sprint Backlog;
Producere kvalitet ved at overholde Definition of Done;
Tilpasning af deres plan hver dag for at lede frem mod Sprint Goal; og,
At holde hinanden ansvarlig som professionelle.

5Product Owner
Product Owner er ansvarlig for at maksimere produktets værdi som er resultatet af Scrum Teams
arbejde. Hvordan dette gøres, kan variere meget på tværs af organisationer, Scrum Teams og
enkeltpersoner.
Product Owner er også ansvarlig for effektiv Product Backlog styring, hvilket inkluderer:●●●●

Udarbejdelse og eksplicit kommunikation af Product Goal;
Oprettelse og tydelig kommunikation af Product Backlog items;
Prioritering af Product Backlog items; og,
Sikring af, at Product Backlog er gennemsigtig, synlig og forstået.

Product Owner kan udføre ovenstående arbejde eller uddelegere til andre. Uanset hvad forbliver
Product Owner den ansvarlige.
For at Product Owners skal lykkes, skal hele organisationen respektere deres beslutninger. Disse
beslutninger er synlige i indholdet og prioritering af Product Backlog og gennem det inspicerbare
Increment i Sprint Review.
Product Owner er én person, ikke et udvalg. Product Owner repræsenterer muligvis mange
interessenters behov i Product Backlog. De, der ønsker at ændre Product Backlog, kan gøre det ved atprøve at overbevise Product Owner.

Scrum MasterScrum Master er ansvarlig for implentering af Scrum som defineret i Scrum Guide. De gør dette ved athjælpe alle med at forstå Scrum teori og praksis, både inden for Scrum Teamet og organisationen.
Scrum Master er ansvarlig for Scrum Teamets effektivitet. De gør dette ved at sætte Scrum Teamet istand til at forbedre sin praksis indenfor Scrum frameworket.
Scrum Masters er ægte ledere, der tjener Scrum Team og den overordnede organisation.
Scrum Master tjener Scrum Teamet på flere måder, herunder:●●●●

Coaching af teammedlemmer i selvledelse og tværfunktionalitet;Hjælpe Scrum Teamet med at fokusere på at skabe værdifulde Increments, der opfylder
Definition of Done;
Varetager fjernelse af hindringer for Scrum Teams fremskridt; og,
Sikring af at alle Scrum events finder sted og er positive, produktive og holdes indenfor
tidsbegrænsningen.

6

Scrum Master tjener Product Owner på flere måder, herunder:●●●●Hjælper med at finde teknikker til effektiv definition af Product Goal og styring af ProductBacklog;Hjælper Scrum Teamet med at forstå behovet for klare og konkrete Product Backlog items;Hjælper med at etablere empirisk produktplanlægning for et komplekst miljø; og,
Faciliterer samarbejdet blandt interessenter efter anmodning eller behov.

Scrum Master tjener organisationen på flere måder, herunder:●●●●

At lede, træne og coache organisationen i sin Scrum implementering;
Planlægning og rådgivning af Scrum‐implementeringer inden for organisationen;Hjælpe medarbejdere og interessenter med at forstå og indgå i en empirisk tilgang til komplekstarbejde; og,
Fjernelse af barrierer mellem interessenter og Scrum Teams.

Scrum Events
Sprintet indeholder alle andre events. Hver event i Scrum er en formel mulighed for at inspicere og
tilpasse Scrum artifacts. Disse events er specielt designet til at muliggøre den nødvendige
gennemsigtighed. Manglende gennemførelse af events som foreskrevet resulterer i mistede muligheder
for at inspicere og tilpasse sig. Events bruges i Scrum til at skabe regelmæssighed og til at minimere
behovet for møder, der ikke er defineret i Scrum.
Optimalt afholdes alle events på samme tid og sted for at reducere kompleksiteten.

SprintSprints er hjerteslaget i Scrum, hvor idéer bliver til værdi.
De er events med fast længde på en måned eller derunder for at skabe konsistens. Et nyt Sprint starterstraks efter afslutningen af det forrige Sprint.
Alt det arbejde, der er nødvendigt for at nå Product Goal, inklusive Sprint Planning, Daily Scrums, Sprint
Review og Sprint Retrospective, sker indenfor Sprints.
Under et Sprint:●●●●

Der foretages ingen ændringer, der vil bringe Sprint Goal i fare;
Kvaliteten falder ikke;
Product Backlog detaljeres efter behov; og,
Omfanget kan afklares og genforhandles med Product Owner, efterhånden som mere læres.
7

Sprints muliggør forudsigelighed ved at sikre inspektion og tilpasning af fremskridt hen imod et Product
Goal mindst hver kalendermåned. Når et Sprints horisont er for langt, kan Sprint Goal blive ugyldigt,
kompleksiteten kan stige, og risikoen kan øges. Kortere Sprints kan bruges til at generere flerelæringscyklusser og begrænse risikoen for omkostninger og indsats til en mindre tidsramme. Hver Sprint
kan betragtes som et kort projekt.
Der findes forskellige metoder til at forudsige fremskridt, fx burn‐downs, burn‐ups, eller cumulativeflows. Selvom det har vist sig nyttigt, erstatter disse ikke vigtigheden af empiri. I komplekse miljøer erhvad der vil ske ukendt. Kun det, der allerede er sket, kan bruges til fremadrettet beslutningstagning.
Et sprint kan blive annulleret, hvis Sprint Goal bliver forældet. Kun Product Owner har tilladelse til atannullere Sprint.

Sprint Planning
Sprint Planning starter et Sprint ved at kortlægge det arbejde, der skal udføres i løbet af Sprint. Planen
er resultatet af den samlede indsats fra hele Scrum Teamet.
Product Owner sørger for, at deltagerne er parat til at diskutere de vigtigste Product Backlog items, og
hvordan de bidrager til Product Goal. Scrum Teamet kan også invitere andre mennesker til at deltage i
Sprint Planning for at give råd.
Sprint Planning behandler følgende emner:

Emne 1: Hvorfor er dette Sprint værdifuldt?
Product Owner foreslår, hvordan produktet kan øge dets værdi og nytte i det aktuelle Sprint. Hele Scrum
Teamet samarbejder derefter om at definere et Sprint Goal, der kommunikerer, hvorfor Sprint erværdifuldt for interessenterne. Sprint Goal skal være udarbejdet inden afslutning af Sprint Planning.

Emne 2: Hvilken færdig funktionalitet leveres i dette Sprint?
Gennem diskussion med Product Owner vælger Developers items fra Product Backlog, der skal
medtages i det aktuelle Sprint. Scrum Teamet kan forfine disse emner under denne proces, hvilket øgerforståelsen og tilliden.
Det kan være udfordrende at vælge, hvor meget der kan gennemføres i et Sprint. Jo mere Developers
ved om deres tidligere præstationer, deres kommende kapacitet og deres Definition of Done, jo mere
selvsikker vil de være i deres Sprint‐prognoser.

Emne 3: Hvordan vil det valgte arbejde blive udført?

8For hvert valgt Product Backlog item planlægger Developers det arbejde, der er nødvendigt for at levere
et Increment, der opfylder Definition of Done. Dette gøres ofte ved at nedbryde Product Backlog items i
mindre opgaver på en dag eller derunder. Hvordan dette gøres, er efter Developers eget skøn. Ingen
andre fortæller dem, hvordan de kan gøre Product Backlog items til et Increment med værdi.
Sprint Goal, Product Backlog items, der er valgt til Sprint, samt planen for levering af dem betegnes
samlet for Sprint Backlog.
Sprint Planning er begrænset til maksimalt otte timer i et Sprint på en måned. For kortere Sprints er
event normalt kortere.

Daily ScrumFormålet med Daily Scrum er at inspicere fremskridt mod Sprint Goal og tilpasse Sprint Backlog efter
behov og justere det kommende planlagte arbejde.
Daily Scrum er et 15‐minutters event for Developers af Scrum Teamet. For at mindske kompleksiteten
holdes det på samme tid og sted hver arbejdsdag i Sprint’et. Hvis Product Owner eller Scrum Masteraktivt arbejder på items i Sprint Backlog, deltager de som Developers.
Developers kan vælge den struktur og de teknikker, de ønsker, så længe deres Daily Scrum fokuserer på
fremskridt mod Sprint Goal og producerer en handlingsplan for den næste arbejdsdag. Dette skaber
fokus og forbedrer selvledelsen.
Daily Scrums forbedrer kommunikationen, identificerer hindringer, fremmer hurtig beslutningstagningog fjerner derfor behovet for andre møder.
Daily Scrum er ikke den eneste gang, Developers har lov til at justere deres plan. De mødes ofte i løbet
af dagen for mere detaljerede diskussioner om tilpasning eller replanlægning af resten af Sprint
arbejdet.

Sprint ReviewFormålet med Sprint Review er at inspicere resultatet af Sprint og bestemme fremtidige tilpasninger.
Scrum Teamet præsenterer resultaterne af deres arbejde for nøgle interessenter, og fremskridt hen
imod Product Goal diskuteres.
Under dette event gennemgår Scrum Team og interessenter, hvad der blev opnået i Sprintet, og hvad
der har ændret sig i deres omgivelser. Baseret på disse oplysninger samarbejder deltagerne om, hvad deskal gøre herefter. Product Backlog kan også justeres for at imødekomme nye muligheder. Sprint Review
er en arbejdssession, og Scrum Teamet bør undgå at begrænse det til en præsentation.

9

Sprint Review er den næstsidste event i Sprint og er tidafgrænset til maksimalt fire timer i et Sprint på
en måned. For kortere sprints er event normalt kortere.

Sprint RetrospectiveFormålet med Sprint Retrospective er at planlægge måder at øge kvaliteten og effektiviteten på.
Scrum Teamet inspicerer, hvordan det seneste Sprint gik med hensyn til enkeltpersoner, interaktioner,
processer, værktøjer og deres Definition of Done. Inspicerede elementer varierer ofte med
arbejdsdomænet. Antagelser, der førte dem på afveje identificeres, og deres oprindelse undersøges.
Scrum Teamet diskuterer, hvad der gik godt under Sprintet, hvilke problemer det stødte på, og hvordan
disse problemer blev (eller ikke blev) løst.
Scrum Teamet identificerer de mest nyttige ændringer der kan forbedre dets effektivitet. De mest
effektive forbedringer løses hurtigst muligt. De kan endda føjes til Sprint Backlog til den næste Sprint.
Sprint Retrospective afslutter Sprintet. Det er tidsafgrænset til maksimalt tre timer i et en‐måneders
Sprint. For kortere sprints er event normalt kortere.

Scrum Artifacts
Scrums artifact repræsenterer arbejde eller værdi. De er designet til at maksimere gennemsigtigheden
af vigtige oplysninger. Således har alle, der inspicerer dem, det samme grundlag for tilpasning.
Hver artifact indeholder en forpligtelse til at sikre, at den giver information, der forbedrer
gennemsigtighed og fokus, som fremskridt kan måles mod:●●●For Product Backlog er det Product Goal.
For Sprint Backlog er det Sprint Goal.
For Increment er det Definition of Done.

Disse forpligtelser eksisterer for at styrke empirisme og Scrum‐værdierne for Scrum Teamet og deresinteressenter.

Product Backlog
Product Backlog er en dynamisk, ordnet liste over hvad der er nødvendigt for at forbedre produktet. Det
er den eneste kilde til arbejde, der udføres af Scrum Team.
Product Backlog items, der kan udføres af Scrum Team inden for et Sprint, anses for at være klar til valg iet Sprint Planning event. De opnår normalt denne grad af gennemsigtighed efter raffinering af items.
Product Backlog raffinering er handlingen med at nedbryde og yderligere definere Product Backlog

10

items i mindre, men mere præcise items. Dette er en løbende aktivitet for at tilføje detaljer, såsom en
beskrivelse, rækkefølge og størrelse. Attributter varierer ofte med arbejdsdomænet.
Developers, der skal udføre arbejdet, er ansvarlige for størrelsen. Product Owner kan påvirke
Developers ved at hjælpe dem med at forstå og vælge afvejninger.

Engagement: Product Goal
Product Goal beskriver en fremtidig tilstand af produktet, som kan tjene som et mål for Scrum Teamet
at planlægge hen imod. Product Goal er i Product Backlog. Resten af Product Backlog opstår for at
definere “hvad” der vil opfylde Product Goal.
Et produkt er et middel, hvorigennem der leveres værdi. Det har en klar afgrænsning, kendte
interessenter, veldefinerede brugere eller kunder. Et produkt kan være en tjeneste, et fysisk
produkt eller noget mere abstrakt.
Product Goal er det langsigtede mål for Scrum Teamet. De skal opfylde (eller opgive) et mål, inden depåtager sig det næste.

Sprint Backlog
Sprint Backlog består af Sprint Goal (hvorfor), det sæt af Product Backlog items, der er valgt til Sprint(hvad), samt en handlingsplan til levering af Increment (hvordan).
Sprint Backlog er en plan af og for Developers. Det er et meget synligt billede i realtid af det arbejde,
som Developers planlægger at udføre under et Sprint for at nå Sprint Goal. Derfor opdateres Sprint
Backlog igennem hele Sprintet, efterhånden som mere læres. Den skal have nok detaljer til, at
Developers kan inspicere deres fremskridt i Daily Scrum.

Engagement: Sprint Goal
Sprint Goal er det eneste mål for et Sprint. Selvom Sprint Goal er en forpligtelse fra Developers, giver det
fleksibilitet med hensyn til det nøjagtige arbejde, der er nødvendigt for at nå det. Sprint Goal skaberogså sammenhæng og fokus og tilskynder Scrum Teamet til at arbejde sammen snarere end om
separate initiativer.
Sprint Goal oprettes under Sprint Planning event og føjes derefter til Sprint Backlog. Mens Developers
arbejder under Sprint, holder de Sprint Goal i tankerne. Hvis arbejdet viser sig at være anderledes, end
de forventede, samarbejder de med Product Owner for at forhandle omfanget af Sprint Backlog
indenfor Sprint uden at påvirke Sprint Goal.

11

Increment
Et Increment er et konkret trin på ej mod Product Goal. Hvert Increment er et tillæg til alle tidligere
Incrementer og er grundigt verificeret og sikrer, at alle Incrementer arbejder sammen. For at give værdi
skal Increment være anvendelig.
Flere Incrementer kan oprettes i et Sprint. Summen af incrementer præsenteres på Sprint Review og
understøtter dermed empirisme. Der kan dog leveres et Increment til interessenter inden Sprint
afslutning. Sprint Review bør aldrig betragtes som en port til frigivelse af værdi.
Arbejde kan ikke betragtes som en del af et Increment, medmindre det opfylder Definition of Done.

Engagement: Definition of Done
Definition of Done er en formel beskrivelse af tilstanden af et Increment når det opfylder
kvalitetsforanstaltningerne, der kræves for produktet.
Det øjeblik et Product Backlog item tilfredsstiller Definition of Done, så svarer det til et Increment.
Definition of Done skaber gennemsigtighed ved at give alle en fælles forståelse af, hvilket arbejde der
blev afsluttet som en del af Incrementet. Hvis et Product Backlog item ikke opfylder Definition of Done,kan det ikke frigives ej heller præsenteres ved Sprint Review. I stedet returneres det til Product Backlog
til fremtidig overvejelse.
Hvis Definition of Done for et Increment er en del af organisationens standarder, skal alle Scrum Teamsfølge det som et minimum. Hvis det ikke er en organisatorisk standard, skal Scrum Teamet oprette en
Definition of Done, der er passende for produktet.
Developers skal overholde Definition of Done. Hvis der er flere Scrum Teams, der arbejder sammen om
et produkt, skal de gensidigt definere og overholde den samme Definition of Done.

12

Konklusion
Scrum er frit og stilles til rådighed i denne Guide. Scrum frameworket, som beskrevet i denne Guide er
en helhed. Selvom det er muligt at implementere dele af Scrum, så er resultatet ikke Scrum. Scrum
eksisterer kun i sin helhed og fungerer godt som en container for andre teknikker, metoder og
praktikker.

Anerkendelser
Individer
Af de tusinder af individer der har bidraget til Scrum, vil vi gerne fremhæve de der var essentielle ved
begyndelsen. Jeff Sutherland, arbejdede med Jeff McKenna og John Scumniotales, og Ken Schwaber,arbejdede med Mike Smith og Chris Martin og de arbejdede alle sammen. Mange andre har bidraget i defølgende år og uden deres hjælp ville Scrum ikke have nået så langt som det er i dag.

Scrum Guide historie
Ken Schwaber og Jeff Sutherland co‐præsenterede Scrum første gang på OOPSLA konferencen in 1995.
Denne præsentation dokumenterede den erfaring som Ken og Jeff havde opnået igennem deforegående år og offentliggjorde samtidig den første definitionen af Scrum.
Scrum Guiden dokumenterer Scrum, som er udviklet og vedligeholdt gennem mere end 30 år af Jeff
Sutherland og Ken Schwaber. Andre kilder beskriver mønstre, processer, og indsigt der komplementerer
Scrum frameworket. Disse kan optimere produktivitet, værdi, kreativitet og tilfredsstillelse ved
resultatet.
Scrum’s historie er beskrevet andetsteds. For at anerkende de første steder hvor Scrum blev afprøvet og
bevist, nævner vi her Individual, Inc., Newspage, Fidelity Investments, og IDX (nu GE Medical).

Oversætter erkendelse
Denne guide er blevet oversat fra den originale engelske version, som er stillet til rådighed af forfatternenævnt herover. Bidragsydere til oversættelsen inkluderer Stig Efsen.

Kontaktinformation
Oversætters navn: Stig EfsenPrimær kontakt email: stig.efsen@gmail.com
LinkedIn: https://www.linkedin.com/in/efsen/13Ændringer fra 2017 Scrum Guide til 2020 Scrum Guide
Endnu mindre dikterende
I årenes løb begyndte Scrum Guide at blive lidt mere dikterende. 2020‐versionen har til formål at bringe Scrum
tilbage til at være et minium, men tilstrækkeligt framework, ved at fjerne eller blødgøre det anvendte sprog. f.eks.
fjernet Daily Scrum‐spørgsmål, blødgøre sproget omkring PBI‐attributter, blødgøre sproget omkring genstande i
Sprint Backlog, forkortet Sprint stop beskrivelsen med mere.

Ét Team, fokuseret på ét ProductMålet var at eliminere konceptet om et separat team i teamet, der har ført til "proxy" eller "os og dem" adfærd
mellem Product Owner og Development Team. Der er nu kun ét Scrum Team med fokus på det samme mål med
tre forskellige sæt af ansvar: Product Owner, Scrum Master og Developers.

Introduktion af Product Goal
2020 Scrum Guiden introducerer konceptet med et Product Goal, der giver Scrum Teamet fokus på et størreværdifuldt mål. Hver Sprint skal bringe produktet tættere på det overordnede Product Goal.

A hjem for Sprint Goal, Definition of Done, and Product Goal
Tidligere Scrum Guides beskrev Sprint Goal og Definition of Done uden virkelig at give dem en identitet. De var ikke
helt artefakter, men var noget knyttet til artefakter. Med tilføjelsen af Product Goal giver 2020‐versionen mere
klarhed omkring dette. Hver af de tre artefakter indeholder nu 'forpligtelser' i sig. For Product Backlog er det
Product Goal, Sprint Backlog har Sprint Goal, og Increment har Definition of Done (nu uden citater). De findes forat bringe gennemsigtighed og fokusere mod fremskridt for hvert artefakt.

Selvstyrende og selvorganiserende
Tidligere Scrum‐guider henviste til Development Teams som selvorganiserende, der valgte, hvem og hvordan man
skulle arbejde. Med mere fokus på Scrum Teamet understreger 2020‐versionen et selvstyrende Scrum Team, dervælger hvem, hvordan og hvad man skal arbejde på.

Tre Sprint Planning emner
Ud over Sprint Planning‐emnerne "Hvad" og "Hvordan" lægger 2020 Scrum Guide vægt på et tredje emne,"Hvorfor", der henviser til Sprint Goal.

Samlet forenkling af sprog for et bredere publikum
2020 Scrum guiden har lagt vægt på at eliminere overflødige og komplekse udsagn samt fjerne enhver
tilbageværende kobling til it‐arbejde (f.eks. test, system, design, krav osv.). Scrum Guide er nu mindre end 13 sider.

14