denne HTML-version af Scrum Guide er en direkte port i November 2020-versionen tilgængelig som en PDFhere.

formålet med Scrum Guide

Vi udviklede Scrum i begyndelsen af 1990 ‘ erne. vi skrev den første version af theScrum Guide i 2010 for at hjælpe folk over hele verden med at forstå Scrum. Vi har udviklet guiden siden da gennem små, funktionelle opdateringer.Sammen står vi bag det.

Scrum-Guiden indeholder definitionen af Scrum. Hvert element i rammen tjener et specifikt formål, der er afgørende for den overordnede værdi og resultater realiseret med Scrum. Ændring af kernedesign eller ideeraf Scrum, udelader elementer eller ikke følger reglerne i Scrum,dækker over problemer og begrænser fordelene ved Scrum, hvilket potentielt endda gør det ubrugeligt.

Vi følger den voksende brug af Scrum i en stadigt voksende kompleks verden.Vi er ydmyge over at se, at Scrum bliver vedtaget på mange områder, hvor det er væsentligt komplekst arbejde, ud over produktudvikling, hvor scrum har sine rødder. Efterhånden som Scrums brug spreder sig, udfører udviklere, forskere,analytikere, forskere og andre specialister arbejdet. Vi bruger ordet” udviklere ” i Scrum for ikke at udelukke, men for at forenkle. Hvis du får værdifra Scrum, overvej dig selv inkluderet.

efterhånden som Scrum bruges, kan mønstre, processer og indsigter, der passer til de rammer, der er beskrevet i dette dokument, findes, anvendes og revideres. Deres beskrivelse er uden for formålet med Scrum Guidefordi de er kontekstfølsomme og adskiller sig meget mellem Scrum-anvendelser.Sådanne taktikker til brug inden for Scrum-rammen varierer meget og er beskrevet andetsteds.

Scrum Definition

Scrum er en letvægtsramme, der hjælper mennesker, teams ogorganisationer med at generere værdi gennem adaptive løsninger til komplekse problemer.

i en nøddeskal kræver Scrum en Scrum Master for at fremme et miljøhvor:

1. en produktejer bestiller arbejdet for et komplekst problem i en ProductBacklog.

2. Scrum-Teamet forvandler et udvalg af arbejdet til en forøgelse af værdien under en Sprint.

3. Scrum-Teamet og dets interessenter inspicerer resultaterne og justerer til næste Sprint.

4. gentag

Scrum er simpelt. Prøv det som det er, og find ud af,om dets filosofi, teori og struktur hjælper med at nå mål og skabe værdi. Scrumrammen er målrettet ufuldstændig og definerer kun de dele, der krævesat implementere Scrum teori. Scrum er bygget på af kollektivetintelligens af de mennesker, der bruger det. I stedet for at give folk detaljerede instruktioner, reglerne for Scrum styrer deres forhold og interaktioner.

forskellige processer, teknikker og metoder kan anvendes inden for rammerne. Scrum ombrydes omkring eksisterende praksis eller gør demunødvendigt. Scrum synliggør den relative effektivitet af nuværende ledelse, miljø og arbejdsteknikker, så der kan foretages forbedringer.

Scrum teori

Scrum er baseret på empirisme og lean tænkning. Empirisme hævderat viden kommer fra erfaring og træffe beslutninger baseret på hvader observeret. Lean thinking reducerer spild og fokuserer på det væsentlige.

Scrum anvender en iterativ, trinvis tilgang til optimering af forudsigelighed og kontrol af risiko. Scrum engagerer grupper af mennesker, somkollektivt har alle færdigheder og ekspertise til at udføre arbejdet og deler eller erhverver sådanne færdigheder efter behov.

Scrum kombinerer fire formelle begivenheder til inspektion og tilpasning inden for enindholdende begivenhed, sprinten. Disse begivenheder fungerer, fordi de implementerer de empiriske Scrum søjler med gennemsigtighed, inspektion, og tilpasning.

gennemsigtighed

den fremvoksende proces og arbejde skal være synlig for dem, der udfører arbejdet, såvel som dem, der modtager arbejdet. Med Scrum er vigtigebeslutninger baseret på den opfattede tilstand af dens tre formelleartifakter. Artefakter, der har lav gennemsigtighed, kan føre til beslutningerder mindsker værdien og øger risikoen.

gennemsigtighed muliggør inspektion. Inspektion uden gennemsigtighed erledende og spildt.

inspektion

Scrum-artefakterne og fremskridtene mod aftalte mål skal inspiceres ofte og flittigt for at opdage potentielt uønskede variationer eller problemer. For at hjælpe med inspektion giver Scrum kadensi form af sine fem begivenheder.

inspektion muliggør tilpasning. Inspektion uden tilpasning erbetragtes meningsløst. Scrum begivenheder er designet til at provokere forandring.

tilpasning

Hvis nogen aspekter af en proces afviger uden for acceptable grænser, eller hvis det resulterende produkt er uacceptabelt, skal den anvendte proces eller de materialer, der fremstilles, justeres. Justeringen skal foretages så hurtigt som muligt for at minimere yderligere afvigelse.

tilpasning bliver vanskeligere, når de involverede ikke ermagt eller selvforvaltende. Et Scrum-Team forventes at tilpasse øjeblikketdet lærer noget nyt gennem inspektion.

Scrum-værdier

vellykket brug af Scrum afhænger af, at folk bliver dygtigere til at leve 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å Sprintets arbejde for at gøre de bedst mulige fremskridt hen imod disse mål. Scrum-Teamet og itsstakeholders er åbne omkring arbejdet og udfordringerne. Scrum-holdkammerater respekterer hinanden for at være dygtige, uafhængige mennesker og respekteres som sådan af de mennesker, de arbejder sammen med. Scrum-holdkammeraterne har modet til at gøre det rigtige, at arbejde på toughproblems.

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 anvendes på, bør styrke disse værdier, ikke mindske eller undergrave dem. De Scrum teammedlemmer lære og udforske de værdier, somde arbejder med Scrum begivenheder og artefakter. Når disse værdier er udformet af Scrum-Teamet og de mennesker, de arbejder med, kommer empiriscrum-søjlerne for gennemsigtighed, inspektion og tilpasning til livsopbyggende tillid.

Scrum Team

den grundlæggende enhed i Scrum er et lille team af mennesker, et Scrum Team.Scrum-Teamet består af en Scrum Master, En produktejer ogudviklere. Inden for et Scrum-Team er der ingen underhold eller hierarchies.It er en sammenhængende enhed af fagfolk fokuseret på et mål ad gangen, Produktmålet.

Scrum Teams er tværfunktionelle, hvilket betyder, at medlemmerne har alle de færdigheder, der er nødvendige for at skabe værdi hver 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 smidigt og stort nok til at fuldføre et betydeligt arbejde inden for en Sprint, typisk 10 eller færre people.In generelt har vi fundet ud af, at mindre hold kommunikerer bedre og er mere produktive. Hvis Scrum-hold bliver for store, bør de overveje at omorganisere sig i flere sammenhængende Scrum-hold, der hver især fokuserer på det samme produkt. Derfor bør de dele det samme Produktmål,Produktefterslæb og produktejer.

Scrum-Teamet er ansvarlig for alle produktrelaterede aktiviteter frastakeholder-samarbejde, verifikation, vedligeholdelse, drift,eksperimentering, forskning og udvikling og alt andet, der måtte kræves. De er struktureret og bemyndiget af organisationen til at styre deres eget arbejde. At arbejde i Sprints i et bæredygtigt tempo forbedrer Scrum teamets fokus og konsistens.

hele Scrum-Teamet er ansvarlig for at skabe en værdifuld, nyttig stigning hver Sprint. Scrum definerer tre specifikke accountabilities inden for Scrum-Teamet: udviklerne, produktejeren og Scrummasteren.

udviklere

udviklere er de mennesker i Scrum-Teamet, der er forpligtet til at skabe ethvert aspekt af en brugbar stigning hver Sprint.

de specifikke færdigheder, som udviklerne har brug for, er ofte brede og vilvarierer med arbejdsområdet. Udviklerne er dog altidansvarlig for:

• oprettelse af en plan for sprinten, Sprint Backlog;

• Indstilling af kvalitet ved at overholde en Definition af udført;

• tilpasning af deres plan hver dag mod sprintmålet; og

• holder hinanden ansvarlige som fagfolk.

produktejer

produktejeren er ansvarlig for at maksimere værdien af produktetsom følge af Scrum-teamets arbejde. Hvordan dette gøres kan variere bredt på tværs af organisationer, Scrum Teams og enkeltpersoner.

