Pikaopas käyttäjätarinoiden hyväksymiskriteereihin

Tässä kirjoituksessa opit helpon tavan saada tiimisi omaksumaan tämän käytännön: tee muistiinpanoja refinement-keskustelujen aikana.

Käydään kuitenkin ensin läpi, miksi hyväksymiskriteerit ovat tärkeitä. Voit myös halutessasi siirtyä suoraan lopussa esiteltyyn muistiinpanomenetelmään.

Mitä hyväksymiskriteerit ovat?

Agile-tiimit käyttävät työjonoa. Työjonon kohteet voidaan kirjoittaa käyttäjätarinoiden muotoon. Käyttäjätarina on lyhyt kuvaus työstä, jossa kerrotaan:

• Kuka tarvitsee työn tuloksia

• Mikä ratkaistava ongelma on

• Miksi ongelma pitää ratkaista

Tätä ”kuka & mitä & miksi” -mallia kutsutaan joskus Cohnin tarinamuodoksi.

Työkohteiden muotoileminen käyttäjätarinoiksi on vain ajattelun apuväline. Sen käyttö ei ole pakollista. Käytä sitä, kun ratkaistavana on selkeä järjestelmän käyttäjän ongelma. Käyttäjätarinat auttavat tiimiä keskustelemaan ratkaistavasta ongelmasta ja muodostamaan siitä yhteisen ymmärryksen.

Miksi käyttäjätarinoihin kannattaa lisätä hyväksymiskriteerit?

Yksi tärkeimmistä syistä käyttää käyttäjätarinoita on luoda yhteinen kieli liiketoiminnan ja kehittäjien välille. Käyttäjätarinat kuvaavat tarpeen eli ongelman tavalla, jota kaikkien pitäisi pystyä ymmärtämään ja käsittelemään.

Käyttäjätarinoiden käyttö auttaa kohdistamaan keskustelun ongelman ymmärtämiseen. Tiimi voi välttää ajautumisen liian syvälle teknisiin keskusteluihin, jotka voivat etäännyttää liiketoiminnan ei-teknisiä sidosryhmiä. Kun tarve ymmärretään yhteisesti, tiimi pystyy paremmin määrittelemään, millainen ratkaisu sen ratkaisemiseksi tarvitaan.

Käyttäjätarina koostuu kolmesta erillisestä osasta:

1. Otsikko

2. Kuvaus (kuka, mitä ja miksi)

3. Hyväksymiskriteerien luettelo

Otsikko ja kuvaus määrittelevät, miksi ongelma pitää ratkaista ja kuka siitä hyötyy.

Hyväksymiskriteerit puolestaan määrittelevät tarinan mitä-osan.

Jos et käytä hyväksymiskriteereitä, vaarana on:

• jokin tarvittava asia jää toteuttamatta (voit siis kutsua jotain valmiiksi, kunnes myöhemmin selviää, että se pitää tehdä uudelleen)

• toteutat jotain, mitä ei tarvita

• yhteinen ymmärrys tarvittavista asioista jää puutteelliseksi

• työmäärä arvioidaan epätarkasti

Kaikki nämä riskit voivat aiheuttaa hukkaa. Tiimisi voi joutua tekemään jotain uudelleen monta kertaa saadakseen sen oikein, tai työ voi olla liian suuri valmistuakseen yhden sprintin aikana.

Vältä kysymys: ”Miksi tässä kestää niin kauan?”

Usein Product Owner ihmettelee, miksi kehitys kestää niin kauan. Ominaisuuden toteuttamisenhan piti olla helppoa. Alkuperäinen työmääräarvio oli yksi tai kaksi viikkoa. Nyt aikaa on kulunut jo yli kuukausi. Mitä on meneillään?

Kehitystiimin on liian helppo lisätä mukaan liikaa asioita, jotta kaikki mahdollinen tulee katettua. Insinöörit haluavat joskus kehittää ylimitoitetun ratkaisun, vaikka tarkastelun perusteella huomattavasti yksinkertaisempi lähestymistapa olisi riittänyt. Tällainen ajan ja työn haaskaus olisi voitu välttää keskustelemalla hyväksymiskriteereistä – ne auttavat hyvin päättämään, mitä ei tarvita.

Esimerkki: paholainen piilee yksityiskohdissa

Toinen yleinen ongelma, joka johtuu hyväksymiskriteerien käyttämättä jättämisestä, on ominaisuuksien kehittäminen ilman, että kaikkia todella tarvittavia asioita huomioidaan. Katsotaan esimerkkiä.

Esimerkkikäyttäjätarina: salasanan vaihtaminen

Käyttäjä:
Haluan vaihtaa salasanani, jotta voin käyttää järjestelmää.

Tämä käyttäjätarina kuvaa ongelman: järjestelmässä tulisi olla tapa, jolla käyttäjät voivat vaihtaa salasanansa. Ratkaisuna voisi olla jossain sijaitseva ”vaihda salasana” -valinta sekä näkymä tai ponnahdusikkuna, jossa käyttäjä voi vaihtaa salasanan.

Yksinkertaista, eikö? Siirrymmekö toteuttamaan sitä tai arvioimaan toteutuksen työmäärää?

Hyväksymiskriteerit paljastavat todellisen monimutkaisuuden

Keskustellaan muutamista mahdollisista hyväksymiskriteereistä. Harkittavia kriteerejä voivat olla esimerkiksi:

