denna HTML-version av Scrum Guide är en direkt port i November 2020-versionen tillgänglig som PDFhere.

syftet med Scrum Guide

Vi utvecklade Scrum i början av 1990-talet. vi skrev den första versionen av theScrum Guide 2010 för att hjälpa människor över hela världen att förstå Scrum. Vi har utvecklat guiden sedan dess genom små, funktionella uppdateringar.Tillsammans står vi bakom det.

Scrum-guiden innehåller definitionen av Scrum. Varje element i ramverket tjänar ett specifikt syfte som är viktigt för det övergripande värdet och resultaten som realiseras med Scrum. Att ändra kärndesignen eller ideasof Scrum, utelämna element eller inte följa reglerna för Scrum, täcker upp problem och begränsar fördelarna med Scrum,vilket potentiellt gör det värdelöst.

vi följer den växande användningen av Scrum i en ständigt växande komplex värld.Vi är ödmjuka över att se Scrum antas i många domäner som innehar väsentligt komplext arbete, bortom mjukvaruproduktutveckling där Scrum har sina rötter. Som Scrum användning sprider, utvecklare,forskare, analytiker, forskare och andra specialister gör arbetet. Vi använder ordet” utvecklare ” i Scrum för att inte utesluta, men för att förenkla. Om du får valuefrom Scrum, anser dig själv ingår.

När Scrum används kan Mönster, processer och insikter som passar ramverket för rum som beskrivs i detta dokument hittas, tillämpas och utformas. Deras beskrivning är bortom syftet med Scrum Guideeftersom de är kontextkänsliga och skiljer sig mycket mellan Scrum-användningarna.Sådan taktik för användning inom Scrum-ramen varierar mycket och beskrivs någon annanstans.

Scrum Definition

Scrum är en lätt ram som hjälper människor, team och organisationer att generera värde genom adaptiva lösningar för komplexproblem.

i ett nötskal kräver Scrum en Scrum Master för att främja en miljö där:

1. en produktägare beställer arbetet för ett komplext problem i en produktbacklog.

2. Scrum-teamet förvandlar ett urval av arbetet till en ökning av värdet under en Sprint.

3. Scrum-teamet och dess intressenter inspekterar resultaten och justerar för nästa Sprint.

4. upprepa

Scrum är enkelt. Prova det som det är och avgöra om dess filosofi, teori och struktur hjälper till att uppnå mål och skapa värde. Scrumframework är målmedvetet ofullständigt och definierar bara de delar som krävs för att implementera Scrumteori. Scrum bygger på kollektivintelligens av de människor som använder den. Snarare än att ge människor detaljerade instruktioner, reglerna för Scrum styr deras relationer ochinteraktioner.

olika processer, tekniker och metoder kan användas inom ramen. Scrum sveper runt befintliga metoder eller gör demonödigt. Scrum synliggör den relativa effekten av currentmanagement, miljö och arbetsteknik, så att förbättringar kan göras.

Scrum teori

Scrum bygger på empirism och magert tänkande. Empirism hävdaratt kunskap kommer från erfarenhet och fattar beslut baserat på vadobserveras. Lean thinking minskar avfallet och fokuserar på det väsentliga.

Scrum använder en iterativ, inkrementell strategi för att optimera förutsägbarheten och kontrollera risken. Scrum engagerar grupper av människor somkollektivt har alla färdigheter och expertis för att göra arbetet och delaeller förvärva sådana färdigheter efter behov.

Scrum kombinerar fyra formella evenemang för inspektion och anpassning inom acontaining event, sprinten. Dessa händelser fungerar eftersom de implementerarde empiriska Scrum-pelarna för öppenhet, inspektion och anpassning.

transparens

den framväxande processen och arbetet måste vara synligt för dem som utför arbetet såväl som de som tar emot arbetet. Med Scrum, viktigtbeslut bygger på det upplevda tillståndet av dess tre formalartifakter. Artefakter som har låg transparens kan leda till besluts som minskar värdet och ökar risken.

transparens möjliggör inspektion. Inspektion utan öppenhet ärmisledande och slösaktig.

inspektion

Scrum-artefakterna och framstegen mot överenskomna mål måste inspekteras ofta och flitigt för att upptäcka potentiellt oönskade varianter eller problem. För att hjälpa till med inspektion ger Scrum kadensi form av sina fem händelser.

