Te lukijat, jotka olette tuoteomistajia, tunnistatte ehkä nämä otsikon sanat! Itsekin tein pitkään tuoteomistajan hommia, ja myönnetään – nuo sanat lipsahtivat huuliltani kerta toisensa jälkeen. Miksi ne on niin helppo sanoa? Ja miksi tuon ”laitan sen backlogille” sanominen on niin vaarallista? Käydäänpä tässä blogissa läpi tätä asiaa!

Yksi hyvän backlogin ominaisuus on se, että se sisältää vain vähän asioita, joita ei varmasti tulla kehittämään.

Tuoteomistaja vastaa backlogista

Tuoteomistajan vastuu on ylläpitää tuotteen kehitysjonoa, backlogia, eli sitä mitä ominaisuuksia tiimi tai tiimit tuotteeseen seuraavaksi kehittävät. Backlog sisältää asioita, prioriteettijärjestyksessä ja eritasoisina – toiset pienempinä ja selkeästi määriteltyinä, toiset saattavat olla isompia ja epämääräisempiä. Mutta yksi hyvän backlogin ominaisuus on se, että se sisältää vain vähän roskaa – asioita, joita ei varmasti tulla kehittämään.

Vältä kerryttämästä roskaa backlogille

Jonkin verran roskaa aina on, koska olemme ihmisiä ja teemme virheitä. Päätämme tehdä jotain, mutta sitten joko opimme jotain lisää, saamme lisää tietoa, ja lisätiedon valossa näyttääkin, ettei sitä tarvitakaan.

Mutta aivan olennaista tuotteen backlogille on, että sinne hyväksytään vain asioita, jotka oikeasti aiotaan tehdä. Tuoteomistajan ehkä yksi tärkeimpiä päätöspisteitä on se, kun jotain tullaan vaatimaan tai ehdottamaan, niin siinä päättää, että onko tällä asialla potentiaalia riittävästi, että se edes pääsee backlogille.

Arvioi potentiaali heti!

Miksi tarvitaan tämä filtteri, että backlogille pääsee? Sen takia, että asioiden pyytäminen on paljon helpompaa kuin niiden tekeminen. Tekeminen, siis tuotekehitys, kestää useimmiten tunneista päiviin ja viikkoihin, joskus jopa kuukausiin ja vuosiin. Mutta näiden asioiden pyytäminen on melkein aina vain minuuttien asia, varsinkin jos pyytäjä vain kuvailee ylimalkaisesti haluamansa. Kun pyytäminen on niin helppoa, niin pyyntöjä on aina enemmän kuin toteutuneita pyyntöjä, ja tämä kasvattaa backlogin pituutta.

Liian pitkä ja roskainen backlog hidastaa kehitystyötä

Backlog ei saisi kasvaa liian pitkäksi, koska liian pitkä backlog vaikeuttaa priorisointia, pidentää asioiden toimitusaikaa, ja hidastaa myös tekemistä, koska tiimi ja tuoteomistaja joutuu käyttämään energiaa backlogilla olevien asioiden määrittelyyn (groomaus).

Optimipituus backlogille

Mikä on sitten backlogin optimipituus? Mielestäni sen pitäisi olla noin kuudesta viikosta ehkä maksimissaan puoleen vuoteen. Jos backlog alkaa olla paljon yli 6 kuukautta pitkä, siinä alkaa olla ehkä jo liian paljon tavaraa. Taas aivan liian lyhyt backlog on usein oire siitä, että tiimi tai tuoteomistaja ei ole pystynyt käyttämään tarpeeksi energiaa ja aikaa selvittämään tulevia tarpeita. Tarpeita voi siis olla piilossa. Oikea pituus backlogille riippuu tosin paljon myös tuotteen elinkaaren vaiheesta ja toimialan ominaisuuksista.

Mitä vastaat pyytäjälle?

Oletetaanpa nyt tilanne, jossa sinulta, tuoteomistajalta, tullaan pyytämään joku uusi toiminto tai ominaisuus. Kuuntelet kohteliaasti, ehkä ajatellen jotain muuta asiaa samalla. Pyyntö kuulostaa hämärästi arvokkaalta, mutta haluat kuitenkin jatkaa keskeytynyttä työtäsi, ja ehkä kirjoitat asian muistiin paperinnurkkaan tai jopa minuutin mittaiseen JIRA-tikettiin, ja vastaat pyytäjälle ”laitan pyyntösi backlogille”. Asiaa pyytänyt lähtee tyytyväisenä pois, ja sinä jatkat tyytyväisenä keskeytynyttä työtäsi. Just another day in the life of Product Owner.

Mikä ”laitan sen backlogille” -skenaariossa meni pieleen?