produktejeren er også ansvarlig for effektiv Product Backlogmanagement, som inkluderer:

• udvikling og eksplicit kommunikation af Produktmålet;

• oprettelse og tydelig kommunikation af produkt Backlog-elementer;

• bestilling af Produktefterslæb; og

• sikring af, at Produktefterslæb er gennemsigtig, synlig og forstået.

produktejeren kan udføre ovenstående arbejde eller kan delegere ansvaret til andre. Uanset hvad forbliver ejeren af Produktetregnskab.

for at produktejere skal lykkes, skal hele organisationen respekterederes beslutninger. Disse beslutninger er synlige i indholdet og rækkefølgen af Produktefterslæb, og gennem den inspicerbare stigning på theSprint gennemgang.

produktejeren er en person, ikke et udvalg. Produktejeren kanrepræsenterer mange interessenters behov i Produktbackloggen. De, der ønsker at ændre Produktefterslæbet, kan gøre det ved at forsøge at overbevise produktejeren.

Scrum Master

Scrum Master er ansvarlig for at etablere Scrum som defineret i Scrum Guide. De gør dette ved at hjæ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 gøre det muligt for Scrum-Teamet at forbedre sin praksis inden for rammerne af Scrum.

Scrum Masters er sande ledere, der tjener Scrum Team og largerorganisation.

Scrum Master betjener Scrum-teamet på flere måder, herunder:

• Coaching af teammedlemmerne i selvledelse og tværfunktionalitet;

• hjælper Scrum-Teamet med at fokusere på at skabe stigninger med høj værdi, der opfylder definitionen af udført;

• forårsager fjernelse af hindringer for Scrum-holdets fremskridt;og

• at sikre,at alle Scrum-begivenheder finder sted og er positive, produktive og holdes inden for tidsfeltet.

Scrum Master betjener produktejeren på flere måder, herunder:

• hjælper med at finde teknikker til effektiv Produktmåldefinition og Product Backlog management;

• hjælper Scrum-Teamet med at forstå behovet for klare og kortfattede Produktefterslæb;

• hjælper med at etablere empirisk produktplanlægning for et kompleksmiljø; og

• fremme af interessentsamarbejde efter anmodning eller behov.

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

• leder, træner og coacher organisationen i sin Scrumadoption;

• planlægning og rådgivning af Scrum-implementeringer i organisationen;

• hjælper medarbejdere og interessenter med at forstå og vedtage en empirisk tilgang til komplekst arbejde; og

• fjernelse af barrierer mellem interessenter og Scrum-Teams.

Scrum Events

sprinten er en container til alle andre begivenheder. Hver begivenhed i Scrum er enformel mulighed for at inspicere og tilpasse Scrum artefakter. Disse begivenheder er specielt designet til at muliggøre den krævede gennemsigtighed. Fejl ved at drive begivenheder som foreskrevet resulterer i mistede muligheder for at inspicere og tilpasse sig. Begivenheder bruges i Scrum til at skabe regelmæssighed og tilminimere behovet for møder, der ikke er defineret i Scrum.

optimalt holdes alle arrangementer på samme tid og sted for at reducerekompleksitet.

Sprint

Sprints er hjerteslag af Scrum, hvor ideer omdannes til værdi.

de er begivenheder med fast længde på en måned eller mindre for at skabe konsistens.En ny Sprint starter umiddelbart efter afslutningen af den tidligereudskrivning.

alt det arbejde, der er nødvendigt for at nå Produktmålet, herunder SprintPlanning, Daily Scrums, Sprint anmeldelse og Sprint retrospektiv, sker inden for Sprints.

under sprinten:

• der foretages ingen ændringer, der ville bringe sprintmålet i fare;

• kvalitet falder ikke;

• Produktefterslæb raffineres efter behov; og

• omfang kan afklares og genforhandles med produktejeren asmore læres.

Sprints muliggør forudsigelighed ved at sikre inspektion og tilpasning affremskridt mod et Produktmål mindst hver kalendermåned. Når asprints horisont er for lang, kan sprintmålet blive ugyldigt, kompleksiteten kan stige, og risikoen kan stige. Kortere Sprints kan bruges til at generere flere læringscyklusser og begrænse risikoen for omkostninger og indsats til en mindre tidsramme. Hver Sprint kan betragtes som en kortprojekt.

