Ketterissä toimintatavoissa pyritään yleisesti siihen, että hanke tai julkaisu saataisiin aikataulussa ja kustannusten puitteissa valmiiksi. Samalla pyritään siihen, että saataisiin aikataulussa juuri oikeat asiat tehtyä. Usein projekteja ohjaamaan muodostetaan jonkinlainen ohjausryhmä. Ohjausryhmän tavoitteena on auttaa projektia onnistumaan, ja se pyrkii tähän tavoitteeseen seuraamalla projektin edistymistä ja myös ajan ja resurssien kuten rahan käyttöä. Usein vastaan tulee kysymys, mitkä ovat tuotekehityshankkeen ohjaamisen kannalta tärkeimmät mittarit.

Pelkkä priorisoitu backlog ei riitä tuotekehityshankkeen ohjaamiseen

Projektilta vaaditaan onnistumiseen myös se, että pystytään ennustamaan, mitä tullaan saamaan valmiiksi.

Tuotekehityshankkeen tiimi koettaa varmistua koko ajan siitä, että tiedetään, mikä on asioiden tärkeysjärjestys eli prioriteetti. Usein on kuitenkin myös niin, että pelkkä prioriteettilista ja ”katsotaan sitten mitä tuli valmiiksi, kun aika tai rahat loppuvat” ei riitä, vaan projektilta vaaditaan onnistumiseen myös se, että pystytään ennustamaan, mitä tullaan saamaan valmiiksi. Lopputuloksen ennustaminen on tärkeää usein sen takia, että asiakkaat, myynti, markkinointi tai johto haluavat pystyä sanomaan tai päättämään, onko lopputulos tarpeeksi hyvä.

Vale – emävale – ennuste

Usein myös muiden tahojen pitää valmistautua tuotteessa oleviin ominaisuuksiin. Tällaisia ovat esimerkiksi dokumentointi, markkinointi, kolmansien osapuolten integraatiot ja muut tämän kaltaiset asiat. Projektin onnistumisen kannalta onkin siis myös tärkeää se, että pystytään ennustamaan tai tietämään, mitä todennäköisesti tullaan saamaan valmiiksi, kun deadline koittaa.

Oikeita mittareita seuraamalla ennusteen luotettavuuden taso selviää

Tuotekehityshanketta ohjattaessa pitääkin katsoa useita erilaisia mittareita, jotta voidaan olla varmoja siitä, että lopputulos on paras mahdollinen. Mittareiden avulla pystytään myös arvioimaan sitä, kuinka luotettava hankkeen lopputuloksen ennuste kullakin hetkellä on. Tämän blogin tavoitteena onkin auttaa projektien ohjausryhmiä ja myös projektitiimejä itseään valitsemaan oikeat mittarit hankkeen seuraamiseen.

Yksi ainoa mittari ei riitä – tarvitset mittariston

Mittareita katsoessa on hyvä ymmärtää, että lopputulosta voidaan arvioida vain useita erilaisia mittareita seuraamalla, ja muodostamalla niistä kokonaiskuva. Kuvitelkaa mieluummin lentokoneen ohjaamo, kuin Harley Davidsonin tankin päällä oleva nopeusmittari. Tutustutaan seuraavassa erilaisiin mittareihin, ja siihen, minkä takia niitä kannattaa seurata.

Backlogiin liittyvät mittarit

Tuotekehitysprojektin backlog on koko hankkeen selkäranka.

Tuotekehitysprojektin backlog on koko hankkeen selkäranka. Se sisältää kuvauksen siitä, minkälaisen ratkaisun hankkeen tiimi kehittää. Jos backlog ei sisällä oikeita asioita, tai tiimi ei kykene priorisoimaan ja jalostamaan backlogia, lopputulos ei varmasti vastaa kenenkään toiveita. Onkin todella tärkeää, että erilaisia backlogin kokoa ja laatua kuvaavia mittareita seurataan ja osataan lukea oikein.

Backlogin koko

Backlogin kokoa voidaan mitata joko

• backlog itemeiden lukumäärällä tai
• backlog itemeiden karkeasti arvioidulla työmäärällä

Ensin mainittu on tarkka, ja jälkimmäinen on huomattavan virheherkkä. Suurta backlogia ei oikein voi kokonaan analysoida niin, että tarkkaa työmäärää jokaiselle backlog itemille voisi sanoa. Jos backlog itemeiden lukumäärä on suuri, se hidastaa backlog itemeiden käsittelyä ja jalostamista (refinement). Priorisointi on hankalampaa, ja suuren backlogin helppo sudenkuoppa on se, että siihen on helppo taas lisätä koko ajan lisää asioita.

