Käyttäjätarinat Scrumissa: kaikki mitä sinun tarvitsee tietää

Tavoite on selvä: haluat kehittää tuotteen, joka tuottaa asiakkaille suurta lisäarvoa. Haluat saavuttaa tuloksen, johon tiimin jäsenet ja sidosryhmät ovat tyytyväisiä. Mutta miten saavutat tämän tavoitteen? Miten voit täyttää kaikki tuotteelle asetetut vaatimukset pienissä, perusteellisissa vaiheissa? 

Agile:ssä käyttäjätarinat ovat osoittautuneet tehokkaaksi työkaluksi tähän. Ne vievät sinut askel askeleelta ensimmäisestä ideasta myyntivalmiiksi tuotteeksi. Näytän sinulle, mitä käyttäjätarinat ovat, miten niitä luodaan ja miten voit hyötyä niistä.

Käyttäjätarinoiden määritelmä Agile:ssä kuvaa tuotteen vaatimuksia käyttäjän näkökulmasta. Toisin sanoen käyttäjätarinat kertovat, mitä ominaisuuksia ja toimintoja tuotteessa pitäisi olla. Tämä tekee niistä keskeisen työkalun, jonka avulla voidaan keskustella käyttäjien tarpeista, validoida ne ja työskennellä niiden toteuttamiseksi yhteisymmärryksessä. 

Käyttäjätarinat ovat universaali kieli, jota tiimin jäsenet, sidosryhmät ja asiakkaat ymmärtävät ja puhuvat. Käytännössä tämä tarkoittaa sitä, että käyttäjätarinoiden avulla voit kehittää asiakkaan haluamasta tuotteesta sellaisen ymmärryksen, joka jättää vain vähän tilaa väärinkäsityksille. 

Useat käyttäjätarinat muodostavat yhdessä käyttötapauksen. Käyttäjätarinat ovat peräisin Agile-ohjelmistokehityksestä.

Käyttäjätarinoissa kuvataan asiakkaan tai käyttäjän näkökulmasta vaatimukset ja toiveet projektin tuloksen luomiseksi. Ketterillä käyttäjätarinoilla on tämä perusrakenne:

WHO (rooli), haluaa MITÄ (tavoite/toive) MIKSI (lisäarvo)?

Tutustutaanpa tarkemmin käyttäjätarinoiden yksittäisiin osiin:

WHO (KÄYTTÄJÄ)

Täytä WER-paikkamerkki asiakkaallasi tai kohderyhmäsi tyypillisellä edustajalla. Se, kuinka yksityiskohtaisesti kuvaat WHO:n Käyttäjätarinassa Agile riippuu itse Käyttäjätarinasta ja projektin etenemisestä. Ole siis riittävän yksityiskohtainen, jotta voit luoda mielekkään käyttäjätarinan.

WHAT (FUNKTIO)

Tähän sijoitetaan käyttäjän toiveet. Voit kysyä itseltäsi, mitä käyttäjä odottaa tai tarvitsee. Jos tuotteesi on vielä varhaisessa kehitysvaiheessa, voit muotoilla kokemuksesi perusteella oletuksia siitä, mitä toimintoja käyttäjä odottaa. Jos sinulla on jo samankaltainen tuote markkinoilla, voit myös johtaa halutut toiminnot kyseisestä tuotteesta saadusta palautteesta.

MIKSI (LISÄARVO)

Vasta lisäarvo osoittaa, miksi toiminto on käyttäjälle tärkeä. MIHIN-kysymys mahdollistaa siksi rehellisen pohdinnan siitä, kuinka hyvin tunnet asiakkaan vaatimukset. Sillä: Vaatimuksen sisällyttäminen käyttäjätarinaan on helppoa – esimerkiksi siksi, että asiakas esittää toiveen. Mutta vasta kun ymmärrät, miksi asiakas tarvitsee sitä, sinulla on konteksti vaatimuksen toteuttamiseen. Vasta sitten voit kyseenalaistaa, tyydyttääkö asiakkaan ehdotus/toive hänen todellisen tarpeensa tehokkaasti – vai onko olemassa älykkäämpi tapa. Katsotaanpa esimerkkiä: 

