Tuoteomistajalla on monia vastuita, mutta ehkä se kaikkein tärkein on backlog hallinta. Backlogin eli kehitysjonon tehokkaalla hallinnalla saadaan ehkä eniten lisätehoa irti tuotekehityskoneesta. Backlogin kuntoa kannattaakin aktiivisesti seurata, ja taitoja ja työkaluja sen hoitamiseen kehittää.

Järjestelmällisyydella lisätehoa backlog hallintaan

Yksi suuri haaste backlog hallinnassa on juuri organisoituminen. Varsinkin, jos tuote on elänyt jo jonkin aikaa, backlogilla tuppaa olemaan jo asioita aika paljon. Isompi backlog on hankalampi hallittava. Tähän on monia syitä, eikä pienin ole se, että suurta backlogia yksinkertaisesti on masentava alkaa katsoa. Kun työlista on kompaktimpi, sitä on mukava mennä tuunaamaan. Olisi myös hyvä pitää backlog niin pienenä, että melkein kaikki siellä olevat asiat voisi pitää takaraivossa, mielessä. Tämän takia backlogilla ei saisi olla yli 150 asiaa. Dunbarin luku toimii tässäkin – vaikka kuulostaakin kamalalta että sosiaalisten taitojen rajoittimia voi käyttää Product Ownerin ja backlogin suhteeseen :-).

Mitä tehdä, jos backlog on kasvanut liian suureksi?

Usein on kuitenkin niin, että backlog vain tuppaa kasvamaan yli tuon maagisen 150 asian tavoitelukeman. Jos näin on päässyt käymään, tai olet saanut komennuksen Product Ownerin hommiin ja edeltäjäsi jätti sinulle tuhat asiaa pitkän backlogin, kannattaa tutustua eri tapoihin organisoida backlog hallintaa paremmin. Tässä seuraavassa omia suosikkejani:

Wishlist

Olen aikaisemmin ollut vähän kahta mieltä toivelistojen käytöstä. Toisaalta wishlistoilla jaetaan backlogi useampaan, mikä ei ole koskaan hyvä asia. Wishlist tarkoittaa siis sitä, että se sisältää kandidaatteja, jotka ehkä päätyvät tulevaisuudessa oikealle backlogille. Wishlistojen käytössä kannattaa seurata seuraavia sääntöjä:

• Tiimi ei saa nähdä wishlistaa ”uutena backlogina”. Tiimin suuntaan on vain yksi backlogi.
• Kun lisäät asian wishlistalle, älä kommunikoi asiaa pyytäneelle taholle, että asia on lisätty backlogille. Kommunikoi selkeämmin: ”harkitsen tätä – jos tarvetta esiintyy muuallakin, ehkä. Kerron sinulle miten asia etenee.”
• Vaikka tiimin suuntaan wishlista onkin ”piilossa” sinä tuoteomistajana joudut ylläpitämään sitäkin. Ei ole hyvä jos wishlistalle vain lisätään asioita, niitä aktiivisesti hallinnoimatta. Varaudu siis siihen, että wishlistaakin pitää miettiä ja hallinnoida. Laita itsellesi vaikka kalenterimuistutus.
• Älä pidä wishlistaa piilossa – testaa siinä olevia ajatuksia ja ideoita, saadaksesi lisää tietoa ovatko ne tärkeitä vai eivät. Jos vastakaikua ei tule – delete. Jos taas ihmiset innostuvat – siirrä asiat varsinaiselle backlogille.
• Wishlista on ”työreservi” – sen ei tarvitse olla priorisoitu, vaan siinä olevat asiat priorisoituvat, kun muualta tulee lisätietoa, että juu tämä olisikin hyvä ja rahanarvoinen ominaisuus.

Wishlistan käytöllä siivoat oikealta backlogilta ”maybe” asiat pois ja lyhennät sitä merkittävästi.

Hajoita ja hallitse

