Kun teemme assessmenttia jollekin tiimille, yksi ensimmäisistä asioista, joihin kiinnitämme huomiota, on backlog itemien laatu. Backlog itemithän tyypillisesti koostuvat lähinnä bugeista ja käyttäjätarinoista. Näihin molempiin liittyy sama perussääntö: jos bugin tai tarinan kuvaus on puutteellinen, on tiimin hyvin hankala tuottaa laadukasta fiksiä tai toteutusta. Bugeista olen kirjoittanut aiemmin kokonaisen bugiblogisarjan. Katsotaankin tässä blogissa lähemmin, miksi ja miten käyttäjätarinoiden kuvaukset saataisiin paremmalle mallille.

Pelkkä otsikko ei riitä

Ongelma on se, että sinun selkeä on eri kuin kaverin selkeä.

Aivan liian usein näkee käyttäjätarinoita, joissa on pelkkä otsikko. Miksi näin on? Minun mielestäni siihen on yksi selvä syy – kaikki ovat sitä mieltä, että vain otsikko riittää – sehän on ihan selkeä juttu! Homman ongelma onkin se, että sinun selkeä onkin eri kuin kaverin selkeä. En usko, että olette ajatustenlukijoita! Kun mitään ei ole kirjoitettu kuvaukseen, saman otsikon voi ymmärtää eri tavalla. Käyttäjätarinalla onkin oltava selkeän otsikon lisäksi aina jonkinlainen kuvaus.

Käyttäjätarinan kuvaus

Käyttäjätarinan perinteinen kuvaus on muotoa:

As a [user role]

I want [desired functionality]

so that [reason why the user wants the functionality]

Tätä formaattia, mitä joskus myös sen popularisoijan mukaan Cohn-formaatiksi kutsutaan, kannattaa pyrkiä käyttämään aina, kun backlog itemille on selkeästi löydettävissä käyttäjärooli. Useimmiten käyttäjä pystytään löytämään, mutta ei ehkä ihan aina. Joskus tiimit, jotka tekevät enemmän platform, backend tai infra-tyyppistä työtä, eivät ihan helposti voi johtaa kaikkea vaadittua työtä käyttäjiin. Ei siitä kannata masentua. Käyttäkää käyttäjätarinaformaattia silloin kun se sopii. Muulloin kannattaa kuitenkin kirjoittaa backlog item kuvaus auki jollain muulla tavalla. Ja muistakaa – se ”miksi” – se syy miksi tarina tehdään ja mitä sillä tavoitellaan – sen voi kirjoittaa tarinan kuvaukseen, vaikka käyttäjää ei olisikaan niin helppo tunnistaa.

Miksi käyttäjätarinan kuvaus tarvitaan?

Tarinalle tarvitaan kuvaus sen takia, että tarinan pyytäjä ja sen toteuttaja saisivat yhteisymmärryksen siitä mitä tehdään. Jos mitään kuvausta ei ole, vaan tarinaa pyytänyt (usein Product Owner, joka toimii välikätenä markkinatarpeen kuvauksessa) odottaa jotain, ja kehittäjällä puolestaan on omia ajatuksia siitä, mitä tämän nimenomaisen tarinan suhteen olisi kiva tai tarpeellista tehdä. Jos kuvaus kirjoitetaan, siitä on paljon vaikeampi olla eriäviä mielipiteitä mitä se tarkoittaa!

Otsikko + kuvaus on jo tuhat kertaa parempi tilanne, kuin pelkkä otsikko. Vielä ei kannata kuitenkaan pysähtyä tähän: kannattaa vielä jatkaa muutama minuutti, ja lisätä kuvauksen alle hyväksyntäkriteerejä.

Esimerkkikäyttäjätarina

Esimerkiksi voisimme kirjoittaa käyttäjätarinan, jossa tehdään uuden käyttäjän rekisteröitymissivu, jossa pitää antaa salasana. Teemme käyttäjätarinan, jossa on uuden salasanan syöttödialogi.

As a user

I want to enter a new password

so that I can use the system

Tämä käyttäjätarina ei vielä kerro kovinkaan paljon toteutettavasta dialogista. Haluamme nimittäin, että salasana on vahva. Käyttäjätarinaan ei käytännössä pysty laittamaan kaikkia niitä tarkennuksia, mitä dialogilta tarvitaan, että se toimii sekä turvallisesti että käyttäjän kannalta sulavasti. Tarvitaan siis vielä lisätarkennuksia.

Mitä käyttäjätarinan hyväksyntäkriteerit ovat?

