Kaikki tunnemme vertauksen, jossa sanotaan, miten elefantti syödään. Aivan, pienissä osissa. Sama pätee myös tuotekehitykseen – käyttäjätarinoiden pilkkominen on onnistumisen edellytys! Jos tiimi päästetään toteuttamaan liian suurta työkokonaisuutta kerralla, siitä ei seuraa kuin ongelmia. Mammuttitarinasta seuraa monia erilaisia vaikeita tilanteita.

Käyttäjätarinoiden pilkkominen on onnistumisen edellytys.

Minulla on omakohtaista kokemusta siitä, kun aloimme tiimini kanssa kehittää toimintoa, jonka luulimme olevan noin 3 viikon työmäärä kahdelta kehittäjältä mukaan lukien testauksen. Todellisuudessa kävikin niin, että kolmen viikon kuluessa ei ollut vielä mitään testattavaa. Koko homma kestikin huomattavasti pidempään ja toiminto oli kovin buginen. Korjasimme kehityksen aikana varmaan sata virhettä.

Jälkeenpäin oli helppo jälkiviisaana huomata, että olimme aloittaneet aivan liian ison toiminnon kehittämisen yhtenä käyttäjätarinana. Ruoskin itseäni, koska emme olleet huomanneet splitata tarinaa pienemmäksi. Jälkikäteen oli helppo jakaa koko toiminto kahteenkymmeneen pienempään tarinaan.

Miksi käyttäjätarinoiden pilkkominen on tärkeää?

Helpompi priorisointi

Käyttäjätarinoiden pilkkominen on tärkeää juuri sen takia, että kun tarinat on jaettu osiin, ne on helpompi priorisoida ja määritellä. Kun yhden tarinan sijasta meillä on kaksikymmentä, on kohtuullisen helppo päättää mitkä 4–5 tarinaa ovat muita tärkeämpiä ja mitkä tarvitaan ensin. Pienemmille tarinoille on myös helpompi määritellä sisältö.

Helpompi määrittely

Tarinoiden sisältö tarkoittaa tarinan määrittelyn lisäksi myös hyväksyntäkriteerejä. Näistä kerrotaan lisää erillisissä blogeissa, mutta periaate on selkeä. Pienempi tarina on helpompi määritellä, se valmistuu nopeammin, se on helpompi testata ja se valmistuu nopeammin.

Vähemmän bugeja ja parempi laatu

Asia on vaan niin, että pienemmät tarinat johtavat parempaan laatuun, nopeampaan koko toiminnon valmistumiseen, parempaan ennustettavuuteen ja vähempään määrään bugeja.

Nopeammin lopullisesti valmista

Kun jotain saadaan myös oikeasti valmiiksi, on tiimillä hyvä tilaisuus ”lukita” osa koodista valmiiksi. Vaikka ketterässä tuotekehityksessä mikään ei olekaan ”lopullista”, silti voidaan tavoitella aina sitä, että kun jotain saadaan valmiiksi, se on tuotantolaatua. Siihen ei periaatteessa tarvitse enää koskea.

Tiheämpi palaute ratkaisun rakenteesta

Toiselta kantilta katsoessa, kun jotain saadaan valmiiksi, on myös hyvä tilaisuus arvioida koko toiminnon toteutuksen arkkitehtuuria. Onko design tarpeeksi hyvä suorituskykymielessä? Miten security? Miten käytettävyys? Kun toteutetaan koko toiminto pienissä palasissa, päästään usein kokeilemaan tiettyjä skenaarioita paljon aikaisemmin, kuin jos toiminto olisi kehitetty suuremmissa palasissa.

Milloin pitää pilkkoa käyttäjätarina?

Useimmat tuotekehitystiimit ovat jo tehneet kymmeniä, ellei satoja backlog itemeita. Tiimit myös omaavat kokemusta backlog itemien koon arvioinnista. Toiset tiimit käyttävät story pointeja, toiset arvioivat asioita päivissä tai tunneissa. Arviointikäytäntö on yksi ketterän toimintatavan perusjuttuja (vaikka on myös olemassa #noestimates-koulukunta, joka on täyttä huuhaata, älkää menkö sille tielle).

Etsi esimerkkejä liian suurista tarinoista

Mitä tahansa arviointiyksikköä tiimi käyttääkin, on varmasti kohtuullisen helppoa etsiä historiasta tarinoita, jotka olivat a) liian isoja ja samaan aikaan b) bugirikkaita ja epäselviä. Idea on juuri katsoa taaksepäin ja löytää asiat, jotka olivat kokonsa takia huomattavasti isompia juttuja kuin mitä aloitettaessa luultiin, tai jossa oli ”liikaa” bugeja. Nyt kun näitä on löydetty pari, kolme, niin tiimin kannattaa katsoa kriittisesti; miten suuriksi arvioimme nämä tarinat ennen kuin aloitimme ne? Olivatko ne kooltaan 20 story pointia? 30? Vai arvioimmeko niihin menevän 10 työpäivää, jos kaikki menee hyvin?