inspektion möjliggör anpassning. Inspektion utan anpassning äranses meningslöst. Scrum händelser är utformade för att provocera förändring.

anpassning

om några aspekter av en process avviker utanför acceptabla gränser eller om den resulterande produkten är oacceptabel, måste den process som tillämpas eller de material som produceras justeras. Justeringen måste göras så snart som möjligt för att minimera ytterligare avvikelser.

anpassning blir svårare när de inblandade inte är empowered eller självhanterande. Ett Scrum-Team förväntas anpassa ögonblicketdet lär sig något nytt genom inspektion.

Scrum värden

framgångsrik användning av Scrum beror på att människor blir mer skickliga inliving fem värden:

engagemang, fokus, öppenhet, respekt och mod

Scrum-teamet förbinder sig att uppnå sina mål och stödja varandra. Deras primära fokus ligger på sprintens arbete för att göra det bästamöjliga framsteg mot dessa mål. Scrum-teamet och itsstakeholders är öppna om arbetet och utmaningarna. Scrum-lagmedlemmar respekterar varandra för att vara kapabla, oberoende människor och ärrespekterade som sådana av de människor de arbetar med. Scrum-lagmedlemmarna har modet att göra det rätta, att arbeta med tuffaproblem.

dessa värden ger riktning till Scrum-teamet med avseende på deras arbete,handlingar och beteende. De beslut som fattas, de åtgärder som vidtagits och hur Scrum används bör förstärka dessa värden, inte minska eller underminera dem. Scrum-teammedlemmarna lär sig och utforskar värdena somde arbetar med Scrum-händelserna och artefakterna. När dessa värden förkroppsligas av Scrum-teamet och de människor de arbetar med, kommer de empiricalScrum-pelarna för öppenhet, inspektion och anpassning till livsbyggande förtroende.

Scrum Team

den grundläggande enheten i Scrum är ett litet team av människor, ett Scrum-Team.Scrum-teamet består av en Scrum Master, en produktägare ochutvecklare. Inom ett Scrum-Team finns det inga underlag eller hierarchies.It är en sammanhängande enhet av proffs fokuserade på ett mål i taget, Produktmålet.

Scrum-Team är tvärfunktionella, vilket innebär att medlemmarna har alla färdigheter som krävs för att skapa värde varje Sprint. De är också självhanterande, vilket innebär att de internt bestämmer vem som gör vad, när och hur.Scrum-teamet är tillräckligt litet för att förbli smidigt och tillräckligt stort för att slutföra betydande arbete inom en Sprint, vanligtvis 10 eller färre people.In allmänt, vi har funnit att mindre team kommunicerar bättre och är mer produktiva. Om Scrum-Team blir för stora bör de överväga att organisera sig i flera sammanhängande Scrum-Team, var och en fokuserade på samma produkt. Därför bör de dela samma Produktmål, produktbacklog och produktägare.

Scrum-teamet ansvarar för alla produktrelaterade aktiviteter från samarbete, verifiering, underhåll, drift,experiment, forskning och utveckling och allt annat som krävs. De är strukturerade och bemyndigade av organisationen atthantera sitt eget arbete. Att arbeta i Sprints i en hållbar takt förbättrarscrum-teamets fokus och konsistens.

hela Scrum-teamet är ansvarigt för att skapa en värdefull, användbar ökning varje Sprint. Scrum definierar tre specifika redovisningarinom Scrum-teamet: utvecklarna, produktägaren och ScrumMaster.

Utvecklare

utvecklare är de personer i Scrum-teamet som är engagerade i att skapa någon aspekt av en användbar ökning varje Sprint.

de specifika färdigheter som utvecklarna behöver är ofta breda och kommer attvariera med arbetsdomänen. Men utvecklarna är alltidaccountable för:

• skapa en plan för sprinten, sprintbackloggen;

• inställa kvalitet genom att följa en Definition av klar;

• anpassa sin plan varje dag mot sprintmålet; och,

• håller varandra ansvariga som proffs.

produktägare

produktägaren är ansvarig för att maximera produktens värderesultat från Scrum-teamets arbete. Hur detta görs kan varieraallmänt mellan organisationer, Scrum-Team och individer.