Käyttäjätarinan hyväksyntäkriteerit tarkentavat kuvausta. Usein käy niin, että käyttäjätarina kuvataan joko yllä mainitulla perinteisellä Cohn-formaatilla, tai sitten muutamalla lauseella, jossa kuvataan tarvittava toiminto ja toivottavasti myös syy sille miksi se tarvitaan. Mutta tämä on vielä aika yleisellä tasolla oleva kuvaus.

Hyväksyntäkriteereillä on tarkoitus helposti tarkentaa kuvausta lisää. Jos vaikkapa käyttäjätarina on tehdä

• Tunnussana on minimissään 8 merkkiä pitkä
• Tunnussana pitää syöttää kaksi kertaa
• Molempien tunnussanakenttien pitää sisältää samat tunnussanat, ennenkuin rekisteröityminen on mahdollista
• Tunnussanaa ei hyväksytä, ellei se ole vahva
• Käyttäjälle näytetään indikaattori, jos salasana ei ole tarpeeksi vahva
• Vahvuusindikaattori muuttuu jokaisen käyttäjän syöttämän merkin jälkeen
• Jos salasana ei ole tarpeeksi vahva, kerrotaan käyttäjälle syy(t) miksi se ei ole tarpeeksi vahva.
• Käyttäjä voi painaa ”rekisteröi” nappia vasta kun kaikki kentät on täytetty. Ennen tätä nappi on näkyvissä mutta se ei salli käyttäjän tehdä rekisteröitymistä.
• Pakolliset kentät on selkeästi merkitty.
• Puuttuvat pakolliset kentät korostetaan käyttäjälle, jos hän yrittää painaa ”rekisteröi” nappia ilman että ne on täytetty
• Vahva tunnussana sisältää sekä isoja että pieniä kirjaimia, vähintään yhden erikoismerkin ja vähintään yhden numeron.
• Erikoismerkkien lista

Pysähdypä miettimään – jos käyttäjätarinan hyväksyntäkriteerit eivät ole kirjattuna, ja pyydät kehittäjiä tekemään rekisteröintitietojen syöttönäytön – mitä näistä he tekevät? Jos he sanovat, että näytön tekemiseen menee vain tunti, kuuluuko tähän tuntiin kaikki yllä oleva?

Kun kaikki nämä käyttäjätarinan hyväksyntäkriteerit on nyt listattu, voidaankin alkaa miettimään, kuinka kauan näiden tekeminen kestää, ja tarvitaanko kaikki nämä nyt heti? Onko riittävästi, jos vain osa hyväksyntäkriteereistä toimitetaan tällä viikolla, ja loput vaikka pilkotaan uudeksi tarinaksi. Kirjoitetuilla kriteereillä pilkkominen on helppoa.

Miksi käyttäjätarinan hyväksyntäkriteerit ovat tärkeitä?

Hyväksyntäkriteerit ovat tärkeitä, jotta kehittäjät ja tuoteomistaja saisivat yhteisymmärryksen tarvittavasta tarinasta.

Hyväksyntäkriteerit ovat tärkeitä juuri siksi, että kehittäjät ja tuoteomistaja saisivat yhteisymmärryksen siitä, millainen tarina nyt juuri tarvitaan, ja paljonko sen tekeminen kestää. Ylläolevan esimerkin mukaisen näytön (ja kaikkien tarpeellisten syötteiden tarkistamisien logiikan) tekeminen varoitusikoneineen saattaa kestääkin vaikka päivän tai kaksi eikä sitä tuntia mikä pelkän otsikon tai kuvauksen perusteella joku saattaisi heittää.

Hyväksyntäkriteerit tarkentavat kuvausta

Hyväksyntäkriteereillä on tarkoitus siis tarkentaa sitä mitä tullaan tekemään, ja paljonko se ottaa aikaa. Nyt tuoteomistajan on mahdollista priorisoida paremmin, kun hän tietää tarkemmin, että ahaa, se on parin päivän homma eikä tunnin homma. Tai – tarvitaanko kaikkea ylläolevaa? Entä jos jätetään pois jotain listattuja hienouksia?

Kriteerien avulla työmääräarvio ja velocity tarkentuu

Kun käyttäjätarinan hyväksyntäkriteerit on kirjoitettu, työmääräarvio on paljon tarkempi kuin ilman niitä. Ja tämä johtaa taas siihen, että tiimin velocity on paljon tarkempi, joka johtaa taas siihen, että tiimi pystyy paremmalla laadulla ja ennustettavuudella ja vähemmällä stressillä toimittamaan pyydettyjä toiminnallisuuksia.