Huonoja asioita tässä skenaariossa oli seuraavat:

• Backlogille tuli uusi asia, jonka asiakasarvosta tai työmäärästä ei ole mitään arviota, ja sen takia sen priorisointi on vaikeaa.
• Asian kirjaaminen tapahtui kiireessä ja ilman sen vaatimaa huomiota, joten on epävarmaa, saatiinko se kirjattua ylös selkeästi ja oikein. Ymmärsitkö perimmäisen tarpeen tai syyn, miksi tämä asia tarvitaan? Usein pyytäjä haluaa ratkaisua, ja unohtaa määritellä ongelman, minkä haluaa ratkaistavan.
• Lupaamalla ”laitan sen backlogille” kommunikoit pyytäjälle, että asia on hyväksytty, prosessissa, tulossa. Hän kuvittelee, että voi alkaa odotella pyytämänsä asian toteutusta. Milloinkahan se valmistuu? Asia on selvästi tärkeä (koska ihmisten pyynnöt ovat aina tärkeitä heidän itsensä mielestä). Onhan siis todennäköistä, että se otetaan piakkoin työn alle. Ehkä hän saa sen jo ensi viikolla tai viimeistään ensi kuussa.
• Vertaapa tätä käsitystä siihen, mitä itse ajattelet pyynnöstä. Sinulle ”laitan sen backlogille” oli vaan helppo ja kohtelias tapa päättää keskustelu. Se ei ollut oikea lupaus toteuttaa pyyntöä. Eikö olekin vakava konflikti?

Näin backlogille kertyy toisarvoisia asioita ja sen hallinta hidastuu.

Jos tämä skenaario toistetaan kymmeniä ja satoja kertoja, eikö olekin selvää, mihin se johtaa? Aivan, backlogille kertyy toisarvoisia asioita, jotka on epäselvästi dokumentoitu, hankala priorisoida, ja niitä on paljon. Backlogin hallinta hidastuu ja muuttuu tuoteomistajalle ja tiimille kovin epämieluisaksi. Epämieluisia töitä ei tehdä kovin mielellään, ja backlog groomaus muuttuu pakkopullaksi. Kun backlog on täynnä roskaa, aletaan oikeasti tarpeellisia asioita uittaa sen ohi toteutukseen. Backlogin loppu osa alkaa maatua, muuttua maan tomuksi. Mutta kaikki asioita pyytäneet kuvittelevat edelleen saavansa pyytämänsä asiat. Tilanne ei ole hyvä, ja koko organisaatio stressaantuu.

Mitä pitäisi tehdä backlogille laittamisen sijaan?

”Laitan sen backlogille” on siis vaarallinen vastaus. Mitä sitten oikeasti pitäisi tehdä?

Oikea vastaus pyyntöön laittaa jotain backlogille on

• Keskittyä jokaiseen pyyntöön kunnolla. Keskeytä muu työ, ja kuuntele pyytäjää. Jos aikaa ei ole juuri nyt, varaa keskusteluhetki myöhemmin. Kirjaa aina ylös kuka asiaa pyysi. Tämäkin itsestään selvä asia on helppo unohtaa, mutta se auttaa myöhemmin, kun pitää selvittää kenelle demotaan tai kuka tarinan lopullinen hyväksyjä on.
• Selvitä ongelma, mikä pyynnön takana on – useimmiten pyytäjät tulevat pyytämään ratkaisua, eivätkä osaa kertoa ongelmaa. Älä hyväksy tätä, vaan selvitä asiakastarve tai perimmäinen ongelma. Kirjaa mahdollisesti tehtävään tikettiin molemmat – alustavasti pyydetty ratkaisu ja ongelma tai tarve minkä se ratkaisee.
• Onko asiakkaan ongelmaan muita, helpompia ratkaisuja, kenties olemassa olevaa vain vähän muokaten.
• Toisiko pyydetty toiminto muita potentiaalisia hyötyjä?
• Pyri arvioimaan alustavasti pyynnön arvo, business potentiaali. Tämä on vaikeaa, ja usein vain suuruusluokka on mahdollista arvata.
• Pyri arvioimaan työmäärä tai investointi, mikä pyydetyn asian toteuttamiseen menee. Jos tarpeen, kutsu joku tiimistä mukaan arvioimaan nopeasti, onko kyseessä, tunnin, viikon vai kuukauden homma.
• Milloin asia on mahdollista tehdä, ja milloin pyytäjä tarvitsisi asian? Mieti, onko toteutus realistista tehdä pyydetyssä aikataulussa.
• Tee päätös – go tai no go. Raaka peli on parasta. Hyväksy backlogille vain asiat, jotka ovat selkeästi ROI (return on investment) mielessä hyvä sijoitus.