Miten tuoteomistaja voi pitää backlogin kurissa ja pienenä?

Backlogin hallinta on keskeinen osa ketterää ohjelmistokehitystä.  Backlog toimii ohjaajana ja mittarina sille, mitä kehitystiimin on tarkoitus tehdä seuraavaksi. 

Backlogin pitäminen järjestyksessä ja siistinä on välttämätöntä tehokkaalle tiimille. Jos backlog on sekava tai liian iso, tiimi ei pysty tehokkaasti tuottamaan arvoa. Backlogin hallinta on yleensä tuoteomistajan vastuulla. Jos tuoteomistajaroolia ei ole käytössä, hallinnasta vastaa tuotepäällikkö.

Tässä blogissa keskitymme siihen, miksi backlogia pitäisi säännöllisesti puhdistaa ja miten se tehdään oikein.

Usein backlogit ovat liian suuria

Usein backlogi kasvaa liian suureksi. Backlogin optimaalinen koko on tyypillisesti noin 50-100 asiaa. Mutta usein backlogeilla on 500 tai jopa tuhat asiaa. Backlogi kasvaa helposti, jos vaan kerää sinne kaikki asiat.

Toinen syy helposti kasvaviin backlogeihin on se, että backlogin ylläpidosta vastaava ihminen (usein tuotepäällikkö tai tuoteomistaja) kokee, että hänen täytyy miellyttää kaikkia ja kerätä backlogille kaikki pyynnöt.

Tuotejohtajan tehtävä ei ole miellyttää kaikkia vaan maksimoida tuotteen organisaatiolle tuoma hyöty! Sokea hyväksyntä backlogille ei hyödytä ketään.

Pidä backlog optimaalisen kokoisena

Kun backlog on pienempi, tästä saadaan seuraavia etuja:

• Motivaatio: Pieni backlog motivoi tiimiä keskittymään olennaiseen ja tiimi kokee saavuttavansa konkreettisia tuloksia.
• Tehokkuus: Kun backlog on kompakti, refinement-sessiot (tai backlogin tarkistus) ovat tehokkaampia.
• Kriittinen ajattelu: Pieni backlog kannustaa tiimiä pitämään hyväksyntäpäätökset kriittisinä. Jokainen päätös mitä tehdään, tarkoittaa samalla päätöstä siitä, mitä ei tehdä.

Mutta jos backlog päästetään kasvamaan liian suureksi, seuraukset voivat olla vakavia:

• Huono priorisointi: Suuren backlogin kanssa tiimi voi helposti hyväksyä kaikki pyynnöt ilman kriittistä arviointia.
• Sekavuus: Liian monimutkainen ja kasvava backlog voi aiheuttaa sekaannusta ja viivästyksiä.
• Sitoutumisen puute: Backlogista tulee passiivinen "to-do"-lista eikä sitova suunnitelma.
• Joustamattomuus: Backlogin pitäisi olla joustava. Suuren backlogin kanssa tiimi ei ehkä pysty vastaamaan nopeasti muuttuviin vaatimuksiin tai prioriteetteihin.

Kolme ideaa backlogin koon hallintaan

Tarjoan tässä kolme käytännöllistä ajatusta ja keinoa backlogin koon hallintaan:

Kriittisyys hyväksynnässä: Jokaisen backlogiin lisättävän tehtävän on kestettävä kriittinen tarkastelu. Ennen kuin lisäät tehtävän, kysy itseltäsi: "Onko tämä todella välttämätöntä? Tuoko se arvoa asiakkaillemme tai liiketoiminnallemme? Miten se tukee nykyisiä tavoitteitamme?" Tämäkysely auttaa varmistamaan, että backlogissa olevat tehtävät ovat todella olennaisia ja niillä on tarkoitus.

Tuotevisio ja lyhyen aikavälin tuotetavoitteet: Tuotteella on oltava visio; tila jossa tuote on muutaman vuoden päästä. Tämä on kuitenkin liian kaukana auttamaan backlog-priorisoinnissa. Tuotevisio pitää tuoda lähemmäs nykytekemistä asettamalla muutaman kuukauden päähän tuotetavoite. Näitä tuotetavoitteita voi määritellä “astinkivinä” tulevaisuuteen vaikka 4-5 kappaletta, niin että ne toistuvat aina muutaman kuukauden välein.