Der findes forskellige fremgangsmåder til at forudsige fremskridt, som f.eks. Selvom det er bevist nyttigt, erstatter disse ikkebetydning af empirisme. I komplekse miljøer er hvad der vil skeukendt. Kun det, der allerede er sket, kan bruges til fremadrettede beslutningerafgørelse.

en Sprint kan annulleres, hvis sprintmålet bliver forældet. Kunproduktejeren har beføjelse til at annullere sprinten.

sprintplanlægning

sprintplanlægning indleder sprinten ved at lægge det arbejde, der skal udføres til sprinten. Denne resulterende plan er oprettet afsamarbejdsarbejde i hele Scrum-Teamet.

produktejeren sikrer, at deltagerne er parate til at diskutere de vigtigste Produktefterslæb-emner, og hvordan de kortlægger til Produktmålet. Scrum-Teamet kan også invitere andre til at deltage i SprintPlanning for at give råd.

sprintplanlægning behandler følgende emner:

emne et: Hvorfor er denne Sprint værdifuld?

produktejeren foreslår, hvordan produktet kan øge dets værdi ognyttighed i den nuværende Sprint. Hele Scrum-Teamet samarbejder derefter for at definere et sprintmål, der kommunikerer, hvorfor sprinten er værdifuld for Tok holders. Sprintmålet skal afsluttes inden afslutningen afprintplanlægning.

emne To: hvad kan der gøres denne Sprint?

gennem diskussion med produktejeren vælger udviklerne varerfra Produktefterslæbet, der skal medtages i den aktuelle Sprint. ScrumTeam kan forfine disse elementer under denne proces, hvilket øger forståelsen og tilliden.

det kan være udfordrende at vælge, hvor meget der kan gennemføres inden for en Sprint.Men jo mere udviklerne ved om deres tidligere præstationer,deres kommende kapacitet og deres Definition af færdig, jo mereoverbevist vil de være i deres Sprintprognoser.

emne tre: Hvordan bliver det valgte arbejde udført?

for hvert valgt produkt Backlog-element planlægger udviklerne arbejdetnødvendigt for at oprette et trin, der opfylder definitionen af udført. Dette gøres ofte ved at nedbryde Produktefterslæb til mindre arbejdsemner på en dag eller mindre. Hvordan dette gøres er efter eget skønudviklerne. Ingen andre fortæller dem, hvordan man kan slå Product Backlog itemsinto stigninger i værdi.

sprintmålet, de Produktefterslæb, der er valgt til sprinten, plusplanen for levering af dem kaldes sammen SprintBacklog.

sprintplanlægning er tidsbegrænset til maksimalt otte timer i en månedsprint. For kortere Sprints er begivenheden normalt kortere.

Daily Scrum

formålet med Daily Scrum er at inspicere fremskridt mod SprintGoal og tilpasse Sprint Backlog efter behov, justere det kommende planlagte arbejde.

Daily Scrum er en 15-minutters begivenhed for udviklerne af ScrumTeam. For at reducere kompleksiteten holdes den på samme tid og placeres hverarbejdsdag i sprinten. Hvis produktejeren eller Scrum Master aktivt arbejder på emner i Sprint Backlog, deltager de somudviklere.

udviklerne kan vælge den struktur og de teknikker,de ønsker, så længe deres daglige Scrum fokuserer på fremskridt mod Sprint-Måletog producerer en handlingsplan for den næste arbejdsdag. Dette skaber fokus og forbedrer selvforvaltningen.

Daily Scrums forbedrer kommunikationen, identificerer hindringer, fremmer hurtig beslutningstagning og eliminerer derfor behovet for andre møder.

Daily Scrum er ikke den eneste gang udviklere får lov til at justerederes plan. De mødes ofte hele dagen for mere detaljeretdiskussioner om tilpasning eller omplanlægning af resten af sprintens arbejde.

Sprint anmeldelse

formålet med Sprint anmeldelse er at inspicere resultatet af Sprintog bestemme fremtidige tilpasninger. Scrum-teamet præsenterer resultaterne af deres arbejde for vigtige interessenter, og fremskridt hen imod Produktmålet diskuteres.

under arrangementet gennemgår Scrum-Teamet og interessenterne, hvad der var afsluttet i sprinten, og hvad der har ændret sig i deres miljø.Baseret på disse oplysninger samarbejder deltagerne om, hvad de skal gøre næste gang. Produktefterslæbet kan også tilpasses for at imødekomme nye muligheder. TheSprint-gennemgang er en arbejdssession, og Scrum-Teamet bør undgåbegrænser det til en præsentation.

