Få styr på backlog

En af de første ting, som jeg som ScrumMaster fokuserer på sammen med et nyt team er deres Product Backlog.

I en optimal verden består en backlog af en række backlog items, som en Product Owner har prioriteret og gjort klar til sprints, således at de højest prioriterede backlog items er estimeret og beskrevet så godt at man kan tage dem ind i et sprint.


Men sådan ser det sjældent ud. Typiske problemer er manglende Product Owner eller en Product Owner der ikke er i stand til at lave dette arbejde. Jeg har også været ude for situationer, hvor backlog ikke er en egentlig Product Backlog, men derimod en backlog der stammer fra flere forskellige produkter, med forskellige Stakeholders og derved også en svær prioritering og forskellige standarder for hvor grundig en backlog item er beskrevet.

I de tilfælde har jeg som ScrumMaster sammen med Teamet måttet bruge tid på at bearbejde backloggen og få hvert enkelt backlog item op på en niveau, hvor man er i stand til at tage den med i et sprint.

Er det optimalt og er det Scrum? Næ, det er det ikke, men hvis det er det, som der skal til for at komme igang med en Scrum proces, så er det vel også ok. Så længe at man samtidig med får trænet Stakeholders i at lave gode backlog items og får dem til at blive enige om en prioritering

Hvordan bearbejder man så backloggen. Det jeg synes man skal gøre er at have et eller flere korte sprints, hvor man bearbejder backlog items sammen med de enkelte stakeholders indtil man har fået lavet en backlog klar til et egenligt sprint. Her er der dog en fælde! Det er vigtigt at man kun fokuserer på mål og acceptance criteria i denne proces og ikke går i designmode, således at man istedet for en Agil proces får lavet sig nogle mini-vandfald bestående af design og udviklingssprint. Designet af løsning hører til i forbindelse med sprintet.