Scrum-opas | 40. Tuotteen backlogin hoitaminen

Tuotteen Backlogin hoitaminen on yksi Tuoteomistajan ensisijaisista tehtävistä. Hoitoprosessi sisältää uusien Käyttäjätarinoiden muotoilemisen, yksityiskohtien lisäämisen ja lisäämisen Tuotteen Backlogiin. Kuitenkin tärkein hoitotehtävä on varmistaa, että Backlogiin sijoitetut merkinnät ovat oikeassa järjestyksessä, eli ne priorisoidaan.

Tuotteen Backlogin hoitaminen – sisällysluettelo:

1. Johdanto
2. Tuotteen Backlogin hoitamisen tarkoitus
3. Virheet Tuotteen Backlogin ylläpidossa
4. Backlogin ylläpito vs. Scrumissa käytettävät mittarit
5. Yhteenveto

Johdanto

Tuote Backlog on yksi Scrumin artefakteista. Se sisältää priorisoidun luettelon työstä, joka tarvitaan tuotteen luomiseksi. Toisin sanoen, se on luettelo Käyttäjätarinoista, jotka ovat välttämättömiä Tuotetavoitteen saavuttamiseksi. Voit löytää yksityiskohtaisen kuvauksen siitä, mitä Käyttäjätarinat ovat tästä artikkelista. Ja tästä löytyvät tiedot Tuotteen Backlogin ominaisuuksista ja siitä, miten sitä ylläpidetään.

Tuotteen Backlogin hoitamista kutsutaan myös seuraavilla nimillä:

• Backlogin priorisointi,
• Backlogin tarkentaminen,
• Backlogin skaalaus.

Tuotteen Backlogin hoitamisen tarkoitus

Tuoteomistaja hallitsee Tuotteen Backlogia. Keskeiset taidot sisältävät tehtävien priorisoimisen niiden eräpäivän lähestyessä. Tämä johtuu siitä, että Tuotteen Backlogin hoitamisen tavoite on varmistaa, että Tuotteen toiminnot tuottavat suurimman liiketoiminta-arvon, eli ne, jotka ovat asiakaskannan kannalta kaikkein olennaisimpia, ovat to-do-listan kärjessä. Ja niiden kuvaus on selkeä ja yksityiskohtainen, jotta niiden toteuttaminen voi alkaa heti seuraavassa Sprintissä.

Tuotteen Backlogia voidaan päivittää päivittäin tarpeen mukaan. Tuoteomistaja voi lisätä uusia Käyttäjätarinoita Tuotteen Backlogiin keskusteltuaan sidosryhmien ja kehitystiimin kanssa tai tekemällä johtopäätöksiä ja muotoilemalla uudelleen jo kirjoitettuja Käyttäjätarinoita Tuotteen Backlogissa.

Pakollinen Backlogin päivittäminen on yksi tehtävistä, jotka suoritetaan Sprintin tarkastelun aikana. Kuvasimme tämän prosessin yksityiskohtaisesti tässä artikkelissa. Yleensä tämän kokouksen aikana Scrum-tiimi keskustelee ei vain seuraavassa Sprintissä suoritettavista tehtävistä. Se myös alustavasti määrittelee Käyttäjätarinoita ja niiden toteuttamista seuraavissa kahdessa tai kolmessa Sprintissä. Tällainen toimintatapa mahdollistaa Scrum-tiimille ja sen toiminnoille laajemman näkemyksen pitkäaikaisesta suunnasta. Se mahdollistaa ajattelun tällä hetkellä suoritettavista tehtävistä niiden kehittämisen näkökulmasta seuraavissa Sprintissä.

Virheet Tuotteen Backlogin ylläpidossa