Sprintanmeldelsen er den næstsidste begivenhed i sprinten og istimboks til maksimalt fire timer i en måneds Sprint. For shorterSprints er begivenheden normalt kortere.

Sprint Retrospective

formålet med Sprint Retrospective er at planlægge måder at øgekvalitet og effektivitet.

Scrum-Teamet inspicerer, hvordan den sidste Sprint gik med hensyn til enkeltpersoner, interaktioner, processer, værktøjer og deres Definition af done. Inspicerede elementer varierer ofte med arbejdsområdet. Antagelser, der førte dem på afveje, identificeres, og deres oprindelse udforskes. Detcrum Team diskuterer, hvad der gik godt under sprinten, hvilke problemer det stødte på, og hvordan disse problemer blev (eller ikke blev) løst.

Scrum-Teamet identificerer de mest nyttige ændringer for at forbedre dets effektivitet. De mest effektive forbedringer behandles så hurtigt sommuligt. De kan endda blive tilføjet til Sprint Backlog for det næstesprint.

sprinten retrospektiv afslutter sprinten. Det er timebokset til enmaksimum på tre timer for en måneds Sprint. For kortere Sprints, denbegivenheden er normalt kortere.

Scrum Artifacts

Scrums artefakter repræsenterer arbejde eller værdi. De er designet til at maksimeregennemsigtighed af nøgleinformation. Således har alle, der inspicerer demsamme grundlag for tilpasning.

hver artefakt indeholder en forpligtelse til at sikre, at den giver information, der forbedrer gennemsigtighed og fokus, som fremskridt kan måles mod:

• for Produktefterslæbet er det Produktmålet.

• for Sprint Backlog er det Sprint mål.

• for stigningen er det definitionen af udført.

disse forpligtelser eksisterer for at styrke empirisme og Scrum-værdierne for Scrum-Teamet og deres interessenter.

Product Backlog

Product Backlog er en emergent, bestilt liste over, hvad der er nødvendigt forforbedre produktet. Det er den eneste kilde til arbejde, der udføres afcrum Team.

produkt Backlog elementer, der kan gøres af Scrum Team inden oneSprint anses klar til udvælgelse i en Sprint planlægning begivenhed. De opnår normalt denne grad af gennemsigtighed efter raffinering.Produkt Backlog raffinement er den handling at nedbryde og videredefinere produkt Backlog elementer i mindre mere præcise elementer. 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 arbejdsområdet.

de udviklere, der vil gøre arbejdet, er ansvarlige for thesising. Produktejeren kan påvirke udviklerne ved at hjælpe demforstå og vælg afvejninger.

forpligtelse: Produktmål

Produktmålet beskriver en fremtidig tilstand af produktet, som kan tjene som et mål for Scrum-Teamet at planlægge imod. Produktmålet er iproduktefterslæb. Resten af Produktefterslæbet fremkommer for at definere”hvad” vil opfylde Produktmålet.

et produkt er et køretøj til at levere værdi. Det har en klar grænse, kendte interessenter, veldefinerede brugere eller kunder. Et produkt kunne være en tjeneste, et fysisk produkt eller noget mere abstrakt.

Produktmålet er det langsigtede mål for Scrum-Teamet. Deskal opfylde (eller opgive) et mål, før de påtager sig det næste.

Sprint Backlog

Sprint Backlog er sammensat af sprintmålet (hvorfor), Sættet afproduktefterslæb elementer valgt til sprinten (hvad) samt anaktionerbar plan for levering af stigningen (hvordan).Sprint Backlog er en plan af og for udviklerne. Det er et meget synligt, realtidsbillede af det arbejde, som udviklerne planlægger at gennemføre under sprinten for at nå sprintmålet.Derfor er Sprint Backlog opdateret i hele Sprint asmore er lært. Det skal have nok detaljer, at de kan inspicerederes fremskridt i Daily Scrum.

forpligtelse: sprintmål

sprintmålet er det eneste mål for sprinten. Selvom printmålet er en forpligtelse fra udviklerne, giver det fleksibilitetmed hensyn til det nøjagtige arbejde, der er nødvendigt for at nå det. Sprintmålet skaber også sammenhæng og fokus og tilskynder Scrum-Teamet til at arbejde sammen snarere end på separate initiativer.

