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.
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.
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:
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.
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.
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:
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.
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.
Får du nogensinde følelsen af, at dagen er for kort til at gøre alt det,…
Hvad er software? Hvad er typerne og metoderne til distribution? Når vi holder os til…
At præsentere og kommunikere forskningsresultater er sandsynligvis en af de mest afgørende (og krævende) evner…
Ved du, hvordan man opretter en e-bog? Kender du alle de væsentlige aspekter af en…
Bæredygtig markedsføring er ikke længere bare en af de markedsføringsstrategier, du kan anvende i din…
For nylig er to fænomener opstået på arbejdsmarkedet, der relaterer sig til holdningerne hos nutidens…