Näin jalostat backlogiasi tehokkaammin – kurinalaisen valmistautumisen avulla

Kuten edellisessä blogissani kerroin, useimmat tiimit eivät tee riittävästi backlog refinementia. Monissa tapauksissa syynä on tiimin sisäinen vastustus: tiimit saattavat kokea backlog refinement -käytännön ajanhukaksi. Työtehtävien määrittely ennen työn aloittamista tuntuu niin tehottomalta, että heidän mielestään on helpompaa hyväksyä hukka ja ryhtyä vain töihin – ja selvittää kantapään kautta, mitä pitää tehdä.

Mitä tehdä, jos tiimisi ei halua tehdä backlog refinementia

Voit käsitellä tiimin vastustusta muutamalla eri tavalla:

1. Kohdista refinement-työsi muihin kuin rutiinitehtäviin

2. Arvioi, hyödyttääkö koko tiimin osallistuminen vai kannattaako refinement tehdä pienemmässä ryhmässä

3. Järjestä työtehtävien valmistelu paremmin

Rutiinitehtävät eivät yleensä hyödy refinementista. Niillä on jo kirjoittamattomat ”hyväksymiskriteerit”, jotka tiimi tuntee hyvin. Jätä nämä tehtävät väliin – ellei joku huomaa, että rutiinilta vaikuttava tehtävä ei sitä todellisuudessa ole.

Kannatan koko tiimin osallistumista backlog refinement -sessioihin, mutta jos tiimi on suuri, tämä ei välttämättä ole järkevää. Jos tiimissäsi on viisi jäsentä, kaikki voivat osallistua. Jos tiimissä on vähintään kymmenen jäsentä, harkitse refinementin tekemistä vain valittujen osallistujien kanssa. Tiedon jakaminen on refinementin keskeinen hyöty, mutta sen voi toteuttaa myös muilla, tehokkaammilla tavoilla.

Tässä blogissa tarkastellaan nyt tarkemmin listan kolmatta kohtaa eli parempaa valmistelua.

Ota käyttöön järjestelmällinen valmistelutapa backlog refinementiin

Seuraavaksi kuvataan prosessi, jolla tuot järjestelmällisempää valmistelua backlog refinementiin. Jos haluat tutustua koko refinement-prosessiin, katso edellinen blogini.

Valmistelut ennen sessiota: 

1. Product Owner valitsee työtehtävät, jotka vaativat refinementia.

2. Product Owner etsii kehitystiimistä sopivan henkilön valmistelemaan työtehtäviä tarkemmin TAI tiimi organisoi itse työn niin, että valmisteluvastuuseen löytyy sopivin henkilö.

3. Valitut tiimin jäsenet valmistelevat työtehtävät.

4. Product Owner lähettää refinement-session osallistujille sähköpostimuistutuksen, jotta he tutustuvat valmisteltuihin työtehtäviin ennen sessiota.

5. Refinementin osallistujat tutustuvat valmisteltuihin työtehtäviin, kirjaavat mahdolliset kysymykset tai kommentit ja arvioivat alustavasti tarvittavan työmäärän.

Session aikana:

1. Valitse refinement-sessiolle sihteeri, joka tekee muistiinpanot.

2. Product Owner kertoo, mikä työtehtävä käsitellään ensin.

3. Tiimillä on mahdollisuus kommentoida työtehtävää tai esittää siitä kysymyksiä. Jos tässä vaiheessa ei tule kommentteja tai kysymyksiä, voit siirtyä suoraan seuraavaan vaiheeseen ilman lisäkeskustelua.

4. Tiimin jäsenet arvioivat työtehtävän työmäärän planning pokerilla.

5. Jos planning pokerin tuloksissa on vain kohtuullista vaihtelua, työmäärä kirjataan ja tiimi siirtyy listan seuraavaan työtehtävään.

6. Jos planning pokerin tulokset osoittavat merkittäviä eroja työmääräarvioissa, tiimi keskustelee tekijöistä, jotka johtivat eri arvioihin. Keskustelun tulokset dokumentoidaan tikettiin.

7. Tiimi arvioi työtehtävän uudelleen, kunnes se voi siirtyä listan seuraavaan työtehtävään.

Asiat, joista tiimien on sovittava

Kuten näet, tämä prosessi on monimutkaisempi ja haastavampi kuin edellisessä blogissa kuvattu yksinkertainen lähestymistapa. Ei kuitenkaan syytä huoleen: käytännössä prosessi ei ole niin vaikea kuin miltä se saattaa kuulostaa. Useista vaiheista on silti sovittava, ja kokonaisuudessaan prosessi vaatii tiettyä kurinalaisuutta.

Tiimien on sovittava muun muassa seuraavista asioista:

• Miten Product Owner voi pyytää tiimin jäsentä valmistelemaan työjonon kohdan?

• Kuinka paljon aikaa valmistelutehtäviin tulisi käyttää?

• Miten valmistelutehtävät suhteutuvat standardityönkulun muihin kohtiin (eli sovittuun ja sprinttiin sitoutuneeseen sisältöön)?

