Kummallisen usein törmään tilanteeseen, että vaikka tiimissä on Scrum Master (joka yleensä on ”oman toimen ohella” -jobi), niin sitten tiimiltä puuttuu oikea, nimetty Product Owner (PO). Joskus tuoteomistaja on kyllä nimetty, mutta käytännössä hän ei voi PO:n hommia hoitaa joko siksi, ettei osaa, tai siksi, että siihen on liian vähän aikaa – tai sitten henkilö ei vain ole tiimin lähellä ja käytettävissä.

Product Owner -tehtävää hoitaa toisinaan Scrum Master, joskus tiimin linjaesimies. Silloin tällöin projektipäällikkö ja joskus myös tuotepäällikkö. Törmään usein myös tilanteeseen, että on useita ihmisiä, jotka ajattelevat yhtä aikaa hoitavansa Product Ownerille kuuluvia töitä.

Ymmärretäänkö organisaatioissa, kuinka paljon tuoteomistaja vaikuttaa lopputulokseen?

Joskus on sellainen fiilis, että tuoteomistajuuden vaikutusta lopputulokseen ei organisaatioissa täysin ymmärretä. On ehkä hankalaa perustella, miksi yhden ei-kehittäjä-ihmisen pitäisi olla liitettynä aika täysipäiväisesti tiimin kylkeen. Jos teidänkin organisaatiossa tämä asia tuntuu hankalalta perustella muille, toivon, että saatte tästä blogista vähän ajatuksia. Blogissa nimittäin kerron, miksi tuoteomistajuudella on suuri vaikutus. Product Ownerin suuren vaikutusvallan ymmärtää, kun oivaltaa, miten ketterä tuotekehitystiimi toimii.

Kuva 1: tiimin backlogi ja tuotekehitystiimi.

Tuotos voi olla vain niin hyvää kuin tiimille tarjottu input

Tuoteomistaja on tärkein henkilö, joka organisaatiossa päättää siitä, mitä tuossa tiimille työtä syöttävässä backlog-suppilossa on, ja millaisina sieltä tiimille työ syötetään. Vaikka tiimi olisi kuinka hyvä, lopputulos, eli output, voi olla huonoa, jos sisään syötettävät työt (eli yleensä käyttäjätarinat) ovat huonolaatuisia, väärin priorisoituja tai väärin valittuja.

Ideoita on aina paljon enemmän kuin toteutuskapasiteettia – tärkein päätös on mitä EI tehdä

Tuoteomistajan pitää oppia rehellisesti sanomaan EI.

Hyvän tuoteomistajan ensimmäinen ja ehkä tärkein päätös on raakata koko ajan vastaan tulevasta ideavirrasta ne, joissa on eniten jatkopotentiaalia – ja heittää sitten loput ideat roskiin tai kypsymään jonnekin wishlistiin. Eli ensimmäinen päätös on se, mitä EI tehdä. Eli tuoteomistajan pitää oppia rehellisesti sanomaan EI. On äärimmäisen yleistä, voisi jopa väittää, että on tuotekehityksen ”nollas laki”, että ideasyötteitä kehitystiimille on aina enemmän kuin mitä kehitystiimi voi käytännössä saada aikaan. Uusikin tiimi päätyy todella nopeasti tilanteeseen, että backlogilla olevat asiat, vaikka olisivatkin prioriteettijärjestyksessä, ottaisivat yli vuoden tehdä kaikki pois.

Pieni vai suuri valkoinen valhe: ”Laitan sen backlogille”

Tunnustan – itsekin olen syyllistynyt tähän tuoteomistajan yleisimpään valheeseen. Jos joku ehdottaa jotain ideaa, mutta on hankala itse nähdä sen potentiaalia, on paljon helpompi sanoa ”lisään sen backlogille” kuin ”ehkä emme lähitulevaisuudessa tee tuota”, tai suora ”EI kuulosta järkevältä”. Kun sanotaan, että lisätään backlogille, se tarkoittaa, että se menee suoraan backlogin loppupäähän, ja sehän tarkoittaa, ettei sitä tehdä käytännössä koskaan.

Backlogin pituus – pidä se maksimissaan 3–6 kuukaudessa

Joskus backlog sisältää monen vuoden työt. On selvää, että tällainen backlog ei enää ole käytännössä toimiva, vaan tiimi ottaa lähes jatkuvasti uusia töitä ja sijoittaa ne ”keskelle” backlogia, niin että ne saadaan muutamassa kuukaudessa tehtyä. Olisi kuitenkin parempi, että keinotekoisen pitkää backlogia ei päästettäisi edes syntymään, ja tuoteomistaja pystyisi suodattamaan ideavirrasta vain todellisesti arvokkaat ideat backlogille asti.

