Meny

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

  • Huvud
  • Övrig
  • Scrum-artefakter: Product Backlog, Sprint Backlog och Product Increments

scrum artifacts product backlog

Prova Vårt Instrument För Att Eliminera Problem

Introduktion till Scrum-artefakter:

I de tidigare artiklarna i denna serie introducerades vi till smidig och de olika smidiga metoderna . Vi lärde oss också hur de olika metoderna skiljer sig åt på sitt eget sätt.

I vår senaste handledning gick vi in ​​i detaljerna i Scrum där vi diskuterade Scrum-roller som produktägare, Scrum Master och scrumteamet och såg vad deras individuella ansvar var.

I denna handledning fortsätter vi med Scrum och går vidare in i detaljerna om de olika scrum-artefakterna.

Scrum-artefakter

Vad du kommer att lära dig:

Olika Scrum-artefakter

Tre typer av scrum-artefakter inkluderar:

  • Produktstock
  • Sprint eftersläp och
  • Produktsteg

Nu får vi se vad dessa termer betyder och hur man skapar dessa artefakter.

Scrum-artefakter-typer

Produktbacklog

För att uttrycka det i enkla termer är en produktbacklog en lista över alla saker som krävs i produkten. Det är det slutliga dokumentet som scrumteamet hänvisar till för allt som har med produkten att göra. Det är en beställd lista med artiklar som ägs av produktägaren (PO).

PO är ansvarig för att skapa, underhålla och prioritera denna lista. PO: erna använder denna produktförsening för att förklara de högsta kraven som måste göras under sprinten till scrumlagen.

Objekten i den här listan kanske eller inte är på ett tekniskt språk. Det kan till och med vara lekmannaspråk, men det bör innehålla alla produktkrav och tillhörande ändringar. Att ha en eftersläpning av produkter betyder inte att scrumteamet bara kommer att ha denna artefakt att följa.

De kan skapa egna detaljerade artefakter men de kommer inte att motsäga eller ersätta produktens eftersläpning. De kommer snarare att vara i linje med kraven på produktbackloggen.

Nedan följer ett exempel på hur en typisk produktstock kan se ut:

BerättelseUppskattaPrioritet
Jag vill logga in41
Jag vill logga uttvåtvå
Jag vill byta lösenord13
Jag vill uppdatera adressen34
Jag vill lägga till ett nytt hemtelefonnummer15

Detta leder oss till frågan, hur man skapar en bra produktstock?

En produktförsening bör helst följa nedanstående regler:

(i) Det bör prioriteras - Varorna i produktstocken bör beställas enligt deras prioritet. Denna prioritering kan beslutas av PO och scrumteamet tillsammans. Prioriteringsfaktorerna kan vara som att dra nytta av berättelsen, ansträngningen i skapandet, komplexitet, kundprioritet etc.

Det hjälper teamet att förstå vad som måste levereras först.

(ii) Det bör uppskattas - Berättelserna bör alltid uppskattas enligt den överenskomna definitionen, oavsett vad det är. Detta kan också användas för prioritering.

(iii) Det bör vara högt - Berättelserna i produktstocken är tänkta att vara höga och bör inte gå in i detaljerna. Skapandet av detaljerade användarberättelser enligt kravet är upp till scrumteamet och inte PO.

(iv) Det ska vara dynamiskt - Produktens eftersläpning är inte ett slutligt statiskt dokument. Det bör ses över när PO får inmatningar från scrumteamet och kundkraven blir allt tydligare. Således fryses inte dokumentkraven direkt i början eftersom det finns tillägg / raderingar / modifieringar som förväntas när projektet fortskrider.

Den sista punkten är den mest relevanta. Syftet med en produktförsening är att vara en aktiv kravkälla. Det ska inte skapas i början och sedan förvaras på en lagringsplats.

Istället är det tänkt att delas om och om igen när förändringarna fortsätter att komma upp. Nya krav kan komma upp när framstegen görs och det kan också ändra prioriteten för eftersläppsposterna. Det kommer att finnas situationer där ett nytt krav är beroende av ett annat objekt i eftersläpningen, så artikelprioriteten kan behöva blandas om.

Eller det kan finnas en kritisk användarberättelse som kanske måste implementeras först eftersom kunden vill se det före de andra även om det kanske inte är högt prioriterat enligt de faktorer som beslutats av PO och scrumteamet.

Produktstocken är alltså en beställd lista över affärsbehov som ägs av PO och besöks i tid och igen när projektet fortskrider.

Sprint Backlog

Du kanske kommer ihåg att scrumteamen arbetar i korta iterationer på 2 till 4 veckor som kallas en sprint. Under dessa sprintar identifierar scrumteamet artiklarna från produktbackloggen som skapats av PO, som de planerar att leverera som en del av nästa iteration. Föremålen som scrumteamet väljer att arbeta med blir en del av sprintbackloggen.