Oikea backlog, jos se on kasvanut suuremmaksi, kannattaa ehdottomasti organisoida toiminnallisuusalueiden, epicien tai user story mapin avulla. Epicit ovat ”isoja tarinoita” joiden elinikä on usein kuukausista vuosiin. Niitä käyttämällä voit priorisoida ja ajatella asiakasarvoa tehokkaasti. Epicien sisällä priorisointi on paljon helpompaa, kun tarinoita on satojen sijasta vain 10-20.

Toiminnallisuusalueet ovat kuten foldereita. Monimutkaisenkin tuotteen ominaisuudet voi usein jakaa pariinkymmeneen osa-alueeseen. Nämä toimivat kuten kansiot – backlogi, jossa on viisi sataa itemia, on todella vaikea priorisoitava. Mutta jos olet ryhmitellyt backlogin vaikkapa 15 toiminnallisuusalueeseen, kuhunkin kansioon jää enää noin reilu parikymmentä asiaa. Nyt priorisointi kansion sisällä onkin tosi helppoa. Seuraavaksi sinun tarvitseekin vain priorisoida kansiot, ja päätöksenteko siitä, mitä pitää tehdä on todella paljon helpompaa.

User story map on hyvä keino organisoida ominaisuudet ”äitiominaisuuksien” alle. Sitä kannattaa käyttää erityisesti monimutkaisissa tuotteissa, ja tuotekehityksen alkutaipaleella.

käytä toiminnallisuusalueita epicejä tai user story mappia ”hajoita ja hallitse”

Käytä työn tyyppiä

Toinen tapa jaotella tehtävä työ on sen tyypin mukaan. Tällaisia ovat esimerkiksi

• mahdollisuudet (opportunity)
• tekninen velka (tech debt)
• toiminnot (features)
• käyttöliittymäparannukset (UX improvements)

On kohtuullisen helppo tehdä joko lippuja tai pyyntötyyppejä Jiraan, ja sitä kautta jaotella uudet ideat ja ehdotukset eri kategorioihin. Seuraavaksi voitte vaikka tiimin kanssa yhdessä sopia, miten erityyppisiä asioita käsitellään. Voi olla esimerkiksi niin, että joka sprinttiin valitaan joku tech debt -tiketti. Tai UX parannuksia tehdään minor bugien korjaukseen varattujen ”juustopäivien” yhteydessä niin monta kuin ehditään. Keinoja on monia, kun käytät tällaista kategorisointia.

Bugit erikseen

Vaikka perinteinen agile-ideologia sanookin, että kaikki työ pitää olla yhdellä backlogilla, itse olen kokeillut myös bugien erottamista erikseen. Bugit omalla listalla voi auttaa vähentämään feature-backlogin pituutta merkittävästi. Tällä saavutetaan myös se etu, että bugeille on usein hyvin erilaiset säännöt kuin normaalille kehittämiselle. Vakavat bugit pitää korjata erittäin nopeasti, ja toisaalta meillä saa vaikka olla vain tietty määrä ”major” tason bugeja auki kun teemme julkaisun. Kun bugeja hallitaan ominaisuusbacklogin ulkopuolella, tämä päätöksenteko yksinkertaistuu.

Mittarit ja mittaristot

Lopuksi, on erittäin tärkeää, että mietit, millä tavalla backlogin sisältöä mitataan. Tuoteomistajana sinulla pitää olla Jira-dashboardilla kaikki ne mittarit, joita säännöllisesti käytät tilanteen seuraamiseen. Ovatko kaikki uudet bugit screenattu? Edistyykö bugikorjaus toivotusti? Mitä tiimi tekee juuri nyt? Mikä on backlogin pituus? Mikä on avoinna olevan bugin keskimääräinen elinikä? Miten paljon saamme asiakastukipyyntöjä? Mittarivaihtoehtoja on monia, ja niistä puhutaan lisää täällä.