Perinteisesti scrumtiimi arvioi tulevalle sprintille tulevaa työmäärää jonkinasteisella estimointikäytännöllä.
Usein on käytössä planning pokerin ja t-shirt sizingin välimuoto, työmäärän arviointi storyn perusteella, mutta tässä on omat haittansa ja riskinsä.
Planning pokerin etu on sen demokraattisuudessa. Jokainen tiimin jäsen saa korttipakan ja voi esittää oman näkemyksensä taskin koosta. Planning pokerin haitta on siinä että se on kohtuullisen aikaa vievä toimenpide. Pokeriarviointi saattaa myös helposti johtaa ajatukset aikamääreisiin, pisteiden ollessa esim. tunteja tai päiviä mielessä. Aikamääreiden käyttämistä on vältettävä ja painotettava suhteellisten kokoarvioiden arvoa.
T-shirt sizing - menetelmän etu on arvojen abstraktiivisuudessa ja siinä ettei varsinaisia välineitä tarvita, voi esim. kirjoittaa kokolaput XS, S, M, L, XL. Suhteelliset kokoluokitukset muunnetaan sovittuun arvoon joiden avulla esim. velositeettia ja burndown charttia voidaan mitata ja seurata.
Jos estimointia ei tehdä, kuinka tiimi voi arvioida sprintin työmäärää? Miten tiimi voi sitoutua toimittamaan jotain aikaikkunan sisällä, jos työmäärä ei ole tiedossa?
Scrum itsessään ei sano mitään estimoinnista. Scrum sanoo, että jokainen item backlogilla on oltava jonkin kokoinen, mutta miten koko luokitellaan riippuu täysin tiimistä. On myös muistettava että scrumtiimi sitoutuu sprintin tavoitteeseen joka on arvon toimittaminen, ei arvioitujen pisteiden toimittaminen.
Estimoinnin puolesta on argumentteja:
- estimointi auttaa meitä ennustamaan milloin sprintin tavoite on saavutettu
- estimoinnit auttavat tiimin sidosryhmiä suunnittelemaan ennalta
- estimoinnit auttavat vähentämään riskiä epämääräisten työmäärien osalta
- sprintin tekemisiä voidaan uudelleenjärjestellä vaihtamalla samankokoisia taskeja. Jos ei ole estimointeja, ei voi tehdä vaihtoja
- estimoinnin tekeminen itsessään tuo arvoa. Kun keskustellaan vaatimusmääritteyiden yksityiskohdista, saavutetaan parempi ymmärrys siitä mitä tarvitaan
Ja estimointia vastaan on argumentteja:
- estimoinnit harvoin ovat tarkkoja. Kaikki mitä estimoinnissa tehdään, on asetetaan vääriä odotuksia
- käytännössä estimointi nähdään sitoutumisena, ei parhaana arvauksena.
- estimointi on aikaavievää ja pois toteuttamiseen käytettävästä ajasta
- vain todellisilla mittareilla on väliä, ei arvioilla. Agiliteetti vaatii metriikkaa, ja ainoa todellinen metriikka on se joka mittaa toimitusta
Vaatimusmäärittelyillä on tapana olla epämääräisiä, monimutkaisia ja toisiinsa kietoutuneita. Sitoutumalla sprintin tavoitteisiin ja toimittamalla merkittävää arvoa, tätä riskiä voidaan hallita.
Epävarmat ja sidonnaiset vaatimusmäärittelyt niputetaan sprinttiin ja hallitaan yhtenä joukkona. Kun tämä tehdään hyvin, on tiimillä selkeä sprintin tavoite ja asianmukainen backlogi. Kun tämä tehdään huonosti, on tiimillä epämääräinen sprintin tavoite, sotku toimeksiantoja jotka ei palvele tiimin tarkoitusta eikä tiimitasoista sitoutumista toimittamiseen.
Lean ja Kanban keskittyy yleensä perustekemiseen. Lean Kanban - toimitus koostuu pienistä ja toistuvista muutoksista, jotka eivät välttämättä liity mitenkään toisiinsa eikä niiden pitäisikään liittyä. Tällaisia ovat esim pienet kehitykset, bugikorjaukset ja ylläpitotehtävät.
Miten sitten voi ja kannattaa arvioida, jos halutaan arvioida?
Funktionaalinen, standardisoitu Cosmic-menetelmä tarjoaa esimerkiksi selkeän tavan suorastaan laskea storyn toteuttamiseen tarvittavaa työmäärää. Näin arvioitava koko mittaa toiminnallisuuden toteuttamista ja on täysin riippumaton tekniikasta ja tekijöistä, esim. koodaus/konfigurointi-tekemisessä.
Cosmicin mainittavia etuja on:
- helposti omaksuttava ja stabiili
- kustannustehokas
- parantaa estimoinnin tarkkuutta
- koon määrittäminen antaa paremman mahdollisuuden kontrolloida vaatimusmäärittelyjen laatua
Cosmicilla arvioidaan prosessia ja sen tapahtumia, esim:
toimeksianto tulee sisään -> toimeksianto kuitataan vastaanotetuksi
taskin tekeminen aloitetaan -> aloituspäivä kirjataan
Näistä kaikista summauksena voisi todeta, että jonkinlainen estimointi on tarpeen, mikäli tekemistä halutaan suunnitella ja toteuttaa se jonkin määritellyn aikaikkunan sisällä jollain määritellyillä resursseilla, tekemistä jota halutaan mitata ja seurata. Koon mittaaminen on estimoinnissa tärkeää, jos sen perusteella esim. mitataan ja seurataan ja esim. laskutetaan toimittajayhteistyössä.
Tällöin voi olla haasteellista lähteä tekemään estimointeja demokraattisen arvioinnin perusteella, ja on ehkä perusteltua ottaa käyttöön funktionaalisempi ja standardisoidumpi menetelmä.
Cosmic on standardi, mutta sekin on muokattavissa erilaisiin tarpeisiin. Esim. jos Cosmicin perustana on mitata prosessin tietokannan kirjauksia (entries & reads), voidaan konfigurointitaskeissa ajatella kirjaukset esim tietue-taulu - tasolla vaikkapa näin:
Story: Rakenna hinnoittelut x, y, z tuotteeseen A jota käyttää valikoima 1
Prosessi:
kirjaus x tauluun x = 1*1=1
kirjaus y tauluun y = 1*1=1
kirjaus z tauluun z = 1*1=1
kirjaus x,y,z tauluun A = 3*1=3
kirjaus A tauluun 1= 1*1=1
Storyn koko: 1+1+1+3+1= 7
Lähteitä:
http://www.cosmicon.com/portal/public/COSMIC%20Method%20v3.0.1%20Measurement%20Manual.pdf
http://agile.dzone.com/articles/large-scale-scrum-and-cosmic
http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/
http://agile.dzone.com/articles/agile-estimation-practice
http://www.slideshare.net/alimenkou/agile-estimation-techniques
http://scrummethodology.com/scrum-effort-estimation-and-story-points/
Usein on käytössä planning pokerin ja t-shirt sizingin välimuoto, työmäärän arviointi storyn perusteella, mutta tässä on omat haittansa ja riskinsä.
Planning pokerin etu on sen demokraattisuudessa. Jokainen tiimin jäsen saa korttipakan ja voi esittää oman näkemyksensä taskin koosta. Planning pokerin haitta on siinä että se on kohtuullisen aikaa vievä toimenpide. Pokeriarviointi saattaa myös helposti johtaa ajatukset aikamääreisiin, pisteiden ollessa esim. tunteja tai päiviä mielessä. Aikamääreiden käyttämistä on vältettävä ja painotettava suhteellisten kokoarvioiden arvoa.
T-shirt sizing - menetelmän etu on arvojen abstraktiivisuudessa ja siinä ettei varsinaisia välineitä tarvita, voi esim. kirjoittaa kokolaput XS, S, M, L, XL. Suhteelliset kokoluokitukset muunnetaan sovittuun arvoon joiden avulla esim. velositeettia ja burndown charttia voidaan mitata ja seurata.
Jos estimointia ei tehdä, kuinka tiimi voi arvioida sprintin työmäärää? Miten tiimi voi sitoutua toimittamaan jotain aikaikkunan sisällä, jos työmäärä ei ole tiedossa?
Scrum itsessään ei sano mitään estimoinnista. Scrum sanoo, että jokainen item backlogilla on oltava jonkin kokoinen, mutta miten koko luokitellaan riippuu täysin tiimistä. On myös muistettava että scrumtiimi sitoutuu sprintin tavoitteeseen joka on arvon toimittaminen, ei arvioitujen pisteiden toimittaminen.
Estimoinnin puolesta on argumentteja:
- estimointi auttaa meitä ennustamaan milloin sprintin tavoite on saavutettu
- estimoinnit auttavat tiimin sidosryhmiä suunnittelemaan ennalta
- estimoinnit auttavat vähentämään riskiä epämääräisten työmäärien osalta
- sprintin tekemisiä voidaan uudelleenjärjestellä vaihtamalla samankokoisia taskeja. Jos ei ole estimointeja, ei voi tehdä vaihtoja
- estimoinnin tekeminen itsessään tuo arvoa. Kun keskustellaan vaatimusmääritteyiden yksityiskohdista, saavutetaan parempi ymmärrys siitä mitä tarvitaan
Ja estimointia vastaan on argumentteja:
- estimoinnit harvoin ovat tarkkoja. Kaikki mitä estimoinnissa tehdään, on asetetaan vääriä odotuksia
- käytännössä estimointi nähdään sitoutumisena, ei parhaana arvauksena.
- estimointi on aikaavievää ja pois toteuttamiseen käytettävästä ajasta
- vain todellisilla mittareilla on väliä, ei arvioilla. Agiliteetti vaatii metriikkaa, ja ainoa todellinen metriikka on se joka mittaa toimitusta
Vaatimusmäärittelyillä on tapana olla epämääräisiä, monimutkaisia ja toisiinsa kietoutuneita. Sitoutumalla sprintin tavoitteisiin ja toimittamalla merkittävää arvoa, tätä riskiä voidaan hallita.
Epävarmat ja sidonnaiset vaatimusmäärittelyt niputetaan sprinttiin ja hallitaan yhtenä joukkona. Kun tämä tehdään hyvin, on tiimillä selkeä sprintin tavoite ja asianmukainen backlogi. Kun tämä tehdään huonosti, on tiimillä epämääräinen sprintin tavoite, sotku toimeksiantoja jotka ei palvele tiimin tarkoitusta eikä tiimitasoista sitoutumista toimittamiseen.
Lean ja Kanban keskittyy yleensä perustekemiseen. Lean Kanban - toimitus koostuu pienistä ja toistuvista muutoksista, jotka eivät välttämättä liity mitenkään toisiinsa eikä niiden pitäisikään liittyä. Tällaisia ovat esim pienet kehitykset, bugikorjaukset ja ylläpitotehtävät.
Miten sitten voi ja kannattaa arvioida, jos halutaan arvioida?
Funktionaalinen, standardisoitu Cosmic-menetelmä tarjoaa esimerkiksi selkeän tavan suorastaan laskea storyn toteuttamiseen tarvittavaa työmäärää. Näin arvioitava koko mittaa toiminnallisuuden toteuttamista ja on täysin riippumaton tekniikasta ja tekijöistä, esim. koodaus/konfigurointi-tekemisessä.
Cosmicin mainittavia etuja on:
- helposti omaksuttava ja stabiili
- kustannustehokas
- parantaa estimoinnin tarkkuutta
- koon määrittäminen antaa paremman mahdollisuuden kontrolloida vaatimusmäärittelyjen laatua
Cosmicilla arvioidaan prosessia ja sen tapahtumia, esim:
toimeksianto tulee sisään -> toimeksianto kuitataan vastaanotetuksi
taskin tekeminen aloitetaan -> aloituspäivä kirjataan
Näistä kaikista summauksena voisi todeta, että jonkinlainen estimointi on tarpeen, mikäli tekemistä halutaan suunnitella ja toteuttaa se jonkin määritellyn aikaikkunan sisällä jollain määritellyillä resursseilla, tekemistä jota halutaan mitata ja seurata. Koon mittaaminen on estimoinnissa tärkeää, jos sen perusteella esim. mitataan ja seurataan ja esim. laskutetaan toimittajayhteistyössä.
Tällöin voi olla haasteellista lähteä tekemään estimointeja demokraattisen arvioinnin perusteella, ja on ehkä perusteltua ottaa käyttöön funktionaalisempi ja standardisoidumpi menetelmä.
Cosmic on standardi, mutta sekin on muokattavissa erilaisiin tarpeisiin. Esim. jos Cosmicin perustana on mitata prosessin tietokannan kirjauksia (entries & reads), voidaan konfigurointitaskeissa ajatella kirjaukset esim tietue-taulu - tasolla vaikkapa näin:
Story: Rakenna hinnoittelut x, y, z tuotteeseen A jota käyttää valikoima 1
Prosessi:
kirjaus x tauluun x = 1*1=1
kirjaus y tauluun y = 1*1=1
kirjaus z tauluun z = 1*1=1
kirjaus x,y,z tauluun A = 3*1=3
kirjaus A tauluun 1= 1*1=1
Storyn koko: 1+1+1+3+1= 7
Lähteitä:
http://www.cosmicon.com/portal/public/COSMIC%20Method%20v3.0.1%20Measurement%20Manual.pdf
http://agile.dzone.com/articles/large-scale-scrum-and-cosmic
http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/
http://agile.dzone.com/articles/agile-estimation-practice
http://www.slideshare.net/alimenkou/agile-estimation-techniques
http://scrummethodology.com/scrum-effort-estimation-and-story-points/
