DENNE HTML-versjonen av Scrum Guide er en direkte port av November 2020-versjonen tilgjengelig Som En Pdfher.

Formålet Med Scrum Guide

Vi utviklet Scrum tidlig på 1990-tallet. vi skrev den første versjonen av Thescrum Guide i 2010 for å hjelpe folk over hele Verden å forstå Scrum. Vi har utviklet Guiden siden da gjennom små, funksjonelle oppdateringer.Sammen står vi bak det.

Scrum-Guiden inneholder definisjonen Av Scrum. Hvert element i rammen tjener et bestemt formål som er avgjørende for totalverdien og resultatene realisert med Scrum. Å endre kjernedesignet Eller ideene Til Scrum, utelate elementer,eller ikke følge reglene For Scrum, dekker problemer og begrenser fordelene Med Scrum, noe som potensielt gjør Det ubrukelig.Vi følger den voksende bruken Av Scrum i en stadig voksende kompleks verden.Vi er ydmyke for Å se Scrum blir vedtatt i mange domener som holder i hovedsak komplisert arbeid, utover programvareproduktutvikling hvor scrum har sine røtter. Som Scrum bruk sprer seg, utviklere, forskere, analytikere, forskere og andre spesialister gjør arbeidet. Vi bruker ordet»utviklere» I Scrum for ikke å utelukke, men for å forenkle. Hvis du får valuefra Scrum, anser deg selv inkludert.

Som Scrum blir brukt, mønstre, prosesser og innsikt som passer theScrum rammeverk som beskrevet i dette dokumentet, kan bli funnet, anvendt anddevised. Deres beskrivelse er utenfor formålet Med Scrum Guidebecause de er kontekstavhengig og varierer mye Mellom Scrum bruker.Slike taktikker for bruk innenfor Scrum-rammen varierer mye og er beskrevet andre steder.

Scrum Definition

Scrum Er et lett rammeverk som hjelper mennesker, lag og organisasjoner til å generere verdi gjennom adaptive løsninger for komplekse problemer.

I et nøtteskall Krever Scrum En Scrum Master for å fremme et miljøhvor:

1. En Produkteier bestiller arbeidet for et komplekst problem i En ProductBacklog.

2. Scrum-Teamet gjør et utvalg av arbeidet til En Økning av verdien under En Sprint.

3. Scrum-Teamet og dets interessenter inspiserer resultatene og justerer for neste Sprint.

4. Gjenta

Scrum er enkelt. Prøv det som det er og avgjøre om filosofien, teorien og strukturen bidrar til å oppnå mål og skape verdi. Scrumframework er målrettet ufullstendig, bare definere delene som kreveså implementere Scrum teori. Scrum er bygget på av kollektivetintelligens av de som bruker den. Snarere enn å gi folk meddetaljerte instruksjoner, reglene For Scrum veilede sine relasjoner andinteractions.

Ulike prosesser, teknikker og metoder kan benyttes innenfor rammen. Scrum wraps rundt eksisterende praksis eller gjør demunødvendig. Scrum synliggjør den relative effekten av currentmanagement, miljø og arbeidsteknikker, slik at forbedringer kan gjøres.

Scrum Theory

Scrum er basert på empirisme og lean tenkning. Empirisme påstårat kunnskapen kommer fra erfaring og tar beslutninger basert på hvaer observert. Lean thinking reduserer avfall og fokuserer på det viktigste.

Scrum benytter en iterativ, inkrementell tilnærming for å optimere forutsigbarhet og for å kontrollere risiko. Scrum engasjerer grupper av mennesker somkollektivt har alle ferdigheter og kompetanse til å gjøre arbeidet og shareor tilegne seg slike ferdigheter etter behov.

Scrum kombinerer fire formelle arrangementer for inspeksjon og tilpasning innen acontaining hendelse, Sprint. Disse hendelsene fungerer fordi de implementerer de empiriske Scrum-pilarene for åpenhet, inspeksjon og tilpasning.