Tällainen tavoite ohjaa backlog-päätöksiä todella tehokkaasti. Useimmat lähimpään tavoitteeseen liittyvät asiat pääsevät backlogille, ja melkein kaikki sellaiset asiat, jotka eivät liity lähimpään tavoitteeseen,eivät pääse. Poikkeus ovat asiat, joiden tutkiminen tai toteutus vaatii pidemmän ajan kuin tavoitteiden välimatka sallii.

Tuotetavoitteet ovat yksi erittäin tehokas, ja valitettavan vähän käytetty priorisoinnin ja backlog-hallinnan työkalu. Niiden käyttö helpottaa myös Scrumin sprinttitavoitteiden käyttöä.

Voit lukea lisää tuote- ja sprinttitavoitteista ja niiden voimasta täältä.

Säännöllinen puhdistus: Backlog ei ole vain paikka lisätä tehtäviä; se on myös paikka poistaa niitä. Backlogiin voi kertyä ajan mittaan tehtäviä, jotka eivät enää ole relevantteja tai ovat muuttuneet prioriteetiltaan. Säännöllinen läpikäynti, arviointi ja tarvittaessa tehtävien poistaminen varmistavat, että backlog pysyy hallittavana ja fokusoituna. On hyvä pitää mielessä, että kaikkea ei voi eikä tarvitse tehdä. Joskus paras päätös on olla toteuttamatta tiettyä ominaisuutta tai tehtävää.

Puhdistusta ei saa tehdä yksin, vaan siihen tulee liittää kaksi tasoa; tiimin kanssa tapahtuva ja sitten sidosryhmien ja tuotejohdon kanssa tapahtuva. Tiimin kanssa voidaan puhdistaa (esimerkiksi kerran kuussa) backlogilta sellaiset asiat, jotka ovat pienempiä ja teknisempiä, eivätkä ehkä kiinnosta ketään tiimin ulkopuolelta.

Tuotejohdon ja sidosryhmien kanssa tapahtuva backlog puhdistaminen voisi tapahtua parin kuukauden välein. Siinä kannattaa keskittyä asioihin, joilla on organisaatiossa riippuvuuksia ja jotka ovat siinä määrin isompia ja vähemmän teknisiä, että ne kiinnostavat myös tätä porukkaa.

Backlogin puhdistuksen "Neljä Ärrää"

Puhdistuksessa voi käyttää muistisääntöä “Neljä Ärrää”:

1. Remove: Poista tarpeettomat tai vanhentuneet tehtävät.
2. Reprioritize: Uudelleenpriorisoi tehtävät, jotka ovat hautautuneet liian alas, mutta ovat edelleen relevantteja.
3. Reduce: Yksinkertaista tehtäviä niiden perusmuotoon ja keskity olennaiseen.
4. Reinvent: Jos jokin tehtävä ei tunnu oikealta, kysy voisiko sen tehdä toisin tai paremmin.

Backlogin hallinta on jatkuva prosessi

Backlogin hallinta ei ole vain tehtävälistan ylläpitämistä; se on olennainen osa ketterän kehityksen prosessia ja auttaa varmistamaan, että tiimi keskittyy oikeisiin asioihin oikeaan aikaan. Kunnollinen backlogin hallinta lisää tuottavuutta, parantaa tiimin motivaatiota ja asiakastyytyväisyyttä ja varmistaa resurssien optimaalisen käytön.

Jos tunnet, että backlogin hallinta tuottaa haasteita tai haluat varmistaa, että prosessit ja työkalut ovat kunnossa, älä epäröi ottaa yhteyttä. Olemme täällä auttaaksemme ja varmistamaan, että tiimisi voi saavuttaa parhaan mahdollisen potentiaalinsa. Muista, että oikein hoidettu backlog on investointi tulevaisuuteen – se maksaa itsensä takaisin moninkertaisesti.