Scrum

Innen prosjektledelse er scrum et rammeverk for å utvikle, levere og opprettholde produkter i et komplekst miljø. Scrum har sin bakgrunn fra programvareutvikling, men har også blitt brukt i andre felt inkludert forskning, salg, markedsføring og høyteknologi. Metodikken er designet for team med 3 til 10 medlemmer, og bryter ned arbeidet i mål (sprintkøer) som skal fullføres innen tidsbokser kalt sprinter. Sprintene har som regel varighet ikke lengre enn en måned og oftest to uker. Scrumteamet vurderer fremgangen i daglige møter på 15 minutter eller mindre kalt daglige scrums (en form for ståmøte). På slutten av sprinten har teamet har ytterligere to møter, henholdsvis sprintgjennomgang hvor man viser utført arbeid for interessenten for å få tilbakemeldinger, og sprintevaluering hvor teamet kan reflektere og forbedre seg.

Navn

Begrepet scrum ble først brukt i forbindelse med programvareutvikling i 1986 i artikkelen "The New New Product Development Game" av japanerne Hirotaka Takeuchi og Ikujiro Nonaka. Artikkelen ble publisert i januar 1986-utgaven av Harvard Business Review. Begrepet er lånt fra rugby hvor scrum er en spillerformasjon. Begrep scrum ble valgt av artikkelforfatterne fordi det legger vekt på samarbeid.

Scrum blir av og til skrevet med store bokstaver som i SCRUM. Navnet er dog ikke en forkortelse, og varianten skrevet med store bokstaver stammer trolig fra en artikkel skrevet av Ken Schwaber i 2004 hvor SCRUM var en del av tittelen.

Varemerket scrum har gjennom sin utstrakte bruk gått over til å anses som et degenerert varemerke eid av samfunnet istedet for et individ.

Mange av begrepene som brukes i scrumlitteraturen på engelsk skrives ofte med store forbokstaver (for eksempel Scrum Master, Daily Scrum), men i de fleste tilfellene bør man ikke bruke store bokstaver (hverken på norsk eller engelsk) dersom begrepet er et fellesnavn. I denne artikkelen brukes derfor små bokstaver for fellesnavn i henhold til vanlig gramatikk (for eksempel scrum master, daily scrum), med mindre det henvises til egennavn (som for eksempel produktnavn eller anerkjente sertifiseringer som Certified Scrum Master og Professional Scrum Master).

Viktige idéer

Scrum er et lett, iterativt og inkrementellt rammeverk for utvikling, levering og vedlikehold av komplekse produkter. Rammeverket utfordrer antagelser om den tradisjonelle, sekvensielle tilnærmingen til produktutvikling (som fossefallmodellen), og gjør det mulig for team å organisere seg selv ved å oppmuntre^{[trenger referanse]} til fysisk samlokalisering eller tett nettbasert samarbeid mellom alle teammedlemmer, samt daglig kommunikasjon ansikt-til-ansikt mellom alle teammedlemmer og involverte disipliner.

Et sentralt prinsipp i scrum er den doble anerkjennelsen om at kunden på den ene siden vil endre omfanget av hva som ønskes (usikkerhet i kravene, kalt requirements volatility på engelsk) og at det på den andre siden vil være uforutsigbare utfordringer som en prediktiv eller planlagt tilnærming ikke vil passe for. Disse endringene kan komme fra en rekke kilder, men i henhold til scrum er det irrelevant å prøve å forstå hvorfor, og endringer bør bare aksepteres, omfavnes og analyseres for hvilke fordeler de kan bringe.

Som sådan har scrum en bevisbasert empirisk tilnærming ved at man aksepterer at et problem ikke kan fullt ut forstås eller defineres på forhånd, og legger istedet vekt på hvordan man kan maksimere teamets mulighet eller evne til å levere raskt, respondere på nye krav, og tilpasse seg til nye teknoloier og endringer i markedet.

Historie

I 1986 introduserte Hirotaka Takeuchi og Ikujiro Nonaka begrepet scrum i sammenheng med produktutvikling i Harvard Business Review-artikkelen The New New Product Development Game. Takeuchi og Nonaka argumenterte senere i Knowledge Creating Company at det er en form for "organisatorisk kunnskapsbygging" særlig egnet for å skape trinnvis og kontinuerlig innovasjon.

Basert på tilfellestudier fra produsenter av biler, kopimaskiner og skrivere beskrev Takeuchi og Nonaka en ny tilnærming til kommersiell produktutvikling som ville gi økt hastighet og fleksibilitet. De kalte denne tilnærmingen helhetlig eller rugbyaktigettersom hele prosessen utføres av ett tverrfunksjonelt team over flere overlappende faser hvor laget prøver å fullføre hele prosessen som et lag "og sender ballen frem og tilbake". Navnet stammer også fra rugby, hvor en scrum brukes for å restarte spillet ved at spillere fra hvert av lagene stiller seg sammen mot motstanderne med hodet ned for å forsøke å få besittelse av ballen.

Scrum-rammeverket er basert på forskning gjort av Schwaber sammen ved ingeniøren Babatunde Ogunnaike ved DuPont Research Station og University Of Delaware. Ogunnaike gav råd om at forsøk på å utvikle komplekse produkter (som for eksempel programvare) som ikke var basert på empirisme var dømt til å ha høyere risiko og feilrater etterhvert som de opprinnelige forholdene og forutsetningene endret seg. Empirisme ved hjelp av hyppige inspeksjoner og tilpasninger sammen med fleksibilitet og åpenhet ble ansett av dem som en mer hensiktsmessig tilnærming.

Tidlig i 1990-årene brukte Ken Schwaber et rammeverk i hans selskap kalt Advanced Development Methods som lignet på det som skulle bli scrum, mens Jeff Sutherland, John Scumniotales og Jeff McKenna utviklet en lignende tilnærming ved Easel Corporation som de kalte Scrum.

Sutherland og Schwaber jobbet sammen for å integrere sine ideer i ett enkelt rammeverk, scrum. De testet scrum og forbedret det kontinuerlig, noe som førte til artikkelen deres fra 1995, samt deres bidrag til manifestet for smidig programvareutvikling i 2001 som var med på å popularisere smidig programvareutvikling, og verdensomspennende spredning og bruk av scrum siden 2002.

I 1995 presenterte Sutherland og Schwaber i fellesskap en artikkel som beskrev scrumrammeverket på Business Object Design And Implementation Workshop som en del av Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA 1995) i Austin, Texas. Med sin erfaring med utvikling av god praksis samarbeidet Schwaber og Sutherland i løpet av de påfølgende årene for å kombinere deres materiale og utvikle det til det som ble kjent som scrum.

I 2001 beskrev Schwaber og Mike Beedle metoden i boken Agile Software Development with Scrum. Scrum sin tilnærming til planlegging og styring av produktutvikling innebærer å bringe beslutningsmyndigheter til et annet nivå.

I 2002 grunnla Schwaber med flere Scrum Alliance og satte opp akkrediteringen Certified Scrum. I slutten av 2009 forlot Schwaber Scrum Alliance og grunnla Scrum.org som gir den alternative akkrediteringen Professional Scrum.

Siden 2009 har det offentlig tilgjengelige dokumentet Scrum Guide blitt publisert og oppdatert jevnlig av Schwaber og Sutherland. I november 2020 ble 6. utgave utgitt.

Scrumteamet

Den grunnleggende enheten i scrum er et lite team av mennesker bestående av en produkteier, en scrumleder og utviklere. Teamet er selvstyrt, tverrfunksjonelt og fokuserer på ett mål om gangen som er produktmålet.

Produkteier

Utdypende artikkel: Produkteier

Produkteieren som representerer produktets interessenter, og er kundens stemme (eller kan representere ønskene til en komité), og er ansvarlig for å levere gode forretningsresultater. Derfor er produkteieren ansvarlig for produktkøen og for å maksimere verdien som teamet leverer. Produkteieren definerer produktet i form av kundesentriske resultater (vanligvis, men ikke begrenset til, brukerhistorier), legger de til produktbackloggen, og prioriterer de basert på viktighet og avhengigheter. Et scrumteam bør bare ha én produkteier (selv om en produkteier kan hjelpe flere enn ett team), og det anbefales sterkt å ikke kombinere rollen som produkteier med rollen som scrumleder. Produkteieren bør fokusere på forretningssiden av en produktutvikling og tilbringe mesteparten av tiden med interessenter og teamet. Produkteieren dikterer ikke hvordan teamet skal oppnå en teknisk løsning, men søker istedet konsensus blant teammedlemmene. Rollen som produkteier er avgjørende, og krever en dyp forståelse av både virksomhetssiden og ingeniørsiden (utviklerne) i scrumteamet. Derfor bør en god produkteier kunne kommunisere hva virksomheten trenger, spørre hvorfor de trenger det (fordi det kan være bedre måter å oppnå det på) og formidle budskapet til alle interessenter etter behov, inkludert utviklerne som bruker teknisk språk. Produkteieren bruker scrum sine empiriske verktøy for å håndtere svært komplekst arbeid, og styrer samtidig risikoen og verdioppnåelse.

Kommunikasjon er en av hovedoppgavene til produkteieren. Evnen til å formidle prioriteringer og sympatisere med teammedlemmer og interessenter er avgjørende for å styre produktutviklingen i riktig retning. Produkteierrollen bygger en bro over kommunikasjonsgapet mellom teamet og dets interessenter, og fungerer som et mellomledd for interessentene til teamet, og som en teamrepresentant for de samlede interessentene.

Som teamets ansikt ovenfor interessentene er følgende noen av kommunikasjonsoppgavene til en produkteier ovenfor interessentene:

• Definere og kunngjøre utgivelser
• Kommunisere status på produkt og leveranse
• Dele fremgang under styringsmøter
• Dele betydelige risikoer, hindringer, avhengigheter og forutsetninger med interessentene
• Forhandle prioriteringer, omfang, finansiering og tidsplan
• Sørge for at produktkøen er synlig, gjennomsiktig og tydelig

Empati er en viktig egenskap å ha for en produkteier, altså evnen til å sette seg selv i andres sko. En produkteier snakker med ulike interessenter med en ulike bakgrunner, med jobbroller og ulike mål, og bør kunne sette pris på forskjellige synspunkt disse kommer med. For å være effektiv er det lurt for en produkteier å vite detaljnivået publikummet trenger. Utviklerne trenger grundige tilbakemeldinger og spesifikasjoner slik at de kan bygge et produkt som står til forventningene, mens en prosjektsponsor kanskje bare trenger et sammendrag av fremgangen. Å gi mer informasjon enn nødvendig kan kaste bort tid og gjøre at interessenten mister interesse. En direkte metode for kommunikasjon foretrekkes av erfarne produkteiere.

En produkteiers evne til å kommunisere effektivt forbedres også ved å være dyktig i teknikker som identifiserer interessentbehov, kunne forhandle om prioriteringer av interessenten sine interesser, og å samarbeide med utviklere for å sikre effektiv implementering av krav.

Utviklerne

Utviklerne utfører alt arbeidet som kreves for å bygge verdi inkrementelt i hver sprint.

Begrep utvikler refererer til alle som spiller en rolle i utviklingen og støtten til systemet eller produktet, og kan inkludere forskere, arkitekter, designere, dataspesialister, statistikere, analytikere, ingeniører, programmerere og testere, med flere. På grunn av forvirringen som kan oppstå med at noen mennesker ikke føler at begrepet utvikler passer for dem blir de ofte referert til som gruppemedlemmer.

Teamet er selvorganiserende. Selv ingen arbeidsoppgaver skal kommer til teamet unntatt gjennom produkteieren og at scrumlederen forventes å beskytte teamet mot distraksjoner, så oppfordres teamet likevel til å samhandle direkte med kunder og/eller interessenter for å få maksimal forståelse og umiddelbare tilbakemeldinger.

Scrumleder

Utdypende artikkel: Scrumleder

Scrumprosessen blir tilrettelagt av en scrumleder (scrum master), som er ansvarlig for å fjerne hindringer for teamets evne til å levere produktmål og leveranser. Scrumlederen er ikke en tradisjonell teamleder eller prosjektleder, men fungerer som en barriere mellom teamet og alle distraherende påvirkninger. Scrumlederen sikrer at scrumrammeverket følges ved å veilede teamet i scrumteori og -konsepter, tilrettelegge viktige økter, og oppfordre teamet til å vokse og forbedre seg. Rollen har også blitt referert til som en teamfasilitator eller tjenende leder for å understreke disse doble perspektivene.

Kjerneansvaret til en scrumleder inkluderer (men er ikke begrenset til):

• Hjelpe produkteieren med å vedlikeholde produktkøen på en måte som sikrer at det nødvendige arbeidet er godt forstått slik at teamet kan ha kontinuerlig fremgang
• Hjelpe teamet med å bestemme definisjonen av ferdig for et produkt, med innspill fra hovedinteressentene
• Veilede teamet, innenfor scrumprinsippene, for hjelpe de med å levere et produkt med høykvalitetsfunksjoner
• Utdanne sentrale interessenter og resten av organisasjonen om scrumprinsipper (og muligens smidig utviklingsmetodikk)
• Hjelpe scrumteamet med å unngå eller fjerne hindringer for sin fremgang (både interne eller eksterne til hindringer)
• Fremme selvorganisering og kryssfunksjonalitet innad i teamet
• Legge til rette for viktige økter for å sikre regelmessig fremgang

Scrumlederen skal hjelpe mennesker og organisasjoner med å anta empirisk og strømlinjeformet tenkning, og etterlate håp om visshet og forutsigbarhet.

En av måtene rollen som scrumleder skiller seg fra en prosjektleder er at sistnevnte kan ha ansvar for personalledelse, mens en scrumleder ikke har det. En scrumleder utøver en begrenset mengde ledelse siden teamet forventes å være bemyndiget og selvorganiserende. Scrum anerkjenner ikke formelt rollen som prosjektleder på grunnlag av at tradisjonelle kommando og kontroll-tendenser vil føre til vanskeligheter.

Arbeidsflyt

Sprint

Scrum-rammeverket

Scrum-prosessen

En sprint (også kjent som iterasjon eller tidsboks) er den grunnleggende tidsenheten for utvikling i scrum. Sprinten er et tidsvindu som avtales og fastsettes på forhånd av hver sprint, og er normalt mellom en uke og en måned, hvor to uker er det vanligste.

Sprintplanleggingen utgjør starten på hver sprint, og starter med at man setter målene for sprinten. Derifra utformes sprintkøen som inneholder arbeidet som er tenkt å gjennomføres i den kommende sprinten.

Hver sprint avsluttes med de to hendelsene:

• Sprintgjennomgang: Oppnådd fremgang vises til interessentene for å få tilbakemeldinger.
• Sprintevaluering: Gjenkjenne læringspunkter og mulige forbedringer for neste sprint.

Det legges stor vekt på verdifulle og nyttige resultater på slutten av sprinten som faktisk er fullførte. Når det kommer til programvare vil dette sannsynligvis inkludere at produktet er fullt integrert, testet og dokumentert, og potensielt kan utgis.

Sprintplanlegging

I begynnelsen av hver sprint har scrumteamet en planleggingsøkt hvor de:

• Blir enige om sprintmålene og lager en kort beskrivelse av hva de forutser å levere ved sprintens slutt, basert på prioriteringer satt av produkteieren
• Velger elementer fra produktkøen som bidrar til dette målet
• Danner en sprintkø ved å gjensidig diskutere og bli enige om hvilke elementer som er ment å bli gjennomførte iløpet av den sprinten

Den maksimale varigheten av en sprintplanlegging er 8 timer for en 4-ukers sprint. Etterhvert som man har gått i detaljene på arbeidsoppgavene kan enkelte elementer i produktkøen bli delt opp eller returnert til produktkøen dersom teamet mener at de ikke kan fullføre det arbeidet iløpet av en enkelt sprint.

Daglig scrum

Den daglig scrummen gjennomføres ofte på et fast sted.

Hver dag i løpet av en sprint har utviklerne et daglig scrummøte med veldig spesifikke retningslinjer: Møtet gjennomføres noen ganger som ståmøte, og alle utviklerne forventes å komme forberedt.

Den dagilige scrummen:

• Skal fokusere på å inspisere fremgangen mot sprintmålet
• Bør skje på samme tid og sted hver dag
• Er begrenset til en tidsboks på 15 minutter
• Utføres på den måten teamet bestemmer
• Kan inkludere andre deltakere, men bare utviklerne bør snakke
• Kan bli fasilitert av scrumlederen
• Kan identifisere hindringer for fremgang (for eksempel risikoer, problemer, forsinkede avhengigheter, antagelser som viste seg å være feil)
• Inneholder ikke diskusjoner
• Er ikke et middel for å oppdatere fremdriftsdiagrammer

Ingen detaljerte diskusjoner bør skje under den daglige scrummen. Når møtet er over kan individuelle medlemmer diskutere problemer i detalj. Identifiserte blokkasjer bør diskuteres kollektivt utenfor den daglige scrummen med sikte på å arbeide mot en løsning.

Dersom teamet ikke ser verdien i den daglige scrummen er det scrumlederens ansvar å finne ut hvorfor og opplyse teamet og interessentene om scrumprinsippene eller oppmuntre teamet til å designe sin egen metode for å holde teamet fullt informert om sprintfremgangen.