Transparency

den fremvoksende prosessen og arbeidet må være synlig for de som utfører arbeidet, så vel som de som mottar arbeidet. Med Scrum, viktigbeslutninger er basert på den oppfattede tilstanden til sine tre formaleartifakter. Gjenstander som har lav gjennomsiktighet kan føre til beslutninger som reduserer verdien og øker risikoen.

Gjennomsiktighet muliggjør inspeksjon. Inspeksjon uten gjennomsiktighet ermisledende og sløsing.

Inspeksjon

scrum artefakter og fremdriften mot avtalte mål må inspiseres ofte og flittig for å oppdage potensielt uønskede variasjoner eller problemer. For å hjelpe med inspeksjon, Gir Scrum kadensi form av sine fem hendelser.

Inspeksjon muliggjør tilpasning. Inspeksjon uten tilpasning eranses meningsløst. Scrum hendelser er designet for å provosere endring.

Tilpasning

hvis noen aspekter av en prosess avviker utenfor akseptable grenser eller hvis det resulterende produktet er uakseptabelt, må prosessen som brukes eller materialene som produseres justeres. Justeringen må gjøresså snart som mulig for å minimere ytterligere avvik.

Tilpasning blir vanskeligere når de involverte ikke er bemyndiget eller selvstyrende. Et Scrum-Team forventes å tilpasse øyeblikketdet lærer noe nytt gjennom inspeksjon.

Scrum Verdier

Vellykket Bruk Av Scrum avhenger av at folk blir dyktigere i å leve fem verdier:

Engasjement, Fokus, Åpenhet, Respekt og Mot

Scrum-Teamet forplikter seg til å nå sine mål og å støtte hverandre. Deres primære fokus er På Sprintens arbeid for å gjøre det bestemulig fremgang mot disse målene. Scrum-Teamet og itsstakeholders er åpne om arbeidet og utfordringene. Scrum-Teammedlemmer respekterer hverandre for å være dyktige, uavhengige mennesker, og errespektert som sådan av de menneskene de jobber med. Scrum-Teammedlemmene har motet til å gjøre det rette, å jobbe med toughproblems.

disse verdiene gir Retning Til Scrum-Teamet med hensyn til deres arbeid, handlinger og oppførsel. Beslutningene som tas, trinnene som tas og måten Scrum brukes på, bør styrke disse verdiene, ikke redusere eller underminere dem. Scrum Teammedlemmene lære og utforske verdiene somde jobber Med Scrum hendelser og gjenstander. Når disse verdiene er legemliggjort Av Scrum-Teamet og menneskene de jobber med, kommer de empiriske krumpilarene av åpenhet, inspeksjon og tilpasning til livsbyggende tillit.

Scrum Team

den grunnleggende enheten I Scrum er et Lite team av mennesker, Et Scrum Team.Scrum-Teamet består av En Scrum Master, En Produkteier og utviklere. Innenfor Et Scrum-Team er det ingen undergrupper eller hierarchies.It er en sammenhengende enhet av fagfolk fokusert på ett mål om gangen, Produktmålet.

Scrum Team er tverrfunksjonelle, noe som betyr at medlemmene har alle ferdigheter som er nødvendige for å skape verdi hver Sprint. De er også selvstyrende, noe som betyr at de internt bestemmer hvem som gjør hva, når og hvordan.

Scrum Teamet er liten nok til å forbli kvikk og stor nok til å fullføre betydelig arbeid innenfor En Sprint, vanligvis 10 eller færre people.In generelt har vi funnet ut at mindre lag kommuniserer bedre og ermer produktive. Hvis Scrum-Lag blir for store, bør de vurdereorganisere seg i flere sammenhengende Scrum-Lag, hver fokusert på det samme produktet. Derfor bør de dele Samme Produkt Mål, Produkt Backlog Og Produkteier.

