Tätä on backlog refinement -työskentely käytännössä

Tuotteen kehitysjono – tuttavallisemmin backlog – on ketterissä ohjelmistoprojektissa se sammio, johon tiimi kokoaa kaikki vaatimukset, tarpeet ja muutokset. Tuolta jatkuvasti päivittyvältä listalta valitaan toteutettavia tehtäviä sprintin työlistalle. Jos näiden kahden sarakkeen välissä ei ole ennalta suunniteltua arviointiprosessia, vaatimusten hallinta muuttuu vaikeaksi.

Backlog refinement tarkoittaa suomeksi tuotteen kehitysjonon työstämistä: siis tehtävien priorisoimista, yksityiskohtien tarkentamista ja työmääräarvioiden lisäämistä. Samasta asiasta on aiemmin käytetty myös nimeä backlog grooming. Kun varaat backlogin tarkasteluun riittävästi aikaa, ehkäiset turhaa työtä ja lisäät laatuvipua ohjelmistokehitykseen.

Onko backlog refinement pakollinen osa ketterää työskentelyä?

“Scrum Guiden mukaan backlog refinement -vaiheessa on erityisen tärkeää tarkistaa kaksi asiaa. Ensinnäkin, jokaisen tehtävän on oltava riittävän pieni, jotta sen voi toteuttaa yhden sprintin aikana. Toiseksi, tehtävälle pitää asettaa selkeät vaatimukset siitä, milloin se on valmis. Näin kehittäjät tietävät varmasti, mihin määränpäähän on tarkoitus päästä”, kuvailee Mikko Suni.

Suni toimii scrum masterina ja lead developerina asiakasprojektissa, jossa tiimiläisiä on kaikkiaan kymmenkunta. 

“Scrum masterilla on velvollisuus huolehtia tuotteen kehitysjonossa olevien tehtävien läpikäymisestä. Hän tyypillisesti myös fasilitoi tilaisuuden. Alkuperäisessä scrum-oppaassa erillinen backlog refinement -tapaaminen ei itse asiassa ole välttämättömyys. Itse näen, että se on tärkeä osa ketteriä työtapoja ja projektin vaatimusten hallintaa. Laajassa projektissa, jossa olen mukana, teemme viikoittain kaksi pienempää refinement-palaveria. Muutoin istunto kestäisi kerralla jopa kolme tuntia”, Suni jatkaa.

Axel Baumgartner toimii toisessa asiakashankkeessa scrum masterina. Hänkin on pohtinut, miksei backlog refinement -työskentelyä mainita muiden tapahtumien tapaan scrumin pakollisena osana:

“Varmasti syynä on se, miten vahvasti koko refinement-prosessi muotoutuu tiimin tarpeiden, roolien ja mukana olevan osaamisen mukaan. Kokoonnutaanko kehitysjonon tarkasteluun kerran kuussa vai viikoittain – riippuu täysin tilanteesta.”

Lue myös: Miten kriittisen tärkeistä ohjelmistoista tehdään vahvoja?

Kenen vastuulle kehitysjonon työstäminen kuuluu?

Kehitysjonoon perehtyminen kuuluu koko tiimille, mutta ajankäyttöä kannattaa silti suunnitella fiksusti.

“Jos tuoteomistaja on hyvin tekninen, hän saa luultavasti jopa itse työstettyä backlogia pitkälle ja tiimin yhteistä aikaa kuluu työhön huomattavasti vähemmän”, Baumgartner vertaa. “Joskus taas tuoteomistajan rooli ei ole lainkaan tekninen, vaan hän keskittyy määrittelemään vaatimuksia hyvin korkealla tasolla. Silloin tarvitaan ehkä varsinaisen refinement-palaverin lisäksi vielä erillisiä, valmistelevia tapaamisia, joissa esimerkiksi 2–3 tiettyyn teknologiaan perehtynyttä tiimin jäsentä esivalmistelee tehtäviä. Sen jälkeen varsinainen palaveri on suoraviivainen: katsotaan läpi tehtävät sekä niiden suhteet toisiinsa.”

Kehitysjonon työstämisestä ei kannata nipistää ajansäästön nimissä. On myös tärkeää osallistaa koko tiimi varsinaisiin refinement-tilaisuuksiin. Puutteellinen vaatimusten hallinta kostautuu myöhemmin, kun yhteinen ymmärrys tekemisestä syntyy vasta virheiden ja turhien työtuntien jälkeen. Kehittäjien työnkuva ei olekaan selkeä ja suunnitelmien huomataan menneen pieleen.

“Yleiset scrum-periaatteet on kirjoitettu minkä tahansa toimialan työskentelyyn – ei pelkästään ohjelmoijille. Meillä asiakasprojektit ovat tyypillisesti niin vaativia ja moniulotteisia, että backlogin työstämiseen on pakko varata aikaa”, Suni kertoo.

Mitä haasteita backlogin hallintaan liittyy – ja miten niitä voi ratkaista?

Backlog refinement on jatkuvaa tekemistä, ei kertaponnistus. Siksi se vaatii myös huomiota koko ohjelmistoprojektin elinkaaren ajan. Esimerkiksi nämä haasteet saattavat heittää kapuloita ketteriin rattaisiin:

“Puuttuuko aika tiimiltä vai asiakkaan vastuuhenkilöiltä? Jos asiakas ei ole halukas osallistumaan riittävästi, on meidän pystyttävä avaamaan hyötyjä selkeämmin. Jokin slotti aikaa on joka tapauksessa tarpeen. Silloin, kun tekninen tuoteomistajuus on ohjelmistokehityskumppanin vastuulla, asiakas voi olla mukana esimerkiksi vain valmistelevassa palaverissa ennen refinement-kokoontumista. Ilman asiakkaan näkemystä tiimi joutuu vain arvailemaan, mitä backlogilta haluttaisiin tehdä seuraavaksi”, Suni sanoo.

“Jos taas tiimin aika on kortilla, olisi hyvä valita palaverissa käsittelyyn vain kaikista olennaisimmat asiat, eli katsoa yhdessä, että tehtävän 1) tunti- tai päiväarvio on kohdillaan ja 2) tavoitteet sekä hyväksyntäkriteerit on ymmärretty yhtenäisellä tavalla. Tiimi tarvitsee riittävästi tukea nimenomaan tuoteomistajalta. Ensisijaisesti pitäisi siis varmistaa, että hänellä on riittävästi aikaa tämän vaiheen työskentelyyn”, Baumgartner jatkaa.

“Varsinkin isoimmat projektit vaativat, että tekninen tuoteomistaja on sataprosenttisesti hankkeen saatavilla, eli ei joudu jakamaan aikaansa eri projektien kesken”, Suni täydentää.

“Kyllähän sitä projekteissa tapahtuu. Silloin on lisättävä yhteistä ymmärrystä ketteristä työskentelytavoista ja scrum-mallista – eli siitä, että vaatimuksia ei voi yleensä lähteä tekemään sen kummemmin miettimättä. Kiirehtiminen voi tuntua ajan säästämiseltä lyhyellä aikavälillä, mutta se tuottaa turhaa työtä ja ongelmat ovat edessä myöhemmin. Jos tuotteeseen haluaa tuoda jotakin uutta, sitä olisi mietittävä vähintään viikko-pari etunojassa. Näin tehtäviä ehtii priorisoida ja niiden työmääristä keskustella”, Suni kommentoi, ja jatkaa:

“Esimerkiksi meidän tiimissämme periaatteena on tehdä vain tehtäviä, jotka ehtii suorittaa kahdessa viikossa. Haluamme tuottaa jatkuvasti arvoa ja saada palautetta, jotta pysymme ketterinä. Se ei onnistu, jos yksittäiseen tehtävään kuluu kaikkien yllätykseksi monta kuukautta. Refinement-prosessi on turvaamassa, ettei näin pääse käymään.”

