Rakas tuoteomistajani, ethän ole unohtanut, että Product Ownerin vastuisiin kuuluu myös hyväksyä tiimin työn tulokset? Tämä Product Ownerin tehtävä jää usein vähän unholaan, vaikka tulosten hyväksyminen ja Definition of Done ovat tärkeitä tuoteomistajan vastuualueita. Muistetaan kyllä, että määrittelyt, prioriteetit ja vision kommunikointi kuuluvat tuoteomistajalle, mutta helposti ei muisteta sitä, että lopputuloksen hyväksyminen kuuluu myös Product Ownerin vastuisiin.

Tuoteomistaja – ei laatupoliisi, mutta asiakkaan edustaja

Mitä tulosten hyväksyminen tarkoittaa? Yksinkertaisimmillaan se tarkoittaa sitä, että Product Owner on varma siitä, että lopputulos on asiakkaan tarpeita vastaava. Asiakkaan ja loppukäyttäjän tarpeet pyritään määrittämään jokaiselle backlog itemille hyväksyntäkriteerien (Acceptance Criteria) muotoon mahdollisimman hyvin jo ennen työn aloitusta. Hyväksyntäkriteereistä puhuttaessa kannattaa kuitenkin muistaa se, että liian tarkka speksaus ennen työn aloittamista saattaa olla hukkaa. Usein ymmärrys kasvaa työtä tehdessä niin että lopulliset hyväksyntäkriteerit kannattaa lyödä lukkoon vasta sprintin sisällä.

Hyväksyntäkriteerit eivät yksinään riitä – Definition of Done on yhtä tärkeä!

 Ketterien tiimien pitäisi pyrkiä siihen, että valmiiksi saadut asiat olisivat suoraan releasoitavissa.

Mutta jos ajattelee liikaa vain asiakkaan tarpeita, saattaa unohtua se, että tulos on ketterässä toimintamallissa hyväksyttävissä vasta kun se on ”release-laatua”. Ketterien tiimien pitäisi pyrkiä siihen, että jokaisen sprintin loputtua, valmiiksi saadut asiat olisivat tuoteomistajan niin halutessa, suoraan releasoitavissa. Tämän saavuttaminen on hyvin vaikeaa, ellei tiimillä ole muistilistaa, mitä kaikkea pitää olla tehty, jotta release laatu on varmasti saavutettu. Tämä muistilista onkin ketterissä toimintatavoissa nimeltään Definition of Done (DoD).

Backlog itemit ovat ”done” kun nämä molemmat asiat on täytetty! Siis kaikki hyväksyntäkriteerit täyttyvät ja kun työ on tehty Definition of Donen mukaisesti. Tämän takia, koska juuri tuoteomistajalla on hyväksyjän rooli, tuoteomistajankin pitää olla kiinnostunut ja ymmärtää tiimin käytännöt Definition of Donen suhteen.

Perusasiat voi olla tylsiä ja saattavat unohtua, jos niihin ei joskus keskitytä

Miksi Definition of Done helposti unohtuu? On helppo keskittyä niihin asioihin, jotka muuttuvat – eli itse kehitettävään kohteeseen. ”Rutiiniasiat” helposti unohtuu, koska niiden pitäisi olla kunnossa. Ykkösasia DoDin suhteen tietenkin on, että se on jossain olemassa, ja kirjoitettuna. Yllättävän monta kertaa kysyn ”onko teillä DoD?”, ja saan vastauksena, että ”juu on meillä”. ”No missä se on?” ”No ei me sitä olla kirjoitettu mihinkään, mutta kyllä kaikki sen tietää ja noudattaa.” Tällainen DoD on ”kummitus-DoD”. Ei hyvä!!

Kummitus-DoD ei ole sallittu!

Definition of Done pitää rakentaa yhdessä, ja niin että kaikki tietää missä se on, ja mitä siinä olevat asiat tarkoittavat. Ja sitä DoD:ia pitää myös noudattaa. Joskus käy niinkin, että DoD on liian kunnianhimoinen, eikä tiimi pysty sitä oikein noudattamaan. Näkisin tällaisen DoD:in ”Visio DoD:ina” – eli sitä kohden voidaan edetä pikkuhiljaa. Mutta tässä tilanteessa se oikea DoD mitä noudatetaan pitää kirjoittaa sekin jonnekin.

DoD:in pitäisi muuttua ja kehittyä.

Definition of Done sekä joustaa että haastaa tiimiä

Tuosta edellisestä kävikin jo ilmi seuraava pointti – DoD:in pitäisi muuttua ja kehittyä. Mitä tiukempi DoD on, sitä lähempänä ”valmista” ollaan kun item saadaan se läpäisemään. Tiukka DoD ohjaa tiimiä jatkuvasti hyvään laatuun. Liian helppo DoD jättää todennäköisesti paljon työtä piiloon, työtä, joka pitää tehdä ennen releasointia (tai pahimmassa tapauksessa reaktiivisesti releasoinnin jälkeen).

Miksi juuri minä?

Miksi sitten juuri Product Ownerin pitäisi huolehtia DoDista? Miksi tiimi tai Scrum Master eivät pidä siitä huolta? Hyvä Scrum Master valmentaa tiimin varmasti sellaiseksi, että DoD:ista pidetään hyvää huolta. Mutta ei se yhtään haittaa, jos tuoteomistajakin osoittaa silloin tällöin olevansa kiinnostunut Definition of Donesta. Ihmiset tekevät juuri niitä asioita, joita kokevat, että organisaatiossa arvostetaan. Jos tiimi näkee ja kuulee Scrum Masterin lisäksi myös tuoteomistajalta, että DoD:in noudattaminen on tärkeää, tiimi on paremmin sitoutunut noudattamaan sitä.

Kenen pää on vadilla, jos Definition of Done on unohtunut?

Voit myös miettiä, mitä tapahtuu, jos tiimi jostain syystä on unohtanut noudattaa Definition of Donea? Mitä siitä seuraakaan? Asia kirjataan tehdyksi, ja release menee ulos. Myöhemmin huomataan ongelmia, ja alkaa selvittely. Miksi feature meni puolivalmiina ulos? Tämä voi käydä organisaatiolle kalliiksi, eikä selittely ole kivaa. Tuoteomistajana ei ole kiva olla tuollaisessa tilanteessa.

Puistattava ajatus, eikö? Mutta tämä on helppo välttää, kun silloin tällöin varmistat sprint review’ssa tai kanbanin osalta tuoteomistajan katselmusvaiheessa, että tiimi oikeasti noudattaa sopimiaan donen määritelmiä. Halpa henkivakuutus, eikö?

Mitä Product Owner saa hyvästä DoD:ista?