Hyväksyntäkriteerit groomauksessa tai nakkina

Parasta olisi, jos käyttäjätarinan hyväksyntäkriteerit voidaan kirjoittaa yhteisesti backlog grooming -sessiossa. Tämä ottaa tietenkin jonkin verran aikaa, ja groomauksen tunnin aikana ei saada niin montaa backlog itemia sitten käytyä läpi. Kun tiimi harjaantuu kriteerien kirjoittamiseen, se kyllä käy nopeammin. Jos haluatte, voidaan toimia myös niin, että tuoteomistaja nakittaa alustavien hyväksyntäkriteerien kirjoittamisen jollekin muulle henkilölle. Voihan tuoteomistaja itsekin kirjoittaa kriteerejä, mutta oma kokemukseni on, että se menee sitten helposti siihen, että tuoteomistajan kirjoittamat kriteerit otetaan kysymättä vastaan ”tyhjentävänä listana” eikä mietitä, että puuttuuko niistä jotain. Parempi olisi, jos PO voi nakittaa kriteerien keksimisen tiimin jäsenille, tai sitten että se tehdään yhteisesti groomingissa.

Nakittamisessa on sekin hyvä puoli, että kehittäjä voi ajatella myös tarinan splittausta ja mahdolilsesti taskitystä jo etukäteen.

Käyttäjätarinan hyväksyntäkriteerit helposti

Nyt sitten se vinkki, jonka lupasin blogin aluksi. Miten tiimi, joka ei ole tottunut kirjoittamaan hyväksyntäkriteerejä, voisi aloittaa niiden tekemisen rutiinin? Tähän minulla on seuraava vinkki:

1. Ottakaa tarina auki – niin että kaikki näkevät sen kuvauksen tv:stä tai projektoriscreeniltä
2. Keskustelkaa siitä, mitä tarina ja sen kuvaus tarkoittavat
3. Sihteeri (usein scrum master) kirjoittaa keskustelussa esiin tulevat pointit heti ylös ranskalaisin viivoin (ja jälleen niin että kaikki näkevät)
4. Keskustelua jatketaan muutama minuutti, kunnes se tuntuu tyrehtyvän
5. Katsotaan bullet pointeja – onko tämä se mitä me haluamme?

Kirjoita keskustelu kaikkien nähden

Tämän metodin pointti on se, että keskustelusta on helppo napata bullet pointit ja kirjoittaa ne ylös – ja kun tämä tehdään kaikkien nähden, ihmisten on helpompi reagoida kirjoitettuun. Jos vain keskustellaan, eikä kirjoiteta mitään ylös, ihmiset eivät välttämättä viitsi osoittaa eriävää mielipidettä johonkin asiaan tai hyväksyntäkriteeriin. Mutta kun se on kirjoitettu, nousee paine sanoa jotain jokaisen mielessä (”oh my god, nekö oikeasti aikoo kirjoittaa tuon hyväksyntäkriteeriksi, vaikka se on niin huono idea”). Kirjoitettu sana on vaan niin paljon voimakkaampaa.

Metodi sopii tiimeille, joilla ei ole aikaisempaa kokemusta hyväksyntäkriteerien käytöstä

Se, mikä tässä metodissa on vaikeampaa, on tehdä kriteereistä ”täydellisiä” – kirjoittaa ne viralliseen kysymyksen muotoon. Mutta tämä on vaan todella nopea keino, ja sen takia suosittelen tätä tiimeille, joilla ei ole mitään kokemusta tai rutiinia hyväksyntäkriteerien käyttämisestä. Usein tällaisissa tiimeissä myös backlogilla on valtavasti parannettavaa, ja olisi tärkeää käydä paljon backlog itemeita läpi ja tarkentaa niitä edes hiukan, eikä tehdä vähän ja täydellistä.

Ota ensin askel siihen suuntaan, että tiimi oppii aina kirjoittamaan kriteerit!

Rutinoi tiimi ensin hyväksyntäkriteerien käyttöön – ja lähde sitten parantamaan itse kriteereitä

Sitten, kun tiimi on rutinoitunut siihen, että kaikista työn alle olevista tarinoista löytyy aina otsikon ja kuvauksen lisäksi myös nämä bullet point tarkennukset, on aika lähteä parantamaan näitä bullet pointeja, ja tehdä niistä parempia hyväksyntäkriteerejä. Mutta ota ensin askel siihen suuntaan, että tiimi oppii aina kirjoittamaan kriteerit!

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

Hiomme teidän hyväksyntäkriteerien tekemisen 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!