Voiko vauhtia käyttää tehokkuuden mittarina?

Tiimin vauhti

Ketterässä kehityksessä käytetään useasti käsitettä vauhti (velocity) tulevaisuuden ennustamiseen. Mikä tämä vauhti on ja voisiko sitä käyttää tiimin tehokkuuden mittarina? Lyhyesti sanottuna vauhti on ennustamisen työkalu ei tehokkuuden mittari. Tästä syystä vauhtia voi käyttää ainoastaan tulevaisuuden ennustamiseen eikä sitä voi käyttää kuvaamaan tehokkuutta millään asteella. Miksikö sitten? Jos kerran vauhti hidastuu niin eikös se ole paha asia?

Oleellista on ymmärtää ensin miten tiimin vauhti määräytyy. Ensimmäinen kysymys on tietysti, että mikä on vauhdin yksikkö? Onko se tuntia, päivää tai kenties ideaalipäivää? Vastaus on, että ei mitään näistä. Vauhdin yksikköä kutsutaan monesti tarinapisteeksi (story point), mutta yksinkertaisesti kyseessä on tiimin kehittäjien hihasta heittämä vertailuluku, joka kertoo minkä kokoisia vaatimukset ovat suhteessa toisiinsa.

Suunniteltu ja toteutunut vauhti

Sprintin suunnittelussa tiimi valitsee työjonosta toteutettavakseen vaatimuksia. Tiimi päättää täysin itsenäisesti paljonko se kykenee seuraavan kahden viikon aikana toteuttamaan. Tämän arvauksen pohjalta saadaan suunniteltu vauhti, eli paljonko tiimi arvioi kykenevänsä toteuttamaan seuraavan sprintin aikana. Valittaessa vaatimuksia työjonosta ei valittavien vaatimusten määrää perusteta aikaisempien sprinttien vauhtiin vaan kyseessä on aina uusi arvio sen hetkisen parhaan mahdollisen tiedon pohjalta. Monesti suunniteltu vauhti on hyvin lähellä laskennallista vauhtia.

Tiimin toteutunut vauhti määräytyy sen perusteella kuinka paljon vaatimuksia on saatu toteutettua valmiiksi asti. Valmiit ominaisuudet ovat oikeasti valmiita ja testattuja, sellaisia jotka voisi viedä tuotantoon vaikka heti. Toteutunut vauhti voi heitellä monista eri syistä. Näitä voivat olla esimerkiksi ulkoiset riippuvuudet, laatuvelka, sairastumiset tai toteutumisvaiheessa havaittu vaatimuksen mutkistuminen tai yksinkertaistuminen.

Ulkoiset riippuvuudet

Ulkoinen riippuvuus voi olla esimerkiksi kolmannen osapuolen järjestelmä, jota vasten ei päästä testaamaan heti. Tämä voi johtua esimerkiksi siitä, että järjestelmän toimittaja ei kykene tarjoamaan tarvittavaan testiympäristöä tai oikeuksia kahden viikon sprintin aikana. Tällöin vaatimus jää työjonoon auki, eikä sen pisteitä lueta mukaan tiimin vauhtiin. Kun testaamiseen tarvittavat ympäristöt ja oikeudet sitten lopulta saadaan kirjautuvat valmiit tarinapisteet siihen sprinttiin, jossa tarina lopulta saatiin valmiiksi. Toinen vaihtoehto on myös uudelleen arvioida seuraavan sprintin suunnittelussa jäljellä olevat pisteet vaatimuksista joita ei saatu valmiiksi. Tällöin pisteitä ”katoaa” koska osa työstä on jo tehty, mutta  seuraavassa sprintissä vauhtiin lasketaan vain jäljellä olleet pisteet.

Laatuvelka

Toinen yleinen tapaus joka aiheuttaa vauhdin laskemista väliaikaisesti on teknisen velan kertyminen. Ketterässä kehityksessä lähdetään siitä, että bugit korjataan välittömästi, eikä niitä jätetä työjonoon priorisoitavaksi. On kuitenkin melko yleistä varsinkin uudella tiimillä, että kaikki sprintiin otetut vaatimukset pyritään saamaan valmiiksi hinnalla millä hyvänsä. Saadakseen asiat nopeammin valmiiksi tiimi tinkii yleensä huomaamattaan laadusta, jolloin työjonoon kertyy bugeja eli tekemätöntä työtä. Tekemättömälle työlle ei koskaan anneta työmääräarviota, koska se pitää tehdä välittömästi pois alta, jotta se ei ala kertymään. Tällöin voi käydä esimerkiksi niin, että seuraavaan sprinttiin tulee valtava määrä bugeja edellisestä sprintistä ja näiden korjaaminen on pois uusien vaatimusten toteuttamiselta. Keskimäärin näiden kahden sprintin vauhti antaa siis kelvollisen ennusteen siitä paljonko tiimi saa aikaan suuressa määrässä tulevia sprinttejä.

Vaatimuksen mutkistuminen tai yksinkertaistuminen

Työmäärä arviointiin pyritään käyttämään kohtuullisen vähän aikaa, koska siihen käytetty aika on pois vaatimusten toteuttamiselta. Tästä syystä melko useastikkin käy niin, että yksinkertaiselta näyttänyt vaatimus mutkistuu huomattavasti kun sitä aletaan toteuttamaan. Tämä on erityisen yleistä  kun siirrytään uuteen vähän tuntemattomaan kokonaisuuteen. Tällöin vauhti putoaa verrattuna suunniteltuun kun asiat osoittautuvat monimutkaisemmiksi kun miltä ne ovat näyttäneet. Tämä kuitenkin tasoittuu seuraavissa sprinteissä kun tiimi oppii miten uuden kokonaisuuden kanssa tulee toimia ja uudelleen pisteyttää vaatimuksia uuden parhaan mahdollisen tietonsa pohjalta.

