Menu

Scrum-artefakter: Product Backlog, Sprint Backlog og Product Increments

  • Vigtigste
  • Andet
  • Scrum-artefakter: Product Backlog, Sprint Backlog og Product Increments

scrum artifacts product backlog

Prøv Vores Instrument Til At Fjerne Problemer

Introduktion til Scrum-artefakter:

I de tidligere artikler i denne serie blev vi introduceret til adræt og de forskellige agile metoder . Vi lærte også om, hvordan de forskellige metoder er forskellige på deres egen måde.

I vores sidste vejledning gik vi ind i detaljerne i Scrum, hvor vi diskuterede Scrum roller som Product Owner, Scrum Master og scrum-teamet og så, hvad deres individuelle ansvar var.

I denne vejledning fortsætter vi med Scrum og går videre ind i detaljerne om de forskellige scrumartefakter.

Scrum artefakter

Hvad du vil lære:

Forskellige Scrum-artefakter

Tre typer scrumartefakter inkluderer:

  • Produktforsinkelse
  • Sprint efterslæb og
  • Produktforøgelser

Nu vil vi se, hvad disse udtryk betyder, og hvordan man opretter disse artefakter.

Scrum-artefakter-typer

Produktforsinkelse

For at udtrykke det i enkle vendinger er en produktforsinkelse en liste over alle de ting, der kræves i produktet. Det er det sidste dokument, som scrum-teamet henviser til for alt, hvad der er relateret til produktet. Det er en ordret liste over varer, der ejes af produktejeren (PO).

PO er ansvarlig for at oprette, vedligeholde og prioritere denne liste. PO'erne bruger dette produktforsinkelse til at forklare de vigtigste krav, der skal gøres under sprinten til scrum-holdene.

Emnerne på denne liste er måske ikke på et teknisk sprog. Det kan endda være et lægmandssprog, men det skal indeholde alle produktkrav og de medfølgende ændringer. At have et produktforsinkelse betyder heller ikke, at scrumteamet kun har denne artefakt at følge.

De kan oprette deres egne detaljerede artefakter, men de modsiger ikke eller erstatter produktets efterslæb. De vil snarere være i overensstemmelse med kravene til produktets efterslæb.

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

HistorieSkønPrioritet
Jeg vil logge ind41
Jeg vil logge aftoto
Jeg vil ændre adgangskode13
Jeg vil opdatere adressen34
Jeg vil tilføje et nyt hjemmetelefonnummer15

Dette bringer os til spørgsmålet, hvordan man opretter et godt produktforsinkelse?

Et produktforsinkelse skal ideelt set følge nedenstående regler:

(i) Det bør prioriteres - Varerne i produktforsinkelsen skal bestilles efter deres prioritet. Denne prioritet kan afgøres af PO og scrum-teamet sammen. Prioriteringsfaktorerne kan være ligesom fordele ved historien, indsatsen involveret i oprettelsen, kompleksitet, kundeprioritet osv.

Det hjælper holdet med at forstå, hvad der skal leveres først.

(ii) Det skal estimeres - Historierne skal altid estimeres i henhold til den aftalte definition, uanset hvad det måtte være. Dette kan også bruges til prioritering.

(iii) Det skal være højt niveau - Historierne i produktforsinkelsen er beregnet til at være på et højt niveau og bør ikke gå i detaljer. Oprettelse af detaljerede brugerhistorier i henhold til kravet er op til scrumteamet og ikke PO.

(iv) Det skal være dynamisk - Produktforsinkelsen er ikke et endeligt statisk dokument. Det bør tages op igen, da PO modtager input fra scrumteamet, og kundens krav bliver mere og mere klare. Dokumentkravene fryses således ikke lige i starten, fordi der forventes tilføjelser / sletninger / ændringer, når projektet skrider frem.

Det sidste punkt er det mest relevante. Formålet med et produktforsinkelse er at være en aktiv kravkilde. Det skal ikke oprettes i begyndelsen og derefter opbevares på et lagersted.

I stedet er det meningen, at det skal deles igen og igen, da ændringerne fortsætter med at komme op. Nye krav kan komme op, når fremskridtene sker, og det kan også ændre prioriteten for efterslæbsposter. Der vil være situationer, hvor et nyt krav afhænger af et andet emne i efterslæbet, så det kan være nødvendigt at omlægge vareprioriteten.

Eller der kan være en kritisk brugerhistorie, som muligvis først skal implementeres, fordi kunden ønsker at se det før de andre, selvom det måske ikke er højt prioriteret i henhold til de faktorer, som PO og scrumteamet beslutter.

Således er produktforsinkelsen en ordnet liste over forretningskrav, der ejes af PO og besøges igen og igen, når projektet skrider frem.

Sprint-efterslæb

Du kan måske huske, at scrum-holdene arbejder i korte iterationer på 2 til 4 uger kaldet en sprint. I løbet af disse sprints identificerer scrumteamet varerne fra produktforsinkelsen oprettet af PO, som de planlægger at levere som en del af den næste iteration. De emner, som scrumteamet vælger at arbejde på, bliver en del af sprintforsinkelsen.

Således beslutter de, hvilke funktioner der skal være der i den næste iteration af produktet. Scrum-teamet er den, der beslutter, hvad der skal ind i sprintforsinkelsen, da det er dem, der skal arbejde på det.

