Olemme Hyvä käyttäjätarina -blogisarjassamme kirjoittaneet jo käyttäjätarinoiden hyväksyntäkriteereistä, antaneet vinkkejä user storyjen laadun parantamiseen groomauksella ja esivalmistelulla, ja käyneet läpi sitä, miksi liian suurten tarinoiden splittaus on tärkeää. Rivien välistä voikin jo ehkä lukea, että yksi usein toistuva virhe käyttäjätarinoiden kanssa on, että ne ovat liian isoja.

Liian suuren käyttäjätarinan aloittamisen lisäksi on neljä muutakin vaarallista virhettä, mitä tiimi ja tuoteomistaja voi tehdä user storyjen kanssa. Tässä seuraavassa on lista viidestä vaarallisimmasta virheestä, joita kannattaa pyrkiä välttämään, mikäli tavoitteena on hyvä käyttäjätarina. Laitoin tämän listan tärkeysjärjestykseen, ja aloitetaan numerosta viisi, ja edetään sitten aina numeroon yksi saakka – kaikkein vaarallisempaan käyttäjätarinavirheeseen.

#5 Käyttäjätarinaksi hyväksytään asioita, joita ei koskaan kyetä toteuttamaan

Tämä johtaa siihen, että tuotteen backlogia käytetään ”wishlistina”.

Tämä virhe on kovin yleinen. Sen perussyy on se, että tuoteomistaja ei ole oikein sisäistänyt rooliaan, ja kirjaa backlogille kaikki pyynnöt, mitä tuotteeseen tulee. Tämä johtaa siihen, että tuotteen backlogia käytetään ”wishlistina”, eli kaikki ideat laitetaan backlogille.

Tuoteomistajan yleisin valhe – ”laitan sen backlogille”

Tämä virhe on vaarallinen, koska se antaa tiimin stakeholdereille signaalin, että heidän pyyntönsä on pipelinessa – se varmaankin valmistuu ihan tuota pikaa. Toisaalta, nyt backlogilla on pyyntö, joka kasvattaa backlogin pituutta. Aika nopeasti backlog kasvaa, vaikka tuhanteen tai kahteentuhanteen asiaan. Mitä tällaisesta seuraa?

Käyttäjätarinat pohjamudassa

Siitä seuraa kaksi asiaa – backlogin läpikäynti hidastuu, koska alkaa olla todella mahdotonta käydä läpi koko kahdentuhannen itemin backlogia. Priorisointi hämärtyy. Kun backlogin läpikäynti hidastuu, groomaus muuttuu tehottomammaksi. Tiimi saattaa unohtaa tärkeitä asioita ”pohjamutatarinoiden” sekaan. Ja tästä seuraa se toinen seuraus – tiimi alkaa arvostaa backlogia vähemmän.

Backlogin arvostus vähenee

Kun backlogia arvostetaan vähemmän, siihen liittyvät seremoniat, kuten backlog grooming tai sprint planning alkavat tuntua tyhmemmiltä, ja tiimi käyttää niihin vähemmän aikaa ja huomiota. Tämä rapauttaa nopeasti koko tiimin tuottavuutta.

Opi sanomaan EI

Tuoteomistajan olisikin syytä pitää huolta siitä, että hän osaa sanoa ”EI”. Tähän pitäisikin tehdä koulutus! Stay tuned – Contribyten ”Just say NO” -koulutus on tulossa!   Tuoteomistaja on gatekeeper-roolissa sen vahtimisessa, ettei backlogille kerry liikaa pohjamutatarinoita. Avainasia on, ettei automaattisesti aina hyväksytä kaikkea backlogille. Laita backlogille vain asiat, jotka aivan varmasti tarvitaan ja pystytään tekemään järjellisessä ajassa. Sano muille joko EI tai kysy lisää perusteluja.

#4 Käyttäjätarinaa, joka on menossa toteutukseen pian, ei ole groomattu

Käyttäjätarinan groomauksella tarkoitetaan yleensä sitä, että se on käyty läpi tiimin backlog grooming -kokouksessa. Tärkeintä tässä on, että tarinasta on keskusteltu jollain tavalla, ja ainakin avainhenkilöt ymmärtävät, miksi tarina tarvitaan ja mitä siinä on tarkoitus tehdä. Lisäksi on tärkeää ymmärtää jollain tasolla, miten iso tarina on ja onko siinä jotain vaikeaa tai riskaabelia. Näiden asioiden tuleminen esiin on helpointa juuri yhteisessä keskustelussa.