Sprintgjennomgang

I sprintgjennomgangen på slutten av hver sprint skal teamet:

• Presentere det ferdige arbeidet til interessentene (altså en teknisk demonstrasjon)
• Samarbeide med interessentene om temaer som:
  • Be om tilbakemeldinger på det ferdige produktinkrementet
  • Diskutere innvirkningene av ufullstendig arbeid (både planlagte og ikke-planlagte)
  • Motta forslag til kommende arbeid (veiledning om hva man skal jobbe med videre)

Produkteieren bør se på denne hendelsen som en verdifull mulighet til å gå gjennom og finjustere produktkøen sammen med interessentene.

Retningslinjer for sprintevaluernger er at:

• Ufullstendig arbeid bør ikke demonstreres, og interessentene bør presenteres med produktinkrementene som de vil motta. Interessentene kan også be om å få se arbeid som pågår dersom nødvendig, men teamet bør bare forberede seg på å vise det som har blitt gjort.
• Den anbefalte varigheten er to timer for en 2-ukers sprint (proporsjonalt for andre sprintvarigheter).

Sprintevaluering

Under sprintevalueringen bør teamet:

• Reflektere over forrige sprint
• Identifiserere og bli enige om aksjoner for kontinuerlig prosessforbedring

Noen retningslinjer for sprintevalueringen er:^{[trenger referanse]}

• Tre foreslåtte områder å vurdere i sprintevalueringen er:
  • Hva gikk bra under sprinten?
  • Hva gikk dårlig?
  • Hva kan vi gjøre annerledes i neste sprint?
• Den anbefalte varigheten er 1.5 time for en 2-ukers sprint (proporsjonalt for andre sprintvarigheter).

Scrumlederen kan fasilitere økten, men deres tilstedeværelse anses ikke som obligatorisk.

Produktkøraffinering

Produktkøraffinering (backlog refinement) er en finpuss av produktkøen. Det var ikke opprinnelig et kjerneprinsipp i scrum, men har siden blitt tatt med i Scrum Guide som en metode for å håndtere kvaliteten på elementene fra produktkøen som blir med inn i en sprint. Den innebærer en kontinuerlig prosess hvor man går gjennom og endrer, oppdaterer og stokker om på elementene i produktkøen i lys av ny informasjon.

Noen grunner for å endre produktkøen og dens elementer kan være:

• Oppdeling av større elementer inn i flere mindre
• Godkjenningskriterier kan avklares
• Avhengigheter kan identifiseres og undersøkes
• Et element kan kreve ytterligere utforskning og analyse
• Prioriteringene kan ha endret seg, og forventet verdi kan ha endret seg

Produktkøraffineringen innebærer at elementene er blir forberedt og ordnet på en måte som gjør dem tydelige og utførbare for utviklerne sin sprintplanlegging.

Produktkøen kan også inkludere teknisk gjeld (også kjent som designgjeld eller kodegjeld). Dette er et konsept innen programvareutvikling som gjenspeiler den implisitte kostnaden i form av forventet arbeid på et senere tidspunkt forårsaket av å velge en enklere løsning nå, istedet for å bruke en bedre tilnærming som ville tatt lengre tid å implementere i første omgang.

Det anbefales å investere inntil 10 prosent av et teams sprintkapasitet på produktkøraffinering. Mer modne team vil ikke se på dette som en planlagt definert hendelse, men som en ad hoc-aktivitet som gjøres som en del av den naturlige arbeidsflyten ved at man raffinerer og justerer produktet etter behov.

Avlysning av en sprint

Produkteieren kan avbryte en sprint om nødvendig, og kan ta med innspill fra andre (utviklere, scrumlederen eller ledelsen). For eksempel kan nylige eksterne faktorer negere verdien av sprintmålet slik at det er meningsløst å fortsette.

Når en sprint avsluttes unormalt er det neste steget å gjennomføre en ny sprintplanlegging hvor årsaken til termineringen av den forrige sprinten blir gjennomgått.

Artefakter

En artefakt refererer til dokumentasjon for å administrere arbeidet i prosjektet.

Produktkø

Utdypende artikkel: Produktkø

Produktkøen er en oversikt over arbeidet som skal gjøres, og inneholder en ordnet liste over produktkrav som teamet vedlikeholder for et produkt. Vanlige formater på elementene i produktkøen er brukerhistorier og brukstilfeller. Disse kravene definerer funksjoner, feilrettinger, ikke-funksjonelle krav, og så videre, hva enn som kan levere et levedyktig produkt. Produkteieren prioriterer produktkøelementene basert på hensyn som risiko, forretningsverdi, avhengigheter, størrelse og datoen elementetne trengs.

Produktkøen er "hva som trengs sortert etter når det trengs", og er synlig for alle, men kan bare endres etter samtykke fra produkteieren som er ansvarlig for å administrere og vedlikeholde elementene i produktkøen.

Produktkøen inneholder produkteierens vurderinger av forretningsverdi, og kan inkludere teamets vurdering av forventet innsats eller kompleksitet (ofte, men ikke alltid, oppgitt i story points ved å bruke en avrundet Fibonacci-følge). Disse estimatene hjelåe produkteieren med å anslå tidslinjen, og kan påvirke prioriteringen av elementene i produktkøen. For eksempel kan produkteieren planlegge at utav to funksjoner med lik forretningsverdi, så skal den ene arbeidsoppgaven med mindre utviklingsinnsats gjøres først (fordi det gir høyere avkastning) eller at oppgaven med større utviklingsinnsats gjøres først (fordi den er mer kompleks eller risikofylt, og de vil eliminere den risikoen tidligere).