Sovi tiimille raja-arvo

Yleensä riittää, kun sovitaan käyttäjätarinan yläraja.

Näin tutkien tiimi voikin päätyä alustavaan raja-arvoon – jos tulevaisuudessa arvioidaan jonkin kestävän näin paljon, on suuri riski, että tarina on liian iso. Nämä tarinat pitäisikin siis pilkkoa pienemmiksi. Nyt tiimi onkin siis löytänyt ensimmäisen raja-arvon ja kannattaa yhteisesti sopia, että jatkossa pilkomme näin isot tarinat pienemmiksi!

Yleensä riittää, kun sovitaan vaan koon yläraja. Tiimi kyllä havaitsee nopeasti, milloin ei enää kannata pilkkoa pienemmäksi. Tarinoista ei ole tarkoitus tehdä tunnin mittaisia. Sopiva alaraja on päivä, kaksi. Pienempiäkin tietenkin saa olla, mutta päivän mittaisia tarinoita ei enää kannata alkaa kovin aktiivisesti pilkkomaan.

Sisäinen kurinalaisuus – mikä menee yleensä pieleen?

Tiimin, ja erityisesti Scrum Masterin pitää nyt olla hereillä. Tässä käy usein niin, että kun ”splittausraja” on määritelty, niin sitten yllättäen suuri osa tarinoista aletaan arvioida juuri sen rajan alle! Jos vaikka raja on 20 storypointia, niin sitten arvioinnissa aletaankin määritellä isot tarinat aina justiinsa sen alle. Ihminen on laiska – Scrum Masterin pitää vahtia, ettei tiimi ala mennä sieltä mistä aita on matalin.

Kun käyttäjätarinoiden pilkkominen tulee harjoittelun kautta tutuksi, tiimi näkee, että se ei olekaan niin vaikeaa. Sitten riski siitä, että mennään kokoarvioinnissa limbona riman ali, vähenee.

Scrum-sprintti ohjaa tarinan pilkkomisen kokorajoja

Toinen asia, mikä ohjaa sitä, minkä kokoiseksi käyttäjätarinat kannattaa pilkkoa, on Scrumin sprintin pituus. Ohjenuorana on yksinkertaisesti se, että olisi hyvä, että suurin osa sprinttiin valituista tarinoista on kooltaan pienempiä kuin puolet sprintin pituudesta. Eli, kahden viikon sprintissä olisi hyvä, että suuri osa tarinoista on pienempiä kuin viikon mittaisia.

Miksi näin? Ensinnäkin, jos suuri osa tarinoista kestää lähes koko sprintin, johtaa se tilanteeseen, että sprintin loppupuolelle kertyy valtavasti testattavaa. Koska useimmissa tiimeissä on kuitenkin niin, että on ihmisiä, joilla on ”testaushattu päässä”, se johtaa ylikuormaan näille henkilöille. Vaikka agile-idealistit sanovatkin, että Scrum tiimissä ei ole testaaja ja kehittäjärooleja, totuus on vaan se, että ihmisten testauskyvyissä on eroja.

Pienemmät tarinat vähentävät sprintin epätasapainoa

Liian ison käyttäjätarinan kehittäminen johtaa epätasapainoiseen kuormitukseen.

Usein ne ihmiset, jotka ovat valinneet urakseen testauksen, ovat vaan hyviä testaamaan. Ja vaikka olen urallani törmännyt myös kehittäjiin, jotka ovat superhyviä testaajia, täytyy sanoa, että he ovat harvassa. Useimmat kehittäjät eivät ajattele testaajien lailla.

Liian ison käyttäjätarinan kehittäminen johtaa epätasapainoiseen kuormitukseen sprintin alussa ja lopussa. Tämä taas lisää tiimin stressiä, ja painetta siihen, että tehdään jotain muuta kuin sprinttiin sovittua työtä.

Kun tarinat pilkotaan ”puolta sprinttiä” pienemmäksi, tämä kuormaepätasapaino tasaantuu nopeasti. Aina käy kuitenkin niin että jokunen tarina venyy edellisestä sprintistä seuraavaan, ja näin testaajilla on heti sprintin alussa testattavaa. Ja kun suuri osa tarinoista on puolta sprinttiä pienempiä, kun testaajat vapautuvat, on heillä taas lisää testattavaa. Ero on pieni, mutta merkittävä!

Missä käyttäjätarinat pilkotaan?

Aivan ehdoton tilaisuus, seremonia on Backlog groomaus (kulkee myös nimellä backlog refinement tai suomeksi kehitysjonon haravointi). Tästä olenkin kirjoittanut erillisen blogin jo aiemmin. Groomauksen olisi syytä olla säännöllinen tilaisuus, joka toistuu joka viikko. Juuri groomaus onkin tilaisuus, jossa tarinat olisi parasta keskustella ja pilkkoa.