Jos user storyja aletaan tehdä ilman groomausta, nousee riskit sille, että tehdään vääriä asioita, väärällä määrittelyllä, vääristä syistä, väärässä prioriteettijärjestyksessä, ja kun asiat etenevät testaukseen, löytyy paljon bugeja. Groomaamattomien asioiden työmääräarvio saattaa olla myös pahasti pielessä, joka johtaa siihen, että tuoteomistaja tekee prioriteettipäätöksen väärällä ajatuksella toiminnon kustannuksesta.

#3 Käyttäjätarinalla, joka on menossa toteutukseen pian, on puutteellinen tai epäselvä kuvaus

User storyn kuvauksesta meillä onkin jo muita blogeja, mutta käydään tässä läpi vielä ihan perusteet. Hyvällä käyttäjätarinalla pitäisi olla

• selkeä otsikko,
• selkeä ja ytimekäs kuvaus, joka sisältää myös käyttäjän identifioinnin ja syyn, miksi tarina tehdään
• jollain lailla listattuina hyväksyntäkriteerejä, eli tietoa siitä mitä tarinassa tehdään ja mitä ei tehdä

Kuvausta voi viedä sitten vielä tarkemmalle tasolle oikein kysymysten muotoon puetuilla hyväksyntäkriteereillä, tehtävälistalla, jota tarinaan kuuluu ja niin edelleen. Mutta jos otsikko, kuvaus ja lista asioita, mitä tarina sisältää on tehty, asia on jo aika hyvällä mallilla, ja tämä virhe voidaan välttää.

Miksi käyttäjätarinan kuvaus on niin tärkeä? Se on tärkeä sen takia, että ilman kuvausta, kaikilla saattaa olla oma ajatus siitä, mitä user storyssa tehdään. Vaikka asiasta oltaisiin keskusteltu, ihmiset voivat muistaa asiat eri tavalla tai ymmärtää ne eri tavalla. Kaikki työmääräarviot ovat epäluotettavia ilman kirjallista kuvausta.

Jos ilman kuvausta oleva tarina aloitetaan, kehittäjillä on sitten täysi vapaus tehdä ihan mitä haluavat. Kehitys ottaa yleensä kuitenkin päiviä, jos ei viikkoja. Kukaan ei enää muista, mitä kaikkea tarinaan kuului tai ei kuulunut, jos mitään ei ole kirjoitettu. Jos kehittäjät törmäävät johonkin asiaan kehityksen kuluessa, heidän on helppo sisällyttää se ilman kysymyksiä tarinan scopeen. Näin todennäköisyys ”sugarcoatingille” nousee. Tuoteomistajalla ei enää ole kontrollia siihen, mitä käyttäjätarinassa tehdään ja mitä ei tehdä.

#2 Liian iso käyttäjätarina aletaan toteuttaa

Tästä puhuinkin jo käyttäjätarinoiden pilkkomista käsitelleessä blogissani. Liian suuren user storyn tuomat uhat ovat seuraavat

• Isoa käyttäjätarinaa on hankalampi kuvata, ja vaikka yritettäisi kuvata hyväksyntäkriteerejä, kuvaamiseen, on todella vaikea kuvata edes niitä täydellisesti, koska tarinan määrittely on niin suuri.
• Isolla tarinalla käy todennäköisesti niin, että sitä ei toteuteta tarpeeksi pienissä iteraatioissa. Kehittäjät hautovat tarinaa viikkokausia, ellei kuukausikaupalla, ja vasta sitten se etenee testaukseen. Testaajat ovat sitten aivan äimän käkenä, kun testattavaksi pöllähtää massiivinen toimintokasa, joka ei pahimmassa tapauksessa edes toimi heidän ympäristössään. Bugeja löytyy taatusti paljon enemmän, kuin jos toiminto olisi toteutettu pienemmissä palasissa.
• Isojen user storyjen työmääräarviot ovat lähes arvottomia. Ne voivat pitää paikkansa, tai sitten (mikä on paljon todennäköisempää) työmääräarviot heittävät dekaadilla. ROI-toiminnon kehittämisestä voi mennä ihan pieleen.
• Isot tarinat sitovat tiimin pitkäksi aikaa tekemään jotain, ja heikentävät tiimin reagointivalmiutta muihin kiireellisiin ongelmiin.

Liian suuret käyttäjätarinat olisivatkin vaarallisin virhe, mitä käyttäjätarinoiden kanssa voi tehdä, ellei olisi vielä yhtä viimeistä ja kaikkein vaarallisinta virhettä, joka vesittää hyvän käyttäjätarinan.

#1 Tarinoiden epävarmuustekijöitä ei ole esitestattu

On monia asioita, mitä kannattaisi selvittää ennen kuin käyttäjätarina otetaan työn alle.

