Yksi ketteryyden peruspilareista on, että ei tehdä töitä liian suurissa palasissa. Scrum sprinttiin pitäisi periaatteessa ottaa vain sellaisia töitä, jotka mahtuvat siihen. Usein kuitenkin backlog itemit ovat niin suuria, että niitä ei saa mahtumaan yhteen sprinttiin. Toisinaan asiat ovat myös niin epäselviä, että niiden työmääräarviointi on hankalaa. Tällöin saatetaan joutua tilanteeseen, että aloitetaan liian isoa juttua kerralla.

Miksi backlog itemien pilkkominen on tärkeää?

Minulla on omakohtaista kokemusta siitä, miten suohon voi joutua, jos lähdetään kehittämään liian isoa käyttäjätarinaa. Kehitystiimini kanssa aloimme vuosia sitten kehittää mielestämme ihan hyvin määriteltyä tarinaa, jonka kestoksi arvelimme noin neljä viikkoa (kahden miehen tiimillä). Kehitys aloitettiin ja sujui kuulemma ihan hyvin, mutta mitään testattavaa en oikein saanut ulos kehittäjiltä. Kaikki sujui kuitenkin ”aikataulussa”, ja kun neljä viikkoa oli kulunut, sain lopultakin koko toiminnon eteeni hyväksyntätestaukseen.

Seurauksena solkenaan bugeja

No, eihän se toiminut, ei sitten pätkääkään. Pitkä tarina (pun intended) lyhyeksi – olimme haukanneet aivan liian suuren toiminnon kerralla. Toiminnosta löytyi bugeja solkenaan, yhteensä lähemmäs sata, ennen kuin se oli valmis asiakkaalle. Lopulta laskin neljän kuukauden jälkeen, että toiminnon kehittäminen ottikin oikeasti melkein neljä kuukautta kalenteriaikaa, ja siihen piti laittaa vielä yksi lisäkehittäjä auttamaan. Alkuperäinen työmääräarviomme oli siis ihan pielessä. Ajoissa tehty backlog itemien pilkkominen olisi helpottanut tilannetta huomattavasti!

Backlog itemien pilkkominen – User story splitting – olisi nopeuttanut valmistumista

Pienissä palasissa olisimme välttäneet suuren määrän bugeja.

Jälkiviisaana analysoin, miten meidän olisi pitänyt pilkkoa tuo iso toiminto pienemmiksi. Päädyin helposti, noin kymmenessä minuutissa siihen, että meidän olisi pitänyt pilkkoa tarina kahteenkymmeneen pieneen tarinaan. Näin pienissä palasissa olisimme välttäneet suuren määrän bugeja, mitä syntyi sen seurauksena, kun yritimme tehdä liian isoa kokonaisuutta kerralla. Koko homma olisi varmasti valmistunut puolessa siitä ajasta, minkä se nyt otti.

Mitä liian suurista backlog itemeista seuraa?

Liian suurista backlog itemeistä voi tulla seuraavanlaisia vaikeuksia:

• määrittely on hankalaa
• bugeja tulee enemmän
• edistymisen seuranta on vaikeampaa
• testaukselle jää usein liian vähän aikaa
• koodimuutoksia tulee paljon, jolloin katselmukset ja designin pitäminen terveenä on hankalaa

katsotaan näitä seuraavaksi vähän tarkemmin.

1. Määrittely on vaikeaa

Mitä isompi työkokonaisuus yritetään kerralla tehdä, sitä hankalampi on määritellä tarkasti kaikki halutut toiminnot. Menee ihan mahdottomaksi keksiä kaikkia tarpeellisia hyväksyntäkriteerejä. Tämä johtaa siihen, että kun työ etenee, löytyy koko ajan asioita mitä ei ole määritelty. Kehittäjät joutuvat menemään tuoteomistajan luo kysymään, miten jonkin pitäisi toimia.

2. Bugeja tulee enemmän

Kun yritetään tehdä liian isoa toiminnallisuutta kerralla, jää väistämättä paljon ”harmaata” aluetta, josta ei tiedetä miten sen pitäisi toimia. Se johtaa siihen, että toimintoa on mahdollista käyttää monella eri tavalla. Tämä johtaa siihen, että sitä käytetään helposti tavoilla mitä ei ole suunniteltu ollenkaan. Ja usein käy niin että järjestelmä, jota käytetään tavoilla, joita ei ole suunniteltu, käyttäytyy väärin. Tulee siis bugeja. Kehittäjien on todella hankala suunnitella robustia järjestelmää, jos järjestelmän eri osien käyttöskenaarioita ei tunneta tarkasti.

3. Edistymisen seuranta on vaikeaa

Kun tuotekehitys ei pysty ennustamaan  valmistumista, se johtaa yleensä tunteenpurkauksiin organisaatiossa.

