Hiljaiset backlog refinement -tapaamiset: tehokkaampi Agile-tapaaminen

Käyn nopeasti läpi, miten voit ottaa ne käyttöön organisaatiossasi.

Mutta ensin:

Backlogin jalostaminen on itsessään haastavaa

Backlogin jalostaminen on oma taiteenlajinsa. Sen tekemiseen hyvin liittyy monia haasteita, kuten:

• Miten kaikki saadaan mukaan

• Miten valmistautua optimaalisesti

• Miten käydä tuottavia keskusteluja ja saada koko tiimi jakamaan arvokasta panostaan tapaamisen aikana

• Miten tehdä kaikki tämä tehokkaasti niin, ettei se vie liikaa aikaa ”varsinaiselta” työltä

Etätapaamiset tuovat lisää haasteita

Verkkotapaamiset ovat tehneet tilanteesta entistä haastavamman. Verkkotapaamisissa on vaikea viestiä tehokkaasti. Yksi henkilö puhuu, muut (ehkä) kuuntelevat (tai tekevät ehkä jotain muuta). Usein tietyt henkilöt (tiedät kyllä ketkä) puhuvat aivan liian pitkään, koska he eivät saa muilta visuaalisia vihjeitä siitä, että on aika siirtyä eteenpäin.

Hiljaiset tapaamiset – yksinkertainen tapa ratkaista nämä haasteet

Hiljaiset tapaamiset ovat kehittyneet ratkaisemaan perinteisten tapaamisten ongelmia. Hiljaisessa tapaamisessa keskitytään enemmän ennen tapaamista valmistellun materiaalin lukemiseen, pohtimiseen ja kommentointiin.

Lukeminen on nimittäin:

• Paljon nopeampi tapa viestiä kuin puhuminen ja kuunteleminen.

• Paljon demokraattisempaa – äänekkäät ekstrovertit eivät jyrää introvertteja tai muita kuin äidinkieltään puhuvia yhtä helposti.

Siksi hiljaisten tapaamisten menetelmä sopii erinomaisesti backlogin jalostamiseen. Kehittäjät ovat tottuneet lukemaan ja kommentoimaan. Ja kehittäjissä on paljon introvertteja.

Lue lisää backlogin hallinnasta

• Ratkaisu liian suureen backlogiin: tuotetoivelista

• 3 jalostuskäytäntöä terveempään ja ennustettavampaan backlogin

• Miten jalostat backlogiasi tehokkaammin – kurinalaisella valmistautumisella

• Hyödynnä Kanbania nopeampaan ja parempaan backlogin jalostamiseen

Mitä hiljaiset backlogin jalostustapaamiset ovat

Katsotaan ensin hiljaisten tapaamisten perusteita. Sen jälkeen tarkastelemme, miten voit soveltaa niitä erityisesti backlogin jalostustapaamisissa.

Hiljainen tapaaminen koostuu seuraavista osista:

1. Esityslista (tapaamisen tavoitteet, asiat, joita ei tavoitella, prosessi ja fasilitaattori)

2. Taulukon lukeminen

3. Lukeminen ja kommentointi

4. Fasilitaattorin yhteenveto, johtopäätökset tai tiivistelmä

Hiljaiset kokoukset eivät välttämättä ole täysin hiljaisia – pikemminkin 95-prosenttisesti hiljaisia. Osallistujat voivat edelleen puhua tarvittaessa. Suurin osa kokouksen viestinnästä tapahtuu kuitenkin lukemalla, kommentoimalla ja täydentämällä työn alla olevaa työtehtävää.

Taulukon lukeminen

Hiljaiset kokoukset toimivat vain, jos niillä on lähtökohta. Perinteinen kokous voi alkaa esimerkiksi PowerPoint-esityksellä. Hiljaisen kokouksen tulisi sen sijaan alkaa taulukon lukemisella. Taulukon lukeminen perustuu kirjalliseen kuvaukseen. Hiljaisten kokousten manifesti suosittelee 4–6-sivuista kuvausta.

Taulukon lukemisen soveltaminen hiljaiseen backlogin tarkentamiseen