Voisiko vauhtia käyttää tehokkuuden mittarina?

Kiusaus käyttää vauhtia tehokkuuden mittarina on yleensä varsin suuri johtajilla, jotka eivät ymmärrä mikä vauhti on ja mitkä ovat sen rajoitteet. Vauhtia ei yksinkertaisesti voi käyttää tehokkuuden mittarina, koska se on itsestään mukautuva. Itsestään mukautuva tarkoittaa sitä, että jos tiimin tehokkuus kasvaa kun tiimi oppii alkaa se myös arvioimaan vaatimukset pienempinä. Tästä syystä äkillinen tehokkuuden kasvu saattaa näkyä toteutuneessa vauhdissa piikkinä, mutta tasoittuu nopeasti pois kun jäljellä olevat vaatimukset  uudelleen pisteytetään uuden tiedon valossa. Tällöin se mikä aikaisemmin oli kahdeksan saattaa nyt olla kolme verrattuna muihin vaatimuksiin. Lopputuloksena vauhti tasoittuu taas takaisin lähelle pitkäaikaista keskiarvoaan.

Voisiko vauhtia käyttää tulospalkkauksen perusteena?

Jos vauhdista itsestään tekee tavoitteen esimerkiksi tekemällä siitä osan tulospalkkausta ampuu helposti itseään jalkaan. Koska tiimi määrittää itse pisteet ja paljonko se kykenee sprintissä toteuttamaan, voi se kertoa ääritilanteessa kaikki pisteet vaikkapa kymmenellä. Tällöin pisteet ovat edelleen vertailukelpoisia keskenään, mutta ne ovat kärsineet vakavasti inflaatiosta. Lisäksi jos vauhdin asettaa tavoitteeksi kannustaa se tiimiä ottamaan laatuvelkaa ja toivomaan, että se ei ehdi alkaa näkyä projektin aikana.

Mihin vauhtia voi sitten käyttää?

Vauhti on itsestään mukautuvuutensa ansiosta aivan loistava työkalu tulevaisuuden ennustamiseen. Käyttämällä sprinttien vauhdin keskiarvoa ennusteena siitä paljonko tiimi saa tehtyä vaikkapa seuraavan viiden sprintin aikana on varsin hyvä arvio. Koska vauhti saattaa heitellä paljonkin yksittäisten sprinttien välillä ei sitä voi käyttää kuin suuntaa antavasti seuraavan sprintin sisällön arvioimiseen. Viiden sprintin keskiarvo on kuitenkin heilahteluista huolimatta luultavasti hyvin lähellä historiallista keskiarvoa. Excel velhot voivat vauhtihistoriaa hyväksikäyttäen laskea melko hyvätkin tilastolliset ennusteet siitä millä todennäköisyydellä yhden sprintin suunniteltu laajuus saadaan toteutettua tai mitkä ovat todennäköisyydet viiden seuraavan sprintin tapauksessa.

Tulevaisuuden ennustamisessa melko yleinen keino on myös käyttää laskennallista vauhtia, joka ottaa huomioon arkipyhistä johtuvat työpäivien vaihtelut sprinteissä ja yksittäisten kehittäjien lomat. Laskennallisen vauhdin laskemisessa käytetään vauhtikerrointa (focus factor), joka on laskennallinen kerroin joka ottaa huomioon työpäivät ja tunnetut lomat. Kun vauhtikertoimella kertoo vauhdin keskiarvon saa vielä aavistuksen parempia ennusteita.

Esimerkki todelliselta tiimiltä

Tiimin vauhti merkinnöillä

Yllä oleva kuva on todellisen tiimin vauhtikuvaaja. Tiimi oli tässä vaiheessa työskennellyt vähän yli vuoden yhdessä ja kaikki sprintit olivat olleet kahden viikon mittaisia. Harmaa palkki kertoo tiimin sprintin suunnittelussa suunnitteleman laajuuden. Keltainen palkki kertoo toteutuneen vauhdin. Harmaa alue ilmaisee laskennallisen vauhdin ja sininen viiva kertoo tiimityytyväisyydestä.

Kohdassa 1 nähdään kun tiimi aloitti ja luonnollisestikkaan sillä ei ollut vielä mitään käsitystä siitä mitä se saa aikaan sprintissä. Tämän jälkeen nähdää kuitenkin heti, että jo sprintissä 2 vauhti asettui aika lähelle sen tulevaa keskiarvoa. Kohdassa 2 nähdään uuden tiimin yritys ottaa laatuvelkaa. Kohdassa 3 tiimi vaihtoi uuteen kokonaisuuteen, jolloin vaatimukset osoittautuivat monimutkaisemmiksi kuin oli etukäteen odotettu. Kohdassa 4 nähdään kuinka laskennallinen vauhti reagoi kesälomiin.

Kohdassa 5 voidaan nähdä, että suunniteltu vauhti kurottaa sprintistä 22 eteenpäin aina korkeammalle kuin toteutunut. On varsin tavallista, että vauhdin pudotuksen jälkeen tiimi yliarvio oman toteuttamiskykynsä. Lisäksi nähdään, että toteutunut vauhti on välillä yli laskennallisen ja välillä alle. Tämän ei sinänsä pitäisi olla mitenkään tavatonta kun ottaa huomioon, että laskennallinen perustuu määritelmän mukaan toteutuneen vauhdin keskiarvolle.

Yksi kommentti artikkeliin ”Voiko vauhtia käyttää tehokkuuden mittarina?

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s