Käyttäjätarinat (User Story)

Kirjoittanut: Ildikó Makra, N4689

Mikä tarina

Palvelun eri käyttäjien näkökulmasta minämuodossa kerrottu vaatimusmäärittely. Käyttäjätarinoita ovat käytännössä palvelun tai ohjelmiston ominaisuudet, muodostettuna tietyllä tavalla. Tarinoita tulee kirjoittaa ensin kehitysjonoon (backlog) josta josta niitä on nostettava eri sprinttien Kanban-taululle kehityksen aikataulun puitteissa. Nämä tarinat ovat enemmänkin lauseitä, jotka kertovat tasan kolmesta asiasta:

KUKA haluaa?
MITÄ tehdä?
MIKSI haluaa sitä?

Suomen kielellä muodostetään näin:

{ Minä tietyssä roolissa } toivoisin, että { joku palveluidea toteutuisi }, jotta { kuvaus miten tästä pääsen hyötymään }.

Ja englanninkielellä näin:

As a { user role/customer }, I want to { goal to be accomplished } so that I can { reason of the goal }.

Esimerkkejä

” Vanhempana toivoisin, että koulu-ilmoittautuminen ja matkakorttioikeus tulisi automaattisesti, jotta minun ei tarvitsisi muistaa tehdä ilmoittautumisia ja hakemuksia.” (Lähde: mydatafi.wordpress.com/kayttajatarinoita)

Lisää suomenkielisiä esimerkkejä löytyy täältä.

Sisältö

Scrum -tyyppisissä ja muissa kettärissä tuotekehitysprojekteissä yleensä tuotteenomistajan tehtävänä on miettiä ja kirjoittaa käyttäjätarinoita. Tarinoita kannatta täydentää myös hyväksyntäkriteereillä johon hyvä ottaa mukaan joku kokenut ohjelmistotestaajaa.

Muutama huomioon otettavaa tarinoiden luontivaiheessa

Käyttäjätarinan ja pelkkä omimaisuuskuvauksen tärkein ero on perusteluosassa, eli korostettuna on se, mikä tulee "jotta" sanan jälkeen, eli MIKSI käyttäjä haluaa tätä ominaisuutta, minkälaista hyötyjä siitä toivoo. On hyvin tärkeä ymmärtää, miten käyttäjämme aikoo hyötyä kuvatusta ominaisuudestä, koska saatta olla, että kokenneelle kehittäjälle / testaajalle / tuotteenomistajalle tulee mieleen jopa parempi tai käevämpi toteutusidea, kuin kyseisen tarinan kakkososassa on kuvailtu. Kun epäily herää, olettamuksien sijaan on otettava yhteyttä pikaisesti loppukäyttäjän edustajaan. Suunnitteluvaiheessa toinen arvioitava seikka on tarinan kakkososa, josta löytyy ominaisuuskuvaus eli se, MITÄ on tehtävä. Jos vaan on mahdollista, olisi hyvä pilkoa sitä vielä pienempiin osiin. Jos ominaisuutta kuvailtiin liian yleisesti sitä seuraa monenlaisia ongelmia toteutusvaiheessa. Lue aiheesta lisää Aarto Kiiskisen blogikirjoituksessa jossa se kertoo omia kokemuksia siitä, miten ns. "mammuttitarinat" tukehduttivat kehitysprosessejä. Alla olevassa kuvassa näkyy, miten käyttäjätarinoita sijoitetaan sprinteille. Hyväksyntäkriteerit kannatta tarkentaa ja lisätä suunnitteluvaiheessa, koska niiden avulla päästään vielä lähemmäs loppukäyttäjän odotuksiin ja vältytään tilanteesta jossa asiakas ei kuitenkaan saa sitä mitä tilaa. Image: Epic vs User Story Kuvan lähde: softwaretestinghelp.com Arto Kiiskinen ja Antti Suvanto Contribyte:stä (joka on nykyään osana Eficode) ovat pitäneet webinaarin 20.10.2020 käyttäjätarinoista ja erityisesti hyväksyntäkriteerien lisäyksen merkityksestä. Webinaari on katsottavissa YouTubessa:

Webinaari: Käyttäjätarinat kuntoon – parhaat käytännön vinkit

Tarinoiden kohtalo projektin aikana

Kaikki kerätyt tarinat kirjataan Kanban-taulun Backlog-puolelle ensin, josta nostetaan tietylle Sprintti-taululle projektin aikana sitä mukaan, miten ja millaisessa järjestyksessä niitä on tarkoitus käsitellä. Arto Kiiskinen Eficodelta kokee, että nämä ovat viisi yleisin virhe käyttäjätarinoiden käsittelyssä:

Tarinoiden epävarmuustekijöitä ei ole esitestattu
Liian iso käyttäjätarina aletaan toteuttaa
Käyttäjätarinalla, joka on menossa toteutukseen pian, on puutteellinen tai epäselvä kuvaus
Käyttäjätarinaa, joka on menossa toteutukseen pian, ei ole groomattu (Groomaus on tiimin backlogiin liittyvä kokous).
Käyttäjätarinaksi hyväksytään asioita, joita ei koskaan kyetä toteuttamaan

Lue lisä blogikirjoituksesta täällä.