Produktkøen og forretningsverdien til hvert produktkøelement er produkteierens ansvar. Innsatsen som kreves for å levere hvert element kan estimeres i story points eller tid. Ved å estimere i story points reduserer teamet avhengigheten til individuelle utviklere, og dette er spesielt nyttig for dynamiske team hvor utviklerne ofte blir tildelt annet arbeid etter sprintlevering. Dersom for eksempel en brukerhistorie estimeres som en 5 i innsats (ved hjelp av Fibonacci-følgen) forblir den estimert som 5 uansett hvor mange utviklere som jobber med oppgaven.

Story points definerer innsatsen i en tidsboks slik at de ikke endres med tiden. For å ta et eksempel i overført betydning kan en person bruke en time på å gå, løpe eller klatre, men innsatsen som må legges inn blir helt klart annerledes. Den økende avstanden mellom Fibonacci-tallene oppfordrer teamet til å være varsmomme med å gi nøye vurderte estimater. Estimat på 1, 2 eller 3 impliserer lignende innsatsmengder (hvor 1 er en triviell mengde), men dersom teamet anslår 8 eller 13 (eller høyere) i innsatsmengde kan innvirkningen på både leveranse og budsjett være betydelig. Verdien av å bruke story points er at de kan gjenbrukes av teamet ved å sammenligne med lignende arbeid fra tidligere sprinter, men man bør være observant på at estimater er relative til det teamet. For eksempel kan en oppgave som gir et passende estimat på 5 for ett team tilsvare 2 for en annet team sammensatt av mer erfarne utviklere med høyere kapasitet.

Hvert team bør ha en produkteier, men i mange tilfeller kan en produkteier jobbe med flere enn ett team. Produkteieren er ansvarlig for å maksimere verdien til produktet. Produkteieren tar imot innspill og tilbakemeldinger fra mange mennesker, men tar til slutt den endelige avgjørelsen om hva som blir bygget.

Produktkøen:

• Fanger opp forespørsler om å endre et produkt, inkludert nye funksjoner, erstatning av gamle funksjoner, fjerning av funksjoner og løsning av problemer
• Sikrer at utviklerne har arbeid som maksimerer virksomhetens nytte av produktet

Vanligvis jobber hele teamet sammen for å finjustere produktkøen. Det er naturlig at produktkøen utvikler seg etterhvert som det dukker opp mer informasjon om produktet og dets kunder, og disse behovene kan gjøres noe med i senere sprinter.

Administrasjon

En produktkø er i sin enkleste form en liste over arbeidsopgaver. Å ha veletablerte regler for hvordan arbeid legges til, fjernes og rangeres hjelper hele teamet med å ta bedre beslutninger om hvordan produktet skal endres.

Produkteieren prioriterer elementene i produktkøen basert på hvilke av dem som trengs tidligst. Basert på sprintmålet velger utviklerne elementer for den kommende sprinten, og flytter disse elementene fra produktkøen til sprintkøen. Konseptuelt påvirkes spintmålene av de høyt prioritets elementene i sprintkøen, men det er ikke uvanlig at utviklere tar for seg noen lavere priortitere elemeneter dersom det er tid til overs innenfor sprinten.

Høyt prioriterte elementer (på toppen av køen) bør brytes ned mer detaljert slik at de er egnet for at utviklerne kan jobbe med dem. Jo lengre ned man kommer i køen, jo mindre detaljerte trenger elementene å være. Schwaber og Beedle har uttalt at "Jo lavere prioritet, desto mindre detaljer før man knapt kan se køelementet."

Etterhvert som teamet arbeider seg gjennom køen må man anta at endringer skjer utenfor deres miljø. Teamet kan bli kjent med nye markedsmuligheter som de kan utnytte, det kan oppstå trusler fra konkurrenter, og det kan komme tilbakemeldinger fra kunder som kan endre hvordan produktet er ment å fungere. Alle disse idéene har en tendens til å trigge teamet til å tilpasse køen for å innarbeide den nye kunnskapen. Dette er en del av den grunnleggende tankegangen til et smidig team: Verden endrer seg, og køen blir aldri ferdig.

Sprintkø

Sprintkøen er utvalgte elementer fra produktkøen som er planlagt utviklet i den aktuelle sprinten. Utviklerne vil fylle sprintkøen til de føler at de har nok arbeid til å fylle sprinten, og baserer seg da på tidligere resultater for å vurdere deres kapasitet og bruke dette som en retningslinje for hvor mye de kan fullføre i den kommende sprinten.

Arbeid i sprintkøen blir aldri tildelt utviklere, istedet henter teammedlemmene arbeidsoppgaver etter behov i henhold til køprioritet og deres egne ferdigheter og kapasitet. Dette fremmer selvorganisering hos utviklerne.

Sprintkøen tilhører utviklerne, og alle tilhørende estimater er gitt av utviklerne. Noen team bruker en kanbantavle for å visualisere tilstanden på arbeidsoppgavene i nåværende sprint med forskjellige felter for "må gjøres", "under arbeid", "ferdig" (todo, doing, done), men dette er ikke egentlig en del av scrum (se kanban).

Inkrement

Inkrementet er det potensielt utgivbare resultat fra sprinten som oppfyller sprintmålene. Inkrementet dannes av alle de fullførte elementene fra sprintkøen integrert med arbeidet fra alle de foregående sprintene. Inkrementet må være komplett i henhold til scrum sin definisjon av "ferdig" (definition of done, DoD), og må være i fullt brukbar tilstand uavhengig av hvorvidt produkteieren bestemmer seg for å faktisk deployere og ta det i bruk.

Utvidelser

De følgende artefaktene brukes av-og-til som hjelpemidler sammen med scrum:

Burndown-diagram

Eksempel på et burndown-diagram for en fullført sprint. Diagrammet viser gjenstående arbeid på slutten av hver dag.