Scrum-Teamet er ansvarlig for alle produktrelaterte aktiviteter fra samarbeid, verifisering, vedlikehold,drift, eksperimentering, forskning og utvikling, og alt annet som kan være nødvendig. De er strukturert og bemyndiget av organisasjonen tiladministrere sitt eget arbeid. Å jobbe I Sprint i et bærekraftig tempo forbedrer Scrum-Teamets fokus og konsistens.

Hele Scrum-Teamet er ansvarlig for å skape en verdifull, nyttig økning i Hver Sprint. Scrum definerer tre spesifikke regnskap innenfor Scrum-Teamet: Utviklerne, Produkteieren og ScrumMaster.

Utviklere

Utviklere Er menneskene I Scrum-Teamet som er forpliktet til å skape ethvert aspekt av en brukbar Økning hver Sprint.

de spesifikke ferdighetene Som Trengs Av Utviklerne, er ofte brede og vil variere med arbeidets domene. Men Utviklerne er alltidcountable for:

• Opprette en plan For Sprint, Sprint Backlog;

• Instilling kvalitet ved å følge En Definisjon Av Ferdig;

• Tilpasse sin plan hver dag mot Sprint Mål; og,

• Holde hverandre ansvarlig som fagfolk.

Produkteier

Produkteieren er ansvarlig for å maksimere verdien av productresulting fra arbeidet Til Scrum-Teamet. Hvordan dette gjøres kan variere på tvers av organisasjoner, Scrum-Lag og enkeltpersoner.

Produkteieren er også ansvarlig for effektiv Produkt Backlogmanagement, som inkluderer:

• Utvikle og eksplisitt kommunisere Produktmålet;

• Opprette og tydelig kommunisere Produkt Backlog elementer;

• Bestille Produkt Backlog elementer; Og,

• Sikre At Produktet Backlog er gjennomsiktig, synlig andforstått.

Produkteieren kan gjøre arbeidet ovenfor eller kan delegere ansvaret til andre. Uansett forblir Produkteierenansvarlig.

For At Produkteiere skal lykkes, må hele organisasjonen respektere deres beslutninger. Disse beslutningene er synlige i innholdet og rekkefølgen Av Produktkøen, og gjennom Den inspiserbare Økningen på theSprint Review.

Produkteieren er en person, ikke en komite. Produkteieren kanrepresenterer behovene til mange interessenter i Produktbackloggen. Thosewanting å endre Produkt Backlog kan gjøre det ved å prøve å overbevise Produkteieren.

Scrum Master

Scrum Master er ansvarlig for å etablere Scrum som definert i scrum Guide. De gjør dette ved å hjelpe alle å forstå Scrum theoryand praksis, både Innenfor Scrum Team og organisasjonen.

Scrum Master er ansvarlig for Scrum-Teamets effektivitet. De gjør dette ved å gjøre Det Mulig For Scrum-Teamet å forbedre sin praksis, innenfor scrum-rammen.

Scrum Masters er sanne ledere som tjener Scrum-Teamet og størreorganisasjonen.

Scrum-Mesteren tjener Scrum-Teamet på flere måter, inkludert:

• Coaching teammedlemmene i selvledelse og cross-funksjonalitet;

• Hjelper Scrum-Teamet med å fokusere på å skape Høyverdige Trinn som møter Definisjonen Av Ferdig;

• Forårsaker fjerning av hindringer For Scrum-Lagets fremgang;og

• sikre at alle scrum-hendelser Finner Sted og er positive, Produktive og holdt innenfor timebox.

Scrum Master tjener Produkteieren på flere måter, inkludert:

• Hjelper med å finne teknikker for effektiv produktmåldefinisjon og produktreservehåndtering;

• Hjelper Med å etablere empirisk produktplanlegging for et kompleksmiljø; og

  li>

• tilrettelegge interessentsamarbeid som forespurt Eller Nødvendig.

Scrum Master serverer organisasjonen på flere måter, inkludert:

