Når vi har besøgt forskellige dele af KMD, har vi bemærket forskellige syn på kravstyringen i forhold til produkterne. Nogen har en god opsamling af:
- Kundeønsker
- Fejl fundet i driften
- Andre interessenters ønsker
… andre knap så meget. Selvom vi har set kravstyringen som mangelfuld, er det ikke ensbetydende med, at forretningsområdet selv ser det sådan. Det kan snildt være, at de tjener penge og har høj kundetilfredshed på trods af dette. Men den løse styring gør, at udviklingsteamet har en temmelig kaotisk hverdag pga. mange pludselige ændringer i, hvad der er vigtigst at arbejde på lige nu.
Så hvordan tilpasser vi backlog-styringen, så vi kan give scrum-teamet ro til fordybelse uden, at forretningen mindsker indtjeningen samtidig med, at kundetilfredsheden forbliver høj?
Manglende prioritering
En af de primære syndere i forhold til at give teamet ro er manglende prioritering. Manglende prioritering giver ikke bare forstyrrelser, det slører også produktets vision.
Manglende prioritering kan manifestere sig på flere måder.
Mange kokke fordærver maden
Hvis man ikke har nogen klart defineret ansvarlig for prioriteringen i forhold til teamet, kan man ende med ”in-fighting”. Altså at personlige holdninger fra både forretningen og team kolliderer. Hvem skal teammedlemmerne så lytte til? Den, der råber højest? Den, hvis personlige holdninger stemmer bedst overens med teammedlemmets? Måske er der endda en eller flere primadonnaer, som driver produktets retning. Hvis man som ledelse skal udnævne en Product Owner, er det vigtigt at have det in mente.
Stor bunke af opgaver
Er der faktisk forsøgt etableret backlog, har vi set uheldige symptomer – flere af dem er godt beskrevet af Neil Killick her. Mine erfaringer fra KMD viser at en Product Backlog giver god værdi for et team, hvis den bliver brugt rigtigt. Det handler om empowerment af Product Owner-rollen. Lige som Scrum Master-rollen, er Product Owner-rollen svær at udfylde, hvis ikke man har det rigtige drive.
Formen på en Product Backlog
Men hvilke forventninger har vi så til indholdet af en Product Backlog? At have en mening om, hvad der skal laves, er nemt. At lave en bunke af løse formuleringer er også nemt. At formulere det som Product Backlog Items (PBI’er) er straks noget sværere.
Indholdet af en Product Backlog varierer fra område til område. Nogle steder har et team ansvaret for flere uafhængige produkter, og typen af opgaver, der skal løses, er ikke nødvendigvis knyttet til disse produkter. Vi anbefaler, at et team altid kan se prioriteret liste over alle de opgaver, teamet skal løfte i kommende sprints. Det betyder, at typen af opgaver i den Backlog, teamet kan se, ikke kun er knyttet til produkter (man kan diskutere om navnet Product Backlog i denne brug er sigende — måske det burde være Team Backlog?). Ligeledes betyder det, at vi anbefaler, at alle opgaver, et team skal løfte, skal repræsenteres i backloggen. Det vil sige, at der er flere typer opgaver i Backloggen.
Funktionalitet
Vi anbefaler, at man bruger User Stories til at beskrive funktionaliteten, og i disse bør man referere, hvor User Story’en kommer fra. Det være sig fx eksisterende Use Cases, indgåede aftaler med interessenter eller Business Cases. Men også relevant dokumentation i form af mock-ups eller andet, der kan afklare, hvad der menes. Mange af vores anbefalinger stemmer overens med Roman Pichlers anbefalinger.
Defects
Alle fejl og mangler identificeret i produktet bør ligge prioriteret i Backloggen på lige fod med andre PBI’er. Om man har et separat system til defect styring eller ej er lige meget, bare prioriteringen er synlig og bevidst.
Spikes
Tidsbegrænsede analyseopgaver, som bruges til afklaring af komplekse problemstillinger. Det være sig fx ved ny teknologi, Proof-of-concept på nye muligheder eller andet. Det vigtigste ved disse typer af opgaver er, at der er en øvre tidsgrænse på, hvor lang tid teamet må bruge på opgaven. Ellers har analyseopgaver og PoC-opgaver en tendens til at trække ud.
Misc
En catch-all kategori, som fanger alt det, der ikke er dækket af ovenstående. Fx tekniske issues, som teamet gerne vil huske.
God læsning om Product Backlogs er at finde hos Mike Cohn og ScrumGuides.org.
Etablering af en Product Backlog
Vi bruger meget tid og energi på at etablere en Product Backlog. Det er en svær øvelse. Inden vi går i gang, har vi lavet udkast til gode “Definition of Ready” og “Definition of Done” i samarbejde med både Product Owner(s) og Scrum Team. Vi får snakket forventningerne til en backlog igennem og viser nogle eksempler på PBI’er, inden vi for alvor går i gang med backlog workshops.
Nedenstående figur viser meget godt hvordan vi arbejder med backloggen.
Backlog workflow
Uge 1
Opstart med området. Vi etablerer en backlog, identificerer og prioriterer Epics. Herefter nedbrydes de vigtigste Epics til PBI’er, der overholder Definition of Ready således, at Product Backloggen er klar til sprint 1 start i uge 2.
Uge 2
Så starter første sprint. Igennem Sprint Planning-aktiviteterne bliver der købt ind, og teamet commit’er sig til en Sprint Backlog. Vi anbefaler, at man holder Backlog Refinement-møder hver uge, så i opstarten vil der også blive en sådan aktivitet i løbet af uge 2.
Uge 3
Første sprint slutter. Igen afholdes Backlog Refinement. Det er Product Owner’s ansvar at have involveret teamet nok i Product Backlog-arbejdet til, at der nu er nok PBI’er, der overholder Definition of Ready til, at teamet er klar til Sprint Planning i uge 4. Efter Sprint Review tilpasses Product Backloggen, så der er taget højde for feedback fra interessenterne.
Uge 4 & 5
Rinse and repeat uge 2 og 3. Nu skulle man gerne have en nogenlunde rytme i Product Backlog-arbejdet og kunne se fremdriften på produktet.
Så skulle backloggen være etableret. Jeg har ikke dækket hvordan vi estimere, planlægger releases, håndterer milestones eller nedbryder PBI’er. Det må vente til en anden gang, men overordnet set, har jeg god erfaring med en tilgang som ovenstående.
Hvad med jer derude? Hvordan styrer I jeres backlog?
Jeg arbejder med et projekt hvor vi for nylig har indført Scaled Agile Framework (SAFe). Vi har to niveauer af backlogs: En “program backlog” med features, og en “team backlog” for hvert team hvor de bryder features ned til user stories og tasks.
Til prioritering på feature-niveau anbefaler SAFe Weighted Shortest Job First, dvs. at prioriteringen afspejler værdien af en feature, men også hvor tidskritisk den er og hvor lang tid den vil tage at implementere. Det er ikke nogen helt let øvelse, men den giver en interessant vinkel på prioriteringen.
Et af de mange punkter hvor vi stadig har noget at lære er størrelsen af features. En stor feature tager ret meget “plads” i planen og medfører at vi skubber detaljerede diskussioner om scope og prioritet foran os. Men hvis vi definerer mange små features bliver backloggen sværere at overskue, ikke mindst når man skal have overblik nok til at prioritere mellem samtlige features.
Hej Tore.
Spændende at I prøver SAFe. Jeg har ikke selv prøvet den fulde SAFe pakke, så jeg er interesseret i at høre hvordan det går for jer. Men det første jeg tænker når jeg læser om SAFe er Troels Richter & Aino Vonge – Don’t kill Agility with Agile processes (https://www.youtube.com/watch?v=9ZXLqHSbePw). Dermed ikke sagt at der ikke er gode ideer i SAFe, så umiddelbart vil jeg nok vælge de dele der giver mening for et eksisterende setup og så se stort på resten.
Jeg har god erfaring med Story Maps (kender ikke til noget godt digitalt værktøj, ud over mind mapping værktøjer 🙂 ) hvor man netop kan inddele themes i mindre themes, epics i mindre epics indtil man er helt nede på User Story niveau. Med lidt disciplin og en stor væg med masser at post-its og “elefant-snot” kan man få et ganske glimrende overblik.