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ä.
Mitä ovat käyttäjätarinat Agile:ssä?
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ä.
Miten ketterät käyttäjätarinat rakentuvat?
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)
Vain lisäarvo osoittaa, miksi toiminto on käyttäjälle tärkeä. MIKSI voit siis rehellisesti pohtia, kuinka hyvin tunnet asiakkaan vaatimukset. Koska: Vaatimus on helppo sisällyttää käyttäjätarinaan esimerkiksi siksi, että asiakas ilmaisee haluavansa sitä. Mutta vasta kun ymmärrät, miksi asiakas tarvitsee sitä, sinulla on konteksti vaatimuksen toteuttamiseen. Vasta silloin voit kyseenalaistaa, tyydyttääkö asiakkaan ehdotus/pyyntö tehokkaasti hänen todellisen tarpeensa – vai olisiko olemassa jokin fiksumpi tapa. Tarkastellaanpa 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 sadeviittaa. Voit myös toimittaa polkupyörän, jossa on integroitu katto. Tärkeintä on, että se ratkaisee asiakkaan tarpeen tai ongelman – olla kastumatta. Mitä paremmin ymmärrät "miksi", sitä paremmin voit suunnitella käyttäjätarinan.
Useimmat Agile-valmentajat kulkevat ympyrää.....
...ja hoitaa pinnallisia oireita. On aika käyttää psykologiaa – kestävään ajattelutavan muutokseen.
"Miksi minulta kestää joskus tunteja valmistella yksinkertainen retrospektiivi?"
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.
Mitä ovat käyttäjätarinat Scrumissa?
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.
Käyttäjätarinoiden kirjoittaminen – Miten luon kiinnostavia käyttäjätarinoita?
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 olla kiveen hakattua sen jälkeen. Se tarkoittaa: Tuotteen omistajaSidosryhmien 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ä.
Miten käyttäjätarinoita hyödynnetään Agile: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.
Päätelmä
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).
