Scrum Guide | 40. Pleje af produktbackloggen

Produkt Backlog pleje er en af de primære opgaver for en Product Owner. Plejeprocessen inkluderer formulering, detaljeringsgrad og tilføjelse af nye User Stories til Produkt Backlog. Dog er den vigtigste af plejeopgaverne at sikre, at de poster, der placeres i Backloggen, er i den rigtige rækkefølge, dvs. bliver prioriteret.

Produkt Backlog pleje – indholdsfortegnelse:

1. Introduktion
2. Formål med Produkt Backlog pleje
3. Fejl i vedligeholdelse af Produkt Backlog
4. Vedligeholdelse af Backlog vs. metrikker brugt i Scrum
5. Sammenfatning

Introduktion

Produkt Backlog er en af Scrums artefakter. Den indeholder en prioriteret liste over det arbejde, der er nødvendigt for at skabe et produkt. Med andre ord, det er en liste over User Stories, der er nødvendige for at opnå Produktmålet. Du kan finde en detaljeret beskrivelse af, hvad User Stories er i denne artikel. Og her er detaljerne om karakteristika og hvordan man vedligeholder Produkt Backlog.

Produkt Backlog pleje går også under følgende navne:

• Backlog Prioritering,
• Backlog Forfining,
• Backlog Skalering.

Formål med Produkt Backlog pleje

Product Owneren administrerer Produkt Backlog. De vigtigste færdigheder inkluderer prioritering af opgaver, når deres forfaldsdato nærmer sig. Dette skyldes, at målet med Produkt Backlog pleje er at sikre, at produktfunktionaliteterne har den højeste forretningsværdi, dvs. dem, der er mest essentielle fra kundens synspunkt, er øverst på to-do-listen. Og deres beskrivelse er klar og detaljeret, så deres implementering kan starte lige i den næste Sprint.

Produkt Backlog kan opdateres dagligt, hvis det er nødvendigt. Product Owneren kan tilføje nye User Stories til Produkt Backlog efter at have talt med interessenter og udviklingsteamet, eller ved at drage konklusioner og reformulere User Stories, der allerede er skrevet i Produkt Backlog.

Obligatorisk opdatering af Backloggen er en af de opgaver, der udføres under Sprint Review. Vi har beskrevet den proces i detaljer i denne artikel. Normalt diskuterer Scrum Teamet ikke kun de opgaver, der skal fuldføres i den næste Sprint under dette møde. Det specificerer også preliminært User Stories og deres implementering i de næste to eller tre Sprints. Denne måde at gøre tingene på giver Scrum Teamet og dets aktiviteter mulighed for at tage et bredere perspektiv på den langsigtede retning. Det muliggør at tænke på de opgaver, der aktuelt udføres, fra perspektivet af deres udvikling i efterfølgende Sprints.

Fejl i vedligeholdelse af Produkt Backlog

En af de mest almindelige problemer vedrørende Produkt Backlog pleje er at tillade den at udvide sig ukontrolleret. Dette skyldes, at mens der arbejdes på produktet, dukker forskellige yderligere funktionaliteter og opgaver, foreslået af både interessenter og Scrum Team medlemmer, spontant op. Derfor er det en af de vigtigste opgaver, der udføres af Product Owneren, at begrænse væksten af Produkt Backlog omfanget (scope creep). De mest almindelige fejl, som Product Owners begår, vedrører:

1. Afrivelse fra Produktmålet – at tilføje for mange idéer til Produkt Backlog ud over det grundlæggende Produktmål er ikke en god praksis, da det i høj grad reducerer læsbarheden. Det fungerer bedre at samle idéer til yderligere funktionalitet i et separat dokument.
2. Duplikation af indhold – at indtaste gentagne eller meget lignende idéer fra forskellige interessenter i Backloggen – før der tilføjes en anden post til Backloggen, bør Product Owneren sikre sig, at den nye post ikke duplikerer nogen af de eksisterende.
3. Mangel på et bredere perspektiv – du bør ordne Produkt Backlog poster i henhold til deres værdi i forhold til Produktmålet. Husk dog, at prioritering bør tage hensyn til de næste flere Sprints, så de opgaver, der udføres i en given Sprint, er sømløst forbundet med både den foregående Sprint og den Sprint, der følger umiddelbart efter.

Du kan ikke undgå fejl af denne art. Men bevidstheden om deres opståen kan gøre Product Owneren mere forsigtig med at tilføje nye User Stories til Produkt Backlog for at finde den rette balance. Dette skyldes, at det også er en fejl at give Backloggen for meget klip og eliminere poster, der indeholder lignende opgaver, der adskiller sig. For eksempel at beskrive lignende produktfunktionaliteter, der adskiller sig betydeligt i anvendelsen.

Vedligeholdelse af Backlog vs. metrikker brugt i Scrum

Produkt Backlog indeholder en beskrivelse af det resterende arbejde gennem hele projektet. Men kun en opdateret og regelmæssigt plejet Backlog kan nøjagtigt estimere forholdet mellem den mængde arbejde, der er udført, og den samlede. For at skildre den mængde arbejde, der er udført, bør du anvende Burndown Diagrammet, som vi har skrevet om i denne artikel.

En anden populær metrik til at beskrive Scrum Team arbejde er Velocity. Du kan måle det ved at sammenligne antallet af Produkt Backlog poster, der er omdannet til Increment i løbet af en enkelt Sprint. Vi har beskrevet Velocity i mere detaljeret i denne artikel.

Sammenfatning

Product Owneren udfører Produkt Backlog Pleje. Når Produkt Backlog er godt vedligeholdt, har Scrum Teamet en klar oversigt over det arbejde, der er tilbage. Det kan også få et bredere, fremadskuende perspektiv på, hvordan vejen til Produktmålet ser ud. Derfor skal Product Owneren sikre sig, at de User Stories, der er inkluderet i Produkt Backlog, er i prioriteret rækkefølge for fuldførelse. Og også at de opgaver, der skal fuldføres i de kommende Sprints, er beskrevet i fineste detalje.

Hvis du kan lide vores indhold, så bliv en del af vores travle bier fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.