produktägaren är också ansvarig för effektiv Produktbacklogmanagement, som inkluderar:

• utveckla och uttryckligen kommunicera Produktmålet;

• skapa och tydligt kommunicera Produktbackloggposter;

• beställa Produktbackloggposter; och

• se till att produktbackloggen är transparent, synlig och förstådd.

produktägaren kan göra ovanstående arbete eller delegera ansvaret till andra. Oavsett är produktägaren kvartalbar.

För att produktägare ska lyckas måste hela organisationen respekteraderas beslut. Dessa beslut är synliga i innehållet och orderingången i produktbackloggen, och genom inspectable Increment at theSprint Review.

produktägaren är en person, inte en utskott. Produktägaren kanrepresentera behoven hos många intressenter i produktbackloggen. De som vill ändra produktbackloggen kan göra det genom att försöka övertyga produktägaren.

Scrum Master

Scrum Master är ansvarig för att upprätta Scrum enligt definitionen i theScrum Guide. De gör detta genom att hjälpa alla att förstå Scrum teori och praktik, både inom Scrum laget och organisationen.

Scrum Master är ansvarig för Scrum-teamets effektivitet. De gör detta genom att göra det möjligt för Scrum-teamet att förbättra sin praxis inom Scrum-ramen.

Scrum Masters är sanna ledare som tjänar Scrum-teamet och largerorganisationen.Scrum Master tjänar Scrum-teamet på flera sätt, inklusive:

• coachar teammedlemmarna i självhantering ochkorsfunktionalitet;

• hjälper Scrum-teamet att fokusera på att skapa steg med högt värde somuppfyller definitionen av gjort;

• orsakar avlägsnande av hinder för Scrum-lagets framsteg;och

• se till att alla Scrum-händelser äger rum och är positiva, produktiva och hålls inom timeboxen.

Scrum Master tjänar produktägaren på flera sätt, inklusive:

• hjälper till att hitta tekniker för effektiv definition av Produktmål ochproduktbacklogghantering;

• hjälper Scrum-teamet att förstå behovet av tydliga och koncisaproduktbackloggposter;

• hjälper till att skapa empirisk produktplanering för en komplexmiljö; och

• underlätta intressenternas samarbete som begärts eller behövs.

Scrum Master tjänar organisationen på flera sätt, inklusive:

• leda, utbilda och coacha organisationen i dess Scrumadoption;

• planera och ge råd till Scrum-implementeringar inom organisationen;

• hjälpa anställda och intressenter att förstå och anta en empiricalapproach för komplext arbete; och

• Ta bort hinder mellan intressenter och Scrum-Team.

Scrum Events

sprinten är en behållare för alla andra evenemang. Varje händelse i Scrum är enformell möjlighet att inspektera och anpassa Scrum artefakter. Dessa evenemang är särskilt utformade för att möjliggöra den transparens som krävs. Misslyckande att driva eventuella händelser som föreskrivs resulterar i förlorade möjligheter attinspektera och anpassa sig. Händelser används i Scrum för att skapa regelbundenhet och tillminimera behovet av möten som inte definieras i Scrum.

optimalt hålls alla händelser samtidigt och plats för att minskakomplexitet.

sprinten

sprintar är hjärtslag av Scrum, där ideer förvandlas till värde.

de är händelser med fast längd på en månad eller mindre för att skapa konsistens.En ny Sprint börjar omedelbart efter avslutningen av föregåendesprint.

allt arbete som krävs för att uppnå Produktmålet, inklusive SprintPlanning, Daily Scrums, Sprint Review och Sprint Retrospective, happenwithin Sprints.

under sprinten:

• inga ändringar görs som skulle äventyra sprintmålet;

• kvaliteten minskar inte;

• produktbackloggen förfinas efter behov; och

• omfattning kan klargöras och omförhandlas med produktägaren asmore lärs.

Sprints möjliggör förutsägbarhet genom att säkerställa inspektion och anpassning av framsteg mot ett Produktmål minst varje kalendermånad. När asprints horisont är för lång kan sprintmålet bli ogiltigt, komplexiteten kan stiga och risken kan öka. Kortare Sprints kan varaanställda för att generera fler inlärningscykler och begränsa risken för kostnad och ansträngning till en mindre tidsram. Varje Sprint kan betraktas som en kortprojekt.

