Blog

Ratkaisu liian suureen backlogiisi: tuotetoivelista

SEP 16, 2022

Kasvaako backlogisi joskus liian suureksi? Backlogit kasvavat helposti niin suuriksi, että niiden hallinta vaikeutuu. Pyynnöstä kieltäytyminen on paljon vaikeampaa kuin sen lisääminen backlogiin.

Arto Kiiskinen

Arto is a Leading Product Owner Coach with 20 years of experience in leading R&D activities both in large and small organizations, in many different roles. He is now committed to training and coaching product owners to become better at their work. He is also CSPO, PSPO, PSM, and ISTQB certified.

Koska olet mukava ihminen, ja kuka tietää? Ehkä ominaisuuspyyntö, johon sanot ei, olisi voinut osoittautua suureksi menestykseksi.

Hyviä uutisia! Voit saada kaiken – kun pidät erillistä toivelistaa.

Tässä blogikirjoituksessa käymme läpi, mitä tapahtuu, kun backlog karkaa käsistä, miksi toivelista ratkaisee ongelmat ja miten sellainen luodaan.

Milloin backlog on liian suuri?

Se riippuu pitkälti tilanteesta. Tiimisi toimintaympäristö, teknologia ja organisaation toimituksiin liittyvät riippuvuudet määrittävät kaikki sen, kuinka pitkälle tiimin sitoumusten on ulotuttava.

Yleinen nyrkkisääntö kuitenkin on, että Product Ownerin tulisi pyrkiä pitämään backlog alle 150 kohteessa ja alle kuuden kuukauden tiimityön laajuisena.

Miksi suuret backlogit ovat haitallisia

Niillä on monia kielteisiä sivuvaikutuksia, ja osa niistä kasaantuu tai synnyttää noidankehiä. Tässä muutamia:

  • Kun kohteita lisätään suureen backlogin, niiden toteutusta on odotettava pitkään. Tämä tekee tiimistäsi vähemmän ketterän.

  • Uudesta pyynnöstä on vaikeampi kieltäytyä, kun backlog on jo suuri. ”Backlogissa on jo 1 500 kohdetta, miksei sinne lisättäisi vielä yhtä?” Product Owner tuntee silloin hallitsevansa heikommin sitä, mihin tiimi sitoutuu. Tämä puolestaan johtaa heikompaan priorisointiin.

  • Kohteet vanhenevat. Jos backlogissa on 12 kuukauden edestä työtä ja lisäät sinne tänään uuden kohteen, tarpeesi ovat todennäköisesti muuttuneet siihen mennessä, kun pääset sen pariin.

  • Tiimisi on vähemmän motivoitunut tarkentamaan suuren backlogin laatua.

  • Kun lisäät pyynnön suureen backlogin, antamasi lupaus ja sitoumus ovat heikompia. Kohteen lisääminen vuoden mittaiseen jonoon ei ole kummoinen lupaus. Tämä heikentää luottamusta organisaatioon.

Parempi backlog roadmapien ja toivelistojen avulla

Product Ownerin ei tulisi antaa backlogin kasvaa liian suureksi. Roadmapit ja toivelistat ovat tärkeitä työkaluja kokonaisuuden hallintaan ja sen varmistamiseen, että tiimillä on pitkän aikavälin suunnitelma siitä, mitä se voi toimittaa.

Katsotaan, miten backlog, roadmap ja toivelista eroavat toisistaan:

  • Backlog – lyhyen aikavälin (0–6 kuukautta) suunnitelma, johon tiimi on vahvasti sitoutunut ja joka määrittää, mitä tiimi toimittaa

  • Roadmap – pitkän aikavälin (6 kuukautta – 5 vuotta) suunnitelma, johon sitoudutaan kevyemmin ja joka määrittää, mitä tiimi pyrkii toimittamaan

  • Toivelista – luettelo kohteista, joiden arvoa ei ole todistettu ja joihin liittyy epävarmuutta. Ne vaativat lisätestausta, jotta voidaan määrittää, kannattaako ne toteuttaa ja milloin. Tiimi sanoo ”ehkä”.

Kyllä, ei vai ehkä

Kun Product Owner saa pyynnön, että tiimin tulisi tehdä jotain tai ratkaista jokin ongelma, hänen on arvioitava, onko se riittävän arvokas ansaitakseen paikan backlogissa. Osa pyynnöistä päätyy backlogin, osa hylätään suoraan.

Joskus pyyntö on riittävän kiinnostava, mutta Product Owner ei pysty tekemään varmaa arviota sen arvosta. Hän voi lisätä pyynnön toivelistalle sen hylkäämisen sijaan.