Yksi yleisimmistä ongelmista liittyen Tuotteen Backlogin hoitamiseen on sen hallitsematon laajentaminen. Tämä johtuu siitä, että työskennellessä Tuotteen parissa, erilaiset lisätoiminnot ja tehtävät, joita ehdottavat sekä sidosryhmät että Scrum-tiimin jäsenet, ilmestyvät spontaanisti. Siksi Tuotteen Backlogin laajuuden rajoittaminen (scope creep) on yksi tärkeimmistä tehtävistä, joita Tuoteomistaja suorittaa. Yleisimmät virheet, joita Tuoteomistajat tekevät, liittyvät:

1. Poikkeaminen Tuotteen tavoitteesta – liian monien ideoiden lisääminen Tuotteen Backlogiin perus Tuotteen tavoitteen lisäksi ei ole hyvä käytäntö, sillä se vähentää huomattavasti sen luettavuutta. On parempi kerätä ideoita lisätoiminnallisuudesta erilliseen asiakirjaan.
2. Sisällön päällekkäisyys – toistettujen tai hyvin samankaltaisten ideoiden syöttäminen Backlogiin eri sidosryhmiltä – ennen kuin lisätään uusi merkintä Backlogiin, Tuoteomistajan tulisi varmistaa, että uusi merkintä ei toista mitään olemassa olevista.
3. Laajemman näkökulman puute – Tuotteen Backlogin merkinnät tulisi järjestää niiden arvon mukaan suhteessa Tuotetavoitteeseen. Silti on pidettävä mielessä, että priorisoinnin tulisi ottaa huomioon seuraavat useat Sprintit, jotta tietyssä Sprintissä suoritettavat tehtävät ovat saumattomasti yhteydessä sekä edelliseen Sprinttiin että sitä seuraavaan Sprinttiin.

Et voi välttää tämänkaltaisia virheitä. Kuitenkin tietoisuus niiden esiintymisestä voi tehdä Tuoteomistajasta varovaisemman lisätessään uusia Käyttäjätarinoita Tuotteen Backlogiin löytääkseen oikean tasapainon. Tämä johtuu siitä, että on myös virhe antaa Backlogin olla liian kova ja poistaa merkintöjä, jotka sisältävät samankaltaisia tehtäviä, jotka eroavat toisistaan. Esimerkiksi kuvaamalla samankaltaisia Tuotteen toimintoja, jotka eroavat merkittävästi sovelluksessa.

Backlogin ylläpito vs. Scrumissa käytettävät mittarit

Tuote Backlog sisältää kuvauksen jäljellä olevasta työstä koko projektin ajan. Kuitenkin vain ajantasainen ja säännöllisesti hoidettu Backlog voi tarkasti arvioida suoritetun työn määrän suhteen kokonaismäärään. Suoritetun työn määrän kuvaamiseksi tulisi käyttää Burndown-kaaviota, josta kirjoitimme tässä artikkelissa.

Toinen suosittu mittari Scrum-tiimin työn kuvaamiseen on nopeus. Voit mitata sitä vertaamalla Tuotteen Backlogin merkintöjen määrää, jotka on muutettu Inkrementiksi yhden Sprintin aikana. Kuvasimme nopeutta tarkemmin tässä artikkelissa.

Yhteenveto

Tuoteomistaja suorittaa Tuotteen Backlogin hoitamisen. Kun Tuote Backlog on hyvin hoidettu, Scrum-tiimillä on selkeä näkemys jäljellä olevasta työstä. Se voi myös saada laajemman, tulevaisuuteen suuntautuvan näkemyksen siitä, miltä polku Tuotetavoitteeseen näyttää. Tästä syystä Tuoteomistajan on varmistettava, että Tuotteen Backlogiin sisältyvät Käyttäjätarinat ovat prioriteettijärjestyksessä toteutettavaksi. Ja myös, että tulevissa Sprintissä suoritettavat tehtävät on kuvattu hienoimmalla mahdollisella tarkkuudella.

Jos pidät sisällöstämme, liity vilkkaaseen mehiläisyhteisöömme Facebookissa, Twitterissä, LinkedInissä, Instagramissa, YouTubessa, Pinterestissä.