Useimmissa tuotetiimeissä backlog on paikka, jossa kiireellisyys kuolee. Kaikki sinne päätyvä oli kiireellistä lisäyshetkellä – asiakasvalitus, myyntipyyntö, kilpailijan ominaisuus, sisäinen idea. Kuuden kuukauden kuluttua kaikki on yhä siellä, kaikki tuntuu yhä kiireelliseltä, eikä kukaan tiedä tarkkaan, mitä pitäisi tehdä seuraavaksi.
Ongelma ei ole työkalujen puute. Priorisointikehyksiä on kymmeniä: RICE, MoSCoW, Kano, ICE ja painotettu pisteytys. Ongelma on, että useimmat kehykset vaativat eräänlaista näennäistä tarkkuutta – tuntemattomille annetaan numeroita – mikä saa ne vaikuttamaan tiukoilta, vaikka ne käytännössä vain pesevät mututuntuman taulukkolaskennan läpi.
Se, mikä oikeasti toimii, on yksinkertaisempaa: kaksi ulottuvuutta, rehellisesti arvioituna, ja kuri toimia tuloksen mukaan.
Priorisointi tiivistyy kahteen kysymykseen. Ensiksi: kuinka paljon tämä parantaa tulosta, josta välitämme? (Vaikutus.) Toiseksi: kuinka paljon sen toimittaminen meille maksaa? (Työmäärä.) Kaikki muu on joko näiden kahden tarkentamista tai niistä harhautumista.
Varmuus lisätään joskus kolmanneksi ulottuvuudeksi – ”kuinka varmoja olemme vaikutuksesta?” – ja se kannattaa pitää mielessä. Käytännössä useimmat tiimit kuitenkin tietävät, milloin arvaavat. Kuri on merkitä arvaus rehellisesti arvaukseksi sen sijaan, että se pisteytettäisiin asteikolla 1–5 ja lisättäisiin kaavaan.
Vaikeaa ei ole ruudukon ymmärtäminen vaan rehellisyys sen täyttämisessä. Jokaisella tiimillä on ominaisuuksia, jotka tiimi haluaa rakentaa ja jotka kuuluisivat kohtaan ”Aikasyöpöt”, mutta jotka luokitellaan jatkuvasti uudelleen ”Isoiksi panostuksiksi”. Kehys toimii vain, jos tiimi pystyy olemaan rehellinen vaikutuksesta.
Vaikutus on ulottuvuus, jonka tiimit kokevat vaikeimmaksi arvioida, koska se vaatii usein tulevaisuuden ennustamista. Houkutus on pisteyttää se numeerisesti ja tuntea itsensä tieteelliseksi. Parempi lähestymistapa on laadullinen mutta jäsennelty.
Kysy jokaisesta harkittavasta ominaisuudesta kolme kysymystä:
Tiimit aliarvioivat työmäärän järjestelmällisesti. Tämä on hyvin dokumentoitu – se liittyy suunnitteluharhaan ja optimismiharhaan – ja se korostuu erityisesti ominaisuuksissa, jotka koskettavat useita järjestelmiä, vaativat koordinointia tiimien välillä tai sisältävät toiminnallisuuksia, joita tiimi ei ole aiemmin rakentanut.
Kaksi käytäntöä auttaa. Ensinnäkin kysy aina kehittäjiltä ennen työmäärän pisteyttämistä, ei sen jälkeen. Tuotepäälliköt, jotka pisteyttävät työmäärän yksin, aliarvioivat lähes aina. Toiseksi käytä ”tuntemattomien tuntemattomien” käsitettä nimenomaisena työmäärän kertoimena. Jokainen ominaisuus, joka koskee uutta koodikannan osaa, kolmannen osapuolen API:a tai käyttäjäpolkua, jota ei ole testattu äskettäin, ansaitsee 1,5 kertaa korkeamman työmääräpisteen kuin ilmeinen työ antaisi ymmärtää.
Suurin osa backlogin kiireellisyydestä ei ole todellista kiireellisyyttä vaan tuoreutta. Asiakas valitti viime viikolla, joten hänen pyyntönsä tuntuu painavalta. Kilpailija julkaisi jotain viime kuussa, joten sen vastaaminen tuntuu kriittiseltä. Tuoreus ei kuitenkaan ole sama asia kuin tärkeys, ja tuoreuteen reagoiminen on yksi luotettavimmista tavoista antaa todella tärkeän työn valua ohi.
Käytännön testi: kysy itseltäsi, pitäisitkö tätä yhä kiireellisenä, jos olisit kuullut siitä kuusi kuukautta sitten viime viikon sijaan. Jos vastaus on ei, kyse on tuoreusharhasta, ei strategisesta prioriteetista. Kirjaa asia ylös, arvioi se rauhassa ruudukkoon nähden ja vastusta houkutusta nopeuttaa sitä vain siksi, että se on tuore.
Ruudukko ei aina anna selkeää vastausta. Kaksi kohdetta päätyy samaan neliöön samanlaisilla pisteillä, ja silti sinun on valittava yksi. Tällöin kaksi ratkaisusääntöä on hyödyllistä: strateginen linjaus (kumpi vie sinut lähemmäs sitä, missä haluat olla 18 kuukauden kuluttua?) ja peruttavuus (kumpaa on vaikeampi perua, jos se osoittautuu vääräksi?). Suosi kohdetta, joka on strategisesti paremmin linjassa ja helpompi perua.