Suositeltavia sääntöjä:

• jos backlogin koko ylittää 300-400 itemin rajan, sen käsittely hidastuu aika paljon
• jos backlogilla on paljon yli 9kk tiimin työtä, tiimi ei enää reagoi kovin ketterästi uusiin pyyntöihin, tai suuri osa backlogilla olevasta tavarasta ei koskaan pääse työn alle (homehtuu pohjalle)

Backlog-itemit eri tiloissa

Backlogista on syytä myös seurata, missä eri tiloissa siellä olevat itemit ovat. Tiloja voi olla esimerkiksi:

• uusi (alustavasti listalle päässyt, ehdotettu, mutta ei vielä käsitelty)
• hyväksytty (tuoteomistajan tai tuotehallinnan hyväksymä)
• valmis / refined (tiimi on käynyt itemin läpi backlog refinementissa, ja se on valmis aloitettavaksi)
• vaatii lisätutkimuksia (tiimi on havainnut, että se haluaa tutkia backlog itemia enemmän)
• ei vaadi lisätutkimuksia (tiimi on katsonut itemin, ja se on valmis tarkempaan jalostukseen refinement-sessiossa)

Tilamalli voi olla teidän organisaatiossa erilainen. Tärkeintä on minusta se, että backlog itemille on muukin tila kuin ”valmis aloitettavaksi”, eli ainakin feasibility study tarve ja refinementin läpikäynti pitäisi olla tilamallissa määritelty

Suositeltavia sääntöjä:

• Feasibility studyä tarvitsevien itemien määrää seurataan
• Backlogille hyväksyttyjen ja hylättyjen itemien määrää seurataan
• Backlogille lisättyjen itemien määrää verrataan siihen, miten nopeasti tiimi saa backlogilla olevia asioita valmiiksi (new vs completed) että ymmärretään, onko backlog kasvamassa liikaa.

Backlogin terveys / Backlog health

Backlogin terveys – mittari lasketaan refined items / velocity -kaavalla. Eli, jos tiimi saa vaikka 40 storypointtia sprintissä valmiiksi, ja backlogin huipusta on jalostettuja tarinoita yhteensä 60 storypointin verran, se tarkoittaa sitä, että tiimillä on puolentoista sprintin verran ”valmista tekemistä”.

Suositeltavia sääntöjä:

• Backlog health on noin 1.5 – 2.0

Hankkeen edistymistä seuraavat mittarit

Burnup -kaavio

Burnup-kaavio kertoo yhdellä silmäyksellä projektin edistymisestä monta asiaa:

• releasen target scopen ja sen muutokset historiassa
• valmiiksi saadut tarinat
• velocityn ja sen muutokset joka sprintissä
• optimistisen ja pessimistisen näkemyksen valmistumisaikataulusta

Tätä voikin käyttää sen visualisointiin, että valmistumisella ei ole yhtä ainutta oikeaa ennustettua päivämäärää, vaan todennäköisemmin aikatauluskaala. Burnup soveltuu käytettäväksi releasen seurantaan paremmin kuin burndown, koska burndown ei visualisoi scope-muutoksia. Burndown sopii taas hyvin vaikka sprintin sisällön seurantaan.

Suositeltavia sääntöjä:

• scope muutokset visualisoidaan
• optimistinen ja pessimistinen aikatauluarvio visualisoidaan (ja varmennetaan vaikka POP metodilla)

• suosittelemme burnup vs burndown, koska siitä näkee paremmin scope muutoksen
• sisältää käytännössä velocityn ja release työmääräarvion

Sprint Spillover / Predictability

Scrum sprintissä on tavoitteena saada tiimi kommittoitumaan tiettyyn osaan tarinoista (sprint backlog), jonka se kuvittelee olevan mahdollista saada valmiiksi sprintin aikana. Tämän takia onkin mielenkiintoista seurata sprintin ”spillover” osuutta, eli sitä osuutta miten suuri osa tarinoista valmistuu ja miten suuri osa ei valmistu (ja yleensä siirtyy seuraavaan sprinttiin). Hyvä lukema tässä on 80% tai yli. Jos tiimi jää jatkuvasti hyvin matalalle, alle 50%:iin, se kertoo jostain ongelmasta.

Yleensä ongelmat liittyvät backlog refinement -seremoniaan ja siihen, että tiimi sallii liian suuret tai puutteellisesti määritellyt tarinat sprintin backlogille.

