Meny

Scrum-gjenstander: Product Backlog, Sprint Backlog and Product Increments

  • Hoved
  • Annen
  • Scrum-gjenstander: Product Backlog, Sprint Backlog and Product Increments

scrum artifacts product backlog

Prøv Instrumentet Vårt For Å Eliminere Problemer

Introduksjon til Scrum-gjenstander:

I de forrige artiklene i denne serien ble vi introdusert for smidig og de forskjellige smidige metodene . Vi lærte også om hvordan de forskjellige metodene er forskjellige på sin egen måte.

I vår siste opplæring gikk vi inn i detaljene til Scrum der vi diskuterte Scrum-roller som produkteier, Scrum Master og scrumteamet og så hva deres individuelle ansvar var.

I denne opplæringen fortsetter vi med Scrum og går videre inn i detaljene om de forskjellige scrumgjenstandene.

Scrum gjenstander

Hva du vil lære:

Ulike Scrum-gjenstander

Tre typer scrumgjenstander inkluderer:

  • Produktet etterslep
  • Sprintforsinkelse og
  • Produktstigninger

Nå skal vi se hva disse begrepene betyr og hvordan vi lager disse gjenstandene.

Scrum Artefakter-typer

Produktet etterslep

For å si det enkelt, er et produktetterslep en liste over alle tingene som kreves i produktet. Det er det endelige dokumentet som scrumteamet skal henvise til for alt som er relatert til produktet. Det er en bestilt liste over varer som eies av produkteieren (PO).

PO er ansvarlig for å opprette, vedlikeholde og prioritere denne listen. PO-ene bruker dette produktetterslepet for å forklare de viktigste kravene som må gjøres under sprinten til scrum-lagene.

Elementene i denne listen kan eller ikke være på et teknisk språk. Det kan til og med være et lekmannsspråk, men det skal inneholde alle produktkrav og medfølgende endringer. Å ha et produktetterslep betyr ikke at scrumteamet bare vil ha denne artefakten å følge.

De kan lage sine egne detaljerte gjenstander, men de motsier ikke eller erstatter etterslepet. De vil heller være i samsvar med kravene til produktets etterslipp.

Nedenfor er et eksempel på hvordan en typisk produktforsinkelse kan se ut:

HistorieanslagPrioritet
Jeg vil logge inn41
Jeg vil logge avtoto
Jeg vil endre passord13
Jeg vil oppdatere adressen34
Jeg vil legge til et nytt hjemmetelefonnummer15

Dette bringer oss til spørsmålet, hvordan lage et godt produktetterslep?

Et produktetterslep bør ideelt sett følge reglene nedenfor:

(i) Det bør prioriteres - Varene i produktets forsinkelse bør bestilles i henhold til deres prioritet. Denne prioriteten kan avgjøres av PO og scrum-teamet sammen. Prioriteringsfaktorene kan være som fordeler fra historien, innsatsen som er involvert i opprettelsen, kompleksitet, kundeprioritet etc.

Det hjelper teamet med å forstå hva som må leveres først.

(ii) Det bør estimeres - Historiene skal alltid estimeres i henhold til avtalt definisjon, uansett hva det måtte være. Dette kan også brukes til prioritering.

(iii) Det skal være høyt nivå - Historiene i produktetterslepet er ment å være på høyt nivå og bør ikke gå i detaljene. Opprettelse av detaljerte brukerhistorier i henhold til kravet er opp til scrumteamet og ikke PO.

(iv) Det skal være dynamisk - Produktet etterslep er ikke et endelig statisk dokument. Det bør sees på nytt ettersom PO mottar innspill fra scrumteamet og kundens krav blir mer og mer tydelige. Dermed fryses ikke dokumentkravene helt i begynnelsen fordi det forventes tillegg / slettinger / modifikasjoner etter hvert som prosjektet skrider frem.

Det siste punktet er det mest relevante. Hensikten med et produktetterslep er å være en aktiv kravkilde. Det skal ikke opprettes i begynnelsen og deretter oppbevares på et lagringssted.

I stedet er det ment å deles igjen og igjen når endringene stadig kommer opp. Nye krav kan komme opp etter hvert som fremgangen gjøres, og det kan også endre prioriteten til etterslaget. Det vil være situasjoner der et nytt krav er avhengig av et annet element i etterslaget, slik at vareprioriteten kanskje må byttes om.

Eller det kan være en kritisk brukerhistorie som kanskje må implementeres først fordi kunden ønsker å se det før de andre, selv om det kanskje ikke er høyt prioritert i henhold til faktorene som er bestemt av PO og scrumteamet.

Dermed er produktetterslepet en ordnet liste over forretningskrav som eies av PO og besøkes gang på gang etter hvert som prosjektet skrider frem.

Sprint Backlog

Du husker kanskje at scrum-teamene jobber i korte iterasjoner på 2 til 4 uker, kalt sprint. I løpet av disse sprintene identifiserer scrumteamet varene fra produktetterslepet opprettet av PO, som de planlegger å levere som en del av neste iterasjon. Elementene som scrumteamet velger å jobbe med blir en del av sprintforsinkelsen.