• Ledende, opplæring og coaching organisasjonen I Sin Scrumadoption;

• Planlegging Og rådgivning Scrum implementeringer i organisasjonen;

• Hjelpe ansatte og interessenter forstå og vedta en empirisk tilnærming for komplisert arbeid; Og,

• Fjerne barrierer mellom interessenter og Scrum Team.

Scrum Hendelser

Sprinten er en beholder for alle andre hendelser. Hver hendelse I Scrum er enformell mulighet til å inspisere Og tilpasse Scrum artefakter. Disse arrangementene er spesielt utviklet for å muliggjøre gjennomsiktigheten som kreves. Å operere hendelser som foreskrevet resulterer i tapte muligheter til å inspisere og tilpasse seg. Hendelser brukes I Scrum for å skape regelmessighet og for å minimere behovet for møter som ikke er definert i Scrum.

Optimalt holdes alle hendelser samtidig og sted for å reduserekompleksitet.

Sprint

Sprint er hjertet Av Scrum, hvor ideer blir omgjort til verdi.

de er faste lengdehendelser på en måned eller mindre for å skape konsistens.En ny Sprint starter umiddelbart etter avslutningen av den forrigeprint.

Alt arbeidet som er nødvendig for Å oppnå Produktmålet, inkludert SprintPlanning, Daily Scrums, Sprint Review og Sprint Retrospective, skjer innen Sprint.

Under Sprinten:

• Det gjøres Ingen endringer som vil sette Sprintmålet i fare;

• Kvaliteten reduseres ikke;

• Produktbackloggen blir raffinert etter behov; og

• Omfang kan avklares og reforhandles med Produkteieren asmore er lært.

Sprints muliggjør forutsigbarhet ved å sikre inspeksjon og tilpasning av fremgang mot Et Produktmål minst hver kalendermåned. Når asprints horisont er for lang, Kan Sprintmålet bli ugyldig, kompleksiteten kan stige, og risikoen kan øke. Kortere Sprints kan beemployed å generere flere læringssykluser og begrense risikoen for kostnad og innsats til en mindre tidsramme. Hver Sprint kan betraktes som en kortprosjekt.

Det Finnes ulike metoder for å forutsi fremgang, som nedbrenning, oppbrenning eller kumulative strømmer. Mens bevist nyttig, erstatter disse ikkebetydningen av empirisme. I komplekse miljøer, hva som vil skje erukjent. Bare det som allerede har skjedd, kan brukes til fremtidsbeslutning.

En Sprint kan bli kansellert dersom Sprintmålet blir foreldet. Bareprodukteieren har myndighet til å avbryte Sprinten.

Sprintplanlegging

Sprintplanlegging initierer Sprinten ved å legge ut arbeidet som skal utføres For Sprinten. Denne resulterende planen er opprettet avsamarbeid av hele Scrum-Teamet.

Produkteieren sørger for at deltakerne er forberedt på å diskutere de viktigste Produktene Og hvordan de tilordner Til Produktmålet. Scrum-Teamet kan også invitere andre til Å delta På SprintPlanning for å gi råd.

Sprintplanlegging adresserer følgende emner:

Emne En: Hvorfor er Denne Sprinten verdifull?

Produkteieren foreslår hvordan produktet kan øke verdien og nytten i dagens Sprint. Hele Scrum-Teamet samarbeider da med å definere Et Sprintmål som kommuniserer hvorfor Sprinten er verdifull for å holde. Sprint Målet må være ferdig før slutten avsprint Planlegging.

Emne To: Hva Kan Gjøres Denne Sprinten?

Gjennom diskusjon Med Produkteieren, Utviklerne velger itemsfrom Produktet Backlog å inkludere i dagens Sprint. ScrumTeam kan forfine disse elementene under denne prosessen, noe som øker forståelsen og tilliten.