Ole täysin selkeä, kun sanot ehkä

Product Ownerin on oltava hyvin selkeä lisätessään kohdetta toivelistalle. ”Ehkä” ei tarkoita kyllä.

Kohteen lisääminen toivelistalle ei tarkoita sitoutumista sen toimittamiseen. Se tarkoittaa, että Product Owner testaa, tutkii ja kerää aktiivisesti päätöksentekoon myöhemmin tarvittavat tiedot. Kun hän siis ilmoittaa pyynnön esittäjälle kohteen lisäämisestä toivelistalle, hänen tulisi pyytää kaikkea päätöksentekoa myöhemmin tukevaa tietoa.

Esimerkki: uusi ominaisuus yhdelle asiakkaalle

Myyjä pyytää uutta ominaisuutta, joka kiinnostaisi sillä hetkellä vain yhtä asiakasta. Yksittäisen asiakkaan liiketoimintaperuste ei oikeuttaisi käyttämään resursseja ominaisuuden kehittämiseen.

Product Owner voi lisätä tämän kiinnostavan ominaisuuden toivelistalle ja pyytää myyjää selvittämään alustavan hinnoittelumallin avulla, olisivatko muutkin asiakkaat kiinnostuneita samasta ominaisuudesta. Product Owner keskustelisi ominaisuudesta myös muiden asiakkaiden ja myyntitiimien kanssa. Jos kysyntää havaitaan olevan riittävästi, asia siirtyy backlogiin.

Miten toivelistat auttavat tiimejä backlogin hallinnassa

Toivelistojen avulla

  • Product Ownerin ”Kyllä, lisään sen backlogiin” muuttuu vahvemmaksi ja selkeämmäksi viestiksi.

  • Kun backlog on lyhyempi, toimitusaikaa on helpompi arvioida.

  • Kun backlog on lyhyempi, tiimi on motivoituneempi hallinnoimaan, tarkentamaan ja käymään sitä läpi.

  • Varsinaisen backlogin työkohtien laatu paranee.

  • Tiimi ei koe yhtä paljon stressiä suuresta ja uhkaavasti kasvavasta sitoutuneesta backlogista.

  • Teknisen velan tiketeille jää enemmän tilaa.

  • Voit kohdistaa tarkentamisen oikeisiin työkohtiin ja arvon testaamisen toivelistan kohtiin.

Näin luot toivelistan käytännössä

Mihin se luodaan

Vaihtoehtoja on monia. Se voi olla esimerkiksi:

  • erillinen projekti tai lista työnhallintatyökalussasi (kuten Jirassa).

  • erillinen tila työnkulussasi (tätä itse suosin).

  • ylläpidetty laskentataulukoissa tai Confluence-sivuilla.

Mitä työkohta sisältää

Muista aina lisätä toiveen esittäjä tikettiin. Ilman sitä jatkotoimien seuraaminen on vaikeaa. Muuten toivetta tulisi käsitellä kuten mitä tahansa muuta backlog-työkohtaa. Käytä user story -muotoa, kun se soveltuu tilanteeseen. On tärkeää kertoa, mitä pyydetään ja miksi.

Näin sitä hallinnoidaan

Jos tuotteella on erilliset Product Manager ja Product Owner, heidän tulisi hallinnoida toivelistaa yhdessä ja tavata säännöllisesti. Toivelistojen yleinen haaste on, että ne unohdetaan. Järjestä 1–3 kuukauden välein säännöllinen tapaaminen, jossa käytte toivelistan läpi ja sovitte, mitkä kohdat vaativat jatkotoimia tai testausta.

Näiden kahden listan hallinta on erilaista, sillä niiden kohteilla on eri tarkoitus. Toivelistan kohtien arvoa ei vielä tunneta, joten painopiste on arvon määrittämisessä. Tämä voi tarkoittaa asiakashaastatteluja, prototypointia, yksinkertaisia ja nopeita A/B-testejä tai muita growth hacking -tyyppisiä toimia.

Backlogin kohteilla on jo riittävän korkea prioriteetti. Tiedät, että niitä tarvitaan ja että ne ovat arvokkaita. Näitä kohtia tulisi tarkentaa, jotta tunnistettuun ongelmaan löydetään todennäköisemmin oikea ratkaisu.

Nauti lyhyemmästä backlogistasi

Suosittelen käyttämään toivelistoja backlogisi hallinnan tukena. Muista kuitenkin viestiä ”ehkä”-tilasta selkeästi ja käydä toivelistasi säännöllisesti läpi.

  • Ketterä kehitys
  • Tuotehallinta

Subscribe to our newsletter