Luit aivan oikein. Tarinat keskustellaan ensin ja pilkotaan sitten. Pilkkomisen tarve on joko heti itsestään selvä, tai sitten tarina keskustellaan, määritellään ja arvioidaan ensin, ja kun se ylittää tiimin itse sopiman työmäärän raja-arvon, tiimi itse päättää tarpeesta pilkkoa tarina pienemmiksi kokonaisuuksiksi.

Jos tarinaa ei ole groomattu, mutta se halutaan ottaa työn alle, se tyypillisesti tapahtuu Sprint planning -sessiossa. Tällöin splittaus voidaan hyvin tehdä siinä.

Miten käyttäjätarinoiden pilkkominen käy tehokkaasti?

Käyttäjätarinoiden pilkkominen onnistuu näiden kolmen ohjeen avulla:

1. Splittaa aina pystysuunnassa
2. Opiskele User story mapping -työkalu
3. Tutustu tarinan splittaustapajulisteeseen

Pilko pystysuunnassa

Tarinoiden splittauksen perusidea on, että pyritään splittaamaan end-to-end pystysuunnassa. Eli, jokainen tarina toimittaa käyttäjälle jonkin osatoiminnon. Ei siis splitata niin, että ensin tehdään tietokanta design, sitten backend tietokanta toteutus, sitten seuraavassa tarinassa interface käyttöliittymälle, ja sitten viimeisessä tarinassa koko frontend. Tämä on väärin splitattu, eikä tuollaisesta pilkkomisesta saada mitään etua.

Pilko kuin söisit hampurilaista!

Ajattele käyttäjätarinoiden pilkkominen pystysuunnassa kuin söisit Big Maciä. Syöt ottamalla haukkauksen hampparista pystysuunnassa, eikö niin. Päällisämpylä, salaatti, pihvi ja pohjasämpylä menee samalla haukkauksella kohti mahalaukkua. Kukaan ei syö hampurilaista niin, että syö ensin pohjimmaisen sämpylän, sitten nuolee ketsupit, sitten syö pihvin… Syö siis tarinat samalla tavalla haukaten.

User story mapping -työkalu

Tarinakartta on hyvä työkalu sekä tarinoiden pilkkomiseen että  EPIC-, Feature- ja Story-kokonaiskuvan järjestämiseen. Kannattaa tutustua, palataan tähän keinoon vielä myöhemmin erillisessä blogissa. Contribytellä on myös tehokas e-learning koulutus user story mapping -keinoon. Kysy meiltä lisää! 

Splittausmallit

Tarinoiden splittaukseen löytyy myös useita erilaisia malleja. Paras, mihin olen törmännyt, on juliste, mikä löytyy tämän linkin takaa. Tutustu tähän. Mike Cohn, koko user story -käsitteen kummisetä, on myös julkaissut omalla saitillaan malleja tarinoiden pilkkomiseen.

Käyttäjätarinoiden pilkkominen on voittavien tuotekehitystiimien olennainen taito

Yhteinen tarinoidensplittaushetki parantaa tiimin yhteenkuuluvaisuutta.

Palataanpa lopuksi mammuttiin. Yksittäiselle ihmiselle mammutti oli liian iso olio, sekä saalistaa että jos sellaisen onnistui kellistämään, syödä. Kun esi-isämme tappoivat mammutin, oli heillä yhtäkkiä ylen määrin lihaa. Se piti jakaa koko porukalle, ehkä myös niille, jotka olivat jääneet kotikylään. Kun lihavuorta jaettiin, se loi yhteiskunnan sääntöjä – ”annoin mammutin lihaa sinulle – ehkä autat minua myöhemmin”. Suurriista pakotti ihmisen laajempaan yhteistyöhön ja paransi kommunikaatiota. Mammuttigrillijuhlat siis lisäsivät heimon yhteenkuuluvaisuutta!

Väitän, että yhteinen tarinoiden keskustelu- ja splittaushetki parantaa tiimin yhteenkuuluvuutta, nostaa kaikkien tietämystä ja pienemmissä paloissa toteutettu toiminto tulee nopeammin valmiiksi ja paremmalla laadulla. Onko sinulla varaa olla kehittämättä sinun tiimisi tarinanpilkkomistaitoja?

Älä päästä mammuttia tukehduttamaan tiimiäsi!

Nykyajan työpaikalla emme joudu keihäin mammuttien kimppuun, mutta voimmeko verrata backlogilla olevaa mammuttitarinaa karvaiseen elefantin esi-isään? Mammutti kannattaa pilkkoa porukalla, ja pienemmissä palasissa se on helpompi syödä. Suomen parhaat mammutinpilkkojakonsultit löydät Contribyteltä. Hiomme teidän pilkkomistaidot veitsenteräviksi. Meiltä löytyy käyttäjätarinoihin koulutusta, valmennusta ja myös e-learning ratkaisuja. Älä enää epäröi, vaan laita meille postia!