Käyttäjätarinoilla voi olla monenlaisia epävarmoja asioita. Toisilla tarinoilla toteutusteknologia, tai designvaihtoehdot ovat epävarmoja, toisilla epävarmuus voi löytyä käytettävyydestä tai käyttäjäkokemuksesta. Toisissa se saattaa olla asiakkaan ongelman väärinymmärrys, tai tarve koko toiminnolle. Tutkimusten ja myös oman kokemukseni mukaan, tuotekehitysorganisaatiot ja tiimit käyttävät aivan liian vähän energiaa ja aikaa näiden asioiden tutkimiseen ennen kuin asioita otetaan lopullisen toteutuksen alle.

Onkin monia eri asioita, mitä kannattaisi selvittää ennen kuin varsinainen käyttäjätarina otetaan työn alle. Tämä virhe on ykkösenä listalla, koska tässä saatetaan mennä kaikkein rankimmin metsään. Väärät teknologiavalinnat tai väärinymmärretty asiakasongelma tai -tarve voivat pahimmassa tapauksessa vetää kuukausien tai vuosien työn pöntöstä alas, ja vaikuttaa jopa joidenkin henkilöiden urakehitykseen.

Asiakastarve

Kuten kollegani Harri aina sanoo, suurinta hukkaa on tehdä jotain, mitä kukaan ei tarvitse. Tuotekehityksen historia on kuitenkin täynnä tarinoita (pun intended) tuotteista, jotka kehitettiin mutta sitten kun ne vietiin markkinoille, ei asiakkaat kuitenkaan ostaneet niitä. Tämä on aivan samoin myös käyttäjätarinatasolla. On aivan varma, että sinunkin backlogillasi on juuri nyt tarinoita, joita ei oikeasti tarvita.

Tarpeen arviointiin on monia keinoja, ja tuoteomistajan ja muun tuotehallintaorganisaation pitäisi sopia, kenen vastuulle se kuuluu. Joskus se kuuluu tuotepäällikölle, joskus tuoteomistajalle. On hyvä pitää tuotekehitystiimiä tai avainroolissa olevia kehittäjiä mukana tässä arvioinnissa tai tietoisena sen tuloksista. Perusasia on kuitenkin se, että tarpeen arviointia pitäisi tehdä useammin, erityisesti silloin kun siinä arvioidaan olevan suurta epävarmuutta. Ethän sinä halua tehdä vaikka 2 kuukautta töitä jonkin toiminnon kehittämisessä, ja sitten kun demoat sitä käyttäjille, selviää että he eivät voikaan käyttää sitä, vaan tarve oli jossain muualla?

Design

Useimmilla asioilla on monia eri toteutusvaihtoehtoja. Mikä näistä on paras? Kannattaako toteutusvaihtoehtoja tutkia ennen tarinan varsinaista aloitusta? Vai sen aikana? Joskus ensimmäinen vaihtoehto voi olla hyvä, koska se voi vaikuttaa tarinan toteutuksen työmääräarvioon huomattavasti. Ehkä tämän suhteen voisi olla ohjenuorana juuri tämä – jos toteutusvaihtoehtoja on useita, mutta ne ovet työmäärältään samankokoisia ja teknisten riskien suhteen samanarvoisia, vaihtoehtojen arviointi voidaan tehdä tarinan toteutuksen alkuvaiheessa. Muussa tapauksessa kannattaisi tehdä SPIKE ennen kuin tarina päätetään aloittaa.

Teknologia

Jos toteutukseen tarvitaan jotain uutta teknologiaa, jota tiimi ei ole aikaisemmin käyttänyt, on erityisen tärkeää tehdä jonkinlainen tutkimus asiasta erillisellä backlog-tiketillä, ennen kuin varsinainen toiminnon käyttäjätarina otetaan työn alle. Näin kehittäjillä on aikaa oppia teknologiasta ennen kuin heillä on paine alkaa tuottaa tuotantokoodia. Myös riski siitä, että on valittu sopimaton teknologia, pienenee.

Käytettävyys

Käyttöliittymäsuunnittelu on myös asia, joka voitaisiin osittain tehdä jo ennen kuin käyttäjätarina otetaan työn alle. Erilaisia prototyyppejä käyttäen voidaan päästä jo todella lähelle lopullista käyttöliittymää, koska iteraatioiden tekeminen on nopeaa, ja päästään näyttämään toimintoa käyttäjille, ja seuraamaan osaavatko he käyttää sitä ja tuleeko jotain uusia ideoita. Kun prototyypeillä on iteroitu käyttöliittymä kohdalleen, insinööri voi tyytyväisin ja turvallisin mielin alkaa toteuttaa lopullista toteutusta.

Suomen parhaat käyttäjätarinakonsultit löydät Contribyteltä

Me tiedämme, millainen on hyvä käyttäjätarina, ja hiomme teidän käyttäjätarinataidot 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!