Vuoden 2018 digitaalinen kehittäminen sai mukavan startin kahdellekymmenelle asiantuntijalle suunnatussa Käyttäjätarinoiden kirjoittaminen ja hallinnointi -valmennuspäivässä. Valmentajiksi saatiin jo entuudestaan tuttu ja aiemmin DriveTurku-hankkeenkin aikana vakuuttanut Codenton ketteryysvalmentaja Karoliina Luoto. Karoliinan lisäksi "koutsaamassa" oli tuotteistamisen ja tuotehallinnan expertti Anu Takala.
Turussa ketterä kehittäminen on jo tuttu juttu, esimerkiksi kaupungin verkkosivusto pystytettiin ketterällä mallilla vuonna 2015 ja sitä kehitetään edelleen leanisti. Me Turun kaupungilla olemme hyvin vakuuttuneita siitä, että ketterät projektit onnistuvat paremmin kuin vesiputousmallin projektit. Ketteryys onkin siksi tapana laajasti kaikessa digitaalisessa kehittämisessä. Miksi siis jälleen oli tarpeen miettiä käyttäjätarinoita?
Olemme havainneet, että käyttäjätarinoiden käsittely on organisaatiossamme ja projektiryhmien sisällä eri asteilla tuttua. Toiset ovat olleet mukana kirjoittamassa tarinoita, toiset pyörittävät kanban-tauluja työkseen, toisille taas koko käsite ”käyttäjätarina” on tuntematon. Vakiintuneita käytäntöjä ei ole, tai ne ovat saaneet jalansijaa lähinnä asiaan omistautuneemman digitaalisen kehittämisen ydinjoukon kesken.
Kommunikoinnin ja seurattavuuden takia on kuitenkin oleellista, että kaikki projektiryhmäläiset ymmärtävät perusasiat käyttäjätarinoiden kirjoittamisesta ja hallinnoinnista. Asiantuntijalla on paras näkemys oman toimialansa asiakkaiden tarpeista ja toiveista, johon tulevaa toiminnallisuutta kehitetään, ja siksi hänen osallistumisensa käyttäjätarinoiden kirjoittamiseen on avainroolissa. Palvelun tai tuotteen tulee olla aidosti asiakasta hyödyttävää. Toiminnan ja käyttäjän tarpeita ei voi ymmärtää kukaan paremmin kuin tilaaja.
Näillä mietteillä päätimme tilata laajalle asiantuntijajoukolle kustomoidun käyttäjätarinatyöpajan, jossa keskityimme Turun kaupungin omiin esimerkkeihin ja työkaluihin.
Milloin käyttäjätarinan kuvaus on auttamattomasti liian pitkä tai yksityiskohtainen? Millainen on aidosti huono käyttäjätarina? Kaivoimme nöyrästi esille omat huonot tarinamme. Liian ylimalkainen, liian yksityiskohtainen, liian tekninen – voi pojat – olemme menneet metsään aika monta kertaa. Onneksi mallikelpoisia tarinoitakin löytyi yllin kyllin.
Nämä periaatteet olivat toki tuttuja, mutta ah, niin tärkeitä muistutella mieliin: käyttäjätarina on saatava niin pieneksi, että sen edistymistä voidaan seurata järkevästi kehitysjakson aikana, toisaalta sen täytyy olla toteutettavissa itsenäisesti.
Oli hauskaa huomata, että vaikka käyttäjätarinoiden kirjoittaminen oli itselle jo tutumpaa, opetti päivä taas paljon. Mistä olimme lipsuneet ja mikä tahtoi unohtua? Käyttäjätarinan hyväksymiskriteerit määrittelevät, millä ehdoilla käyttäjätarina voidaan todeta tehdyksi. Huomasimme, että joskus tarinoista jäivät tarkat kriteerit kirjaamatta. Miten toiminnallisuuden testaus onnistuu ilman selkeitä speksejä? Mitä paremmin määritelty, sitä helpompi testata.
Toinen yhtä tärkeä pointti oli rajaaminen ja sen tunnistaminen mikä ei kuulu toteutukseen. Pois jäävästä osiosta voi aina kirjoittaa oman tarinansa. Iltapäivä antoi ryhtiä myös kanban-taulun suunnitteluun ja organisointiin. Oli hyvä kirkastaa tavoitetta: edistymisen ja mahdollisten pullonkaulojen tulisi olla kehitystyön arjessa läpinäkyviä.
Päivän alkaessa koulutustilassa näkyi epäileviä ilmeitä ja kuvitteellisia kysymysmerkkejä ilmassa, mutta koulutuksen tullessa päätökseensä oli ilo nähdä osallistujien kirkastuneet katseet ja hymyn kare huulilla. ”Nyt ymmärrän kokonaisuuden! Tunnen oman toimialani, ja voin hyvin kuvitella mitä asiakkaat toivovat. Nyt osaan kiteyttää asiakkaidemme tarpeet tarinoiksi.”
Oli myös hieno oivallus, että perinteisemmissäkin projekteissa on hyödyllistä kirjata tarpeet selkeiksi käyttäjätarinoiksi. Ketterästä tavasta voidaan myös aina poimia matkaan aikataulujen ja väliaikatavoitteiden selkeä kirjaaminen sekä keskeneräisten versioiden avoin esittely ja testaaminen.
Kiitos siis huippu-Karo, Anu ja Codento! Näitä oppeja tulemme hyödyntämään käytännössä – itse asiassa käyttäjätarinoiden kirjoittamistyöpajat käynnistyivät heti seuraavalla viikolla. Tästä on hyvä jatkaa.
Käyttäjätarinat kuvaavat mitä halutulla ominaisuudella on tarkoitus tehdä. Ne muotoillaan lauseeksi: ”Käyttäjänä Y haluan Z jotta X”. Eli käytännössä vaikkapa: "Sivuston loppukäyttäjänä haluan pysäyttää kuvakarusellin, jotta pystyn keskittymään luettavaan sisältöön paremmin".