Et burndown-diagram er en grafisk fremstilling av gjenstående arbeidsoppgaver sammenlignet med tid, og brukes for å forutsi når et arbeid vil bli fullført. Det brukes med scrum, men er strengt tatt ikke en del av scrum. Diagrammet oppdateres hver dag og kan gi en rask visualisering av prosjektets fremgang. Den horisontale aksen viser antall dager som gjenstår, mens den vertikale aksen viser hvor mye arbeid som gjenstår for hver dag.

Det idelle burndown-diagrammet plottes under sprintplanleggingen, og deretter oppdaterer utviklerne diagrammet dag for dag med gjenstående arbeid slik at man får en sammenligning av predikert og faktisk fremgang.

Release burnup-diagram

Eksempel på et burnup-diagram for en utgivelse som viser omfang fullført ved hver sprint. Linjen merket MVP viser til det enkleste brukbare produktet.

Et release burnup-diagram gir teamet mulighet for synlighet og sporing av fremgang mot en utgivelse. Det oppdateres på slutten av hver sprint, og viser fremgangen mot å levere et estimert omfang. Den horisonale aksen på burnup-diagrammet viser sprintene i en utgivelse, mens den vertikale aksen viser mengden arbeid fullført på slutten av hver av sprintene (typisk representert med kumulative story points for fullført arbeid). Fremdriften plottes som en linje som vokser oppover for å møte en horisontal linje som representerer the estimerte omfanget, vist med et estimat basert på fremgangen til dags dato som indikerer hvor mye av omfanget som ventes å fullføres ved en gitt utgivelsesdato, eller hvor mange sprinter det vil ta å fullføre det gitte omfanget.

Utgivelsesdiagrammet skal gjøre det enkelt å se hvor mye arbeid som har blitt fullført, hvor mye arbeid som har blitt lagt til eller fjernet (dersom den horisontale omfangslinjen har beveget seg) og hvor mye arbeid som gjenstår.

Definisjonen av klar

Definisjonen av hva som regnes for "klart" (definition of ready, DoR) er et startkriterie for å avgjøre hvorvidt spesifikasjonene og innputt er satt tydelig nok til å starte arbeidselementet.

Definisjonen av ferdig

Definisjonen av hva som regnes for "ferdig" (definition of done, DoD) er et avslutningskriterie som brukes for å avgjøre hvorvidt et sprintkøelement regnes som fullført. For eksempel kan en definisjon av ferdig kreve at alle regresjonstester er vellykket (altså at endringer i programvaren ikke har ødelagt funksjonalitet som pleide å fungere). Definisjonen av ferdig kan variere fra et team til et annet, men må være konsekvent innenfor et team.

Hastighet

Hastigheten eller implementeringshastigheten er et mål på teamets totale innsatskapasitet for en enkelt sprint, utledet ved å evaluere arbeidet som ble fullført i den forrige sprinten. Historiske hastighetsdata brukes da ofte som en rettesnor for å hjelpe teamet med å forstå kapasiteten deres i form av hvor mye arbeid de komfortabelt kan regene med å utføre.

Hastighetsmålet har vært kontroversielt innen scrummijøet:

• Forbrukte story points tilsvarer ikke levert verdi: Fokus på arbeidet som er gjort kan føre til at teamet mister fokus på fordeler interessenten får av leveransen.
• Innføring av distraherende prosesser: Det kan bli fokus på sammenligning av estimeringer kontra faktiske forhold, undersøkelser av varians, og man kan få en økende praksis med re-estimeringer.
• Ledelsen kan begynne å se på hastighet som et ytelsesmål og forsøke å øke hastigheten, hvilket medfører at:
  • Kvalitet blir lidende: Teamet begynner å ta snarveier for å inkludere ekstra arbeidsbelastninger.
  • Moralen blir lidende: Teamet er ikke i stand til å arbeide i et behagelig og bærekraftig tempo, og økt press fører til utbrenthet.
  • Estimering blir lidende: Utviklerne vil blåse opp estimater for å bygge inn buffere og utnytte ytelsesmålet, og ender bare opp med å måle den samme innsatsen på en annen skala.
  • Verdien blir lidende: Slutteffekten er forstyrrelser som forårsaker misnøye hos interessenten som følge av å bytte fokus bort fra levering av forretningsverdi.

Det finnes en verdi i å forstå leveransekapasiteten til et team som en indikator for teamet, men man bør ikke anse det som noe man kan justere.

Spike

En spike er en tidsboks brukt til å undersøke et konsept eller lage en enkel prototype. Spikes kan enten planlegges å finne sted i mellom sprinter eller (gjerne for større team) bli tatt inn i sprinten som et av mange sprintmål. Spikes brukes ofte før levering av store eller komplekse produktkø-elementer for å sikre budsjett, skaffe kunnskap eller fremstille et konseptbevis. Varigheten og målene for spiken blir teamet enig om før den settes i gang. I motsetning til sprintforpliktelser behøver ikke spikes å levere konkret, utgivbar og verdifull funksjonalitet. For eksempel kan et spikemål være å lykkes med å ta en beslutning om å velge et konkret handlingsforløp. Spiken er over når tiden er ut, ikke nødvendigvis når målet har blitt levert.

Sporlys

Et sporlys (tracer bullet) er en spike med nåværende arkitektur, nåværende teknologistakk og nåværende mønsterpraksis som resulterer i kode med produksjonskvalitet. Sporlyset kan være en veldig smal implementering av funksjonalitet, men er ikke bortkastet kode. Det skal ha produksjonskvalitet, og resten av iterasjonene skal kunne bygge på denne koden. Navnet har militær opprinnelse fra ammunisjon som lyser opp og gjør kulens bane synlig, hvilket gir mulighet for korrigeringer. Ofte er sporlys-implementeringer et hurtig skudd gjennom alle lagene i en applikasjon, som for eksempel å koble inndatafeltet i et enkelt skjema på klientdelen (frontend) med tjenerdelen (backend) for å bevise at lagene kan kobles sammen som forventet..

Begrensninger

