Scrumin seremoniat: yhdeksän vinkkiä hyvään Backlog Grooming -kokoukseen!
Backlog Grooming on yksi tärkeimmistä Scrum-tiimin kokouksista. Sen päätavoitteena on parantaa backlogin laatua. Tuotteen kehittämisen ennustettavuus paranee suoraan verrannollisesti backlogin laatuun, ja juuri sen takia Backlog Grooming onkin niin tärkeä kokous.
Kun Sprint Planning -kokous fokusoi nimenomaan siihen juuri seuraavaan alkavaan Sprinttiin, niin Backlog Groomingin pitäisikin katsoa hiukan kauemmas. Miten kauas – se riippuu hieman tiimistä, backlogin laadusta ja hankkeen elinkaaresta. Projektin alkupäässä voidaan katsoa ehkä vain sprintti tai puolitoista eteenpäin, mutta projektin myöhemmissä vaiheissa horisontti siirtyy pidemmälle. Olisin kuitenkin sitä mieltä, että muutamaa sprinttiä kauemmas ei kannata tarinadetaljeja viedä taskitasolle asti.
Backlog Groomingissa onkin siis tarkoitus, että jo tunnistettuja backlog itemejä tarkennetaan ja niiden kuvauksista, sisällöstä, tavoitteista, riskeistä ja työmääristä keskustellaan. Mutta tavoite ei ole pelkästään tämä. Tavoitteena on myös huomata, jos backlogilta puuttuu jotain, jos asiat ovat väärässä prioriteettijärjestyksessä tai jos jotkin tarinat ovat liian isoja siihen nähden, miten lähellä ne ovat implementoinnin aloittamista.
Seuraavassa on yhdeksän pointtia hyvään Backlog Groomingiin!
1. Keskustelu
Grooming-kokous kannattaa pitää niin, että siellä syntyy keskustelua tarinoista. Tämä on koko homman ydinasia. Vaikka tehtäisiin paljonkin valmistelevaa työtä yksitellen tai pienryhmissä, suosittelen että pidetään silti yksi yhteinen sessio, missä päästään esittelemään ja keskustelemaan valmistelluista tarinoista. Jos taas ei tehdä tahoillansa valmistelua, niin sitten idea on juuri, että keskustellaan Groomingissa.
2. Keskustelun kirjaaminen ylös kaikkien nähtäväksi
On aivan ehdotonta, että joku kirjaa keskustelun ylös sen edetessä. Tarkoituksena on, että kirjataan mitä ihmiset sanovat: joko tarinan kuvaukseen, acceptance criteriaksi, taskeiksi tai lisätiedoiksi. Tiimiä pitää coachata myös siihen, että jos he näkevät kirjoitettuna jotain mistä he ovat eri mieltä, he sanovat sen. Olen huomannut, että ihmisten on helpompi osoittaa erimielisyytensä, jos he näkevät asiat kirjoitettuna – jos joku sanoo jotain, mistä olet eri mieltä, et välttämättä sano sitä ääneen. Mutta jos joku kirjoittaa sen ylös ikään kuin konkretisoiden sen hyväksytyksi asiaksi, ylittyy kipukynnys, ja avaat suusi. On pakko, koska muuten muut tekevät virheen.
Kannattaa siis dokumentoida keskustelu hyvin nopeasti tarinan kuvaukseen. Kannattaa sopia kuka tämän tekee – kannatan Scrum Masteria tai jotain kolmatta ihmistä. Haluaisin että Product Ownerin ei tarvitse käyttää ajatusvoimaa kirjoittamiseen vaan hän voi keskittyä kuunteluun ja ajatteluun.
3. Tarinoiden kuvaukset kuntoon
Tämä liittyy myös Sprint Planning -kokoukseen. Tiimin kannattaa sopia, milloin tarina on groomattu. Esimerkiksi: siinä on kuvaus, acceptance criteriat, effort estimate, taskejä, ja siitä on keskusteltu. Ja sitten seuraava sääntö pitää olla se, että mitään tarinaa, mikä ei ole groomattu, ei yksinkertaisesti ladata sprinttiin. Tässä kannattaa olla hyvin kurinalainen. Viime hetken tarinat voidaan hyvin groomata Sprint Planning -kokouksessa. Tavoitteena on että mitään, minkä valmistumisesta ei ole tietoa, ei aloiteta.
4. Acceptance criteriat
Kannattaa ajatella, että Grooming-kokouksessa listataan groomattaville asioille acceptance criteriat, mutta ei pyritä tässä 100% kattavuuteen. Oma mielipiteeni on, että acceptance criterioista kannattaa listata ainakin 80% groomingissa. Olen nähnyt, että tarinat elävät hyvin usein vielä implementaatiovaiheessa, ja siellä itseasiassa kovin usein keksitään parempia ratkaisuja, kun Grooming- tai Planning-vaiheessa. Työ on suuri opettaja. Kun asiaa rakentaa – keksii usein parempia ratkaisuja kuin silloin kuin sitä vain suunnittelee.
Tämä 80%-sääntö tosin tarkoittaa myös sitä, että Product Owner on valppaana juuri alkaneiden tarinoiden kanssa – tästä puhun myös kirjassani. Suosittelen tähän kehittämääni “Small discussions” -seremoniaa, joka toimii niin, että kun tarinaa on tehty 10% sen effort-pituudesta, pidetään lyhyt keskusteluhetki, jossa PO kyselee, että mitä kehittäjä on oppinut – onko joku hankalaa ja vaikuttaako joku osa tarinamäärittelystä vähän tyhmältä. Tavoitteena on keksiä vielä parempi ratkaisu. Olen nähnyt tämän lähestymistavan johtavan parempaan lopputulokseen niin monta kertaa, etten voi enää vaieta tästä salaisesta aseesta!
5. Valmistelu ennen groomingia
Jos ongelmana on tiimin suuri koko tai groomattavien asioiden määrä, on todella hyvä idea nakittaa groomattavien tarinoiden valmistelua laajemmalle porukalle. Tämä kannattaa tehdä niin, että muutamaa päivää ennen groomausta Product Owner jakaa groomattavia tarinoita tiimille, ja sitten joko yksittäin tai pienryhmissä (tämän saatte päättää itse) ihmiset miettivät mitä tarina tarkoittaa, mitkä sen acceptance criteerit on ja mitkä taskit, miten se toteutetaan, onko riskejä, entä refaktorointitarvetta…
Kun tämä on tehty, palataan yhteiseen palaveriin ja esitellään työn tulokset kaikille, ja sitten ei unohdeta sitä keskustelua! Tällä tavoin säästetään aikaa itse groomingista ja saadaan enemmän tarinoita groomattua.
6. Säännöllisyys
Groomaus kannattaa pitää aina samaan aikaan, saman pituisena ja joka viikko. Yleensä saattaa riittää tunti per viikko (tämä ei sisällä valmistelutöitä). Tästä kannattaa pitää kiinni. Tämä tunnin sijoitus lyhentää varmasti itse Sprint Planning -session pituutta ja parantaa tarinoiden ja toteutuksen laatua.
7. Testauksen huomioon ottaminen
Testaajat ja testattavuuden mietintä kannattaa muistaa ottaa huomioon jo groomingissa. Ei riitä, että testaajat tai osa heistä on kutsuttu mukaan, vaan pitää myös muistaa varmistaa, että he osallistuvat. Minun kokemukseni on, että osa testaajista ei halua aina avata suutaan. Eli jos tuntuu siltä, että testaus ei osallistu aktiivisesti, kokouksen vetäjän pitää huolehtia, että kaikista osallistujista saadaan mielipiteet ulos.
8. Tarinoiden pilkkomisen harjoittelu
Tiimeillähän pitää olla yläraja määriteltynä sille, miten isoja tarinoita otetaan työn alle. On tämä sitten 13, 15 tai 20 story pointia, sillä ei ole väliä. Mutta on tärkeää, että tiimi asettaa itselleen rajan, jonka se kokee olevan takuu, että tarinat, jotka ovat tätä rajaa pienempiä, voidaan erittäin todennäköisesti saada aina valmiiksi sprintissä hyvälaatuisina.
Nyt nimenomaan Grooming on se sessio, missä tätä rajaa pitää vahtia – jos joku tarina on isompi, se pitää pilkkoa. Pilkkominen on jonkin verran hankalaa ennen kuin siitä saa kunnon otteen. Eli pilkkomista kannattaa tietoisesti harjoitella. Pilkkomiseen löytyy netistä useita erilaisia ajatusmalleja, joita kannattaa kokeilla.
9. Effort estimaatit
Effortin estimoinnissa ei kannata jäädä jumiin numeroihin. Olennaista ei ole se, onko joku tarina 3 vai 4 story pointia. Olennaista on se, että useampi kuin yksi henkilö esittää mielipiteensä kirjoitetun kuvauksen ja acceptance criterioiden pohjalta – ja jos estimaatit eroavat olennaisesti, sitten asiasta keskustellaan. Keskustelu on paljon tärkeämpää kuin se numeroarvo.
Joskus suosittelemme jopa, että käytetään vain S, M ja L kolmitasoista luokittelua. Tätä voi tietenkin soveltaa myös story pointeihin käyttämällä vain kolmea sallittua arvoa, vaikkapa 1, 5 ja 13 story pointia. Kaikki tätä suuremmat splitataan, ja kaikki ykköstä pienemmät ovat ykkösiä.
Lopuksi muutama haaste
Tässä vielä muutama lisähaaste grooming sessioihin:
- miettikää tulevien sprinttien sprinttitavoitteita Groomingin lopuksi
- pysähtykää pariin otteeseen miettimään, puuttuuko backlogilta jotain
- siivotkaa muutama turha tarina roskakoppaan jokaisessa Grooming-kokouksessa
Näillä kolmella kikalla saatte pitkässä juoksussa siivottua turhia tarinoita pois, lisättyä ehkä puuttuvia juttuja mukaan ja ohjattua ajattelua tulevien sprinttien sisältöä draivaaviin asioihin.
Kuten huomasitte, on paljon asioita, mitä pitää miettiä, jotta Grooming-kokous onnistuisi hyvin. Hyvä Grooming on yksi toimivan Scrumin perusjuttuja. Toivottavasti näistä vinkeistä on apua teidän Grooming-sessioissa!
Lisätietoja
Tagit
Liiketoimintaprosessi
Tietohallinto |
Erikoisosaaminen
Ketterät menetelmät | |
Ohjelmistokehitys |
Toimialakokemus
IT |
Tarjonnan tyyppi
Konsultointi | |
Koulutus |
Omat tagit
scrum
Agile
Contribyte - Asiantuntijat ja yhteyshenkilöt
Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.
Contribyte - Muita referenssejä
Contribyte - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Laura - Ohjelmistokehittäjä
- Nordea - Senior Manual Test Engineer, Nordea Payments
- Nordea - Senior Test Automation Engineer with Python, Nordea Payments
- Nordea - Senior IT Analyst in SWIFT area
- Laura - C++ kehittäjä
- Nordea - Senior Backend Developer, Nordea Finance
- Laura - Palveluvastaava, tietohallinto
Premium-asiakkaiden viimeisimmät referenssit
- e21 Solutions Oy - Pakkausalan Benchmark-palvelu Mercamerilta
- Into-Digital Oy - S-Ryhmän rengasliiketoiminnan digitaalinen kauppapaikka
- Into-Digital Oy - Burger Kingin Whopperit, ravintolat, aukioloajat ja kampanjat verkossa
- Into-Digital Oy - Uusi Worldvision.fi viemään järjestön varainhankinta uudelle tasolle
- Netum Group Oyj - Radio- ja tv-museo Mastolassa opastaa kohta tekoälypohjainen asiakaspalvelija
- Netum Group Oyj - Peppi-järjestelmän ylläpito turvaa opiskelijoiden ja opettajien arjen sujuvuuden Lapin korkeakouluissa
- Into-Digital Oy - Suomalaisen työn uusi verkkopalvelu edistämään jäsenpalvelua ja -hankintaa
Tapahtumat & webinaarit
- 29.01.2025 - Modern toolchain and AI breakfast seminar with Eficode, AWS and HashiCorp
- 30.01.2025 - 30.1.2025 | Webinaari: Tehokkaampaa tuotantoa teollisuusyritykselle Fellowmindin Manufacturing Template -ratkaisulla
- 30.01.2025 - Suuri Rahoitusilta
- 30.01.2025 - Open Future
- 29.01.2025 - SecD-Day event
- 05.02.2025 - Smart Commerce Nordic 2025
- 05.02.2025 - AIX Forum - Medical Device Regulation and AI: Success Stories
Premium-asiakkaiden viimeisimmät bloggaukset
- Ready Solutions Oy - Mitä on Data Science tai datatiede?
- Ready Solutions Oy - Mikä on datatuote?
- Into-Digital Oy - Onnistunut verkkopalvelu – millainen se on ja miten niitä tehdään?
- Into-Digital Oy - Miksi verkkosivusto kannattaa uudistaa nyt, eikä sitten joskus?
- Netum Group Oyj - ”Jatkuva release-show ei tunnu kovin upealta” – tietojärjestelmäprojektin julkaisuprosessin kehittäminen
- Netum Group Oyj - Jälkitunnelmia ja -ajatuksia Kuntamarkkinoilta
- Into-Digital Oy - Oletko tekemässä B2B-verkkosivua? Huomioi ainakin nämä asiat
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |