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
Related blogs