Fordelene med scrum kan være vanskelige å oppnå dersom:

• Teamet har medlemmer som er geografisk spredde eller jobber deltid: I scrum bør utviklere samhandle tett og kontinuerlig , og ideelt sett jobbe sammen på samme sted mesteparten av tiden. Til tross for at forbedringer i teknologi har redusert virkningen av disse barrierene (for eksempel ved å kunne samarbeide på en digital tavle) hevder manifestet for smidig programvareutvikling at den beste kommunikasjonsmetoden er ansikt til ansikt.
• Team hvor medlemmer har svært spesialiserte ferdigheter: I scrum bør utviklere ha T-formede ferdigheter slik at de også kan jobbe med oppgaver utenfor deres spesialisering. Dette kan oppmuntres av godt scrumlederskap. Teammedlemmer med svært spesifikke ferdigheter kan også bidra godt, men bør ifølge scrum oppfordres til å lære om fagområder og samarbeide mer med folk fra andre disipliner.
• Produkter med mange eksterne avhengigheter: I scrum kreves planlegging for å dele opp produktutviklingen i korte sprinter. Eksterne avhengigheter som for eksempel brukerakseptansetester eller koordinering med andre team kan føre til forsinkelser og feil i individuelle sprinter.
• Produkter som er modne, legacysystemer eller systemer med regulert kvalitetskontroll: I scrum skal produktinkrementer være fullt utviklet og testet iløpet av en enkelt sprint. Produkter som trenger store mengder regresjonstester for hver utgivelse (som for eksempel medisinsk utstyr eller styring av kjøretøy) er mindre egnet til korte sprinter enn lengre fossefall-utgivelser.

Tilgjengelige verktøy

  Det finnes et bredt spekter av verktøy som kan hjelpe med å ta i bruk scrum på en effektiv måte.

Mange bedrifter bruker generelle verktøy som for eksempel regneark for å bygge og vedlikeholde en sprintkø. Det finnes også egne programvarepakker (både med åpen og proprietær kildekode) som benytter scrumterminologi for for å hjelpe med produktutvikling.

Det er også mulig å implementere scrum uten programvareverktøy og istedet vedlikeholde artefaktene på papir, tusjtavle og notatlapper.

Scrumverdier

Scrum er en tilbakemeldingsdrevet empirisk tilnærming som i likhet med alle former for empirisk prosesskontroll understøttes av de tre søylene gjennomsiktighet, inspeksjon og tilpasning. Alt arbeid innenfor scrumrammeverket skal være synlig for de som er ansvarlige for utfallet: prosessen, arbeidsflyten, fremdriften, og så videre. For å gjøre disse tingene synlige må scrumteamet ofte inspisere produktet som utvikles og hvor godt teamet fungerer. Ved hyppig inspeksjon kan teamet oppdage når arbeidet avviker utenfor akseptable grenser og tilpasse prosessen eller produktet som er under utvikling.

Disse 3 søylene krever tillit og åpenhet i teamet, hvilket blir muliggjort av de følgende 5 scrumverdiene:

1. Engasjement: Teammedlemmene forplikter seg individuelt til at teammålene skal oppnås i alle sprintene.
2. Mot: Teammedlemmene vet at de har mot til å jobbe seg gjennom konflikter og utfordringer sammen slik at de kan gjøre det rette.
3. Fokus: Teammedlemmene fokuserer utelukkende på teamets mål og sprintkøen, og det bør ikke gjøres noe arbeid utenom det som står i køen.
4. Åpenhet: Teammedlemmene og deres interessenter er enige om å være åpne om sitt arbeid og eventuelle utfordringer de står overfor.
5. Respekt: Teammedlemmene respekterer hverandre for å være teknisk dyktige og å jobbe med gode hensikter.

Tilpasninger

Hybridiseringen av scrum med andre metoder for programvareutvikling er vanlig da scrum ikke dekker hele livssyklusen for produktutvikling, hvilket medfører at organisasjoner ser et behov for å legge til flere prosesser for å skape en mer komplett implementering. I starten av produktutviklingen legger for eksempel mange organisasjoner til prosessveiledning i prosjektbegrunnelsen, kravinnsamling og prioritering, et innledende høynivå-design, budsjett og en skisse for fremdrift.

Ulike forfattere og samfunn av mennesker som bruker scrum har også foreslått mer detaljerte teknikker for hvordan man kan bruke eller tilpasse scrum til bestemte problemer eller organisasjoner. Mange refererer til disse metodiske teknikkene som "mønstre" etter en analogi designmønstre innen arkitektur og programvare.

Scrumban

Scrumban er en produksjonsmodell for programvare basert på scrum og kanban. Scrumban er spesielt egnet for produktvedlikehold med hyppige og uventede arbeidselementer, som for eksempel produksjonsfeil eller programmeringsfeil. I slike tilfeller kan de tidsbegrensede sprintene i scrumrammeverket oppfattes å være av mindre nytte, selv om scrum sine daglige rutiner og annen praksis fortsatt kan brukes, avhengig av teamet og situasjonen for hånd. Visualisering av arbeidsfaser og begrensninger for samtidig uferdige arbeider og feil er kjent fra kanbanmodellen. Ved hjelp av disse metodene er teamets arbeidsflyt rettet på en måte som gir minimum tid for ferdigstillelse for hvert arbeidselement eller programmeringfeil, og sikrer på en annen side at hvert teammedlem konstant har arbeidsoppgaver.

For å illustrere hvert trinn i arbeidet bruker team som arbeider på samme sted ofte notatlapper eller en stor tavle. I tilfelle teamet er desentralisert kan det bruke programvarebaserte varianter som Jira.