olika metoder finns för att förutsäga framsteg, som nedbränningar,uppbränningar eller kumulativa flöden. Även om de visat sig vara användbara ersätter de intebetydelsen av empirism. I komplexa miljöer är vad som kommer att händaokänd. Endast det som redan har hänt kan användas för framåtblickandebeslut.

en Sprint kan avbrytas om sprintmålet blir föråldrat. Endast produktägaren har befogenhet att avbryta sprinten.

sprintplanering

sprintplanering initierar sprinten genom att lägga ut det arbete som ska utföras för sprinten. Denna resulterande plan skapas avsamarbete av hela Scrum-teamet.

produktägaren ser till att deltagarna är beredda att diskutera de viktigaste produktbackloggen och hur de kartlägger till Produktmålet. Scrum-teamet kan också bjuda in andra att delta i SprintPlanning för att ge råd.

Sprint planering behandlar följande ämnen:

ämne ett: Varför är denna Sprint värdefull?

produktägaren föreslår hur produkten kan öka sitt värde ochanvändbarhet i den aktuella sprinten. Hela Scrum-teamet samarbetar sedan för att definiera ett sprintmål som kommunicerar varför sprinten är värdefull förinnehavare. Sprintmålet måste slutföras före slutet avsprint planering.

ämne två: Vad kan göras denna Sprint?

genom diskussion med produktägaren väljer utvecklarna objektfrån produktbackloggen för att inkludera i den aktuella sprinten. Scrumteamet kan förfina dessa objekt under denna process, vilket ökar förståelsen och förtroendet.

att välja hur mycket som kan slutföras inom en Sprint kan vara utmanande.Men ju mer utvecklarna vet om deras tidigare prestanda, deras kommande kapacitet och deras Definition av gjort, desto mersäker kommer de att vara i sina Sprintprognoser.

ämne tre: Hur kommer det valda arbetet att bli gjort?

För varje valt produktbacklog-objekt planerar utvecklarna arbetetnödvändigt för att skapa en ökning som uppfyller definitionen av klar. Detta görs ofta genom att sönderdela produktbacklog objekt i mindre workitems på en dag eller mindre. Hur detta görs är efter eget gottfinnande Avutvecklarna. Ingen annan berättar för dem hur man vänder produktbacklog itemsinto steg av värde.

sprintmålet, produktbackloggen som valts ut för sprinten, plusplanen för att leverera dem kallas tillsammans SprintBacklog.

sprintplanering är tidsboxad till högst åtta timmar för en månadsprint. För kortare sprintar är evenemanget vanligtvis kortare.

Daily Scrum

syftet med Daily Scrum är att inspektera framstegen mot sprintmålet och anpassa sprintbackloggen efter behov, justera det kommande planerade arbetet.

the Daily Scrum är en 15-minuters händelse för utvecklarna av ScrumTeam. För att minska komplexiteten hålls den samtidigt och placerar varjearbetsdag i sprinten. Om produktägaren eller Scrum Master arbetar aktivt med artiklar i sprintbackloggen deltar de somutvecklare.

utvecklarna kan välja vilken struktur och teknik de vill ha,så länge deras dagliga Scrum fokuserar på framsteg mot sprintmålet och producerar en handlingsbar plan för nästa arbetsdag. Detta skaparfokus och förbättrar självhantering.

dagliga Scrums förbättrar kommunikationen, identifierar hinder, främjar snabbbeslut och därmed eliminerar behovet av andra möten.

Daily Scrum är inte den enda gången utvecklare får justeraderas plan. De träffas ofta hela dagen för mer detaljeradediskussioner om anpassning eller omplanering av resten av sprintens arbete.

Sprint Review

syftet med Sprint Review är att inspektera resultatet av Sprintoch bestämma framtida anpassningar. Scrum-teamet presenterar resultaten av sitt arbete för viktiga intressenter och framsteg mot Produktmålet diskuteras.

under evenemanget granskar Scrum-teamet och intressenterna vad som slutfördes i sprinten och vad som har förändrats i deras miljö.Baserat på denna information samarbetar deltagarna om vad de ska göra nästa. Produktbackloggen kan också anpassas för att möta nya möjligheter. TheSprint Review är en arbetssession och Scrum-teamet bör undvikabegränsar det till en presentation.

