Så håller du din produktbacklogg i rätt storlek för teamet

Tyvärr är de flesta produktbackloggar alldeles för stora, vilket skapar stress och kaos för ovetande Product Owners. Undvik detta. Läs vidare och lär dig hur du avgör om din backlogg har rätt storlek.

Om du känner till den optimala storleken kan du inte bara godkänna rätt poster i backloggen, utan också med säker hand styra rensning, granskning och refinement-aktiviteter.

Då kommer ditt team att leverera mer värde och din vardag blir betydligt enklare.

Hur stor en backlogg bör vara

När det gäller antalet poster är en tumregel att backloggen bör innehålla mellan 50 och 150 poster. Även här är mindre bättre. Om du närmar dig 150 bör du försöka ta bort poster från backloggen.

Det finns också en tumregel för hur lång kalendertid teamet bör behöva för att leverera allt i backloggen. Sikta på mellan två och sex månaders arbete.

Det här är förstås generella regler. Du kan hamna i situationer och miljöer som kräver antingen längre eller kortare backloggar.

Din backlogg bör inte vara den enda platsen för arbete

Product Owners försöker ofta hålla allt arbete på ett och samma ställe – i backloggen. Det är helt fel.

Backloggen bör endast innehålla arbete med hög prioritet och tydligt åtagande. Arbete med lägre åtagandegrad, som idéer och ej godkända förfrågningar, kan hållas på andra ställen, till exempel i roadmaps eller önskelistor.

• Önskelistor kan innehålla arbete som är intressant men som kräver utredning eller ytterligare signaler innan det kan godkännas för backloggen.

• Roadmaps kan beskriva produktens utveckling längre fram i tiden, upp till flera år.

Om allt detta arbete läggs till i backloggen förvirrar det teamet och intressenterna. Backloggen bör förbli en kort, prioriterad lista över arbete med hög prioritet och tydligt åtagande.

När du som Product Owner håller arbetet med lägre åtagandegrad på andra ställen blir det enklare att hantera storleken på den faktiska backloggen.

Tecken på att din backlogg är för stor

Ett enkelt sätt att upptäcka en överdimensionerad backlogg är att räkna posterna. Backloggar bör innehålla färre än 150 poster. Om den växer till 200, 300 eller 400 är backloggen alldeles för stor.

Liknande signaler finns i kalendertiden. Om du uppskattar att det tar mer än ett halvår för teamet att slutföra allt arbete i backloggen är den för stor.

En annan signal att vara uppmärksam på är när ditt team drar sig för att gå igenom backloggen. När backloggen har rätt storlek är det inte lika svårt att få dem att göra det. Men om den är för stor blir teamet inte motiverat att gå igenom den, eftersom de vet att:

• Det kommer att ta för mycket av deras tid.

• De kommer att gå igenom poster som de vet aldrig kommer att bli gjorda.

• Vissa poster ligger så långt fram i tiden att viktigare poster nästan säkert kommer att upptäckas först.

Även om det är bra att hålla sig under 150 bör du sikta på en ännu mindre backlogg. Du och ditt team lägger mer tid på att hantera backloggen när den innehåller 150 poster än när den innehåller 50. Att komma ner till 50 poster är svårt, kanske till och med omöjligt, men att försöka hålla den liten hjälper dig att fokusera.

Tecken på att din backlogg är för liten

En alltför liten backlogg är inte lika vanlig som en alltför stor, men den kan vara ett problem.

Om ditt team till exempel börjar bygga en produkt kan backloggen vara nästan obefintlig. Frågan blir då: Hur bygger du upp backloggen samtidigt som ni utvecklar produkten och arkitekturen, på ett sätt som engagerar intressenterna, fortsätter att samla in återkoppling och vidareutvecklar produktkonceptet?

Ett tecken att vara uppmärksam på är att backloggen innehåller få ärenden och inte förändras över tid. Ett litet antal ärenden i sig är inget tydligt tecken, men om ärendena samtidigt inte förändras är det en tydlig signal om att backloggen inte fungerar.

Det kan finnas flera grundorsaker till detta:

• Teamet kan påbörja arbete som inte finns i backloggen.

• Product Owner kanske inte har tillräcklig kontakt med kunder och andra intressenter.

Så håller du backloggen i optimal storlek

För att hålla backloggen i optimal storlek behöver du se till att inflödet av nya ärenden motsvarar utflödet av slutförda. Men här finns en vanlig fallgrop.

Som Product Owner behöver du känna till teamets velocity, men om du försöker få godkännandetakten att exakt motsvara implementationstakten kommer du nästan säkert att misslyckas. Det skulle kräva att alla förfrågningar i backloggen alltid har liknande värde och prioritet, och så är det vanligtvis inte.

Det är bättre att införa regelbundet underhåll och rensning av ärenden som ska tas bort från backloggen. Detta bör göras tillsammans med teamet.

Ett bra sätt är metoden ”scan-and-plan”, som jag beskriver i det här blogginlägget. Under en av de regelbundna veckovisa sessionerna för backlog refinement förfinar teamet inte bara ärendena högst upp i backloggen, utan går också igenom resten för att rensa och omprioritera ärenden. Scan-and-plan är en återkommande aktivitet som genomförs varje månad.

På en övergripande nivå har de flesta organisationer etablerat någon form av långsiktig planering. Den kan likna eller följa SAFe product increment planning.

Den här typen av planeringssessioner kan hållas varannan eller var tredje månad och ger också möjlighet att rensa bort ärenden ur backloggen som inte kommer att genomföras. Du kan även överväga metoden ”scan-and-plan” här.

Metoden med de fyra R:en

I ”scan-and-plan”-sessioner kan du använda metoden med de fyra R:en, där ärenden i backloggen granskas i omvänd prioritetsordning eller efter ålder, från äldst till nyast.

De fyra R:en:

• Rensa bort

• Reprioritera

• Reinventera

• Reducera

Rensa bort innebär att du beslutar att ett ärende inte hör hemma i backloggen. Flytta det då till lämpligt workflow-tillstånd, exempelvis avvisat, uppskjutet eller liknande.

Det är bättre att behålla ett ärende i backloggen och ändra dess status för att visa att det inte kommer att genomföras än att ta bort det. När du gör det, glöm inte att meddela avvisandet till den som skickade in ärendet och berörda intressenter.

Om du inte ska ta bort ärendet behöver du ändra det eller omprioritera det. Både att reinventera och reducera innebär att ändra ärendet. Att reinventera innebär att återgå till det ursprungliga problemet och tänka om kring angreppssättet. Att reducera innebär att förenkla ärendet.

Rätt storlek på backloggen ger ett nöjt team som skapar värde

När backloggen har optimal storlek kan teamet lita på att de alltid arbetar med de viktigaste ärendena. Det motiverar dem också att förfina backloggen och hjälper Product Owner att underhålla den.

Det är ditt ansvar som Product Owner att veta vilken storlek på backloggen som är rätt för din produkt, ditt team och din miljö.