Asiakas haluaa sadeviitan pyöräilyä varten. Voit siis nyt lisätä vaatimuksen “sadeviitta”. Tai voisit kysyä asiakkaalta, miksi hän tarvitsee sadeviittaa. Oletetaan, että asiakas vastaa: “Koska en halua kastua”. 

Tämä tarkoittaa, että sinun ei välttämättä tarvitse toimittaa sadetakkia. Voisit myös toimittaa polkupyörän, jossa on integroitu katto. Ratkaisevaa on, että asiakkaan tarve tai ongelma ratkaistaan sillä – nimittäin se, ettei kastuisi. Mitä paremmin ymmärrät “miksi”-kysymyksen, sitä paremmin voit suunnitella käyttäjätarinasi.

Mitä ovat käyttäjätarinat Agile:ssä (esimerkki)?

Tunnet nyt Agile-käyttäjätarinoiden yksittäiset osat. Esimerkki Agile-käyttäjätarinasta voi näyttää seuraavalta: 

Kuten ASIAKAS Haluaisin TURVALLINEN SALASANA***,*** JOTTA ASIAKASTIETONI OVAT SUOJATTUJA.

Tässä on “ASIAKAS” käyttäjä, “TURVALLINEN SALASANA” toiminto ja “JOTTA ASIAKASTIETONI OVAT SUOJATTUJA” lisäarvo. 

Kun työskentelet Scrumissa käyttäjätarinoiden kanssa, lisäät niihin hyväksymiskriteerit. Hyväksymiskriteereissä kuvataan tekniset vaatimukset, jotka käyttäjätarinoiden on täytettävä hyväksymishetkellä. Toisin sanoen: Hyväksymiskriteerit ovat vaatimuksia, joita tarvitset, jotta käyttäjätarina voi luoda arvoa.

Agile-käyttäjätarinoiden merkitys backlogissa voi olla eriytyneempi. Koska: Backlogeissa käyttäjätarinat voivat paitsi kuvata vaatimuksia myös edustaa erityistä hierarkiatyyppiä. Näitä hierarkiatyyppejä on 3:

Eepokset: Eepokset ovat tuotteen laajasti määriteltyjä toiminnallisia alueita, joiden konkreettinen laajuus voi olla vielä epäselvä.

Ominaisuudet: Ominaisuudet ovat eepoksen erityisiä suorituskykyominaisuuksia.

Tarinat: Tarinat ovat teknisiä Agile-käyttäjätarinoita ja ominaisuuden sisällä olevia käyttäjätarinoita.

Voit toteuttaa nämä hierarkiatyypit sprintin sisällä. Ne luovat konkreettista hyötyä käyttäjälle. 

Jotta ketterässä projektinhallinnassa voidaan kirjoittaa hyödyllisiä käyttäjätarinoita, yksityiskohtaiset keskustelut kaikkien sidosryhmien kanssa ovat ratkaisevan tärkeitä. Näiden pitäisi antaa kattava käsitys kohderyhmästä ja luotavasta tuotteesta. Tästä voit sitten johtaa esimerkiksi persoonat. 

Lisäksi ns. INVEST-kriteeritluoda vakuuttava käyttäjätarina:

Itsenäinen: Käyttäjätarinan tulisi olla riippumaton muista käyttäjätarinoista. Tämä tarkoittaa sitä, että tarinan toteuttaminen ei saa edellyttää, että jokin toinen tarina on toteutettu sitä ennen. Tästä on se etu, että käyttäjätarinoita voidaan priorisoida tai poistaa backlogista milloin tahansa. 

Tarkastellaan vielä kerran polkupyöräesimerkkiä. Oletetaan, että olet päättänyt asentaa sadeviitan sijasta pienen katon polkupyörän satulan päälle, jotta asiakas ei enää kastuisi. Se olisi siis käyttäjätarina. Mutta nyt huomaat, että sinun on ensin kehitettävä vakaampi satula, johon katto voidaan kiinnittää. Se olisi eri käyttäjätarina. Molemmat tarinat rakentuvat toistensa päälle. Juuri tätä sinun pitäisi estää.

Joskus on tietenkin väistämätöntä, että yksi käyttäjätarina on tehtävä ennen toista. Yleissääntönä on kuitenkin, että vältä sellaisia käyttäjätarinoita, joita varten sinun on ensin toteutettava 20 muuta käyttäjätarinaa.