Dermed bestemmer de hvilke funksjoner som skal være der i neste iterasjon av produktet. Scrum-teamet er det som bestemmer hva som skal inn i sprintforsinkelsen, ettersom det er de som skal jobbe med det.

Dermed er det de som bør estimere innsatsen som er involvert i å implementere historiene og bestemme hvor mye de kan levere.

Teamet plukker ikke bare varene fra produktets forsinkelse å jobbe med, men de legger også et estimat på hvor mye tid det vil ta for dem å utvikle den funksjonaliteten. De legger også til brukernivåene på høyt nivå ved å lage detaljerte oppgaver som kreves for å nå sprintmålet.

hvordan du åpner en .bin fil i Windows

Scrum-teamet kan også fortsette å oppdatere sprintforsvaret når og når det kreves under sprinten, men det er bare scrumlaget som kan gjøre endringer i sprintforsvaret.

En typisk Sprint Backlog vil se ut som vist nedenfor.

Sprint Backlog

Teamet kan ideelt sett oppdatere dette en gang om dagen, og scrum-mesteren kan bruke denne informasjonen til å lage et sprintnedbruddskart. Dette nedbrytningsdiagrammet vil hjelpe teamet å se hvor mye arbeid som fortsatt er igjen for sprinten, og teamet kan planlegge sitt arbeid deretter. De kan til og med legge til eller fjerne oppgaver om nødvendig.

Noen gode fremgangsmåter når du oppretter et sprintforsinkelse kan være:

# 1) Ta gruppebeslutninger - Det skal ikke være scrummesteren eller noe annet scrumteammedlem som bestemmer etterslepet. Snarere bør det være hele teamet sammen som bestemmer hvilke ting som skal inkluderes i sprintforsinkelsen og hvordan de skal planlegge for dem.

Hvert medlem av dette tverrfunksjonelle teamet har sine egne ferdigheter, og det er viktig at vi bruker deres erfaring for å skape et best mulig etterslep.

# 2) Ikke tildel oppgaver - Siden det har blitt gjentatt flere ganger i den smidige litteraturen, må du aldri tildele oppgaver til teammedlemmene. Et scrumteam skal være selvforsynt, og de bør vite hvordan de skal organisere arbeidet sitt alene.

Så i stedet for å tildele arbeid, bør vi la teamet velge arbeid for seg selv og bestemme seg imellom for hvordan de vil fortsette.

# 3) Definisjon av gjort - Det skal ikke bare avtales av interessentene, men også gjøres tydelig synlig for teamet når som helst når de må ta noen avgjørelse angående sprintmålene. Dette vil tjene som en påminnelse om hva som nøyaktig må gjøres før de kan levere et fungerende produkt som kan sendes.

# 4) Fortsett å oppdatere etterslepet - Det er viktig at når sprinten utvikler seg, vil teamet få større forståelse, og derfor bør de derfor oppdatere sprintforsinkelsen for å gjenspeile denne større forståelsen også. Det skal ikke bli et statisk dokument når som helst.

# 5) Legg til en hvilken som helst oppgave - Oppgaven trenger ikke bare å være relatert til koding, men det kan være viktig å levere et produkt som kan sendes. Nevn derfor også slike oppgaver i etterslaget.

Produktøkninger

Dette bringer oss til den siste scrum-artefakten som er produktstegene. Som definert av scrumguiden, er en økning summen av alle Produktet Backlog elementer fullført i løpet av en Sprint og verdien av trinnene til alle tidligere Sprints. Som vi vet godt nå, er Scrum en iterativ prosess.

Resultatet av hver iterasjon er dette produktinngangen, og hvert slikt produktinnsamling hjelper teamet til å ta et skritt nærmere mot å levere sluttproduktet.

Hva dette betyr er at det som var resultatet av sprinten, er en økning. Åpenbart, for at resultatet skal betraktes som en økning, bør det først oppfylle den forhåndsdefinerte definisjonen av gjort, dvs. at sluttresultatet skal være et brukbart produkt som er i stand til å 'sende'.

Det kan kontrolleres, brukes og testes for å sikre at det virkelig er 'gjort' i henhold til definisjonen, og hvis produktseieren ønsker det, kan det slippes for å gå live også.

Det viktigste for å levere dette produktøkningen er å ha en felles forståelse av 'definisjonen av ferdig' som alle forstår.

Scrum-laget skal aldri være i tvil om det de gjør blir akseptert eller ikke. Hvis det er tvil, bør definisjonen av gjort være fullstendig nok til å veilede dem om hvordan du går videre. Basert på denne definisjonen, bestemmer scrumteamet hvor mange produktforsinkelser som skal velges for sprinten.

Dette er minimum som forventet ut av sprinten.

Konklusjon

Fra denne opplæringen har vi forstått hva som er de tre scrum-gjenstandene, som eier dem sammen med noen av de beste fremgangsmåtene som kan hjelpe oss med å lage gjenstander av bedre kvalitet. I de neste opplæringene våre i denne serien vil vi diskutere Scrum-hendelsene og se hvordan vi kan gjennomføre disse hendelsene.

I vår kommende opplæring om ‘Scrum arrangementer , ’Vi skal diskutere hvert av Scrum-arrangementet i detalj!

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^