Tähän liittyy yksi käänne: Agile-tiimin jäsenille ei tulisi osoittaa työtä, vaan heidän tulisi ilmoittautua siihen itse. Saako tiimi siis antaa Product Ownerin pyytää suoraan tiimin jäsentä käyttämään aikaa refinementin valmisteluun?

Vaihtoehtona sille, että PO osoittaa valmistelutehtävän, PO voi pyytää tiimiä osoittamaan sen. Tällöin tiimillä on oltava käytäntö, jolla se hallinnoi itse, kenellä tiimin jäsenellä on valmisteluun tarvittava asiantuntemus ja kapasiteetti. Tämä on hieman haastavampaa kuin se, että PO pyytää jotakuta suoraan tekemään valmistelun, mutta se on paremmin Agile-periaatteiden mukaista. Tiimin kannattaa kokeilla, kumpi näistä kahdesta lähestymistavasta toimii sille parhaiten.

Mitä tehdään, jos suunniteltu ja osoitettu valmistelutyö epäonnistuu?

Jos valmistelu ilman työpyyntöä epäonnistuu toistuvasti muiden työvelvoitteiden vuoksi, yksi vaihtoehto on luoda sprintin backlogiin "refinement-työpyyntöjä". En erityisesti pidä tästä lähestymistavasta, koska se muistuttaa "määrittelyvesiputousta". Se on silti toimiva lähestymistapa, jota kannattaa kokeilla.

Kuinka paljon aikaa riittää?

Tiimin tulisi myös keskustella valmistelun laajuudesta ja sopia siitä. Kuinka paljon aikaa siihen tulisi käyttää?

Useimmille kohdille noin 20–30 minuuttia tarjoaa usein riittävän valmisteluajan lähtökohdaksi. Nykyisen sprintin luvattujen tulosten parissa työskennellessäkin on varmasti mahdollista löytää 20–30 minuuttia kutakin kohtaa kohden.

Mitä valmistelu todella tarkoittaa?

Valmistelun tekevä henkilö ottaa huomioon ja dokumentoi seuraavat asiat:

• Mikä on backlog-kohdan "miksi" – miksi tiimin tulisi tehdä se?

• Kohdan hyöty loppukäyttäjälle, jos mahdollista.

• Backlog-kohdan kuvaus.

• Hyväksymiskriteerit (luettele 3–8 hyväksymiskriteeriä).

• Jos backlog-kohta on jaettava pienempiin osiin, suositus siitä, miten jako kannattaa tehdä.

• Mitä tiimin ei tulisi toteuttaa tässä backlog-kohdassa.

Kaikki on kiinni kurinalaisuudesta

Tässä backlog refinementiin valmistautumisen tavassa on muutamia ylimääräisiä määräaikoihin sidottuja vaiheita, jotka vaativat tiimiltä melko paljon kurinalaisuutta.

• Tiimin on tehtävä valmistelutyö muutaman päivän kuluessa.

• Refinementiin osallistuvien tiimin jäsenten on luettava ja pohdittava kohdat ennen refinement-sessiota.

Hyvä valmisteluaikataulu auttaa kehittämään kurinalaisuutta

Suosittelen, että tiimit luovat tiukan rutiiniaikataulun, joka auttaa kehittämään ja ylläpitämään tarvittavaa kurinalaisuutta. Esimerkiksi:

• Backlogin jalostus tehdään joka tiistaiaamu kello 10 samaan aikaan.

• Valmisteltujen asioiden tulee olla valmiina katselmointia varten maanantaina keskipäivällä.

• Jalostukseen osallistuvat tiimin jäsenet varaavat maanantai-iltapäivälle tunnin mittaisen ajan tutustuakseen asioihin.

• Product Owner käy valmistelutyön läpi edellisenä keskiviikkona.

• Product Owner nimeää keskiviikon työpäivän loppuun mennessä sopivan tiimin jäsenen valmistelemaan asian.

• Tiimin jäsenellä on torstai, perjantai ja maanantaiaamu aikaa tehdä 20–30 minuutin valmistelutyö.

Mielestäni tällaisista määräajoista sopiminen ja niissä pysyminen on ainoa tapa saada valmisteluprosessi toimimaan. Yritys sopia jotain muuta ad hoc epäonnistuu todennäköisesti.

Kurinalaisen valmistelutavan hyödyt

Kehitystiimit voivat hyötyä kurinalaisesta valmistelutavasta monin tavoin:

• Koko tiimi voi luottaa asian valmistelleen tiimin jäsenen asiantuntemukseen.

• Tiimin jäsenten ei tarvitse keksiä kaikkea asian kuvaukseen tai kaikkia hyväksymiskriteerejä.

• Tiimi voi keskittää huomionsa ja työnsä valmistelun haastamiseen sekä kysymysten esittämiseen sen selvittämiseksi, onko jotain jäänyt huomaamatta.

Kun tästä käytännöstä tulee rutiini, tiimi voi käydä asiat läpi paljon nopeammin ja pysähtyä, kun kuvauksessa on epäselviä kohtia. Keskustelussa voidaan ohittaa arkiset asiat ja keskittyä huomattavasti enemmän työn arvokkaimpiin osiin.