Således er det dem, der skal estimere den indsats, der er involveret i implementeringen af ​​disse historier og beslutte, hvor meget de kan levere.

Holdet vælger ikke kun varerne fra produktets efterslæb, der skal arbejdes med, men de sætter også et skøn over, hvor lang tid det tager for dem at udvikle den funktionalitet. De føjer også til brugerhistorierne på højt niveau ved at oprette detaljerede opgaver, der kræves for at nå sprintmålet.

hvor man kan se anime gratis online

Scrum-holdet kan også fortsætte med at opdatere sprintforsinkelsen, når og når det kræves under sprinten, men det er kun scrumholdet, der kan foretage ændringer i sprintforsinkelsen.

En typisk Sprint Backlog vil se ud som vist nedenfor.

Sprint-efterslæb

Holdet kan ideelt opdateres dette en gang om dagen, og scrummasteren kan bruge disse oplysninger til at oprette et sprint nedbrudt diagram. Dette nedbrændingsdiagram hjælper holdet med at se, hvor meget arbejde der stadig er tilbage til sprinten, og holdet kan planlægge deres arbejde i overensstemmelse hermed. De kan endda tilføje eller fjerne opgaver, hvis det kræves.

Nogle bedste fremgangsmåder, når du opretter et sprintforsinkelse, kan være:

# 1) Lav gruppebeslutninger - Det bør ikke være scrummasteren eller noget andet scrumteammedlem, der beslutter efterslæbet. Det skal snarere være hele teamet, der sammen beslutter, hvilke ting der skal medtages i sprintforsinkelsen, og hvordan man planlægger dem.

Hvert medlem af dette tværfunktionelle team har deres egne færdigheder, og det er vigtigt, at vi bruger deres erfaring til at skabe den bedst mulige efterspørgsel.

# 2) Tildel ikke opgaver - Da det er gentaget flere gange i den agile litteratur, skal du aldrig tildele opgaver til teammedlemmerne. Et scrum-team formodes at være selvforsynende, og de skal vide, hvordan de organiserer deres arbejde alene.

Så i stedet for at tildele arbejde, skal vi lade teamet vælge arbejde for sig selv og beslutte indbyrdes, hvordan de vil fortsætte.

# 3) Definition af gjort - Det skal ikke bare være aftalt af interessenterne, men også gøres klart synligt for holdet på alle punkter, når de skal træffe nogen beslutning vedrørende sprintmålene. Dette vil tjene som en påmindelse om, hvad der nøjagtigt skal gøres, før de kan levere et fungerende produkt, der kan sendes.

# 4) Fortsæt med at opdatere efterslæbet - Det er bydende nødvendigt, at efterhånden som sprinten udvikler sig, får teamet en større forståelse, og derfor bør de derfor opdatere sprintforsinkelsen for også at afspejle denne større forståelse. Det bør ikke blive et statisk dokument på noget tidspunkt.

# 5) Tilføj enhver opgave - Opgaven behøver ikke kun at være relateret til kodning, men det kan være vigtigt at levere et produkt, der kan sendes. Derfor nævnes også sådanne opgaver i efterslæbet.

Produktforøgelser

Dette bringer os til den sidste scrumartefakt, som er produktstigningerne. Som defineret af scrumguiden er en stigning summen af ​​alle Produkt-efterslæbsposter afsluttet i løbet af en Sprint og værdien af ​​trinene i alle tidligere Sprints. Som vi ved godt nu, er Scrum en iterativ proces.

Resultatet af hver iteration er dette produkts forøgelse, og hvert sådant produktforøgelse hjælper holdet med at tage et skridt nærmere mod at levere slutproduktet.

Hvad dette betyder er, at uanset hvad der var resultatet af sprinten er en stigning. For at resultatet skal betragtes som en forøgelse, skal det naturligvis først opfylde den foruddefinerede definition af færdig, dvs. slutresultatet skal være et brugbart produkt, der er i stand til 'forsendelse'.

Det kan kontrolleres, bruges og testes for at sikre, at det virkelig er 'gjort' i henhold til definitionen, og hvis produktejeren ønsker det, kan det også frigives til live.

Det vigtigste ved at levere dette produkts inkrement er at have en fælles forståelse af 'definitionen af ​​færdig', som forstås af alle.

Scrum-holdet burde aldrig være i tvivl om, hvad det, de laver, bliver accepteret eller ej. Hvis der er tvivl, bør definitionen af ​​gjort være fuldstændig nok til at guide dem om, hvordan man går videre. Baseret på kun denne definition beslutter scrumteamet, hvor mange produktforsinkelser, der skal vælges til sprinten.

Dette er minimumet som forventet ud af sprinten.

Konklusion

Fra denne vejledning har vi forstået, hvad der er de 3 scrum-artefakter, der ejer dem sammen med nogle af de bedste fremgangsmåder, der kan hjælpe os med at skabe artefakter af bedre kvalitet. I vores næste tutorials i denne serie vil vi diskutere Scrum-begivenhederne og se, hvordan man udfører disse begivenheder.

I vores kommende vejledning om 'Scrum Begivenheder , ”Vi vil diskutere hver af Scrum-begivenhederne i detaljer!

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^