Den store forskjellen mellom scrum og kanban er at i scrum er arbeidet delt inn i sprinter som varer en fast tid, mens i kanban er arbeidsflyten kontinuerlig. Dette kan sees i arbeidstabellene, som i scrum tømmes etter hver sprint, mens i kanban vil alle oppgaver ligge i samme tabell. Scrum fokuserer på team med allsidig kunnskap, mens kanban muliggjør spesialiserte funksjonelle team.

Scrum of scrums

Scrum of scrums er en teknikk for å ta i bruk scrum i større skala i form av flere scrumteam som arbeider på samme produkt slik at de kan diskutere fremgang på gjensidige avhengigheter, særlig på områder med overlapp og integrasjon. Det har et fokus på hvordan å koordinere leveranse av programvare,

Avhengig av kadensen eller timingen av scrum of scrums avsluttes den daglige scrummen for hvert scrumteamene ved å utpeke et medlem som en ambassadør for å delta i scrum of scrums med ambassadører fra andre team. Avhengig av konteksten kan ambassadørene for eksempel være tekniske bidragsytere eller hvert av teamene sin scrumleder.

Istedet for bare å fokusere på å oppdatere fremdriften bør scrum of scrums fokusere på hvordan teamene arbeider kollektivt for å løse, redusere eller akseptere risikoer, hindringer, avhengigheter og forutsetninger (samlet kalt RIDA-er fra: risks, impediments, dependencies, assumptions) som har blitt identifiserte. Scrum of scrums sporer disse risikoene, hindringene, avhengighetene og forutsetningene i en egen kø, for eksempel en risikotavle, noen ganger kalt ROAM-tavle (etter initialene til resolved, owned, accepted, mititagated) som vanligvis fører til bedre koordinering og samarbeid mellom teamene.

En scrum of scrums bør kjøres på lignende måte som en daglig scrum, for eksempel ved at hver ambassadør svarer på følgende fire spørsmål:

• Hvilke risikoer, hindringer, avhengigheter eller forutsetninger har teamet ditt løst siden vi sist møttes?
• Hvilke risikoer, hindringer, avhengigheter eller forutsetninger vil teamet ditt løse før vi møtes igjen?
• Er det noen nye risikoer, hindringer, avhengigheter eller forutsetninger som sakker ned eller kommer i veien for teamet ditt?
• Er du i ferd med å introdusere en ny risiko, hindring, avhengighet eller antagelse som kan komme i veien for et annet team?

Jeff Sutherland, som opprinelig definerte scrum of scrums, har kommentert at scrum of scrums ikke er en meta-scrum, og at det har blitt brukt med suksess. Han nevnte eksempler et prosjekt med PatientKeeper hvor de leverte til produksjon fire ganger per sprint, et prosjekt for Ancestry.com hvor de leverte til produksjon 220 ganger per 2-ukers sprint, og Hubspot hvor de leverte 100-300 ganger til produksjon om dagen. Scrum of scrums-ledere er ansvarlige for dette arbeidet, hvilket ifølge han gjør scrum av scrums til en operativ leveringsmekanisme

Scrum i storskala

Large-scale scrum (LeSS) er et rammerk for produktutvikling som utvider scrum med skaleringsregler og -retningslinjer uten å miste de opprinnelige formålene med scrum.

Rammeverket har to nivåer, hvor det første nivået av LeSS er designet for inntil 8 team, mens det andre nivået (kalt "LeSS Huge") introduserer flere skaleringselementer for å kunne drive utvikling med opp til hundrevis av utviklere. Ifølge en kilde starter scrum i storskala med å forstå at de enkelte scrum teamene må være ordentlige scrumteam som følger scrumrammeverket. Man skal så forsøkte å finne ut hvordan man kan nå de samme formålene samtidig som man holder seg innenfor begrensningene av de vanlige scrumreglene.

Bas Vodde og Craig Larman utviklet LeSS-rammeverket fra egne erfaringer med produktutvikling i stor skala, særlig innen telekom- og finansnæringene. De utviklet det ved å for seg scrum og prøvde mange forskjellige eksperimenter for å se hva som fungerte, inntil de i 2013 landet på LeSS-rammeverket. Hensikten med LeSS er å nedskalere organisasjonskompleksitet, løse opp unødvendig komplekse organisasjonsløsninger, og løse de på enklere måter gjennom færre roller, mindre ledelse og færre organisasjonsstrukturer.

Kritikk

Scrum har blitt kritisert fra mange hold. Dette har stort sett blitt forsvart med at de som kritiserer angivelig bruker konseptene dårlig og forventer gode resultater, eller misforstår de kulturelle endringene som scrum krever:

• Scrummøter har blitt kritisert for å hindre produktivitet og kaste bort tid som kunne blitt brukt bedre på faktiske produktive oppgaver. En mulig forklaring på dette kan være en misforståelse av møtenes formål slik at møtene blir for langtekkelige og grundige istedet for en kort tidboks med diskusjoner.
• Scrumprosesser som ikke skjer i tråd med manifestet for smidig utvikling har en tendens til å utvikle seg til en form for mikromanagement og gjeninnfører de samme dysfunksjonene som de var ment å fjerne.
• Scrum antar også at innsatsen som kreves for å fullføre arbeidet kan estimeres nøyaktig, selv om dette ofte kan være ganske uforutsigbart.
• Scrum unngår med vilje å beskrive hvordan det skal praktiseres for å oppmuntre til frihet til empirisk analyse og eksperimentering.
• Scrum oppfattes å være en form for styring av prosjekter snarere enn en alternativ tilnærming til det
• Å ta i bruk scrum vil ikke gi resultater av høy kvalitet umiddelbart, og utålmodighet kan således hindre scrum fra å sette seg og vokse

Vanlige dysfunksjonelle tilnærminger til scrum har blitt anerkjent som antimønstre, inkludert under navn som dark scrum og scream.

Se også

• Strømlinjeformet produksjon og strømlinjeformet programvareutvikling
• Prosjektledelse
• Enhetlig prosess
• Informasjonssystem
• Ekstrem programmering