I de fleste produktteams er backloggen et sted, hvor hastværk går hen for at dø. Alt det, der kom ind i den, var presserende, da det blev tilføjet – en kundeklage, en salgsanmodning, en konkurrents funktion, en intern idé. Seks måneder senere ligger det hele der stadig, det føles stadig presserende, og ingen ved helt, hvad der skal gøres næste gang.
Problemet er ikke mangel på værktøjer. Der findes snesevis af prioriteringsmodeller: RICE, MoSCoW, Kano, ICE, vægtet scoring. Problemet er, at de fleste modeller kræver en slags falsk præcision – man tildeler tal til ukendte størrelser – som får dem til at føles stringente, mens de i virkeligheden bare vasker mavefornemmelse rene gennem et regneark.
Det, der faktisk virker, er enklere: to dimensioner, vurderet ærligt, og disciplin til at handle på resultatet.
Prioritering koger ned til to spørgsmål. For det første: Hvor meget forbedrer dette det resultat, vi går op i? (Effekt.) For det andet: Hvor meget koster det os at levere det? (Indsats.) Alt andet er enten en finpudsning af disse to eller en distraktion fra dem.
Sikkerhed tilføjes nogle gange som en tredje dimension – »hvor sikre er vi på effekten?« – og det er værd at have i baghovedet. Men i praksis ved de fleste teams godt, hvornår de gætter. Disciplinen er at mærke gættet ærligt og ikke at score det på en skala fra 1 til 5 og lægge det ind i en formel.
Det svære er ikke at forstå gitteret – det er at være ærlig, når man udfylder det. Alle teams har funktioner, de gerne vil bygge, som hører hjemme under »Tidsslugere«, men som bliver ved med at blive omklassificeret til »Store satsninger«. Modellen virker kun, hvis teamet kan være ærligt om effekten.
Effekt er den dimension, teams har sværest ved at vurdere, fordi den ofte kræver, at man forudsiger fremtiden. Fristelsen er at score den numerisk og føle sig videnskabelig. En bedre tilgang er kvalitativ, men struktureret.
Stil tre spørgsmål til hver funktion, du overvejer:
Teams undervurderer systematisk indsats. Det er veldokumenteret – det hænger sammen med planlægningsfejlslutningen og optimismebias – og det gælder især for funktioner, der berører flere systemer, kræver koordinering på tværs af teams eller involverer kompetencer, teamet ikke har bygget før.
To fremgangsmåder hjælper. For det første: Spørg altid udviklerne, før du scorer indsats, ikke bagefter. Produktchefer, der scorer indsats på egen hånd, undervurderer den næsten altid. For det andet: Brug begrebet »ukendte ukendte« som en eksplicit multiplikator på indsatsen. Enhver funktion, der berører et nyt område af kodebasen, en tredjeparts-API eller et brugerflow, der ikke er testet for nylig, fortjener en indsatsscore, der er 1,5 gange højere, end det åbenlyse arbejde tilsiger.
Det meste af hasten i en produktbacklog er ikke reel hast – det er aktualitet. En kunde klagede i sidste uge, så kundens ønske føles akut. En konkurrent lancerede noget i sidste måned, så det føles kritisk at matche det. Men aktualitet er ikke det samme som vigtighed, og at reagere på aktualitet er en af de mest sikre måder at lade virkelig vigtigt arbejde glide.
En praktisk test: Spørg dig selv, om du stadig ville betragte det som presserende, hvis du havde hørt om det for seks måneder siden i stedet for i sidste uge. Hvis svaret er nej, er det aktualitetsbias, der er på spil, ikke strategisk prioritet. Notér det, vurdér det roligt op mod gitteret, og modstå trangen til at fremskynde det, bare fordi det er frisk.
Gitteret giver ikke altid et klart svar. To elementer havner i samme kvadrant med lignende scorer, og du skal alligevel vælge ét. I de tilfælde er to afgørende kriterier nyttige: strategisk tilpasning (hvilket af dem fører dig tættere på, hvor du vil være om 18 måneder?) og reversibilitet (hvilket af dem er sværest at fortryde, hvis det viser sig at være forkert?). Foretræk det element, der er mere strategisk tilpasset og lettere at gøre om.