Inden vi kaster os ud i detaljerne om etablering af en Product Backlog, så lad os lige træde et skridt tilbage og samle op på hvad karkateristika for en veletableret Product Backlog er.
En Product Backlog er først og fremmest et levende dokument. Som jeg beskrev det i blog-indlægget omkring vores viden under et projektforløb, så kan vi ikke vide alle de rigtige ting på forhånd. Derfor ændrer Product Backlog’ens indhold sig løbende gennem projektet. Vi tilføjer ny funktionalitet, når vi bliver klar over, at dette er nødvendigt for at støtte brugerens behov. Vi fjerner funktionalitet, når vi bliver klar over, at dette ikke er nødvendigt, og vi omorganiserer rækkefølgen i Product Backlog’en, når vi får ny viden om, hvad der er vigtigst. Arbejdet med en Product Backlog er altså en iterativ proces.
Elementerne i en Product Backlog (dvs. indholdet af funktionalitetslisten – vi kan også kalde disse for krav eller User Stories) skal have en passende detaljeringsgrad. Jo højere et element er i sorteringsrækken, jo flere detaljer har det. Jo lavere et element er i sorteringsrækkefølgen, jo færre detaljer er nødvendige. Elementerne i den øverste del af Product Backlog’en, svarende til lidt mere end hvad teamet kan gennemføre i et Sprint, skal have en detaljeringsgrad så dyb, at teamet præcist ved hvad der forventes af resultatet af deres arbejde (dette omfatter også acceptkriterier). Jo længere vi bevæger os ned i sorteringsrækkefølgen, jo færre detaljer. I den nederste del af Product Backlog’en finder vi korte beskrivelser – måske blot enkelte linjer – som dækker over flere hundrede (ja, måske flere tusinde) timers arbejde. Vi kalder disse for Epics. Disse vil med tiden blive brudt ned i mindre dele, og detaljerne vil blive tilføjet, når seneste ansvarlige tidspunkt begynder at nærme sig.
Jeg mener også, at en Product Backlog til enhver tid bør være estimeret. Det er ikke alle, som deler dette synspunkt med mig. Fair nok! Jeg forstår deres intentioner, men mener samtidigt også at et Scrum-teams (dvs. udviklingsteamet, ScrumMaster og Product Owner tilsammen) troværdighed overfor sponsor og interessenter er stærkere, når man kan give et bud på, hvilken tidsramme og hvilket budget projektet forventes gennemført indenfor. Denne opfattelse kan naturligvis ændre sig over tid – det er jo ikke eksakt videnskab, som jeg tidligere har skrevet om.
Det er Product Owner’ens ansvar at backloggen er veletableret, men det er ikke udelukkende Product Owner, som skal beskrive indholdet i den. Indholdet og detaljerne kommer gennem samarbejde mellem Product Owner, interessenter og team. Et samarbejde som Product Owner’en naturligvis har et ansvar for at forberede, så det kan ske på den mest effektive måde. Product Owner’en er den eneste som bestemmer sorteringsrækkefølgen i backloggen, og det er udelukkende Product Owner’en som kan fjerne elementer fra backloggen.