Suositeltavia sääntöjä

• yli 80% saadaan valmiiksi keskimäärin – tilanne on hyvä
• alle 50% saadaan valmiiksi keskimäärin – syyt pitää selvittää tiimin kanssa

Cumulative flow diagram

Cumulative flow diagram (CFD) on lean-toiminnan perusmittareita. Sen päätarkoitus on parantaa ennustettavuutta ja osoittaa tiimin prosessin pullonkaulat, mutta se kertoo myös tiimin toimitusnopeudesta. CFD kaaviosta näkee yhdellä silmäyksellä, miten kauan jonkin asian saamisessa prosessin läpi on kestänyt historiallisesti, ja miten kauan siihen menee tällä hetkellä. CFD diagrammin tarkat lukuohjeet kannattaa lukea täältä.

CFD kaaviosta näkee:

• miten kauan jonkin asia kestää saada prosessin läpi juuri nyt, ja onko tämä nopeus paranemassa vai huononemassa (cycle time)
• tällä hetkellä kesken olevien asioiden määrä (Work in progress, WIP) ja onko se paranemassa vai huononemassa
• resurssien käytön optimointi – jos reagointinopeus on ”liian iso”, eli WIP ja cycle time on pieni, se saattaa olla merkki yliresurssoinnista

Suositeltavia sääntöjä:

• tarkkaile WIP määrää ja seuraa, totteleeko tiimi omia sääntöjään

Tiimin mielipiteitä luotaavat mittarit

Tiimiltä kannattaa kysyä silloin tällöin seuraavia asioita:

• tiimin ”fiilis” tai onnellisuustaso
• tiimin luottamus tai konfidenssi siihen, onko tavoite saavutettavissa
• tiimin näkemys teknisen velan määrästä, onko se kasvamassa vai vähenemässä

Itsestään selvästi, tiimin onnellisuudessa ja teknisen velan määrässä kannattaa seurata trendejä. Onko tilanne menossa parempaan vai huonompaan suuntaan? Jos suunta on huono, kannattaa ottaa tiimi koolle puhumaan asiasta. Tiimin luottamusta tavoitteen saavuttamiseen kannattaa käyttää indikaattorina siitä, onko tuoteomistajan esittelemä aikataulu ja release sisältö ollenkaan realistinen.

Backlogin nopeaa kiertoa vaativien projektien mittarit

Nopeissa projekteissa, joissa pyritään vastaamaan asiakkaiden pyyntöihin, on tärkeää seurata backlogin kiertonopeutta. Tällöin tulee tärkeäksi seuraavat metriikat

• ticket lead time
• cycle time
• average age / story wait time
• backlog ratio (uusien tikettien määrä vs. koko backlogin koko)

Näillä mittareilla voidaan selvittää, pystyykö tiimi reagoimaan tarpeeksi nopeasti asiakkaiden pyyntöihin.

Julkaisun lähestyessä hyvät mittarit

Nämä mittarit ovat hieman harvinaisempia, mutta voivat kertoa siitä, miten hyvää laatua on onnistuttu rakentamaan. Jos julkaisua voidaan kokeilla vaikka pilottimarkkinalla tai pilottiasiakkaalla, deployment-ongelmien ja NPS tuloksien perusteella voidaan päätellä, onko julkaisu valmis laajempaan jakeluun

• failed deployments
• release net promoter score

Kerää sopivat mittarit sinun tarpeisiin

On mahdotonta parantaa, ilman että on jonkinlainen mittari nykytilan ja edistymisen seurantaan.

Kun on puhe siitä, millaisia mittareita kannattaa käyttää, kannattaa ensin miettiä, mikä on oma tavoitteesi. Missä organisaatiosi tuntuu tällä hetkellä olevan suurimpien haasteiden edessä? Mitä haluaisit parantaa? On mahdotonta parantaa, ilman että on jonkinlainen mittari nykytilan ja edistymisen seurantaan. Erilaisiin mittareihin kannattaa sen takia panostaa. On myös hyvä laajentaa mittareiden lukutaitoa ja kiinnostusta omassa organisaatiossa. Lue lisää tuotekehityksen mittaamisesta täältä!

Meillä Contribytellä on vuosikymmenten kokemus tiimien ja organisaatioiden mittareista ja erilaisten dashboardien rakentamisesta. Tuemme tälläkin hetkellä monien asiakkaiden metriikkahankkeita. Ota yhteyttä, jos tuntuu, että tarvitset asiantuntevaa apua.