I de fleste produktteam er backloggen stedet der hastverk går for å dø. Alt som havner der, var hastesaker da det ble lagt til – en kundeklage, en salgsforespørsel, en konkurrents funksjon, en intern idé. Seks måneder senere ligger alt fortsatt der, alt føles fortsatt hastepreget, og ingen vet helt hva de skal ta fatt på neste gang.
Problemet er ikke mangel på verktøy. Det finnes dusinvis av rammeverk for prioritering: RICE, MoSCoW, Kano, ICE, vektet poengsetting. Problemet er at de fleste rammeverk krever en slags falsk presisjon – å sette tall på ukjente størrelser – som får dem til å føles grundige, men i praksis bare vasker magefølelse gjennom et regneark.
Det som faktisk fungerer, er enklere: to dimensjoner, vurdert ærlig, og disiplinen til å handle på resultatet.
Prioritering koker ned til to spørsmål. For det første: Hvor mye forbedrer dette resultatet vi bryr oss om? (Effekt.) For det andre: Hva koster det oss å levere det? (Innsats.) Alt annet er enten en finjustering av disse to eller en distraksjon fra dem.
Sikkerhet legges noen ganger til som en tredje dimensjon – «hvor sikre er vi på effekten?» – og den er verdt å ha i bakhodet. Men i praksis vet de fleste team når de gjetter. Disiplinen er å merke gjetningen ærlig, ikke å gi den en skår på en skala fra 1 til 5 og legge den inn i en formel.
Det vanskelige er ikke å forstå matrisen – det er å være ærlig når man fyller den ut. Hvert team har funksjoner de vil bygge som hører hjemme under «Tidssluk», men som stadig omklassifiseres til «Store satsinger». Rammeverket fungerer bare hvis teamet kan være ærlig om effekten.
Effekt er dimensjonen teamene synes er vanskeligst å vurdere, fordi det ofte krever å forutsi framtiden. Fristelsen er å gi den en tallverdi og føle seg vitenskapelig. En bedre tilnærming er kvalitativ, men strukturert.
Still tre spørsmål for hver funksjon som vurderes:
Team undervurderer systematisk innsats. Det er godt dokumentert – det henger sammen med planleggingsfeilslutningen og optimismeskjevhet – og er særlig uttalt for funksjoner som berører flere systemer, krever koordinering på tvers av team eller krever evner teamet ikke har bygget opp før.
To grep hjelper. For det første: Spør alltid utviklingsteamet før du gir innsatsen en skår, ikke etterpå. Produktsjefer som vurderer innsats på egen hånd, undervurderer nesten alltid. For det andre: Bruk begrepet «ukjente ukjente» som en eksplisitt innsatsmultiplikator. Enhver funksjon som berører et nytt område av kodebasen, en tredjeparts-API eller en brukerflyt som ikke er testet på en stund, fortjener en innsatsskår som er 1,5 ganger høyere enn det åpenbare arbeidet tilsier.
Det meste av hasten i en produktbacklog er ikke ekte hast – det er ferskhet. En kunde klaget forrige uke, så forespørselen føles presserende. En konkurrent lanserte noe forrige måned, så det å matche den føles kritisk. Men ferskhet er ikke det samme som viktighet, og å reagere på ferskhet er en av de sikreste måtene å la virkelig viktig arbeid skli ut.
En praktisk test: Spør deg selv om du fortsatt ville ansett dette som hastesak hvis du hadde hørt om det for seks måneder siden i stedet for forrige uke. Hvis svaret er nei, er det ferskhetsskjevhet som styrer, ikke strategisk prioritet. Logg det, vurder det rolig mot matrisen, og stå imot trangen til å fremskynde det bare fordi det er ferskt.
Matrisen gir ikke alltid et klart svar. To punkter havner i samme kvadrant med like skårer, og du må likevel velge ett. I slike tilfeller er to avgjørende kriterier nyttige: strategisk tilpasning (hvilken flytter deg nærmere der du vil være om 18 måneder?) og reversibilitet (hvilken er vanskeligst å angre hvis den viser seg å være feil?). Foretrekk punktet som er mer strategisk tilpasset og lettere å reversere.