sprintmålet oprettes under Sprintplanlægningsbegivenheden og tilføjes derefter til Sprint Backlog. Da udviklerne arbejder under sprinten,holder de sprintmålet i tankerne. Hvis arbejdet viser sig at være anderledesend de forventede, samarbejder de med produktejeren om at forhandle omfanget af Sprint Backlog inden for sprinten uden at påvirke printmålet.

forøgelse

en stigning er en konkret springbræt mod Produktmålet. Everyincrement er additiv til alle tidligere trin og grundigt verificeret,hvilket sikrer, at alle trin fungerer sammen. For at give værdi skal stigningen være anvendelig.

flere trin kan oprettes inden for en Sprint. Summen af de stigninger præsenteres ved Sprintanmeldelsen og understøtter således empirisme.Der kan dog leveres en stigning til interessenterne inden slutningen af sprinten. Sprintanmeldelsen bør aldrig betragtes som en port tilfrigivelsesværdi.

arbejde kan ikke betragtes som en del af en stigning, medmindre det opfylder definitionen af udført.

forpligtelse: Definition af udført

definitionen af udført er en formel beskrivelse af tilstanden af stigningen, når den opfylder de kvalitetsforanstaltninger, der kræves for produktet.

i det øjeblik et produkt efterslæb element opfylder definitionen af udført, anIncrement er født.

definitionen af udført skaber gennemsigtighed ved at give alle en fælles forståelse af, hvilket arbejde der blev afsluttet som en del af stigningen. Hvis en Product Backlog-vare ikke opfylder definitionen afgjort, kan den ikke frigives eller endda præsenteres ved Sprintanmeldelsen.I stedet vender den tilbage til Produktefterslæbet til fremtidig overvejelse.

Hvis definitionen af Udført for en stigning er en del af organisationens standarder, skal alle Scrum-hold følge det som et minimum. Hvis det ikke er en organisatorisk standard, skal Scrum-Teamet oprette en definition, der er udført passende for produktet.

udviklerne skal overholde definitionen af udført. Hvis der er flere Scrum-Teams, der arbejder sammen om et produkt, de skalgensidigt definere og overholde den samme Definition af udført.

slutnote

Scrum er gratis og tilbydes i denne vejledning. Scrum-rammen, som beskrevet heri, er uforanderlig. Mens det kun er muligt at implementere dele af Scrum, er resultatet ikke Scrum. Scrum eksisterer kun i sin helhed og fungerer som en beholder til andre teknikker, metoder og praksis.

anerkendelser

mennesker

af de tusinder af mennesker, der har bidraget til Scrum, skal vi fremhæve dem, der var medvirkende i starten: Jeff Sutherland arbejdede sammen med Jeff McKenna og John Scumniotales, og Ken Schvaber arbejdede sammen med Mike Smith og Chris Martin, og alle arbejdede sammen. Mange andre bidrog i de efterfølgende år, og uden deres hjælp ville Scrum ikke blive raffineret som det er i dag.

Scrum Guide History

Ken Schvaber og Jeff Sutherland præsenterede først Scrum på OOPSLAConference i 1995. Det dokumenterede i det væsentlige den læring, som Ken andJeff fik i løbet af de foregående par år, og offentliggjorde den første formaldefinition af Scrum.Scrum-Guiden dokumenterer Scrum som udviklet, udviklet og opretholdt i mere end 30 år af Jeff Sutherland og Ken Schvaber. Andre kilder giver mønstre, processer og indsigter, der supplerer Scrum-rammen.Disse kan øge produktivitet, værdi, kreativitet og tilfredshed med resultaterne.

den komplette historie af Scrum er beskrevet andetsteds. For at ære de førstesteder, hvor det blev prøvet og bevist, anerkender vi Individual Inc.F. eks.er der tale om en ny form for forskning og udvikling.

denne publikation udbydes til licens under AttributionShare-Alike licens af Creative Commons, tilgængelige athttps://creativecommons.org/licenser/BY-sa/4.0/legalcode og ogsåbeskrevet i summarisk form athttps://creativecommons.org/licenser/by-sa/4.0/. Ved at bruge denne ScrumGuide, Du anerkender og accepterer, at du har læst og accepterer at være bundet af betingelserne i Attribution Share-Alike-licensen for CreativeCommons.