Produkt Backlog er den eneste kilde til opgaver udført af Scrum Teamet. Det er en liste over planlagt produktfunktionalitet og forbedringer. Dets form er foranderlig, og ikke alle opgaver inkluderet i Produkt Backlog vil blive fuldført. Det udvikler sig under diskussioner med interessenter. Det forbedres også konstant. Det betyder, at jo tættere man kommer på deadline, jo mere detaljeret bliver en opgave.
Hvad er Produkt Backlog? – indholdsfortegnelse:
- Introduktion
- Hvad indeholder Produkt Backlog?
- Formen af Produkt Backlog
- Forbedring af Produkt Backlog
- Sammenfatning
Introduktion
Produkt Backlog er den største af Scrum Artefakter. Det afspejler status for arbejdet på et produkt i forhold til produktmålet. På den anden side, når arbejdet på et produkt er afsluttet, bliver dens backlog en komplet liste over de opgaver, der er udført af Scrum Teamet for at skabe produktet. Det indeholder dog ikke detaljerede tekniske løsninger.
Hvad indeholder Produkt Backlog?
Produkt Backlog oprettes under Produkt Ejerens møder med interessenter. Produkt Ejer er den eneste ejer og den person, der er ansvarlig for denne kilde til opgaver.
Forretningssprog karakteriserer indlæggene i Produkt Backlog. Med andre ord beskriver de værdien af produktet fra interessenternes synspunkt.
Opgavebeskrivelserne inkluderet i listen over opgaver har brug for sammenhæng og klarhed. De indeholder funktioner og forbedringer af produktet, der normalt præsenteres i form af brugerhistorier, som vi dedikerer en separat indlæg til. Her vil vi kun nævne, at disse er beskrivelser af delvise funktionaliteter af produktet, der besvarer spørgsmål om følgende emner:
- Omfanget af produktmodifikationer
- Formålet med at modificere produktet
- Den type bruger for hvem denne modifikation opstår
Formen af Produkt Backlog
Rækkefølgen af opgaver inkluderet i Produkt Backlog ændrer sig i takt med at produktet udvikler sig. Mens der arbejdes på det, former og forbedrer Scrum Teamet dets funktionaliteter. Når der opstår forhindringer, tillader de implementerede handlinger alle at tænke over og definere fremtidige passende løsninger, og disse vil også ændre sig i overensstemmelse med uforudsete yderligere forhindringer. Derfor er der ingen klar og defineret rækkefølge af handlinger, alt er foranderligt. Forbedring af Produkt Backlog har til formål at sikre dens kontinuerlige opdatering og forberedelse til de næste opgaver. Af denne grund er det kontinuerligt.
Opgaver med en fjern deadline er typisk store, generiske helheder. Deres beskrivelse indeholder ikke detaljer, men kun en skitse af funktionalitet, der skal realiseres. Det er også muligt at finde opgaver blandt dem, der aldrig vil blive afsluttet.
Indlæg i Produkt Backlog kan præsentere alternative løsninger. Og også kundens ideer, som kan blive forældede, ufordelagtige eller af en eller anden grund aldrig komme ind i implementeringsfasen. Derfor kaldes Produkt Backlog nogle gange spøgefuldt for “kundens ønskeliste”.
En anden grund til ændringer i formen af Produkt Backlog er omdefinering af løsninger. Nogle gange viser det sig, at et bestemt problem allerede er blevet løst, mens der blev skabt en anden produktfunktionalitet. Eller den forventede funktionalitet er blevet overflødig på grund af ændringer i andre løsninger.
En af de grundlæggende aktiviteter under forbedringen af Produkt Backlog er at opdele opgaverne indeholdt i Produkt Backlog i dele. Takket være dette præsenteres den generelle skitse af funktionalitet i form af mindre, mere detaljerede og præcist definerede enheder.
Opgaver designet til tættere implementering bliver mere detaljerede. De bliver også mindre, indeholdende detaljer om løsninger. Detaljer opstår under produktudviklingen. Og takket være kendskabet til den nuværende tilstand af produktet og de nuværende forventninger fra interessenterne, supplerer Produkt Ejer de kommende opgaver med deres beskrivelse, rækkefølge og størrelse. Derefter vælger de bedst beskrevne opgaver til den næste Sprint Backlog.
Forbedring af Produkt Backlog
Mens der arbejdes på et produkt, modificerer og detaljerer Produkt Ejer Produkt Backlog i samarbejde med udviklingsteamet. I henhold til Produkt Ejerens forslag vælger teamet under Sprint Planlægning funktioner til implementering fra Produkt Backlog. De flyttes derefter til Sprint Backlog og opdeles i opgaver, der skal fuldføres. Opgaverne, der flyttes til Sprint Backlog, beskrives i teknisk sprog, som er mest nyttigt for udviklerne.
Opgavestørrelse er en vigtig måling fra udviklingsteamets synspunkt. Dens korrekte estimering bliver især kritisk, når der vælges brugerhistorier fra Produkt Backlog til Sprint Backlog.
Udviklingsteamet lærer over tid at korrekt estimere den tid og indsats, der kræves for at fuldføre en specifik brugerhistorie. Dette udtrykkes i dage, mandetimer eller Story Points og giver et estimat af en værdi kaldet Team Velocity.
Sammenfatning
Produkt Backlog er en kontinuerligt forbedret liste over opgaver, der fører til produktmålet. Indholdet af Produkt Backlog udtrykkes normalt i form af brugerhistorier. Og jo kortere tid der er tilbage til at fuldføre en opgave, jo:
- Jobbeskrivelsen er mere detaljeret
- Opgavens omfang er mindre
- Opgavens omfang er bedre defineret
Scrum Teamet tager sig af opgaverne. Produkt Ejer administrerer og modificerer Produkt Backlog.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Scrum Guide:
- Ordbog over grundlæggende termer, roller og begreber
- Hvad er Scrum?
- Scrum værdier
- Hvordan implementerer man Scrum i din virksomhed?
- Scrum Team - hvad er det, og hvordan fungerer det?
- Hvem er en Product Owner?
- De mest almindelige fejl hos Product Owner
- Hvem er Scrum Masteren?
- De mest almindelige fejl hos Scrum Master
- Hvilke statistikker og målinger bør Scrum Masteren følge?
- Udviklingsteam i Scrum
- De mest almindelige fejl hos udviklere
- Scrum artefakter
- Skalering af Scrum
- Sprint Backlog
- Hvad er produktbackloggen?
- Hvad er brugerhistorier?
- At skabe den bedste User Story med INVEST
- De mest almindelige fejl i User Stories
- Brugerhistorie Acceptkriterier
- Estimering og Story Points i Scrum
- Planlægningspoker
- Team Estimeringsspil
- Definere inkrement
- Scrum begivenheder
- Hvad er et Burndown-diagram?
- Fordele og ulemper ved burndown-diagrammet
- Kanban-tavler i Scrum og Scrumban
- Hastighed i Scrum - Udviklingsteamets hastighed
- Daglig Scrum
- Sprintplanlægning
- Sprintgennemgang
- Hvad er en Sprint Retrospektiv?
- Almindelige fejl under en Sprint Retrospektiv
- Produkt Backlog pleje
- Hvordan opretter og fortolker man et burndown-diagram?