Mitä tästä voisi ottaa opiksi tuotekehitystiimin backlog hallintaan?

Toimitusaikaennuste ja varastotaso

Tiimin backlogin pituus tai odotettu uuden pyynnön läpimenoaika olisi tilaajan tiedossa jopa ennen tilauksen tekemistä. Käytännössä monissa tiimeissä voi olla kahdenlaista toimitusaikaennustetta – lyhyempi toimitusaika tärkeille ja kiireellisille asioille, ja sitten pidempi toimitusaikaennuste ei-kiireellisille pyynnöille. Erona verkkokauppaan, tiimin tuoteomistajan kanssa voi neuvotella pyynnön prioriteetista – jos pyyntö on tärkeä, kiireellinen ja helppo tehdä, se voi päästä prioriteetissa hyvinkin ylös, ja ketterä tiimi voi tehdä toimituksen joskus todella nopeastikin (tunneissa, päivissä tai viikoissa). Jos taas tarvitsemasi muutos on vaikeampi toteuttaa, tai päädytään siihen, että muu työ on firmalle kokonaisuudessaan tärkeämpää, saattaa pyyntösi mennä backlogilla alaspäin. Silloin alkaa olla tärkeää seurata sen edistymistä tiimin backlogilla ylöspäin kohti kärkeä.

Varastotaso tarkoittaa tuotekehitystiimin tapauksessa backlogin läpinäkyvyyttä. Jokainen uusi backlogille pyrkivä asiahan taistelee paikastaan backlogilla. On parempi, jos backlog on julkinen ja sen pituutta ja sisältämiä asioita voi kuka tahansa tutkailla. Kun tiimin tuoteomistaja sitten on tehnyt päätöksen siitä, mihin sinun pyytämäsi asia menee, päätös pitäisi olla helpompi sulattaa kun näet tiimin kaiken työn, ja oman pyyntösi sijoituksen siellä.

Tilauksen pakolliset kentät

Suurinta hukkaa tulee, jos tiimi tekee jotain, mikä sitten osoittautuu vääräksi. Olisikin hyvä, jos jo pyyntöä tehtäessä saataisiin kaikki tarpeelliset tiedot kerättyä, jotta priorisointipäätös ja toteutuksen suunnittelu varmasti vastaisi tarvetta. Tätä voi koettaa taklata konfiguroimalla backlogin hallintatyökaluun kenttiä, joihin tarpeelliset tiedot syötetään. Tämä voi tuntua turhauttavalta ja hitaaltakin, mutta luota minuun – pari lisäminuuttia kenttien täytössä maksaa itsensä takaisin, jos saat pyydetyn asian nopeammin ja se varmasti ratkaisee ongelmasi.

Tilausvahvistus

Millä tavalla pystyt itse seuraamaan pyyntösi etenemistä tiimin prosessissa? Olisi hienoa, jos saat sähköpostiin pyynnön linkin, jossa pystyt seuraamaan sen tilaa ja paikkaa tiimin backlogilla. Ehkä tikettiin tulee käyttöliittymäluonnoksia tai ”wireframe demojakin”. Sinulta voidaan pyytää kommentteja jo ennen toteutusta tai jopa sen aikana.

Tieto toimituksesta

Demo! Näet pyytämäsi asian toimivan käytännössä ja voit vaikuttaa siihen. Jos pyyntö oli tehty oikein, tiimi ja tuoteomistaja oli ymmärtänyt asian jota tarvitsit, nyt näet ratkaisun ongelmaasi. Toivottavasti se on parempi kuin osasit kuvitellakaan. Mutta jos tarvitaan jotain säätöä, voit demossa päästä vaikuttamaan ja pyytämään muutoksia, kun asiat ovat vielä koodareiden tuoreessa muistissa.

Näitä tuotteita odotamme vielä

Jos pyytämäsi asia ei pääsekään ihan backlogin kärkeen, olisi hyvä saada tietoa molempiin suuntiin – milloin suunnilleen pyytämäsi asia olisi menossa toteutukseen? Entäpä toisinpäin: oletko sinä saanut odotusaikana selville jotain, mikä tarkentaisi pyyntöä tai vaikuttaisi siihen? Joskus asiat jopa osoittautuvat tarpeettomiksi odotusaikana. Kuten sanottu, mikään ei ole suurempaa hukkatyötä kuin turha työ. Jos pyydettyäsi jotain havaitsetkin, että odotusajan workaround on aivan riittävä, tai saat jopa ratkaistuksi asian itse, on sinun vastuullasi ilmoittaa tiimille siitä.

Usein toistuvat virheet backlogin hallinnassa

Meille käy aika helposti niin, että unohdamme katsoa tiimistä ulospäin. Tällöin seuraavat virheet on aika helppo tehdä päivittäisen kiireen takia

• unohdamme laittaa ”tilaajalle” tiedon tiketin linkistä (tai splitatuista tarinoista jos pyyntö toteutetaan useammassa palassa)
• unohdamme päivittää tilaajaa, kun pyyntö on käsitelty ja hyväksytty backlogille
• unohdamme kertoa todennäköistä toimitusaikaa (huomioiden historiallisen ”urgent kuorman” vaikutuksen suunnitelmiimme)
• unohdamme interaktiot refinementin ja suunnitelun aikana – halvinta on muuttaa pyyntöä hyväksyntäkriteerien listausvaiheessa, tai klikattavan proton vaiheessa

On parempi, jos backlog on julkinen ja sen pituutta ja sisältämiä asioita voi kuka tahansa tutkailla. Kun tiimin tuoteomistaja sitten on tehnyt päätöksen siitä, mihin sinun pyytämäsi asia menee, päätös pitäisi olla helpompi sulattaa kun näet tiimin kaiken työn, ja oman pyyntösi sijoituksen siellä.