Tarkentamisen taulukon lukemisen lähtökohtana voi olla Product Ownerin tai jonkin muun tiimin jäsenen valmistelema käyttäjätarina.

Tarinassa olisi edelleen seuraavat osat:

• Otsikko

• Tarinan kuvaus

• Lisätiedot

• Hyväksymiskriteerit (nämä ovat tärkeitä – lue niistä lisää täältä)

Voit lisätä myös kirjallisen kuvauksen, mutta se ei ole pakollista. Voit käyttää hiljaista tarkentamista myös epicien tai jopa aloitteiden analysointiin. Tällöin pidemmän kirjallisen kuvauksen käyttö on entistäkin perustellumpaa.

Hiljaisen backlogin tarkentamisen prosessi

Käytä työkalua, jonka avulla jokainen osallistuja näkee muiden lisäykset heti. Jira ei sovellu tähän erityisen hyvin. Parempia vaihtoehtoja ovat Confluence yhteismuokkaustilassa, Miro-taulut tai vastaavat verkossa toimivat valkotaulutyökalut.

Et kuitenkaan järjestä luostaria: joissakin keskustelun vaiheissa voi olla tarpeen puhua. Kysymykset tai kommentit voivat olla liian monimutkaisia kirjoitettaviksi. Tiimin tulisi silti välttää puhumista mahdollisimman paljon ja suosia kirjoittamista ja lukemista.

Ennen hiljaista sessiota tiimin tulisi sopia seuraavista asioista:

• Käytettävä työkalu.

• Kirjoitusmuoto, jolla tarinaan lisätään tarkennuksia, kommentteja ja kysymyksiä.

• Merkintätapa: miten ilmaistaan samaa tai eri mieltä oleminen kirjoitetusta sisällöstä (peukku ylös, tähdet rivin lopussa tai vastaava).

• Miten ilmaistaan, että tiimi on valmis siirtymään työmäärän arviointiin. Tämä voi olla aikaraja (5 minuuttia per kohde) tai fasilitaattori huomaa, ettei muokkauksia enää tehdä.

• Miten kohteen työmäärä arvioidaan (esimerkiksi erityisellä työkalulla, Miro-taulun lisäosalla tai samanaikaisella chat-äänestyksellä).

Tässä on ehdotukseni merkintätavaksi:

• En ymmärrä – kysymysmerkki: ”?”

• Samaa mieltä, kannatan täysin – tähti: “*”

• Täysin eri mieltä – huutomerkki: “!”

Näin järjestät hiljaisen backlog refinement -palaverin

Ennen palaveria

1. Product Owner kokoaa tarkennettavat storyt käyttämäänne työkaluun

2. Joku valmistelee storyt etukäteen (table read) (katso täältä, miksi tämä on niin tärkeää)

Palaverissa

1. Fasilitaattorin johdolla tiimi käy yksi kerrallaan läpi storen kuvauksen (hiljaa!)

2. Tiimi muokkaa, kommentoi, esittää kysymyksiä sekä on samaa tai eri mieltä käsiteltävästä aiheesta

3. Fasilitaattori huomaa, että muokkaaminen hidastuu (tai sovittu aikaraja saavutetaan)

4. Tiimi arvioi työmäärän esimerkiksi planning pokerin avulla

5. Siirrytte esityslistan seuraavaan kohtaan

Yhteenveto: miksi hiljainen palaverimenetelmä sopii erinomaisesti backlog refinementiin

Tällainen backlog refinement ei ole vain huomattavasti nopeampi ja tehokkaampi:

• Se pakottaa tiimin valmistelemaan backlog-kohdat refinementia varten (jotta table read voidaan tehdä).

• Se dokumentoi refinement-keskustelun automaattisesti kyseiseen kohtaan.

• Se on huomattavasti demokraattisempi tapa keskustella, ja sen avulla hiljaisemmat sekä kokemattomammat tiimin jäsenet voivat ilmaista mielipiteensä vapaammin.

En väitä, että tämä käytäntö sopii kaikille tai jokaiseen tiimiin. Kannattaa silti kokeilla sitä tai sen osia ja katsoa, miten se toimii omalla kohdallasi.