Som en Product Owner er backloggen det første du skal have styr på. Jeg har lavet en guide til hvordan du helt grundlæggende bygger en god backlog op, lad os først gå i gennem hvad en “backlog” er.
Hvad er en backlog?
Helt kort og enkelt er en backlog en opgaveliste. Den er – og det vigtigt – tilgængelig og prioriteret. Mere om det senere i artiklen, men lad os først overveje hvor værdifuldt det faktisk er. Et team som har en liste med prioriterede opgaver, der er tilgængelig for alle. Teamet ved hvad de skal arbejde på og ingen er i tvivl om hvad teamet laver.
Det er et hamrende godt udgangspunkt, og selvom det kan virke enkelt er det rigtig svært for mange Product Owners at have en god og veltrimmet backlog. Det kræver en dedikeret indsats at bygge en god backlog op, og det vigtigste er ikke at give op – at blive ved med at forbedre den.
Hvad er der på en backlog?
En backlog er fyldt af problemer der skal løses, behov der skal indfries, opgaver der skal laves og fejl der skal rettes. Og det er allerede her at en af udfordringerne viser sig, for der er mange navne for de “opgaver” som bor på backloggen. For at nævne et par stykker: Stories, User Stories, Product Backlog Items, PBI’er, Bugs, Spikes, Tasks, Epics, Features… hvor skal vi starte?
Du kan kalde det hvad du vil på din backlog, der er ikke noget der er rigtigt eller forkert. Sørg for at være konsistent og brug et navn, som dit team og dine stakeholders kan forstå eller kan lære at forstå. Jeg synes at “opgaver” er det, der er mest ligetil at gå til, så det bruger jeg her.
Sådan beskriver du opgaverne på din backlog
Lad os tage udgangspunkt i det mest simple scenarie – vi kan altid bygge mere på. Vi skal have en titel og en beskrivelse på vores opgaver på backloggen. Begge dele skal så vidt muligt beskrive et behov – ikke en løsning.
Løsning vs behov
Ja – hold nu fast, for det her kan være svært. Opgaverne på backloggen skal være udtrykt som behov og ikke som løsninger der skal implementeres, og det er der to væsentlige grunde til:
- Det er meget nemmere for stakeholders at afkode opgaverne, når de beskriver det behov de dækker i stedet for løsningen.
- Det er meget sjovere for et team at løse de udfordringer der ligger i at indfri et et behov, end det er at implementere en løsning, som nogen andre har fundet på.
Lad os tage et eksempel på en løsning.
Titel: Minuttæller ud for stationer Beskrivelse: Ud fra stationerne i stationslisten skal vi lave en timer som viser antallet af minutter der er til toget ankommer til stationen.
Lad os så tage et eksempel på et behov.
Titel: Passager kan se hvornår taget ankommer på ønsket station Beskrivelse: Som passager vil jeg kunne se hvornår toget ankommer til de næste stationer med det formål at jeg kan planlægge min rejse eller fx give besked om hvornår jeg er fremme.
Hvis jeg som stakeholder skal forholde mig til, om jeg synes at den opgave er vigtig og skal prioriteres, sparer min hjerne en arbejdsgang eller to, hvis jeg læser en beskrivelse af behovet i stedet for løsningen.
Og hvis jeg som udvikler i et team skal løse problemet, har jeg væsentligt mere frihed i opgaveløsningen, hvis jeg får præsenteret behovet – ikke løsningen.
Alligevel er det svært for Product Owners at undgå, at backloggen fyldes med løsninger, som bare lige skal laves.
Uafhængige opgaver
Det er Product Owners ansvar at prioritere opgaverne i et team og at backloggen afspejler den priotering – vigtigste opgave øverst på listen! Derfor er det vigtigt at opgaverne på backloggen er så uafhængige af hinanden, at rækkefølgen på dem kan byttes rundt.
Rigtig mange backlogs ender med at være opskrifter, som skal følges slavisk og det sætter i praksis Product Owneren ude af stand til at udføre sit arbejde. Et eksempel fra en backlog:
- Opret webserver
- Opsæt ny database
- Installer CMS og lav initial opsætning
- Tilpas styling efter designet
- Opret forside
- Opret kontaktside
- Indlæs produkter i produktkataloget
- Tilkobl betalingsløsning
Held og lykke med at ændre prioriteringen af de opgaver! Resultat vil nok være et team af udviklere, der synes at du blander dig lige lovligt meget i deres arbejde.
Hold den kort
Jo kortere din backlog er, jo nemmere er den at holde overblik over, både for dig og for dit team. Sørg for kun at have de opgaver på backloggen, som teamet kan løse inden for den nærmeste fremtid. Det er aldrig meningen, at man skal have “alle opgaverne” på backloggen.
Nogen siger at Dunbar’s number på 150 er det højeste antal opgaver, man bør have på sin backlog. Jeg vil personligt anbefale det halve. Kommer du over 75 opgaver, skal du til at overveje en strategi for at nedbringe mængden.
Hvor skal backloggen være om hvem må se den?
Backloggen kan være en udgjort af post-it’s på en væg, et Excel-ark på computeren eller den kan bo i alverdens systemer, som er mere eller mindre bygget til formålet. Trello, Jira eller Azure DevOps for at nævne et par af de mest almindelige.
Din backlog skal være tilgængelig for alle. Ikke bare for dig selv og teamet der skal arbejde på den, men for alle. På den måde sikrer du den transparens i din prioritering, som er fundamental for et tillidsfuldt samarbejde med dine stakeholders.
Må alle rette i backloggen?
Når du er Product Owner, er backloggen din og din alene. Men hvis du er den eneste der må oprette nye opgaver eller bidrage med oplysninger på de eksisterende opgaver, får du både travlt og mistillid til dig. Så lad kollegaer fra både teamet og stakeholders komme til, men aftal med dem, hvordan du gerne vil have at samarbejdet skal fungere, så du ikke bliver overrasket over de ændringer, som din kollega laver.