A legtöbb termékcsopatnál a backlog egy olyan hely, ahol a sürgetőség halálra van ítélve. Minden, ami bekerül, sürgős volt, amikor hozzáadták — egy ügyfélpanasz, egy értékesítési kérés, egy versenytárs funkciója, egy belső ötlet. Hat hónappal később még mindig ott van az összes, még mindig sürgősnek tűnik, és senki sem tudja pontosan, hogy mit kellene tenni a következőként.
A probléma nem az eszközök hiánya. Tucat prioritizálási keretrendszer létezik: RICE, MoSCoW, Kano, ICE, súlyozott pontozás. A probléma az, hogy a legtöbb keretrendszer egy bizonyos hamis pontosságot igényel — számok hozzárendelése az ismeretlenekhez — amely rigorózusnak érzi magát, miközben valójában csak érzést mosogat keresztül egy táblázatba.
Az, ami ténylegesen működik, egyszerűbb: két dimenzió, őszintén értékelve, és a fegyelem az eredményre viselkedni.
A prioritizálás két kérdésre esik. Először: mennyire javítja ez az eredményt, amely érdekel minket? (Hatás.) Másodszor: mennyibe fog kerülni, hogy szállítsa? (Erőfeszítés.) Minden más vagy ezeknek a kettőnek a finomítása, vagy abból való elterelés.
A bizalom néha harmadik dimenzióként jelenik meg — "mennyire vagyunk biztosak a hatásban?" — és érdemes szem előtt tartani. De a gyakorlatban a legtöbb csapat tudja, amikor találgatnak. A fegyelem az, hogy őszintén nevezd meg a találgatást, nem pedig pontozzad 1-5 skálán, és add hozzá egy képlethez.
A nehéz rész nem a rács megértése — hanem őszinte maradni, amikor kitöltöd. Minden csapatnak vannak olyan funkciói, amelyeket szeretne építeni, amelyek az "Időpazarlás" kategóriába tartoznak, de továbbra is "Nagy fogadások" szerint reklaszifikálódnak. A keretrendszer csak akkor működik, ha a csapat őszinte lehet a hatásban.
A hatás az a dimenzió, amelyet a csapatok a legkeselyebbnek találnak, mert gyakran a jövő előrejelzésére van szükség. A kísértés az, hogy pontszámozzad numerikusan és tudományosnak érezzd magad. Jobb megközelítés a kvalitatív, de strukturált.
Tegyen fel három kérdést az egyes mérlegelt funkcióra:
A csapatok szisztematikusan alulbecsülik az erőfeszítéseket. Ez jól dokumentált — a tervezési hiba és optimizmus torzításához kapcsolódik — és különösen erős olyan funkcióknál, amelyek több rendszert érintenek, csapatokon átívelő koordinációt igényelnek, vagy olyan képességeket, amelyeket a csapat még nem épített.
Két gyakorlat segít. Először mindig kérdezd meg a mérnöket az erőfeszítés pontozása előtt, nem után. Az olyan termékvezérek, akik önkényesen pontozzák az erőfeszítéseket, szinte mindig alulbecsülik. Másodszor, az "ismeretlenek az ismeretlenekről" fogalmát használd explicit erőfeszítési szorzóként. Bármely funkció, amely egy új kódbázis területét érinti, egy harmadik fél API-t vagy egy olyan felhasználói folyamatot, amely közelmúltban nem tesztelték, érdemel egy erőfeszítés pontszámot 1,5-szerese magasabb, mint az nyilvánvaló munka sugallja.
A termékeik backlogban történő sürgetősége nem igazi sürgetőség — ez közelmúltbeli. Egy ügyfél panaszolt múlt héten, így kérésük fontosnak tűnik. Egy versenyző egy hónapja elindított valamit, így az egyeztetés kritikusnak tűnik. De a közelmúltbeli nem ugyanaz, mint a fontos, és a közelmúltra való reagálás az egyik legmegbízhatóbb módja annak, hogy hagyod csúszni az igazán fontos munkát.
Egy praktikus teszt: kérdezd meg magadtól, hogy még mindig sürgősnek tartanád-e ezt, ha hat hónapja hallanál róla, ahelyett, hogy múlt héten. Ha a válasz nem, a közelmúltbeli torzítás működik, nem a stratégiai prioritás. Rögzítsd le, értékeld meg nyugodtan a rácsnak, és állj ellen annak a húzásnak, hogy gyorsítsd fel, csak azért, mert friss.
A rács nem mindig ad tiszta választ. Két elem landol ugyanabban a kvadránsban hasonló pontszámokkal, és még mindig ki kell választanod az egyiket. Ezekben az esetekben két kötőszót érdemes használni: stratégiai igazítás (melyik az, amely közelebb mozogtat oda, ahol 18 hónapban lenni szeretnél?) és visszafordíthatóság (melyik az nehezebben visszavonható, ha rossz?). Előnyben részesítsd az olyan elemet, amely jobban strategiailag igazított és visszafordíthatóbb.