Å Velge hvor mye som kan fullføres I En Sprint kan være utfordrende.Men jo mer Utviklerne vet om deres tidligere ytelse, deres kommende kapasitet og Deres Definisjon Av Ferdig, desto mer selvsikker vil De være i Sprintprognosene.

Emne Tre: Hvordan vil det valgte arbeidet bli gjort?

For hvert valgt Produkt Backlog element, Utviklerne planlegge worknecessary å lage En Økning som oppfyller Definisjonen Av Ferdig. Thisis ofte gjøres ved å dekomponere Produkt Backlog elementer i mindre workitems av en dag eller mindre. Hvordan dette gjøres er etter eget skjønn Avutviklerne. Ingen andre forteller dem hvordan å slå Produkt Backlog itemsinto Verdiøkninger.

Sprint Målet, Produkt Backlog elementer valgt For Sprint, plusplanen for å levere dem er sammen referert til Som SprintBacklog.Sprintplanlegging er tidsbokset til maksimalt åtte timer for en månedsprint. For kortere Sprints er arrangementet vanligvis kortere.

Daily Scrum

Formålet Med Daily Scrum er å inspisere fremdriften mot Sprintmål og tilpasse Sprintetterslepet etter behov, justere det kommende planlagte arbeidet.The Daily Scrum Er en 15-minutters hendelse for Utviklerne Av ScrumTeam. For å redusere kompleksiteten holdes den på samme tid og sted hverarbeidsdag I Sprinten. Hvis Produkteieren eller Scrum Master eraktivt arbeider med elementer I Sprint Backlog, deltar de asDevelopers.Utviklerne kan velge hvilken struktur og teknikker de vil ha, så lenge Deres Daglige Scrum fokuserer på fremgang mot Sprintmålet Og produserer en handlingsplan for neste arbeidsdag. Dette skaper fokus og forbedrer selvforvaltning.Daglige Scrums forbedrer kommunikasjon, identifiserer hindringer, fremmer rask beslutningsprosess og eliminerer dermed behovet for andre møter.Den Daglige Scrum Er Ikke den eneste Gangen Utviklere har lov til å justerederes plan. De møtes ofte hele dagen for mer detaljertdiskusjoner om tilpasning eller omplanlegging av Resten Av Sprintens arbeid.

Sprint Gjennomgang

formålet Med Sprint Gjennomgang er å inspisere utfallet Av Sprint Og bestemme fremtidige tilpasninger. Scrum-Teamet presenterer resultatene av deres arbeid til viktige interessenter og fremgang mot Produktmålet er diskutert.

Under arrangementet vurderer Scrum-Teamet og interessenter hva Som var fullført I Sprinten og hva som har endret seg i deres miljø.Basert på denne informasjonen samarbeider deltakerne om hva de skal gjøre videre. Produktreserven kan også justeres for å møte nye muligheter. TheSprint Review Er en arbeidsøkt, Og Scrum-Teamet bør unngå å begrense det til en presentasjon.Sprint Gjennomgang Er den nest siste hendelsen I Sprinten og istimeboxed til maksimalt fire timer for en måneds Sprint. For shortsprints er arrangementet vanligvis kortere.

Sprint Retrospective

formålet Med Sprint Retrospektivet er å planlegge måter å økekvalitet og effektivitet.

Scrum-Teamet inspiserer hvordan Den siste Sprinten gikk med hensyn til enkeltpersoner, interaksjoner, prosesser, verktøy og Deres Definisjon av done. Inspiserte elementer varierer ofte med arbeidets domene. Antagelsersom førte dem vill er identifisert og deres opprinnelse utforsket. TheScrum-Teamet diskuterer hva som gikk bra under Sprinten, hvilke problemer det møtte, og hvordan disse problemene ble (eller ikke) løst.

Scrum-Teamet identifiserer de mest nyttige endringene for å forbedre sineffektivitet. De mest effektive forbedringene tas opp så snart sommulig. De kan også bli lagt Til Sprint Backlog for nextSprint.