3. Joku lupaa asiakkaalle toiminnallisuuksia ilman yhteistä päätöstä

“Kuten edellisessä kohdassa, tätäkin haastetta taklataan pitämällä huolta siitä, että jokainen ymmärtää projektin kokonaisuuden edun. Silloin ei ole mielekästä luvata lennosta ja ilman kriittistä pohdintaa asioita, jotka sitten blokkaavat aikaa muulta”, Baumgartner muistuttaa.

Suni kehottaa tuomaan asiakkaan tiiviimmin mukaan scrum-työskentelyyn, jossa uudet ideat sinänsä ovat aina tervetulleita. Molemmat painottavat, miten tärkeää on backlogin läpinäkyvyys kaikille osallisille: vain silloin jokainen näkee omien valintojensa vaikutuksen muiden työhön ja käynnissä oleviin tehtäviin. 

4. On epäselvää, milloin tehtävä on valmis aloitettavaksi ja milloin se taas katsotaan tehdyksi

Vaatimusten hallintaan liittyvät olennaisesti termit Definition of Ready (DoR) ja Definition of Done (DoD). Pähkinänkuoressa DoR tarkoittaa kriteerejä, joiden on täytyttävä ennen kuin kehitysjonolla olevaa tehtävää voi alkaa työstää. DoD taas viittaa kriteereihin, joiden pitää täyttyä, jotta tehtävä katsotaan valmiiksi.

“Toiset tykkäävät määrittää näitä todella tarkasti”, Suni sanoo. “Itse ajattelen, ettei yksityiskohtaisten DoD-määritysten tarvitse olla vielä sataprosenttisen mietittyjä, kun tehtävä aloitetaan DoR-seulan läpäisyn jälkeen. Olennaisinta on selkeä päämäärä, eli minkä muutoksen käyttäjä tulee näkemään lopputuotteessa. Matkalla sinne voi sitten tilannekohtaisesti tarvita lisää esimerkiksi testausta tai dokumentaatiota.”

“Ylemmällä tasolla Definition of Done -määrittelyistä kannattaa kuitenkin keskustella. Se takaa laatua. Muutoin käy helposti niin, että tiimin yhteinen käsitys tuotoksen tilasta on keskenään aika ristiriitainen”, Baumgartner muistuttaa.

Ongelmien löytäminen on onnistumista

Backlog refinement -työskentely on onnistunut, kun sprinttiä aloittaessa huomaa tehtävien olevan selkeitä ja niihin on varattu sopivasti aikaa. Toisin sanottuna läpi ei ole päässyt vaillinaisia tai epäselviä tehtäviä. Onnistua voi myös toisella tapaa, Mikko Suni muistuttaa:

“Joskus tehtävä on päätynyt sprintin listalle asti, mutta huomaamme, ettei se olekaan valmis toteutettavaksi. Muu tiimi ei ehkä näe siinä ongelmaa, mutta yhden asiantuntijan silmään puutteet osuvat. Sellaisina hetkinä huomaa, että koko scrum-prosessi ja erilaisten osaajien yhteen tuominen toimii.”

Backlog refinement -työskentelyn muistilista

• Siirrä tehtävät backlogilta sprintin työjonoon vasta kriittisen tarkastelun jälkeen
• Varmista, että jokainen tehtävä on riittävän pieni toteutettavaksi yhden sprintin aikana
• Aseta selkeät vaatimukset sille, milloin tehtävä on valmis
• Osallista backlog refinement -työskentelyyn koko tiimi sekä asiakas, mutta pilko ajankäyttöä tarvittaessa valmisteleviin palavereihin
• Varaa työskentelylle riittävästi aikaa, jotta vältät turhan työn myöhemmin
• Pidä huoli siitä, että kaikilla osallisilla on hyvä näkymä backlogiin ja projektin kokonaisuuteen