Vrnimo se danes na največ uporabljeno agilno metodo, Scrum in si razjasnimo ključne tri tehnike planiranja in kontroliranja dela. Hotel sem napisati »tehnike za obvladovanje časa«, a v večini virov poudarjajo, da se pri Scrumu ne obremenjujemo preveč s časom, da ga je težko planirati … in da je pomembneje, da so izdelki narejeni … a več o tem v nadaljevanju.

Torej, avtorji poudarjajo, da naj pri planiranju zahtevnost uresničevanja uporabniške zgodbe ne bi ocenjevali s potrebnimi urami (dnevi) za izvedbo, ampak s točkami, ki naj bi izražale kompleksnost zgodbe / naloge, pri tem pa priporočajo ocenjevanje po Fibonaccijevi lestvici (0,5, 1,2,3, 5, 8, 13, 21, 34…). Nekateri avtorji predlagajo zelo enostaven način – od izbranih zgodb sprinta tim izbere najmanj in najbolj zahtevno, ostale pa razporedi vmes (s postopkom medsebojne primerjave). Seveda se sprašujemo, ali je najbolj enostavna ocenjena z 0,5 ali 3 … in s koliko točkami naj bi ocenili najzahtevnejšo. Naslednje vprašanje je seštevek točk vseh teh nalog, ki naj bi ga izenačili s točkami, ki jih tim zmore doseči v sprintu.

Odgovor na prvo vprašanje sem našel v več virih: podjetje ima lahko pripravljeno tabelo, ki je timu v pomoč pri oceni. V tabeli so opisani dejavniki, ki vplivajo na kompleksnost naloge, kot so: obsežnost zgodbe / naloge, potreben vložen trud, morebitna tveganja, nepredvidljivost, odvisnost od drugih zgodb ali izvajalcev, število neznank, ipd. (glej primer na sliki).

Pomoč pri oceni točk zgodbe (povzeto po medium.com)

Ostaja pa vprašanje, koliko točk zmore tim v enem sprintu. Po navedbah avtorjev naj bi imel vsak tim svoj maksimalni zbir točk sprinta. Povsem razumljivo je, da je to odvisno od števila članov tima, a podjetja nimajo nekega standarda, kjer je zapisano, da naj bi vsak član tima zmogel npr. 12 točk na sprint. Moramo se zavedati, da so tudi člani tima različno učinkoviti, kar je odvisno od znanja, izkušenj, kreativnosti, motiviranosti, ipd. Ali kot pravi Czerniak (vir): točke niso merilo, ki opisuje učinkovitost razvijalcev in niso osnova za primerjavo učinkovitosti dveh različnih Scrum timov. Skratka, v prvem sprintu se vsota točk določi po občutku (po možnosti se uporabi učinkovitost članov tima iz prejšnjega projekta), potem pa se z vsakim zaključenim sprintom izkristalizira maksimalni zbir točk, ki jih zmore tim na tem projektu.

Zanimiva tehnika ocenjevanja zahtevnosti zgodb, ki bi jo bilo smiselno uporabiti tudi pri planiranju tradicionalnih projektov, pa je planski poker. Koristimo ga za natančnejšo oceno zahtevnosti izvedbe neke naloge (zgodbe), ne glede na to, ali jo ocenjujemo s potrebnim časom za izvedbo ali s točkami. Ključni pogoj za izvedbo pokra pa je, da imamo več članov tima iz iste stroke. Ko lastnik izdelka predstavi neko zahtevo (uporabniško zgodbo), vsak član pri sebi oceni zahtevnost, nakar v istem trenutku vsi sodelujoči (običajno s posebnimi kartami, lahko pa z listki, kamor napišejo točke) podajo svojo oceno. Tim potem ne vzame povprečja točk, ampak tista dva člana tima, ki sta napisala najnižjo in najvišjo oceno, ostalim pojasnita razloge za to. Z novimi spoznanji potem ponovijo ocenjevanje, po potrebi pa sledi še ena razlaga in še en krog glasovanja, v katerem pa naj bi bila ocena enotna, dosežena s konsenzom sodelujočih.

Po planiranju sledi izvedba nalog, ki se pri Scrumu meri s točkami opravljenih nalog (uresničenih zgodb). Običajno se to prikazuje v grafu, kateremu v angleškem jeziku rečejo »graf dogorevanja« (ang. burndown chart), v našem »poslovnem« jeziku pa bi ga bilo najbolje poimenovati »graf napredka ali napredovanja« projekta (sprinta). Z zaključkom prve naloge oz. uresničitvijo uporabniške zgodbe se od celotnega zbira točk sprinta odštejejo točke te zgodbe, na grafu pa prikaže preostanek točk. Ob zaključku naslednje se odšteje od preostanka, itd. … V grafu se torej prikazuje zbir točk nalog, ki jih je treba še dokončati v sprintu, ob primerjavi z linijo, ki povezuje maksimalno število točk ob začetku sprinta z 0 ob koncu, pa ugotavljamo napredek in ustrezno hitrost izvajanja nalog ter ocenjujemo raven verjetnosti, da bo tim do konca sprinta izvedel vse naloge.