Sprint Review är den näst sista händelsen i sprinten och istimeboxed till högst fyra timmar för en månads Sprint. För shorterSprints är händelsen vanligtvis kortare.

Sprint Retrospective

syftet med Sprint Retrospective är att planera sätt att ökakvalitet och effektivitet.Scrum-teamet inspekterar hur den senaste sprinten gick när det gäller individer, interaktioner, processer, verktyg och deras Definition avgjort. Inspekterade element varierar ofta med arbetsdomänen. Assumptions som ledde dem vilse identifieras och deras ursprung utforskas. TheScrum-teamet diskuterar vad som gick bra under sprinten, vilka problem det stod inför och hur dessa problem löstes (eller inte).

Scrum-teamet identifierar de mest användbara förändringarna för att förbättra desseffektivitet. De mest effektiva förbättringarna behandlas så snart sommöjligt. De kan till och med läggas till sprintbackloggen för nextSprint.

Sprint Retrospective avslutar sprinten. Det är tidsboxat till högst tre timmar för en månads Sprint. För kortare sprintar, händelsen är vanligtvis kortare.

Scrum artefakter

Scrum artefakter representerar arbete eller värde. De är utformade för att maximeratransparens av nyckelinformation. Således har alla som inspekterar demsamma grund för anpassning.

varje artefakt innehåller ett åtagande att säkerställa att det ger information som förbättrar öppenhet och fokus mot vilka framsteg kan mätas:

• För produktbackloggen är det Produktmålet.

• För sprintbackloggen är det sprintmålet.

• för ökningen är definitionen av klar.

dessa åtaganden finns för att förstärka empirismen och Scrum-värdena för Scrum-teamet och deras intressenter.

produktbacklog

produktbacklog är en framväxande, beställd lista över vad som behövs för att förbättra produkten. Det är den enda källan till arbete som utförs av theScrum-teamet.

produktbacklog objekt som kan göras av Scrum laget inom oneSprint anses redo för val i en Sprint planering händelse. De brukar förvärva denna grad av öppenhet efter raffinering av aktiviteter.Produktbacklog förfining är handlingen att bryta ner och vidaredefiniera produktbacklog objekt i mindre mer exakta objekt. Detta är en pågående aktivitet för att lägga till detaljer, till exempel en beskrivning, ordning och storlek. Attribut varierar ofta med arbetsdomänen.

utvecklarna som ska göra arbetet är ansvariga försizing. Produktägaren kan påverka utvecklarna genom att hjälpa demförstå och välja avvägningar.

engagemang: Produktmål

Produktmålet beskriver ett framtida tillstånd för produkten som kan tjäna som ett mål för Scrum-teamet att planera mot. Produktmålet är Iproduktens eftersläpning. Resten av produktbackloggen framträder för att definiera”vad” som kommer att uppfylla Produktmålet.

en produkt är ett fordon för att leverera värde. Den har en tydlig gräns, kända intressenter, väldefinierade användare eller kunder. En produkt kan vara en tjänst, en fysisk produkt eller något mer abstrakt.

Produktmålet är det långsiktiga målet för Scrum-teamet. De måste uppfylla (eller överge) ett mål innan de tar på sig nästa.

Sprint Backlog

Sprint Backlog består av Sprint-målet (varför), uppsättningen avproduktbacklog-objekt som valts för sprinten (vad), samt en åtgärdsplan för att leverera inkrementet (hur).

Sprint Backlog är en plan av och för utvecklarna. Det är en mycket synlig, realtidsbild av det arbete som utvecklarna planerar att följa under sprinten för att uppnå sprintmålet.Följaktligen uppdateras sprintbackloggen under hela sprinten asmore lärs. Det borde ha tillräckligt med detaljer som de kan inspekteraderas framsteg i den dagliga Scrum.

engagemang: sprintmål

sprintmålet är det enda målet för sprinten. Även omprint-målet är ett åtagande från utvecklarna, ger det flexibilitetnär det gäller det exakta arbete som behövs för att uppnå det. Sprintmålet skapar också samstämmighet och fokus, vilket uppmuntrar Scrum-teamet att arbeta tillsammans snarare än på separata initiativ.