Kaikki tämä johtaa siihen, että liian suuren työkokonaisuuden aloittamisesta johtuu se, että saadaan valheellinen edistymisen tunne. Tämä tunne muuttuu nopeasti kriisiksi, kun havaitaan, että ei oikeasti voidakaan ennustaa milloin toiminto saadaan valmiiksi. Kun tuotekehitys ei pysty ennustamaan milloin joku asia valmistuu, se johtaa yleensä tunteenpurkauksiin organisaatiossa. Myynti ja tuotehallinta odottaa kiivaasti tärkeää uutta toimintoa, mutta ennuste toisensa perään osoittautuu liian optimistiseksi. Trust me – tässä välikädessä ei ole mukava olla.

Kun joka sprintissä saadaan ainakin pieni osa työtä valmiiksi, koko homman edistymisestä saadaan parempi käsitys. Item-kohtainen velocity kertoo nopeasti, jo muutaman pienen palasen valmistuttua sen, milloin koko homma saadaan todennäköisesti valmiiksi.

4. Testaukselle jää liian vähän aikaa

Ison kokonaisuuden tullessa testaukseen, käy usein niin että testaus löytää nopeasti paljon bugeja testattavasta kokonaisuudesta. Sitten näitä bugeja lähdetään korjaamaan, ja asiat kimpoilevat devaajien ja testaajien välillä. Käy helposti niin, että tiimi vähän väsyy tämän itemin kanssa puljaamiseen. Sotaväsymys saattaa johtaa siihen, että kaikkea eksploratiivista testausta ei enää jakseta tehdä. Seuraavatkin tarinat painavat jo päälle.

Iso tarina myös on kauan testauksessa, jolloin kehittäjät aloittavat jo seuraavaa tarinaa. Nämä alkavat sitten puskea päälle testaajille. Vaikka ketteryydessä ei pitäisikään olla ylävirrasta tulevaa painetta, sellainen helposti muodostuu, jos joku tarina tukkii testauksen pitkäksi aikaa. 

5. Koodimuutoksia tulee paljon kerralla

Kun tehdään isoa tarinaa, tulee paljon muutoksia kerralla. Tämä johtaa sitten siihen, että koodin katselmointi ja designin terveyden ylläpito on hankalaa. Refaktorointia kun pitäisi tehdä melkein joka tarinan yhteydessä, niin jos tehdään isoa kokonaisuutta kerralla, refaktorointitarpeetkin on isommat. Tällöin käy helposti niin että tehdään vaan koodi niin että se toimii, mutta ei refaktoroida ollenkaan. Jos tämä otetaan tavaksi, refaktorointivelka kasvaa koko ajan. Tämä hidastaa kehitystä pitkällä tähtäimellä merkittävästi – mutta onneksi backlog itemien pilkkominen auttaa!

Backlog itemien pilkkominen: Contribyten neuvot ja ohjeet

1. Pilko työ riittävän pieneksi

Testaus tasoittuu, kun storyt ovat riittävän pieniä.

Tässäpä on meidän Contribyten ohjenuora pilkkomiseen. Pyri siihen, että jos tarina tai backlog item on enemmän kuin puolet sprintin kestosta (kahden viikon sprintissä raja voisi olla vaikka siis 5 työpäivää), pilko se pienemmäksi. Alarajana olemme pitäneet ohjenuorana sitä, että jos item on 1/4 sprintistä (kahden viikon sprintissä siis vaikka 2–3 päivää) niin sitten se on jo tarpeeksi pieni, eikä välttämättä tarvitse enää pilkkoa pienemmäksi. Eli: pidä backlog itemien kokona 2–5 työpäivää, niin olet kohtuullisen hyvässä tilanteessa.

Tämä tarkoittaa tietenkin vain työn alla olevia tarinoita tai backlog itemeja. Backlogilla saa prioriteettijärjestyksessä alempana ollakin isompia ja epäselvempiä tarinoita.

Tämänmittaisten tarinoiden lisähyöty on se, että ne valmistuvat sopivasti eri aikaan. Tämä johtaa siihen, että niille ihmisille tiimissä, jotka ovat enemmän testaajien roolissa, ei tule sprintin lopussa testauksen ylikuormaa. Testaus tasoittuu paremmin koko sprintin mitalle (varsinkin kun tiedämme, että usein edellisen sprintin asioita osittain jatketaan vielä seuraavassa sprintissä – näin se vaan reaalimaailmassa on).

2. Tarkkaile pilkkomistarvetta

Pilkkomisen tarve tulee siis siitä, että huomataan kokonaisuuden ylittävän tuon asetetun rajan. Tiimin tulisi käyttää rajana samaa asteikkoa, jota käytetään asioiden estimoinnissa. Jos siis käytetään story pointteja, niin sitten tiimin tulisi itse määrittää oma rajansa, joka vastaa suunnilleen tuota puolta sprintin kestosta. Se voi olla vaikka 10, 13 tai 15 story pointtia, riippuen tiimistä. Jos joku ylärajan lähellä ollut tarina osoittautuukin testauksessa vaikkapa liian bugirikkaaksi, kannattaa harkita rajan laskemista.

