I de fleste produktteams er backloggen et sted hvor pres går for at dø. Alt hvad der kom ind i det var presserende når det blev tilføjet — en kundeklage, en salgsanmodning, en konkurrentfunktion, en intern ide. Seks måneder senere er det hele stadig der, og det føles stadig presserende, og nobody helt ved hvilken ting at gøre næste.
Problemet er ikke mangel på værktøjer. Der er dusin af prioriteringsramme: RICE, MoSCoW, Kano, ICE, vægtet scoring. Problemet er at de fleste rammer kræver en slags falsk præcision — tildeling af tal til ukendte — som gør dem føles stringent mens faktisk bare udvaskning magefølelse gennem et regneark.
Hvad der faktisk fungerer er enklere: to dimensioner, ærligt bedømt, og disciplinen til at handle på resultatet.
Prioritering kollapser til to spørgsmål. Først: hvor meget forbedrer dette resultatet vi bryr os om? (Påvirkning.) Andet: hvor meget vil det koste os at levere det? (Indsats.) Alt andet er enten en forfining af disse to eller en aflenkelse fra dem.
Tillid tilføjes nogle gange som en tredje dimension — "hvor sikre er vi på påvirkning?" — og det er værd at huske på. Men i praksis ved de fleste teams når de gætter. Disciplinen er at mærke gættet ærligt, ikke at score det på en 1–5 skala og tilføje det til en formel.
Det svære er ikke at forstå gitteret — det er at være ærlig når man udfylder det. Hvert team har funktioner de ønsker at bygge som hører hjemme i "Tidsslugere" men bliver ved med at blive omklassificeret som "Store væddemål." Rammen fungerer kun hvis teamet kan være ærlig om påvirkning.
Påvirkning er den dimension teams finder sværest at bedømme, fordi den ofte kræver forudsigelse af fremtiden. Fristelsen er at score det numerisk og føle videnskabeligt om det. En bedre tilgang er kvalitativ men struktureret.
Stil tre spørgsmål for hver funktion under overvejelse:
Teams undervurderer systematisk indsats. Dette er velkendt — det er relateret til plangefeilen og optimisme-bias — og det er særligt udtalt for funktioner der berører multiple systemer, kræver koordination på tværs af teams, eller involverer kapabilitet teamet ikke har bygget før.
To praksisser hjælper. Først, spørg altid teknik før du scorer indsats, ikke efter. PM'er der scorer indsats ensidigt undervurderer næsten altid. Andet, brug begrebet "ukendte ukendte" som en eksplicit insatssmultiplikator. Enhver funktion der berører et nyt codebase-område, en tredje-part API, eller en brugerflow der ikke er blevet testet for nylig fortjener en indsat score 1,5x højere end det åbenlyse arbejde foreslår.
De fleste presset i en produkt-backlog er ikke virkeligt pres — det er nylig. En kunde klagede sidste uge, så deres anmodning føles presserende. En konkurrent lancerede noget sidste måned, så matching det føles kritisk. Men nylig er ikke det samme som vigtighed, og reageren på nylig er en af de mest pålidelige måder at lade ægte vigtig arbejde glide.
En praktisk test: spørg dig selv om du ville stadig overveje dette presserende hvis du havde hørt om det seks måneder siden i stedet for sidste uge. Hvis svaret er nej, det er nylig-bias i arbejde, ikke strategisk prioritet. Log det, evaluer det roligt mod gitteret, og modstand trækket til fast-track det bare fordi det er frisk.
Gitteret producerer ikke altid et rent svar. To elementer lander i samme kvadrant med lignende scores, og du skal stadig vælge et. I disse tilfælde er to jambrudder nyttig: strategisk justering (hvilken bevæger dig tættere på hvor du ønsker at være i 18 måneder?) og reversibilitet (hvilken er sværere at fortryde hvis det er forkert?). Foretrækker emnet der er mere strategisk justeret og mere reversibelt.