• Salasana on vähintään 8 merkkiä pitkä

• Salasanassa on oltava vähintään yksi erikoismerkki

  • Tarkistettavien erikoismerkkien luettelo

• Salasanassa on oltava vähintään yksi pieni ja yksi iso kirjain

• Salasana on syötettävä kahteen erilliseen kenttään

• Molempien salasanakenttien on täsmättävä, jotta rekisteröinti on mahdollista

• Loppukäyttäjälle näytetään ilmaisin, jos salasana ei ole riittävän vahva

• Vahvuusilmaisimen tulee päivittyä jokaisen salasanakenttään tehdyn muutoksen jälkeen

• Käyttäjälle kerrotaan, miksi rekisteröinti ei onnistu

  • Salasanan on oltava vähintään 8 merkkiä pitkä

  • Salasana ei ole riittävän vahva: lisää erikoismerkkejä tai numeroita

  • Täytä kaikki pakolliset kentät - [kentästä puuttuu tietoa]

• Rekisteröinti on mahdollista vain, jos salasana on riittävän vahva

• Rekisteröinti on mahdollista vain, jos kaikki muut pakolliset kentät on täytetty

• Pakolliset kentät on merkitty selkeästi

Ilman keskustelua hyväksymiskriteereistä esimerkkimme kaltainen yksinkertainen tarina voitaisiin toteuttaa, mutta sivun taustalla oleva logiikka ei olisi valmis. Asiat tulisivat esiin myöhemmin, ja tiimin pitäisi palata sivuun, jotta siitä saataisiin käyttäjälle toimiva ja miellyttävä.

Arvioi työmäärä vasta, kun hyväksymiskriteerit on listattu

Keskustelemalla tarkasti siitä, mitä pitää tehdä, tiimi voi muodostaa yhteisen ymmärryksen. Arvioi työmäärä vasta tämän jälkeen. Ilman hyväksymiskriteerejä sivun luomisen voisi kuvitella vievän vain muutaman tunnin tai yhden tarinapisteen. Kun kaikki hyväksymiskriteerit otetaan huomioon, arvio voi muuttua pariksi päiväksi tai 3–5 tarinapisteeksi.

Hyväksymiskriteerien tärkeimmät hyödyt

Hyväksymiskriteerien tärkeimmät hyödyt ovat:

• Yhteinen ymmärrys siitä, mitä tarvitaan

• Tarkemmat työmääräarviot

• Tarkemmat nopeusarviot

• Parempi sitoutuminen sprinttiin

• Liian suurten tarinoiden helpompi tunnistaminen

• Liian suurten tarinoiden helpompi pilkkominen pienemmiksi

Näin aloitat hyväksymiskriteerien käytön helposti: dokumentoi keskustelu

Tämä menetelmä on tarkoitettu tiimeille, joilla ei ole aiempaa kokemusta hyväksymiskriteerien käytöstä.

Tähän prosessiin tarvitset muistiinpanojen kirjaajan tai sihteerin. Jos tiimissäsi on Scrum Master, hän voi hoitaa tehtävän.

1. Avaa käyttäjätarina niin, että kaikki näkevät sen (tämä on erittäin tärkeää – kaikkien pitää nähdä heti, millaisia muistiinpanoja tehdään).

2. Aloittakaa kysymysten esittäminen sekä kommenttien ja vastausten antaminen – mitä tämä tarina tarkoittaa?

3. Muistiinpanojen kirjaaja tulkitsee kysymykset ja kommentit ja kirjaa ne heti luettelomerkeiksi tarinan kuvauksen alle. HUOM.: Tässä vaiheessa on tärkeää, että kirjaaja lisää kaikki kommentit ja kysymykset kuvaukseen odottamatta vahvistusta tai päätöstä. Tavoitteena on dokumentoida keskustelu. Jatkakaa näin muutaman minuutin ajan.

4. Muutaman minuutin kuluttua tai keskustelun hiipuessa alkakaa tarkastella luettelomerkkien listaa. Listatut asiat ovat ehdokkaita hyväksymiskriteereiksi. Seuraavaksi tarkistetaan, onko joku eri mieltä jostakin listan kohdasta. Jos on, kohdistakaa keskustelu siihen aiheeseen.

5. Pohtikaa lopuksi muutamaa kysymystä:

   1. Tarvitaanko näitä kaikkia?

   2. Onko jokin niistä ristiriidassa toisen kanssa?

   3. Puuttuuko jotain ilmeistä?

   4. Onko hyväksymiskriteerejä liikaa? Jos niitä on yleensä yli 10, se voi olla merkki siitä, että tarina kannattaisi pilkkoa kahdeksi pienemmäksi tarinaksi.

Tutustuttakaa tiiminne ensin paremmin hyväksymiskriteereihin – kehittäkää käytäntöä myöhemmin

Asian voi tiivistää hyvin yksinkertaisesti: tehkää muistiinpanoja ja dokumentoikaa keskustelu. Älkää huolehtiko muodollisuuksista, kuten siitä, että hyväksymiskriteerit pitäisi muotoilla kysymyksiksi. Niihin voi palata myöhemmin, jos niin haluatte.

Dokumentoitujen luettelokohtien tuoma lisäarvo ja se, että tiimi oppii lisäämään niitä jokaiseen tarinaan, ovat tärkeämpiä kuin tällaisten muodollisten sääntöjen noudattaminen.