Neuvottelukelpoinen: Käyttäjätarinoiden kirjoittaminen voi joskus kestää melko kauan – mutta sen ei pitäisi sen jälkeen olla kiveen hakattu. Tämä tarkoittaa: Tuotteen omistaja Sidosryhmien ja kehittäjien tulisi aina keskustella käyttäjätarinasta ja tarkentaa sitä yhdessä. 

Arvokas: Ketterän projektinhallinnan käyttäjätarinoiden tuloksena on oltava lisäarvoa asiakkaalle.

Arvioitavissa: Vakuuttava käyttäjätarina antaa kehitystiimille mahdollisuuden arvioida, kuinka paljon työtä sen toteuttaminen vaatii.

Pieni: Käyttäjätarinan tulisi olla niin “pieni”, että se voidaan toteuttaa yhdessä sprintissä.

Testattavissa: Scrumissa käyttäjätarinoiden pitäisi olla testattavissa. Tämä on ainoa tapa tarkistaa, voidaanko ne todella toteuttaa käytännössä.

Jos käyttäjätarinoiden kirjoittaminen Agile:ssä ei ole sinulle tuttua, ne saattavat tuntua ylimääräiseltä työltä. Käyttäjätarinat tarjoavat kuitenkin tiimeille tärkeän kontekstin heidän tehtävilleen, mikä selventää kunkin tehtävän tärkeyttä entisestään.

Käytännössä näin voit hyötyä käyttäjätarinoista:

Käyttäjäkeskeisyys: Käyttäjätarinat ovat kuin ongelmakeskeinen tehtävälista. Tiimisi voi käyttää niitä tehtäviensä seurantaan ja tietää tarkalleen, miten käyttäjien tarpeet täytetään.

Kokonaisvaltainen yhteistyö: Käyttäjätarinat näyttävät kaikille osapuolille yhdellä silmäyksellä, missä mennään. Näin kaikki voivat vetää yhteen ja päättää yhä uudelleen, miten käyttäjä saa erityisen paljon lisäarvoa. 

Luovat ratkaisut: Käyttäjätarinoiden luominen Agile-ohjelmistokehityksessä luovia tuloksia . Koska: Ne saavat tiimit miettimään kriittisesti, mikä on paras ratkaisu lopputuotteen kannalta.

Johdonmukaiset onnistumiset: Jokainen käyttäjätarina on pieni haaste. Siksi tiimit voivat juhlia pientä onnistumista jokaisen tarinan jälkeen. Tämä motivoi koko kehitysprosessin ajan.

Käyttäjätarinat ovat tärkeä työkalu ketterien tiimien työssä. Niistä näet yhä uudelleen ja uudelleen yksityiskohtaisesti, kenelle kehität mitä ja miksi. Tämä auttaa paitsi luomaan laadukkaan, kohderyhmälle räätälöidyn tuotteen myös pitämään tiimin motivoituneena koko prosessin ajan. 

Jotta voisit menestyä tällä ketterän työskentelyn makrotasolla, koko organisaatiosi on ajateltava ja toimittava ketterästi. Jotta voisimme tukea sinua ja organisaatiotasi tässä, olemme tehneet yhteistyötä tunnettujen asiantuntijoiden kanssa luodaksemme seuraavan kokonaisuuden Scagile-projekti suunniteltu. Tämä näyttää sinulle useissa webinaareissa, miten ketterää muutosta lähestytään oikein. Koulutus on maksuton. Käy rohkeasti katsomassa!

Jos haluat monipuolisempia kysymyksiä retrospektiivejäsi varten, tutustu postaukseemme osoitteesta 32 tuoretta retrospektiivistä menetelmää aloittelijoille ja ammattilaisille (muun muassa Mario Kart Retro, Marathon Retro ja Elon Musk Retro).

Yksi parhaista tavoista kehittää tiimin jäsenten ketterää ajattelutapaa kestävästi on muuten ketterän kuntotarkastuksen käyttöönotto. Meidän ilmainen Team-Health Check-rakennussarja voi auttaa sinua esittämään oikeat kysymykset – klikkaa itsesi läpi.