Sprint Retrospektiv avslutter Sprint. Det er timeboxed til amaksimalt tre timer for en måneds Sprint. For kortere Sprints er hendelsen vanligvis kortere.

Scrum Artefakter

Scrum artefakter representerer arbeid eller verdi. De er designet for å maksimeregjennomsiktighet av nøkkelinformasjon. Dermed har alle som inspiserer demsamme grunnlag for tilpasning.

hver artefakt inneholder en forpliktelse til å sikre at den gir informasjon som forbedrer åpenhet og fokus mot hvilken fremgang kan måles:

• For Produktetterslepet er Det Produktmålet.

• For Sprint Backlog er Det Sprint Målet.

• For Økningen Er Det Definisjonen Av Ferdig.

disse forpliktelsene eksisterer for å styrke empirisme og Scrum-verdiene for Scrum-Teamet og deres interessenter.

Product Backlog

Product Backlog er en fremvoksende, bestilt liste over hva som trengs for å forbedre produktet. Det er den eneste kilden til arbeid utført av theScrum-Teamet.

Produkter som Kan Gjøres Av Scrum-Teamet innen oneSprint, anses som klare for valg i En Sprintplanleggingshendelse. Deoppnå vanligvis denne grad av gjennomsiktighet etter raffinering.Produkt Backlog raffinement er lov å bryte ned og furtherdefining Produkt Backlog elementer i mindre mer presise elementer. Dette er en pågående aktivitet for å legge til detaljer, for eksempel en beskrivelse, ordre og størrelse. Attributter varierer ofte med arbeidets domene.

Utviklerne som skal gjøre arbeidet er ansvarlig for thesizing. Produkteieren kan påvirke Utviklerne ved å hjelpe demforstå og velg avveier.

Forpliktelse: Produktmål

Produktmålet beskriver en fremtidig tilstand av produktet som kan tjene som et mål For Scrum-Teamet å planlegge mot. Produktet Målet er inthe Produktet Backlog. Resten av Produktbackloggen kommer frem til å definere » hva » vil oppfylle Produktmålet.

et produkt er et redskap for å levere verdi. Den har en klar grense, kjente interessenter, veldefinerte brukere eller kunder. Et produkt kunne 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) ett mål før de tar på seg det neste.

Sprint Backlog

Sprint Backlog er sammensatt Av Sprint Målet (hvorfor), settet av produkt Backlog elementer valgt For Sprint (hva), samt anactionable plan for å levere Tilveksten (hvordan).

Sprint Backlog er en plan av Og For Utviklerne. Det er et høytsynlig, sanntidsbilde av arbeidet Som Utviklerne planlegger åkomplisere Under Sprinten for Å oppnå Sprintmålet.Følgelig er Sprint Backlog oppdatert gjennom Sprinten asmore er lært. Det bør ha nok detaljer som de kan inspiserederes fremgang I Den Daglige Scrum.

Forpliktelse: Sprintmål

Sprintmålet er det eneste målet for Sprinten. Selv om theSprint Mål er en forpliktelse Av Utviklerne, det gir fleksibilitet i form av den eksakte arbeidet som trengs for å oppnå det. Sprintmålet skaper også sammenheng og fokus, og oppfordrer Scrum-Teamet til å jobbe sammen enn på separate tiltak.

Sprintmålet opprettes under Sprintplanleggingen og legges deretter til Sprintbackloggen. Som Utviklerne jobber under Sprinten, holder De Sprintmålet i tankene. Hvis arbeidet viser seg å være annerledes enn de forventet, samarbeider De med Produkteieren for å forhandle Omfanget Av Sprintbackloggen i Sprinten uten å påvirke trykkmål.

Inkrement

Et Inkrement er et konkret springbrett mot Produktmålet. Hver økning er additiv til alle tidligere Trinn og grundig verifisert,slik at alle Trinn fungerer sammen. For å gi verdi må Økningen være brukbar.