sprintmålet skapas under Sprintplaneringsevenemanget och läggs sedan till sprintbackloggen. När utvecklarna arbetar under sprinten håller de sprintmålet i åtanke. Om arbetet visar sig vara annorlunda än vad de förväntade sig samarbetar de med produktägaren för att förhandla om omfattningen av sprintbackloggen inom sprinten utan att påverka utskriftsmålet.

ökning

en ökning är en konkret språngbräda mot Produktmålet. EachIncrement är additiv till alla tidigare steg och noggrant verifierad,se till att alla steg fungerar tillsammans. För att ge värde måste ökningen vara användbar.

flera steg kan skapas inom en Sprint. Summan av ökningarna presenteras vid Sprint Review och stöder därmed empirism.En ökning kan dock levereras till intressenter före slutet av sprinten. Sprintgranskningen bör aldrig betraktas som en port tillsläpp värde.

arbete kan inte betraktas som en del av ett steg om det inte uppfyller definitionen av gjort.

åtagande: definition av gjort

definitionen av gjort är en formell beskrivning av tillståndet för ökningen när den uppfyller de kvalitetsåtgärder som krävs för produkten.

i det ögonblick som en produktbacklog-artikel uppfyller definitionen av klar är aincrement född.

definitionen av gjort skapar öppenhet genom att ge alla ashared förståelse för vilket arbete som slutfördes som en del av ökningen. Om en produktbacklog-artikel inte uppfyller definitionen avgjort, kan den inte släppas eller ens presenteras vid Sprint Review.Istället återgår den till produktbackloggen för framtida övervägande.

om definitionen av gjort för en ökning är en del av organisationens standarder måste alla Scrum-Team följa det som ett minimum. Om det inte är en organisationsstandard måste Scrum-teamet skapa en definition som är lämplig för produkten.

utvecklarna är skyldiga att överensstämma med definitionen av klar. Om det finns flera Scrum-team som arbetar tillsammans på en produkt måste de definiera och följa samma Definition av gjort.

End Note

Scrum är gratis och erbjuds i den här guiden. Scrum-ramverket, som anges häri, är oföränderligt. Även om det bara är möjligt att implementera delar av Scrum är resultatet inte Scrum. Scrum existerar endast i sin helhet ochfungerar väl som en behållare för andra tekniker, metoder och praxis.

erkännanden

människor

av de tusentals människor som har bidragit till Scrum, borde vi singla ut de som var instrumentala i början: Jeff Sutherlandarbetade med Jeff McKenna och John Scumniotales, och Ken Schwaber arbetademed Mike Smith och Chris Martin, och alla arbetade tillsammans. Många andra bidrog under de följande åren och utan deras hjälp skulle Scrumskulle inte förfinas som det är idag.

Scrum Guide History

Ken Schwaber och Jeff Sutherland presenterade först Scrum vid OOPSLAConference 1995. Det dokumenterade i huvudsak det lärande som Ken andJeff fick under de senaste åren och offentliggjorde den första formaldefinitionen av Scrum.Scrum Guide dokumenterar Scrum som utvecklat, utvecklat och upprätthållit i 30 år av Jeff Sutherland och Ken Schwaber. Andra källor germönster, processer och insikter som kompletterar Scrum-ramverket.Dessa kan öka produktiviteten, värdet, kreativiteten och tillfredsställelsen med resultaten.

den fullständiga historien om Scrum beskrivs någon annanstans. För att hedra den förstaplatser där det prövades och bevisats, känner vi igen Individual Inc., Newspage, Fidelity Investments och IDX (nu ge Medical).

2020 Ken Schwaber och Jeff Sutherland denna publikation erbjuds för licens under AttributionShare-Alike licens Creative Commons, tillgänglig athttps://creativecommons.org/licenser/by-sa/4.0/legalcode och ocksåbeskrivs i sammanfattande form athttps://creativecommons.org/licenser/by-sa/4.0 / legalcode och ocksåbeskrivs i sammanfattande form athttps: / / creativecommons.org / licenser / by-sa / 4.0/. Genom att använda denna ScrumGuide bekräftar och godkänner du att du har läst och samtycker till att följa villkoren i creativecommons Attribution Share-Alike-licens.