Estimointi on siis pakko ottaa käyttöön. Ilman estimointia ei tätä pilkkomistarvetta oikein helposti huomaa. Tämä onkin yksi vakavimmista #noestimates-trendin vastaväitteistä.

3. Pilko työt Product Backlog Refinement -sessiossa

Milloin backlog itemien pilkkominen sitten pitäisi tehdä? Tähän on oikeastaan vain yksi oikea vastaus: backlog grooming tai backlog refinement (PBR) -sessiossa (rakkaalla lapsella on monta nimeä). PBR-sessiot olisi hyvä pitää joka viikko tai ainakin joka sprintti. Näistä olenkin kirjoittanut jo aiemmin, käypä lukemassa se blogi seuraavaksi!

Viimeinen takaportti splittaukselle on tietenkin Sprintin suunnittelukokous. Olisi tietenkin hyvä, ettei sinne asti jouduttaisi, vaan PBR:ssä olisi jo käsitelty. Mutta joskus ehkä joudutaan sprint planningissa splittaamaan. No big deal, mutta tavaksi sitä ei kannata ottaa.

4. Työn alla olevien ”Spin off” -tarinat

Usein käy myös niin (varsinkin jos määrittelyjen kanssa ollaan vähän oltu laiskoja), että kun joku asia on työn alla, huomataan että ehkä pitää tehdä yksi tai kaksi uutta tarinaa. Nämä voivat siis olla, vaikka juttuja, mitä opitaan tekemisen aikana, ja yhdessä kehitystiimi ja tuoteomistaja päättävät, että niitä ei tehdä nyt, vaan niistä tehdään omat tarinat. Tietyssä mielessä nämäkin ovat ”splittausta”. Jos tämmöistä tapahtuu jatkuvasti, niin se on kyllä oire siitä, että backlog refinementtia ei ole tehty tarpeeksi hyvin. Sinänsä on hyvä, että spin off tarinat tunnistetaan ja kirjataan backlogille. Nämä spin off tarinat kannattaa huomata joko sprintin aikana tai viimeistään Sprint Review kokouksessa.

5. Miten pilkkoa – Contribyten pilkkomismalli

Meillä Contribytellä on seuraavan kuvan tapainen pilkkomismalli. Tässä mallissa tarinoita voi pilkkoa seuraavien asioiden pohjalta

• käyttäjän flow (user flow)
• toiminto (operation)
• datatyyppi
• riippuvuudet
• maantieteellinen (geographical)
• business rule
• unhappy skenaariot
• non-functional vaatimukset

6. Muita pilkkomismalleja

Kirjallisuutta käyttäjätarinoiden pilkkomisesta on paljon. Vaikka tässä (sivulta 247 eteenpäin puhutaan tarinoiden pilkkomisesta) tai tässä. Muuta luettavaa löydät täältä tai täältä.

Mitä hyötyä backlog itemien pilkkominen tuo?

Koko organisaatio hyötyy, kun tiimit osaavat pilkkoa liian isot tarinat pienemmiksi.

Koko organisaatio hyötyy, kun tiimit osaavat pilkkoa liian isot tarinat pienemmiksi. Hyöty tulee parantuneena laatuna ja parempana ennustettavuutena. Jokaisen kehitysitemin kohdalla tulee parempaa tuotosta ulos – vähemmän bugeja terveemmällä designilla. Koodin säilyy robustimpana. Refaktorointitarpeet on helpompi toteuttaa. Vähemmän bugeja livahtaa tuotantoon asti, kun testaus on simppelimpää ja helpompaa eikä joudu toimimaan aikataulupaineen alla. Ennustettavuus paranee, kun ei ole enää ihan täysi arvoitus, milloin hommat saadaan valmiiksi.

Backlog itemien pilkkominen on asia, missä tiimi voi kehittyä koko ajan paremmaksi. Aluksi se voi tuntua vaikealta, mutta hyvin pian käytäntö muuttuu rutiiniksi kun opitaan halkomaan tarinat sopivan kokoisiksi kokonaisuuksiksi. SItten tiimi voi valita sopivan toteutusjärjestyksen. Järjestys kannattaa valita niin, että päästään nopeasti kokeilemaan asioita, joissa on suurimmat epävarmuudet.

Tarinoiden pilkkomistaitoja kannattaa siis aktiivisesti kehittää. Nämä taidot helpottavat tuotekehitystä ja madaltavat stressiä koko organisaatiossa! Pyydä Contribyte apuun jos tuntuu siltä että tarvitsette sparrausta pilkkomistaitojen kehittämisen kanssa!