Flere Trinn kan opprettes i En Sprint. Summen av theIncrements presenteres På Sprint Gjennomgang dermed støtte empirisme.Imidlertid kan En Økning leveres til interessenter før Sprinten avsluttes. Sprint-Gjennomgangen bør aldri betraktes som en port tilutgivelse verdi.

Arbeid kan ikke betraktes som en Del av Et Inkrement med mindre det oppfyller Definisjonen Av Ferdig.

Forpliktelse: Definisjon av Ferdig

Definisjonen av Ferdig er en formell beskrivelse av tilstanden til økningen når den oppfyller kvalitetstiltakene som kreves for produktet.

i det øyeblikket Et Produkt Backlog element oppfyller Definisjonen Av Ferdig, anIncrement er født.

Definisjonen av Ferdig skaper åpenhet ved å gi alle ashared forståelse av hva arbeidet ble gjennomført som en del av theIncrement. Hvis Et Produkt Backlog element ikke oppfyller Definisjonen ofDone, det kan ikke bli utgitt eller presentert På Sprint Gjennomgang.I stedet, det går tilbake Til Produkt Backlog for fremtidig vurdering.

Hvis Definisjonen Av Ferdig For en økning er en del av organisasjonens standarder, må Alle Scrum-Lag følge det som et minimum. Hvis Det ikke er en organisatorisk standard, Må Scrum-Teamet opprette En Definitionof Gjort passende for produktet.

Utviklerne er pålagt å samsvare Med Definisjonen Av Ferdig. Hvis Det er Flere Scrum-Lag som jobber sammen på et produkt, må de regelmessig definere og overholde samme Definisjon Av Ferdig.

End Note

Scrum er gratis og tilbys i Denne Guiden. Scrum-rammeverket, som er skissert her, er uforanderlig. Mens implementering av bare deler Av Scrum er mulig, er resultatet ikke Scrum. Scrum eksisterer bare i sin helhet og fungerer som en beholder for andre teknikker, metoder og praksis.

Anerkjennelser

Folk

av de tusenvis av mennesker som har bidratt Til Scrum, bør vi skille ut de som var instrumentale i starten: Jeff Sutherland Jobbet med Jeff McKenna Og John Scumniotales, Og Ken Schwaber jobbet Med Mike Smith og Chris Martin, og alle jobbet sammen. Manyothers bidratt i de påfølgende årene, Og Uten deres hjelp Scrumville ikke bli raffinert som det er i dag.

Scrum Guide History

Ken Schwaber og Jeff Sutherland første co-presentert Scrum På OOPSLAConference I 1995. Det dokumenterte i hovedsak læringen Som Ken andJeff fikk de siste årene og offentliggjorde Den første formaldefinisjonen Av Scrum.Scrum Guide dokumenterer Scrum som utviklet, utviklet og opprettholdt for 30-pluss år Av Jeff Sutherland og Ken Schwaber. Andre kilder girmønstre, prosesser og innsikt som utfyller Scrum-rammeverket.Disse kan øke produktiviteten, verdi, kreativitet, og satisfactionwith resultatene.

den komplette historien Til Scrum er beskrevet andre steder. For å hedre den førstesteder der det ble prøvd og bevist, gjenkjenner Vi Individual Inc., Newspage, Fidelity Investments, OG IDX (nå GE Medical).

© 2020 Ken Schwaber Og Jeff Sutherland denne publikasjonen er tilbudt for lisens under AttributionShare-Alike-lisensen Til Creative Commons, tilgjengelig athttps://creativecommons.org/licenses/by-sa/4.0/legalcode og alsodbeskrevet i sammendragsform athttps://creativecommons.org/licenses/by-sa / 4.0/. Ved å benytte Denne ScrumGuide, erkjenner og godtar du at du har lest og godtar å befound av vilkårene I Attribution Share-Alike lisens Av CreativeCommons.