Backlog Refinement - tidligere kaldet Backlog Grooming - er den løbende aktivitet, hvor Scrum-teamet gennemgår, detaljerer og prioriterer Product Backlog. Refinement er ikke en formel Scrum-begivenhed med fast tidsramme, men en kontinuerlig proces, der typisk optager omkring 10 procent af Development Teams kapacitet i hver sprint.
Formålet med refinement er at sikre, at de øverste elementer i Product Backlog er tilstrækkeligt detaljerede og forståelige til, at teamet kan tage dem ind i en kommende sprint. Uden effektiv refinement risikerer teamet at møde op til Sprint Planning med uklare krav, manglende acceptkriterier og uventede tekniske udfordringer. Det fører til lange planløgningsmøder og upræcise estimater.
Product Owner er ansvarlig for at prioritere og formulere backlog-elementer, men refinement er en samarbejdsproces. Development Team bidrager med teknisk indsigt, identificerer risici og hjælper med at nedbryde store elementer. Scrum Master faciliterer processen og sikrer, at refinement finder sted regelmæssigt. I praksis deltager hele Scrum-teamet typisk i refinement-sessioner en til to gange per sprint.
En refinement-session følger ofte dette mønster: Product Owner præsenterer de næste elementer i backlog-prioriteringen og forklarer konteksten og forretningsværdien. Teamet stiller opklarende spørgsmål, diskuterer mulige løsninger og identificerer afhængigheder. Elementerne tilføjes acceptkriterier, og teamet estimerer størrelsen, typisk med Story Points eller t-shirt-størrelser. Elementer, der er for store, nedbrydes til mindre, leverbare User Stories.
Estimering under refinement er foreløbig. Formålet er at give Product Owner et grundlag for prioritering og at hjælpe teamet med at vurdere, hvor meget arbejde de kan påtage sig i næste sprint. Mange teams bruger Planning Poker til estimering: hvert teammedlem viser sit estimat samtidigt, og forskelle diskuteres. Denne teknik sikrer, at alle perspektiver høres, og at estimaterne ikke påvirkes af ankring fra mere dominerende teammedlemmer.
Et velfungerende refinement-flow arbejder med en horisont på to til tre sprints frem. De øverste elementer (næste sprint) skal være fuldt detaljerede med klare acceptkriterier og estimater. Elementer til sprinten efter skal være nogenlunde forstået og groft estimerede. Elementer længere ude i horisonten kan være større epics, der endnu ikke er nedbrudt. Denne graduerede detaljeringsgrad sikrer, at teamet ikke bruger tid på at specificere arbejde, der måske aldrig prioriteres.
En typisk faldgrube er at behandle refinement som et formelt møde med præsentationer. Effektiv refinement er en dialog, ikke en monolog. Product Owner bør ikke præsentere færdige specifikationer, men invitere teamet til at udforske problemet sammen. De bedste løsninger opstår ofte, når udviklere forstår det underliggende behov og kan foreslå alternativer, som Product Owner ikke havde overvejet.
En anden faldgrube er at refinere for meget eller for lidt. For meget refinement fører til over-specificering, hvor teamet bruger uforholdsmæssigt lang tid på detaljer, der ændrer sig, før arbejdet påbegyndes. For lidt refinement resulterer i uklare opgaver, der skaber forvirring under sprinten. Balancen ligger i at detaljere nok til, at teamet trygt kan forpligte sig til arbejdet i Sprint Planning.
Definition of Ready er et koncept, som nogle teams bruger til at formalisere, hvornår et backlog-element er klar til at tages ind i en sprint. Typiske kriterier inkluderer: elementet har en klar beskrivelse, acceptkriterier er defineret, afhængigheder er identificeret, elementet er estimeret, og teamet forstår, hvad der skal leveres. Definition of Ready er ikke en del af den officielle Scrum Guide, men mange teams finder det nyttigt som en kvalitetsgate.
Refinement påvirker direkte kvaliteten af Sprint Planning. Når backlog-elementer er velforståede og korrekt estimerede, kan Sprint Planning fokusere på at vælge de rigtige elementer og planlægge arbejdet - i stedet for at bruge tid på at afklare krav. Teams, der investerer i god refinement, rapporterer konsekvent kortere og mere produktive Sprint Planning-sessioner.
Teknisk refinement er et supplement til den funktionelle refinement. Her fokuserer udviklerne på at undersøge tekniske aspekter af kommende opgaver: arkitekturovervejelser, integrationspunkter, performancekrav og potentielle risici. Nogle teams afholder separate tekniske refinement-sessioner, mens andre integrerer det i den almindelige refinement. Begge tilgange fungerer, så længe de tekniske indsigter deles med hele teamet.
Product Backlog-elementer, der gentagne gange udskydes eller aldrig prioriteres højt nok til at komme i nærheden af toppen, bør overvejes slettet. En overfyldt backlog med hundredvis af elementer skaber støj og gør det svært at identificere det vigtige. Regelmæssig oprydning - hvor forældede, irrelevante eller for små elementer fjernes - holder backloggen fokuseret og håndterbar. En sund Product Backlog har typisk mellem 30 og 60 aktive elementer.