Således bestämmer de vilka funktioner som kommer att finnas där i nästa iteration av produkten. Scrumteamet är det som bestämmer vad som ska gå in i sprintbackloggen eftersom det är de som ska arbeta med det.

Således är det de som bör uppskatta ansträngningen för att genomföra dessa berättelser och bestämma hur mycket de kan leverera.

Teamet plockar inte bara föremålen från produktstocken att arbeta med, men de gör också en uppskattning av hur mycket tid det tar för dem att utveckla den funktionen. De lägger också till användarberättelser på hög nivå genom att skapa detaljerade uppgifter som krävs för att uppnå sprintmålet.

konvertera char-nummer till int c ++

Scrumteamet kan också fortsätta att uppdatera sprintbackloggen när det behövs under sprinten, men det är bara scrumteamet som kan göra ändringar i sprintbackloggen.

En typisk Sprint Backlog kommer att se ut som visas nedan.

Sprint Backlog

Teamet kan helst uppdatera detta en gång om dagen och scrummastern kan använda den här informationen för att skapa ett sprintnedbrottstabell. Detta nedbrytningsdiagram hjälper teamet att se hur mycket arbete som återstår för sprinten och laget kan planera sitt arbete därefter. De kan till och med lägga till eller ta bort uppgifter om det behövs.

Några bästa metoder när du skapar en sprintbacklog kan vara:

# 1) Ta gruppbeslut - Det bör inte vara scrummästaren eller någon annan scrumlagmedlem som bestämmer eftersläpningen. Snarare bör det vara hela teamet som tillsammans bestämmer vilka artiklar som ska ingå i sprintbackloggen och hur man planerar för dem.

Varje medlem i detta tvärfunktionella team har sina egna färdigheter och det är viktigt att vi använder deras erfarenhet för att skapa bästa möjliga eftersläpning.

# 2) Tilldela inte uppgifter - Eftersom det har upprepats flera gånger i den smidiga litteraturen, tilldela aldrig uppgifter till teammedlemmarna. Ett scrumteam ska vara självförsörjande och de borde veta hur de ska organisera sitt arbete på egen hand.

Så istället för att tilldela arbete bör vi låta teamet välja arbete för sig själva och själva bestämma hur de vill gå vidare.

# 3) Definition av gjort - Det bör inte bara överenskommas av intressenterna, utan också göras klart synligt för laget vid alla punkter när de måste fatta beslut om sprintmålen. Detta kommer att fungera som en påminnelse om vad som exakt behöver göras innan de kan leverera en leveransbar produkt som fungerar.

# 4) Fortsätt uppdatera eftersläpningen - Det är absolut nödvändigt att när sprinten utvecklas kommer laget att få en större förståelse och därför bör de därför uppdatera sprintbackloggen för att återspegla denna större förståelse också. Det ska inte bli ett statiskt dokument när som helst.

# 5) Lägg till en uppgift - Uppgiften behöver inte bara relateras till kodning utan det kan vara viktigt att leverera en leveransbar produkt. Därför nämner också sådana uppgifter i eftersläpningen.

Produktökningar

Detta leder oss till den sista scrum-artefakten som är produktsteg. Som definierats av scrumguiden är en ökning summan av alla Produkter i eftersläpsprodukter slutförd under en Sprinta och värdet på inkrementen för alla tidigare sprints. Som vi vet väl nu är Scrum en iterativ process.

Resultatet av varje iteration är att denna produkt ökar och varje sådan produktökning hjälper teamet att ta ett steg närmare mot att leverera slutprodukten.

Vad detta betyder är att vad som än var resultatet av sprinten är ett steg. För att resultatet ska betraktas som en ökning bör det uppenbarligen uppfylla den fördefinierade definitionen av gjort, dvs. slutresultatet ska vara en användbar produkt som kan 'levereras'.

Det kan kontrolleras, användas och testas för att säkerställa att det verkligen 'görs' enligt definitionen och om produktägaren önskar kan det släppas för att gå live också.

Det viktigaste för att leverera den här produktinkrementet är att ha en gemensam förståelse för ”definitionen av gjort” som alla förstår.

Scrumteamet borde aldrig vara i tvivel om det de gör kommer att accepteras eller inte. Om det råder något tvivel bör definitionen av gjort vara tillräckligt fullständig för att vägleda dem om hur man går vidare. Baserat på endast denna definition bestämmer scrumteamet hur många eftersläppsprodukter som ska väljas för sprinten.

Detta är det minsta som förväntas av sprinten.

Slutsats

Från denna handledning har vi förstått vilka är de tre scrum-artefakterna, som äger dem tillsammans med några av de bästa metoderna som kan hjälpa oss att skapa artefakter av bättre kvalitet. I våra nästa handledning av denna serie kommer vi att diskutera Scrum-händelserna och se hur man genomför dessa händelser.

I vår kommande handledning om ”Scrum evenemang , ”Vi kommer att diskutera vart och ett av Scrum-evenemanget i detalj!

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^