Minulta on kysytty viime aikoina aika usein, että pitääkö bugit estimoida, kun niitä ladataan Scrumin sprinttibacklogiin. Olen vastannut, että en oikein tykkää siitä, että bugien korjaukseen kuluvaa aikaa yritetään ennalta arvata. Monet tiimit puolestaan eivät oikein tykkää ajatuksesta, että sprinttiin otetaan bugeja, joista ei sitten saada velocityä.

Ketsuppipulloefekti

Mitä lähempänä ollaan tuotteen releasointia, sitä enemmän vastaan tulee bugeja.

Bugeja tulee eri tahtiin eri projektin vaiheissa. Projektin tai tuotteen elinkaaren alkuvaiheessa bugeja tulee luonnollisesti vähemmän, ja mitä enemmän pystytään testaamaan end to end, ja mitä lähempänä ollaan tuotteen releasointia, sitä enemmän vastaan tulee bugeja. Myös bugien kiireellisyys vaihtelee. Lähempänä releasea fokusta saavat ne bugit, jotka täytyy korjata ennen releasointia.

It is story point – not bug point

Scrumissa olisi tarkoitus yrittää arvioida sprinttiin laitettavat tarinat. Mutta entä bugit? Jos tiimi tekee kahden viikon sprinteissä työtä, ja sprint planningissä valitaan bugit, jotka halutaan korjata seuraavan kahden viikon aikana, eikö bugeillekin pitäisi laittaa jokin korjauseffort-estimate? Siitähän saisi sitten velocityä. Varsinkin, jos ollaan sen verran lähellä releasea, että uusia tarinoita ei haluta aloittaa, tuntuu tylsältä valita sprintille vaan bugeja ja sitten saadaan velocityksi nolla.

On useita syitä, miksi bugien effortin arviointi voi johtaa ongelmiin. Monesti effortin voi kyllä arvioida, mutta vasta kun tarkka root cause on tiedossa. Root causen etsiminen saattaa monesti olla paljon suuritöisempää kuin varsinaisen korjauksen tekeminen, ja root causen etsimisen effort-arviointi taas voi olla täyttä arvailua.

Karvaa, älä arvaa

Entä jos tehdään vaan joku hattuarvaus? Riskinä on mielestäni tässä se, että se voi jo vaatia kehittäjän ”arvaamaan” mikä root cause voisi olla. Se voi taas johtaa siihen, että kehittäjä lähtee tekemään paikkoa ilman root causesta varmistumista. Tiimin olisi hyvä ajatella, että tehtäisiin hyvää laatua mahdollisimman vähällä bugimäärällä – ennaltaehkäistään vihulaista, eli karvataan!

Estimoi vaan isot remontit

Estimointi on vain arvaus.

Bugien effort-estimointia tulisikin tehdä vain silloin, kun voidaan tehdä ensin jonkinlainen tutkimus jokaiselle bugille, joka halutaan estimoida. On huomattava, että tällöin voidaan joutua myös luomaan tarina ”tutkimusspikelle” ja ladata se ensin johonkin sprinttiin. Alkaako tämä kuulostaa vähän vähemmän ketterältä? Estimointi on joka tapauksessa vain arvaus. Organisaation ei kannattaisi suhtautua estimaatteihin niin kuin ne olisivat totuus. Itse lähtisin Scrumin tapauksessa seuraavista lähtökohdista

• Sprinttiin valitaan korjattavaksi ne bugit, jotka pitää korjata (vakavimmat ja tärkeimmät)
• Bugeja ei yritetä estimoida, vaan ne valitaan sprinttiin vähän mutu-tuntumalla
• Tarinat valitaan sprinttiin vakavampien bugien jälkeen, ja ne estimoidaan.
• Jos joku bugi alkaa näyttää siltä että root cause on sellainen, että korjaus tulee kestämään tosi kauan ja vaatii ”uudelleenkoodaamista”, niin sitten tehdään refaktorointitarina, joka estimoidaan kuten muutkin tarinat.
• Jos saadaan kaikki sprinttiin valkatut bugit valmiiksi (ja tarinatkin) otetaan sitten sprinttiin lisää bugeja.

Seuraa paljonko vettä tulee veneeseen

Projektin kannattaisi seurata testikattavuutta ja bugimetriikkaa, eli bugien inflowta ja outflowta.

Bugien estimoinnin ja velocityn sijaan projektin kannattaisi seurata testikattavuutta ja bugimetriikkaa, eli bugien inflowta ja outflowta. Eli kuinka monta bugia viime viikolla löytyi, montako korjattiin, montako oli salestopper-bugeja, ja montako bugia vielä on löytymättä. Viimeistä voi koettaa arvata trendianalyysillä ja systeemitesticasejen ajonopeudella.

Jos paisti on uunissa, unohda sprintit

Harkinnan arvoinen ajatus voisi jollekin agileen jo tottuneelle tiimille olla, että pitäisikö vaihtaa Kanbaniin sitten, kun projektissa alkaa olla kypsennysvaihe, jossa uutta toiminnallisuutta toteuttavia tarinoita ei toteuteta niin paljon.

Lupasin jo aiemmissa bugiblogisarjassa, että se loppuu, eli lisäosia ei tule – mutta kyllähän tämäkin voisi olla osa bugiblogitrilogiaa, joka jo tätä ennen venähti neliosaiseksi! Ensimmäisessä osassa käsiteltiin bugien kuvausta, toisessa osassa bugien korjaamisen virtausnopeuden tärkeyttä. Kolmannessa osassa kuvasin hankalien bugien ratkaisua ”vyöryttämällä” ylivoimaisin voimavaroin ongelman ratkaisuun. Neljännessä osassa puolestaan käsiteltiin järjestelmällistä ongelmanratkaisua.

P.S. Haluatko pysyä perillä Contribyten uutisista sekä koulutuksista ja tapahtumista? Tilaa uutiskirjeemme!