Näin pidät product backlogisi tiimillesi sopivan kokoisena

Valitettavasti useimmat product backlogit ovat aivan liian suuria, mikä aiheuttaa kaikenlaista stressiä ja kaaosta siihen varautumattomille Product Ownereille. Vältä tämä kohtalo. Lue eteenpäin ja opi määrittämään, onko backlogisi sopivan kokoinen.

Kun tiedät backlogisi optimaalisen koon, voit paitsi hyväksyä siihen oikeat työt myös ohjata sen siivousta, läpikäyntiä ja refinement-toimia varmuudella.

Näin tiimisi tuottaa enemmän arvoa ja oma työsi helpottuu huomattavasti.

Kuinka suuri backlog pitäisi olla

Työmäärän osalta nyrkkisääntö on 50–150 työtä. Tässäkin pienempi on parempi. Jos olet lähempänä 150:tä, pyri poistamaan töitä backlogista.

Toinen sääntö koskee kalenteriaikaa, joka tiimiltä kuluu kaiken backlogin työn toimittamiseen. Tavoitteena tulisi olla kahden–kuuden kuukauden työmäärä.

Nämä ovat toki yleisiä sääntöjä. Saatat kohdata tilanteita ja toimintaympäristöjä, jotka edellyttävät joko pidempää tai lyhyempää backlogia.

Backlog ei saa olla ainoa paikka työlle

Product Ownerit yrittävät usein pitää kaiken työn yhdessä paikassa – backlogissa. Tämä on täysin väärä lähestymistapa.

Backlogin tulisi sisältää vain työtä, johon on vahvasti sitouduttu. Vähemmän sitoutumista vaativa työ, kuten ideat ja hyväksymättömät pyynnöt, voidaan pitää muissa paikoissa, esimerkiksi roadmapissa tai toivelistoilla.

• Toivelistat voivat sisältää kiinnostavaa työtä, joka vaatii selvitystä tai lisäsignaaleja ennen kuin se voidaan hyväksyä backlogin.

• Roadmapit voivat kuvata tuotteen kehityspolkua pidemmälle tulevaisuuteen, jopa useiksi vuosiksi.

Jos kaikki tämä työ lisätään backlogin, se hämmentää tiimiä ja sidosryhmiä. Backlogin tulisi säilyä lyhyenä, priorisoituna listana työstä, johon on vahvasti sitouduttu.

Kun pidät Product Ownerina vähemmän sitoutumista vaativan työn muissa paikoissa, varsinaisen backlogin koon hallinta helpottuu.

Merkit siitä, että backlogisi on liian suuri

Helppo tapa tunnistaa ylikokoinen backlog on laskea työmäärä. Backlogissa tulisi olla alle 150 työtä. Jos määrä kasvaa 200:aan, 300:aan tai 400:aan, backlog on aivan liian suuri.

Samankaltaisia merkkejä löytyy kalenteriajasta. Jos arvioit, että tiimiltä menee yli puoli vuotta kaiken backlogin työn viimeistelyyn, backlog on liian suuri.

Toinen varoitusmerkki on se, että tiimisi käy backlogia vastahakoisesti läpi. Kun backlog on sopivan kokoinen, tiimiä ei ole yhtä vaikea saada tekemään sitä. Jos se taas on liian suuri, tiimi ei motivoidu käymään sitä läpi, koska se tietää:

• Siihen kuluu liikaa aikaa.

• He käyvät läpi töitä, joiden he tietävät jäävän koskaan tekemättä.

• Jotkin työt ovat niin kaukana tulevaisuudessa, että tärkeämpiä töitä löydetään lähes varmasti ennen niitä.

Vaikka alle 150 työn määrä on hyvä, kannattaa silti tavoitella vielä pienempää backlogia. Sinä ja tiimisi käytätte enemmän aikaa backlogin hallintaan, kun siinä on 150 työtä verrattuna tilanteeseen, jossa niitä on 50. 50 työhön pääseminen on vaikeaa, ehkä jopa mahdotonta, mutta pyrkimys pitää backlog pienenä auttaa keskittymään olennaiseen.

Merkit siitä, että backlogisi on liian pieni

Liian pieni backlog ei ole yhtä yleinen ongelma kuin liian suuri, mutta sekin voi aiheuttaa haasteita.

Jos tiimisi esimerkiksi alkaa rakentaa tuotetta, backlogisi saattaa olla lähes olematon. Ongelma on silloin se, miten kasvatat backlogia tuotetta ja arkkitehtuuria rakentaessasi tavalla, joka sitouttaa sidosryhmät, kerää jatkuvasti palautetta ja kehittää tuotekonseptia.

Yksi merkki, johon kannattaa kiinnittää huomiota, on se, että backlogissa on vähän kohteita eikä niiden määrä muutu ajan myötä. Pieni kohteiden määrä ei yksinään ole hyvä merkki, mutta jos kohteet eivät samalla myöskään muutu, se kertoo selvästi, ettei backlog toimi.

Tähän voi olla useita juurisyitä:

• Tiimi saattaa aloittaa työtä, jota ei ole backlogissa.

• Product Owner ei välttämättä ole riittävästi yhteydessä asiakkaisiin ja muihin sidosryhmiin.

Näin pidät backlogisi sopivan kokoisena

Jotta backlog pysyy sopivan kokoisena, uusien kohteiden tulon on vastattava valmiiden kohteiden poistumaa. Tässä piilee kuitenkin yleinen sudenkuoppa.

Product Ownerina sinun on tunnettava tiimin velocity, mutta jos yrität sovittaa hyväksyntävauhdin täsmälleen toteutusvauhtiin, epäonnistut lähes varmasti. Tämä edellyttäisi, että kaikki backlogiin tulevat pyynnöt olisivat aina arvoltaan ja tärkeydeltään samanlaisia, mikä ei yleensä pidä paikkaansa.

Parempi tapa on sopia säännöllisestä backlogista poistettavien kohteiden ylläpidosta ja karsimisesta yhdessä tiimin kanssa.

Hyvä käytäntö tähän on ”scan-and-plan”, jota kuvaan tässä blogikirjoituksessa. Yhdessä säännöllisistä viikoittaisista backlog refinement -tapaamisista tiimi ei ainoastaan tarkenna backlogin kärjessä olevia kohteita, vaan käy läpi myös sen muun sisällön karsiakseen ja priorisoidakseen kohteita uudelleen. Scan-and-plan on kuukausittainen, säännöllinen käytäntö.

Ylemmällä tasolla useimmilla organisaatioilla on käytössään jonkinlaisia pidemmän aikavälin suunnittelukäytäntöjä. Ne voivat muistuttaa SAFe product increment -suunnittelua tai noudattaa sitä.

Tällaisia suunnittelutapaamisia voidaan järjestää kahden tai kolmen kuukauden välein. Ne tarjoavat myös mahdollisuuden poistaa backlogista kohteet, joita ei toteuteta. Voit harkita myös ”scan-and-plan”-toimintatapaa.

Neljän R:n menetelmä

”Scan-and-plan”-tapaamisissa voit käyttää neljän R:n menetelmää, jossa backlog-kohteet käydään läpi käänteisessä prioriteettijärjestyksessä tai iän mukaan vanhimmasta uusimpaan.

Neljä R:ää:

• Poista

• Uudelleenpriorisoi

• Keksi uudelleen

• Yksinkertaista

Poistaminen tarkoittaa, että päätät, ettei kohde kuulu backlogiin. Siirrä se tällöin sopivaan työnkulun tilaan, kuten hylätyksi tai siirretyksi myöhempään ajankohtaan.

Backlog-kohde kannattaa säilyttää ja muuttaa sen tila osoittamaan, ettei sitä toteuteta, sen sijaan että poistaisit sen kokonaan. Muista myös viestiä hylkäyksestä pyynnön esittäjälle ja asiaan liittyville sidosryhmille.

Jos et aio poistaa kohdetta, sinun on muutettava sitä tai priorisoitava se uudelleen. Uudelleen keksiminen ja yksinkertaistaminen tarkoittavat molemmat kohteen muuttamista. Uudelleen keksiminen tarkoittaa palaamista alkuperäiseen ongelmaan ja lähestymistavan uudelleenajattelua. Yksinkertaistaminen tarkoittaa kohteen yksinkertaistamista.

Oikean kokoinen backlog tekee tiimistä tyytyväisen ja auttaa sitä tuottamaan arvoa

Kun backlog on sopivan kokoinen, tiimisi voi luottaa siihen, että se työskentelee aina tärkeimpien tehtävien parissa. Tämä myös motivoi tiimiä tarkentamaan backlogia ja auttaa Product Owneria ylläpitämään sitä.

Sinun vastuullasi Product Ownerina on tietää, mikä on oikea backlog-koko tuotteellesi, tiimillesi ja toimintaympäristöllesi.