I dette indlæg vil jeg gå i dybden med den vigtige rolle, som en product backlog spiller i et Scrum udviklingsprojekt.
Jeg vil begynde med, at beskrive de forskellige typer af items, som typisk udgør en product backlog. Derefter diskuterer jeg fire regler for en god product backlog og hvordan god backlog grooming hjælper med at sikre, at de valgte karakteristikker er opnået.
Herefter beskriver jeg hvorfor en product backlog er et nøgleelement i hurtig håndtering og fleksibelt flow på både release og sprint niveau. Til sidst vil jeg diskutere hvordan vi vurderer hvilke og hvor mange product backlogs vi bør have.
Overblik
En product backlog er en prioriteret liste af ønsket produkt funktionalitet. Det giver en centraliseret og delt forståelse af hvad der skal bygges og rækkefølgen, som det skal bygges i.
Det er et meget synligt artifact i hjertet af Scrum Framework, som alle projektets deltagere har adgang til.
Så længe der er et produkt eller system ved at blive bygget, forbedret eller opdateret, så er der brug for en product backlog.
Product Backlog Items
En product backlog er bygget op af backlog items, som typisk refereres til som enten PBI’er, backlog items eller bare items.
De fleste PBI’er er features, items af funktionalitet, som vil have håndgribelig værdi til brugeren eller kunden.
Disse er ofte skrevet som user stories, selvom Scrum ikke specificerer hvordan du skal formatere PBI’er.
Eksempler på en feature kunne være noget helt nyt, som f.eks. en login-side på en ny hjemmeside, men det kan også være en ændring til eksisterende features, som f.eks. en mere brugervenlig login-side til en eksisterende hjemmeside.
Andre PBI’er inkluderer defekter der skal repareres, tekniske forbedringer, videnssøgende arbejde og andre typer arbejde, som gruppens product owner vurdere til at være værdifulde.
Product Backlog regler for effektive projekter
Gode product backlogs udviser typisk lignende karakteristikker. Roman Pichler og Mike Cohn har skabt akronymet DEEP, som fokuserer på flere vigtige karakteristikker af gode product backlogs, nemlig: Detailed appropriately, Emergent, Estimated og Prioriteret.
Meget som INVEST kriterierne er hjælpsomme til at vurdere kvaliteten af en user story, så er DEEP kriterierne gode til at vurdere om en product backlog er blevet struktureret på en god måde.
Detailed Appropriately
Ikke alle items i en product backlog vil være på samme niveau af detaljer på samme tid.
PBI’er, som vi har planer om snart at arbejde på, bør være nær toppen af backloggen, små i størrelse og meget detaljeret, så der kan arbejdes på dem i den næste sprint. PBI’er som vi ikke skal arbejde på i noget tid bør være mod bunden af backloggen, store i størrelse og mindre detaljeret. Det er OK; vi har ikke planer om at arbejde på disse PBI’er i noget tid.
Som vi nærmer os at skulle arbejde på en større PBI, som f.eks. en epic, så vil vi bryde denne story ned i en samling af mindre, sprint-ready stories.
Det bør ske på en just-in-time måde. Hvis vi forfiner for tidligt, så kan det være, at vi bruger en masse tid på at bestemme hvad detaljerne skal være, bare for at finde ud af, at vi ikke skal implementere denne story.
Men hvis vi venter i for lang tid, så vil det forstyrre flowet af PBI’er ind i sprinten og dermed forsinke hele projektgruppen.
Så det er nødvendigt, at vi finder den perfekte balance mellem just enough og just in time.
Emergent
Så længe der er et produkt under udvikling eller vedligeholdelse, så er en product backlog aldrig færdigt eller statisk.
I stedet, så er den kontinuerligt opdateret baseret på en strøm af økonomisk værdifuld information, som konstant dukker op.
For eksempel, så kan det være, at kunder ændrer mening om hvad de gerne vil have, konkurrenterne laver måske modige og uforudsigelige ændringer, eller uventet tekniske problemer kan opstå. Din product backlog er designet til at tilpasse sig til disse ting.
Strukturen af en product backlog er derfor i konstant udvikling over tid. Som nye items tilføjes, eller eksisterende items forfines, så skal produktets product owner re-balancere og re-prioritere den gældende product backlog, og tænke over den nye information.
Estimated
Hvert product backlog item har en estimeret størrelse, som svarer til den indsats der er krævet for at udvikle dette item.
Product owneren bruger disse estimater som en af mange inputs til at hjælpe med at vurdere en PBI’s prioritet (og dermed position) i dens product backlog.
Derudover, så signalerer en høj-prioritet, stor PBI, til product owneren, at ekstra forfining af denne item er nødvendigt før at det kan flyttes ind i næste sprint.
De fleste PBI’er er estimeret enten i story points eller ideelle dage. Disse størrelses estimater skal være nogenlunde præcise uden at være for præcise.
Da items nær toppen af en product backlog er mindre og mere detaljeret, så vil de også have mindre og mere præcise estimater. Det er muligvis ikke muligt at levere numerisk præcise estimater for store items (som epics) der er placeret nær bunden af product backlog, så nogle projektgrupper vælger måske ikke at estimere dem overhovedet, eller at bruge T-shirt estimater (L, XL, XXL, osv.).
I takt med at disse store items bliver forfinet ned til mindre items, så vil hver af de mindre items blive estimeret.
Prioritized
Selvom at en product backlog er en prioriteret liste af PBI’er, så er det usandsynligt, at alle de forskellige items i en backlog vil blive prioriteret.
Det er hjælpsomt at prioritere items på kort sigt, som skal med i de næste par sprints. Det er muligvis værdifuldt af prioritere så langt ned i en backlog, som vi tænker vi kan i Release 1. At gå ud over det punkt i andet end et overordnet niveau af prioritering er højst sandsynligt spild af vores tid.
For eksempel, så kan det være, at vi erklærer, at en item først bliver aktuel i Release 2 eller Release 3 i følge vores product roadmap.
Men, hvis vi er tidligt på den i udviklingen af Release 1 features, så er det højst sandsynligt ikke en god investering at bruge vores værdifulde tid på at bekymre os om hvordan vi skal prioritere features, som vi skal arbejde på i Release 2 eller Release 3.
Det kan være, at vi ender med rent faktisk aldrig at udføre Release 2 eller Release 3, eller at vores ideer omkring disse releases ændrer sig betydeligt under udviklingen af Release 1.
Tid brugt på at prioritere så langt ud har altså en høj sandsynlighed for at være spildt tid.
Selvfølgelig, som nye items opstår under vores udvikling, så er produktets product owner ansvarlig for at indsætte disse items i den korrekte rækkefølge baseret på de items, som der på nuværende tidspunkt eksisterer i vores backlog.
Grooming
For at få en god, DEEP product backlog, så skal vi proaktivt håndtere, organisere, administrere, eller, som det typisk refereres til, groome, vores product backlog.
Hvad er Grooming?
Grooming referer til et sæt af fire principielle aktiviteter; oprette, forfine (tilføje detaljer til), estimere og prioritere PBI’er.
På et passende tidspunkt skal alle PBI’er estimeres for at hjælpe med at vurdere deres rækkefølge i product backlog og for at hjælpe med at bestemme om yderligere forfining er garanteret.
Derudover, i takt med at vigtig information bliver tilgængeligt, så er nye items lavet og indsat i product backlog i den korrekte rækkefølge.
Selvfølgelig, hvis prioriteter skifter, så vil vi ændre på rækkefølgen af disse items i vores backlog.
Og som vi kommer tættere på at arbejde på et stort item, så vil vi forfine det om til en samling af mindre items. Vi vælger måske også, at en specifik backlog item ikke er nødvendig, og så vil vi slette den.
Hvad gør Grooming’en?
Grooming af product backlogs er en kontinuerlig samarbejde indsats som er ledet af produktets product owner og inkluderer betydelig deltagelse fra interne og eksterne interessenter, så vel som Scrum Master og udviklingsholdet.
Ultimativt er der én grooming beslutningstager: det er product owneren.
Men, gode product owners forstår, at samarbejdende grooming fører til en vigtig dialog mellem alle deltagere og udnytter den kollektive intelligens og perspektiv af en divers gruppe af individer, og viser derfor vigtig information, som ellers kunne være blevet misset.
Gode product owners ved også, at ved at involvere de forskellige projektgruppemedlemmer i selve grooming’en, så sikrer de, at alle har en mere tydelig, delt forståelse af produktets product backlog, så mindre tid vil blive spildt på dårlig kommunikation og handoffs.
Sådan samarbejdende indsatser fører også mere til at lukke, eller minimere, det historiske gap mellem forretningsfolk og det tekniske folk.
Interessenter bør allokere en nødvendig mængde af tid til grooming baseret på naturen af en organisation og dens type projekt.
Som en generel regel, så bør udviklingsholdet allokere op til 10% af siden tid hver sprint på at hjælpe deres product owner med grooming aktiviteter.
Projektgruppen vil bruge denne tid på at hjælpe med at skabe eller gennemgå dårlige product backlog items, så vel som at kontinuerligt forfine store items og lave dem om til små items.
Projektgruppen vil også estimere størrelsen af en product backlog items og hjælper en product owner med at prioritere dem baseret på tekniske afhængigheder og nye ressourcer.
Hvornår finder Grooming sted?
Et Scrum framework indikerer ikke kun, at grooming skal finde sted, men indikerer ikke hvornår det skal ske. Så hvornår finder en Grooming indsats sted?
Ved brug af sekventiel udvikling, forsøger vi på at fange en komplet og detaljeret beskrivelse af alle kravene up-front, så ingen eller næsten ingen krav-grooming er planlagt efter kravene er blevet godkendte.
I mange organisationer kan disse basale krav muligvis kun blive ændret via en separat kontrol process, som ikke følger sammen med det primære flow.
Derfor er grooming under traditionel projektledelse en exceptionel, ikke-planlagt, aktivitet udenfor det normalt planlagte flow, som vi kun vil bruge hvis vi har brug for det, da det er disruptivt til det normale hurtige flow af leveret forretningsværdi.
Ved brug af Scrum antager vi et kaotisk miljø og må derfor være forberedt på konstant af inspicere og tilpasse os. Vi forventer, at en product backlog vil udvikle sig til konstant at blive kigget på og ændrer sig først gennem en sekundær process for at håndtere exceptionelle, uønsket tilfælde.
Som resultat, så må vi sikre, at vores grooming aktiviteter er en essentiel, intrinsisk del af hvordan vi håndterer vores arbejde.
Initiel grooming foregår, som del af en release-planning aktivitet. Under produktudviklingen, så bør din product owner mødes med interessenter med den hyppighed, som det giver mening at lave ongoing grooming.
Når der arbejdes med udviklingsholdet, så vil en product owner måske planlægge enten en ugentligt eller once-a-sprint grooming workshop under en sprint execution.
At gøre det forsikre, at grooming opstår på et regulært niveau og gør det derudover muligt for projektgruppen at stå til ansvar for den tid der er lavet under sprint planning.
Det reducerer derudover ad hoc møder (for eksempel, finde ud af hvornår mennesker er tilgængelige, finde nye ledige pladser, osv.)
Nogle gange foretrækker projektgrupper at sprede alt groomingen ud over en sprint; i stedet for at blokere en forudvalgt periode af tid.
Det tager en smule tid efter at deres daglige scrums har gjort noget inkrementelt grooming.
Denne grooming behøver ikke at inkludere alle af projektudviklerne. For eksempel, efter en daglig scrum, så vil en product owner blive nødt til at spørge om hjælp for at forfine af en større story.
Gruppemedlemmer som er informeret og interesseret bliver og hjælper deres product owner. Næste gang, kan det måske være andre medlemmer af projektgruppen, som kan hjælpe.
Selv hvis projektgrupper har standard planlagt workshops eller tager noget tid hver dag til at kigge på backlogs, så har de fleste grupper opdaget, at de helt naturligt gør en del af denne grooming, som en del af dette sprint review.
I takt med at alle der er involveret får en bedre forståelse for hvor produktet er og hvor det er på vej hen, så er nye PBI’er ofte lavet eller eksisterende PBI’ers prioriteringer er ændret, eller slettet hvis de ikke længere er nødvendige.
Hvornår grooming sker er mindre vigtigt end at sikre, at det er godt integreret i Scrum udviklings-flowet, for at sikre fleksibilitet og hurtigt levering af forretningsværdi.
Definition of Ready
Grooming af ens product backlog bør sikre, at items i toppen af det gældende backlog er klar til at blive flyttet ind i en sprint, så udviklingsholdet sikkert kan forpligte sig til og færdiggøre dem til slutningen af en sprint.
Nogle Scrum projektgrupper formaliserer denne ide ved at etablere en definition of ready. Du kan tænke på definition of ready og definition of done, som to stadier af product backlog items under en sprint cycle.
Både definitionen af done og definitionen af ready er tjeklister af arbejdet, som skal færdiggøres, inden en product backlog items kan betragtes som at være i det respektive stadie.
Et eksempel af en definition af done og ready for product backlog items er givet nedenunder.
- Forretningsværdien tydelig beskrevet
- Den er detaljeret nok til at en udvikler kan forstå opgaven og kan udføre den korrekt.
- Der er ikke nogen afhængigheder til opgaven som blokkere opgaven i at blive udført.
- Der er nok udviklere i teamet til at kunne udføre opgaven.
- Opgaven er lille nok til at den kan udføres i et sprint.
- Der er et klart og enkelt acceptkriterie på opgaven.
- Udviklingsholdet forstår hvad der er succeskriterierne for opgaven, og hvad kunden i bund og grund ønsker.
En stærk definition of ready vil betydeligt forbedre scrum gruppens chance for at succesfuldt møde sit sprint mål.
Flow Management
Projektgruppens product backlog er et altafgørende redskab, som gør det muligt for scrum gruppen at opnå et hurtigt, fleksibelt og værdifuldt leverings flow i tilfælde af usikkerhed.
Usikkerhed kan ikke elimineres fra produktudvikling. Vi må antage, at en strøm af økonomisk vigtig information konstant vil ankomme og at vi er nødt til at organisere og håndtere arbejdet (håndtere product bagklog) på en måde, hvor denne information kan behandles på en hurtig, omkostningseffektiv måde mens vi vedligeholder et godt flow.
Lad os gå videre med at kigge på rollen af product backlog i forhold til at hjælpe med et godt release flow og sprint flow.
Release Flow Management
Product backloggen skal være groomed på en måde, som støtter on-going release planlægning (flowet af features i en release).
I en product backlog er der must-have, nice to have og won’t have features.
- Must-have features repræsenterer de items, som der bare skal være med i den kommende release da vi ellers ikke vil have en levedygtig kunde release.
- Nice-to-have features repræsenterer items, som vi går efter til næste release og gerne vil inkludere. Hvis vi løber tør for tid eller andre ressourcer, så kan vi droppe nice-to-have features og stadig levere et levedygtigt produkt.
- Won’t-have features er items, som vi ikke vil inkludere i den nuværende release.
Vedligeholdelse af vores product backlog på denne måde hjælper os med bedre at håndtere release planlægning.
Sprint Flow Management
Product backlog grooming er essentielt for effektiv sprint planlægning og det resulterende flow of features i en sprint.
Hvis det gældende product backlog er blevet grundigt detaljeret, så bør items i toppen af product backlog være klart beskrevet og testable.
Når man skal foretage grooming for et godt sprint flow, så er det hjælpsomt at kigge på det gældende product backlog som en pipeline af krav der går igennem sprints for at blive designet, bygget og testet af projektgruppen.
Store ikke-så-godt-forstået krav indsættes i denne pipeline. Som de går igennem denne pipeline og bevæger sig tættere på det tidspunkt, hvor de skal arbejdes på, bliver de progressivt forfinet gennem grooming aktiviteten.
Når en item flower ud af pipelinen, så skal den være klar – detaljeret nok til at projektgruppen kan forstå den og er sikker på, at de kan nå at levere den gennem en sprint.
Hvis der nogensinde er et mismatch eller ulighed mellem inflow og outflow af items, så har vi et problem.
Hvis et flow af groomed, detaljeret, klar-til-at-blive-implementeret items er for langsom, så vil pipelinen på et tidspunkt løbe tør og projektgruppen vil ikke have mulighed for at planlægge og eksekvere den næste sprint (en stor flow forstyrrelse eller spild i scrum).
På den anden side vil det, at indsætte for mange items i pipelinen for forfining, skabe et stort inventar af detaljeret krav, som vi måske skal arbejde på igen eller smide ud, når vi lære mere (et stort spild).
Derfor er den ideelle situation at have præcis nok product backlog items i inventaret til at skabe et lige flow, men ikke så mange, at det skaber spild.
En tilgang som Scrum grupper bruger er at have en passende størrelse inventar af groomed og ready-to-implement items i deres backlog.
En heuristisk tilgang som virker til at virke for mange grupper, som er ved at have to til tre sprints værd af stories klar.
Så, for eksempel, hvis projektgruppen normalt kan klare omkring 5 PBI’er per sprint, så skal gruppens groome deres backlog, så den altid har 10-15 PBI’er klar til at blive arbejdet på til hver en tid.
Denne ekstra inventar sikrer, at deres pipeline ikke løber tør, og giver også gruppen fleksibilitet, hvis den bliver nødt til at vælge PBI’er uden rækkefølge på grund af kapacitetsgrunde eller andre sprint-specifikke begrænsninger.
Hvilke og hvor mange product backlogs?
Når man skal vælge hvilke og hvor mange product backlogs der skal laves, så starter jeg altid med en simpel regel: Et produkt, en product backlog, hvilket betyder, at hvert produkt bør have sit egen product backlog, som tillader for en bred produktbeskrivelse og prioritering af arbejdet der skal laves.
Der er dog nogle tilfælde, hvor man er nødt til at være forsigtig med at bruge denne regel for at sikre, at man ender med en praktisk product backlog struktur.
For eksempel, i nogle tilfælde er det ikke altid klart hvad der konstituerer et produkt; nogle produkter er meget store, nogle gange har vi mange projektgrupper som ikke er udskiftelige, andre gange er der mange forskellige produkter og en enkelt projektgruppe.
Lad os kigge på hver af disse tilfælde for at se, hvordan de påvirker vores single-backlog regel.
Hvad er et produkt?
Et problem med et-produkt-en-product-backlog reglen er, at det ikke altid er klart hvad der konstituere et produkt.
Er Microsoft Word produktet eller er det bare en enkelt del af et større produkt kaldet Microsoft Office?
Hvis vi kun sælger en samlet pakke, har vi så en product backlog for hele pakken, eller har vi en product backlog for hver individuelle applikation i pakken?
Eksempel: IBM
Hos IBM sælger de et bredt udvalg af produkter fra et stort katalog, så derfor opstår dette spørgsmål naturligvis ofte. Her har man dog besluttet, at noget defineres som et produkt, når det har sit eget unikke produkt ID nummer.
Grunden til at det er en god måde at gøre det på er, at det er en meget simpel definition. Hvis det man lavede havde en PID nummer, så kunne sælgerne inkludere det i en ordre og derfor er det et “produkt”. Selvom det måske virker for simpelt, så er det et godt startpunkt. Et produkt er noget af værdi, som en kunde vil være villig til at betale for og noget som vi er villige til at at pakke og sælge.
Brug af denne regel bliver mere kompliceret, hvis vi laver component teams, som står for at lave en komponent af et større produkt, som en kunde vil købe.
For eksempel, når du er ude at købe en GPS. Her køber du ikke rute-algoritmen, men en bærbar enhed, som vil give dig præcis grafisk og auditiv sving-for-sving direktioner. Rute “komponentet” var simpelthen bare en af mange dele, som blev sat sammen for at skabe en enhed, som en kunde er villig til at betale for.
Hvis GPS fabrikanten lavede et rute hold til at udviklingen rute komponenten, er der så en product backlog for hver komponent? Eller er der bare en product backlog, som passer til hele GPS’en med rute features integreret ind i dette product backlog?
Og for at gøre tingene endnu mere interessante, hvad hvis den samme rute komponent kan bruges i flere forskellige GPS produkter (hver med sit eget PID)? Er vi mere tilbøjelige til at lave et separat product backlog for en komponent, hvis den kan bruges til flere forskellige enheder?
Som du kan se, så ryger man hurtigt ned i et sort hul, når man begynder at stille alle disse spørgsmål. Når man skal vælge, så er det vigtigt, at huske på at det overordnet mål er at minimere antallet af komponentgrupper og derfor behovet for komponent product backlogs.
Tænk i stedet på hvad du kan skabe, som er pakket, leveret og giver kundeværdi. Derefter kan du opbygge dit produkt backlog med det i tankerne.
Store produkter – hierarkisk backlogs
Når det er muligt, så foretrækker jeg en product backlog selv for et stort produkt som Microsoft Office. Men, det er vigtigt at være praktisk, når denne regel bruges.
Ved en stor produktudviklings indsats for at skabe noget stort, som f.eks. en telefon, så kan vi have mange eller hundredvis af projektgrupper, hvis arbejde skal mødes og komme sammen for at skabe en markedsklar enhed.
At forsøge på, at sætte PBI’erne fra alle af disse projektgrupper ind i en enkelt product backlog, er ikke praktisk (eller nødvendigt).
Ikke alle af grupperne vil arbejde i relateret områder. Det kan for eksempel være, at vi har syv hold, som arbejder på den audiovisuelle del af en iPhone og otte yderligere hold, som arbejder på web browseren for telefonen.
Hver af disse områder leverer tydelig værdi til kunden, og arbejdet i hvert område kan organiseres og prioriteres på et detaljeret niveau uafhængigt af andre områder.
Baseret på disse karakteristikker kan de fleste organisationer adressere problemet vedrørende store produkter ved at lave hierarkiske backlogs.
I toppen af hierarkiet har vi stadig en product backlog som beskriver og prioriterer de store features (måske epics) af produktet. Der vil også være en chief product owner på dette niveau. Hver af de relateret feature-områder har så sin egen backlog.
Det audiovisuelle player område har en backlog som indeholder PBI’er for de syv hold, som arbejder i det område. PBI’er på feature-område niveau vil højst sandsynligt være mindre i skala (feature eller story størrelse) end de passende items i en product backlog.
Flere projektgrupper – En product backlog
Et-produkt-en-product-backlog reglen er designet til at tillade at alle projektgrupperne der arbejder på produktet kan dele en product backlog.
Tilpasningen af alle projektgrupperne til et enkelt backlog gør det muligt for os at optimere vores økonomi på et full-product niveau. Vi får denne fordel, fordi vi sætter alle features ind i en backlog og får dem til at konkurrere om prioritering imod alle andre features, hvilket sikrer at de features med den højeste prioritet fra et full-product perspektiv er identificeret og prioriteret til at blive arbejdet på først.
Hvis alle vores projektgrupper er udskiftelige, så hvilken som helst projektgruppe kan arbejde på hvilken som helst PBI i en delt backlog, så kan vi rent faktisk realisere prioriteringens fordelen der er gjort muligt af det enkelte product backlog.
Men hvad hvis projektgrupperne ikke er udskiftelige? For eksempel, et hold som arbejder på Microsoft Word kan højst sandsynligt ikke sættes til at arbejde på Microsoft Excel. Selvom det ikke er ideelt, i nogle tilfælde, så kan ethvert hold ikke arbejde på enhver item fra product backlog.
For at arbejde i denne realitet, så skal vi vide hvilke items i en product backlog, som hvert hold kan arbejde på. Med andre ord, så skal vi have projektgruppe-specifikke backlogs.
I praksis, så laver vi ikke rent faktisk product backlog på projektgruppe niveau. I stedet, så har vi projektgruppe-specifikke overblikke over det delte backlog.
En ulempe ved dette er mangel på fleksibilitet. Det kan nemlig være, at en projektgruppe kun er i stand til at lave en feature, som egentligt ikke er af så høj prioritet, men fordi det er hvad de kan lave, så sættes de til denne feature.
Det er også derfor, at mange organisationer sigter efter et højt niveau af delt kode ejerskab og mere udskiftelige projektgrupper, så de kan få fordelene af at have projektgrupper der kan arbejde på flere forskellige områder af at produkt.
En projektgruppe – Flere produkter
Hvis en organisation har flere produkter, så vil den have flere forskellige product backlogs. Den bedste måde at håndtere flere product backlogs er ved at tildele en eller flere projektgrupper til at arbejde eksklusivt på hver product backlog.
I nogle tilfælde er der dog en projektgruppe, som ender med arbejde fra flere forskellige product backlogs. Målet bør dog være, at minimere mængden af multi-projektarbejde for projektgrupperne.
Den første, og typisk den bedste, løsning er at have projektgruppen til at arbejde på et produkt af gangen. I hver sprint vil projektgruppen kun arbejde på items fra en product backlog.
Hvis der dog er organisatoriske begrænsninger der tvinger en projektgruppe til at arbejde på flere produkter på samme tid, så kan man overveje om det giver mening at sammenflette PBI’erne for alle tre produkter sammen og nå en enkelt prioritering på tværs af alle produkterne.
Selv hvis vi vælger at beholde tre separate product backlog, så vil en person i hver sprint (ofte product owneren for projektgruppen) blive nødt til at lave et prioriteret sæt af PBI’er fra de tre backlogs (måske baseret på en pre-allocation af holdets tid til hver produkt under en sprint) og præsentere disse til projektgruppen for dens overvejelse og dedikation.
Konklusion
I dette indlæg gik jeg i dybden med den altafgørende rolle af en product backlog for at nå et hurtigt, fleksibelt værdidrevet leverings flow i tilfælde af usikkerhed.
Jeg har fremhævet et antal af strukturelle og process problemstillinger omkring en product backlog, som hvilke typer af items der er i en product backlog og hvordan du kan groome en product backlog til at opnå flere gode product backlog karakteristikker. Jeg konkluderede ved at gå i dybden med problemet om hvilke og hvor mange product backlogs vi bør have.