Backlogin tehokas hallinta olisi helpompaa, jos se olisi vain 3–6 kuukautta pitkä. Erillisissä wishlisteissa tai mappi-ö:ssä voi sitten pitää muita ideoita, mutta tosiaan ideoiden virta ei ole yleensä ongelma yrityksissä. Todella tärkeät asiat tulevat aina vastaan uudelleen. Tärkeää tässäkin on transparenttius, eli koko organisaation olisi syytä ymmärtää miten tuoteomistajana pyrit backlogia hallinnoimaan. Eli missä on ideat, missä eteenpäin vietävät tarinat ja epicit.

”Laitetaan se idealaariin”

Parempi lähestymistapa olisikin, että olisi kaksi laaria: idealaari ja varsinainen backlog.

Ehkä parempi lähestymistapa olisikin, että olisi kaksi laaria: idealaari ja varsinainen backlog. Samalla tavalla kuin varsinaista backlogia groomataan, niin idealaaristakin voisi groomata ehkä hiukan eri porukalla asioita backlogille. Tämä alkaa jo muistuttaa tuotejohtamisen kanbania.

Kaikella on paikkansa prioriteettijärjestyksessä. Arvaa jos et tiedä!

Tuoteomistajan pitäisi pystyä arvaamaan, kuinka arvokas yksittäinen idea voisi olla, ja myös kuinka isotöinen se tulee olemaan. Effortin arviointikyky paranee, kun tuoteomistaja tutustuu ja kerää kokemusta tuotteestaan. Ennen kuin kokemus on kehittynyt riittävälle tasolle, kannattaa avuksi ottaa kehitystiimin porukkaa ja tehdä ideoiden arviointia vaikkapa backlog grooming -sessiossa tai sitten informaalisti.

Tarinoiden arvotus onkin todella hankalaa ja ehkä oman blogin paikka. Toisinaan tarinaan liittyy joku suora asiakastilaus ja silloin arvotus on helppoa. Monesti se menee ihan arvailuksi.

Tarinoiden kirjoittaminen yhdessä on tärkeää

Sitten kun on tehtävät työt on valittu, tuoteomistajan seuraava homma on varmistaa, että tarinat ovat sellaisia, että niissä saadaan juuri oikeat asiat tehtyä, ja tiimi saa tehtyä niiden kanssa työtä tehokkaasti ilman hukkatyötä. Eli, tarinoiden pitäisi olla tarpeeksi pieniä, selkeitä, toisistaan riippumattomia ja niistä pitäisi keskustella tiimin jäsenten kanssa, jotta kaikki ymmärtävät mitä ollaan tekemässä ja niihin voidaan myös tehdä tarvittavia toteutusteknisiä säätöjä.

Anna tiimin huolehtia toteusteknisestä ja laatuasioista. Ole utelias, miten asia etenee ja ohjaa tarvittaessa!

Työn alla oleviin tarinoihin tuoteomistajan kannattaa suhtautua uteliaisuudella, mutta samalla kuitenkin niin, että tiimille jätetään tekninen omistajuus tehdä toteutus niin, että se on hyvälaatuista ja tervettä ja helposti ylläpidettävää. Suosittelenkin, että tuoteomistaja käy kyselemässä kehitystiimiltä, miten homma edistyy ja onko tullut mitään tenkkapoota vastaan. Usein näissä ongelmakohdissa on hyviä tilaisuuksia hienosäätää tarinaa vieläkin arvokkaammaksi.

Asiakasymmärrys ja keskustelut kaikkien kanssa ovat tuoteomistajan arkea – varaa niihin tarpeeksi aikaa

Suuri osa tuoteomistajan työtä on tehdä ”koulututettuja arvauksia”. Arvauksia siitä, mitkä tarinat ovat arvokkaimpia juuri nyt, tai siitä mitkä tarinat on nyt vaan pakko hylätä, koska ne eivät tuota tarpeeksi lisäarvoa tai ovat hankalia myydä sekä liian työläitä. Ehkä haastavin osa tuoteomistajan työtä onkin säilyttää tarpeeksi hyvä asiakaskontakti ja markkinaymmärrys, jotta nämä joka päivä vastaan tulevat arvaustilanteet menisivät mahdollisimman oikein. Asiakaskontaktien ja jatkuvan keskustelun arvo onkin todella suuri tuoteomistajalle, ja siihen on syytä osata varata tarpeeksi työaikaa.

Vie pullaa välillä myös tuotepäälliköille!

Tuotepäällikön ja tuoteomistajan yhteistyö onkin yleensä yksi hyvin toimivien tuotekehitysorganisaatioiden menestystekijä.

Organisaatioissa tuotepäällikkö on yleensä se, jolla on vielä tuoteomistajaakin enemmän vastuuta asiakaskontakteista ja asiakasymmärryksestä. Tuotepäällikön ja tuoteomistajan yhteistyö onkin yleensä yksi hyvin toimivien tuotekehitysorganisaatioiden menestystekijä. Jos et vielä lukenut aikaisemmin kirjoittamaani blogia tuotepäällikön ja tuoteomistajan roolien eroista, lue se nyt!