"A key tenet of Agile estimating and planning is that we estimate size, but derive duration." - Mike Cohn, Agile Estimating and Planning
Despre estimări s-a discutat intens și se discută mult în continuare. Probabil tuturor ni s-a cerut la un moment dat să apreciem efortul necesar pentru o anumită activitate. Este în natura noastră să ne estimăm activitățile de zi cu zi, iar Scrum-ul nu face excepție.
Estimările reprezintă o parte importantă a acestui proces, fiindcă o mare parte a deciziilor luate la ședințele de planning se bazează pe acestea. Ar trebui să privim estimările ca un ajutor în a ne realiza un plan și în a ne măsura progresul în raport cu acest plan. Cu cât ne îndepărtăm mai mult de această idee, cu atât vom pierde încrederea stakeholderilor și a Product Ownerului, ceea ce este de nedorit.
Pentru cei familiarizați cu textele homerice sau cu tragedia greacă, legenda Casandrei, profeta menită să spună adevărul, prezintă cel mai bine "capcana" în care putem cădea dacă încercăm o abordare perfecționistă a estimărilor. Pe scurt, legenda povestește despre Casandra, care a primit darul profeției de la zeul Apollo, însă nu și darul persuasiunii; cu alte cuvinte, oricât de bine ar fi prevăzut viitorul, nimeni nu credea în profețiile Casandrei și în avertismentele ei. Deci, Scrum Teams, don't become like Casandra!
Pentru a evita astfel de situații, nu uitați că, atunci când ni se cere să estimăm, scopul urmărit este de a avea o marjă cât mai mică de eroare și de a fi cât mai previzibili în contextul Scrum. Estimarea este un instrument al ECHIPEI, iar tehnicile de estimare sunt bazate pe colaborare. Trebuie să includem întreaga echipă în acest proces de estimare a efortului pentru product backlog items.
Atenție mare, însă! Estimarea și angajamentul sunt două lucruri total diferite. Gândiți-vă, spre exemplu, la drumul către casă. Dacă ați fi întrebați la ce oră apreciați că ajungeți acasă într-o după-amiază și răspundeți, de pildă, cu ora 18:30, aceasta nu înseamnă că v-ați luat angajamentul ca la ora respectivă să ajungeți. Nu lăsați estimările să devină angajamente. Amintiți-vă întotdeauna să faceți distincție între cele două concepte.
Pentru început, doresc să prezint trei dintre cele mai folosite tehnici de estimare în Agile:
Planning Poker rămâne cea mai cunoscută și cea mai utilizată tehnică de estimare. Aceasta presupune folosirea de către participanți a unui set special de cărți, reprezentând numerele din șirul lui Fibonacci, pentru a vota estimările. Este recomandată pentru un număr mic de user stories și generează discuții în care fiecare membru al echipei trebuie să își argumenteze estimarea. Votul se repetă până când există unanimitate.
Adeseori, alegem șirul lui Fibonacci pentru a reflecta incertitudinea în estimarea elementelor mai mari, iar folosirea lui ne ajută să recunoaștem această incertitudine și să ajungem la o velocitate stabilă. Dar nu este obligatoriu să folosim valori numerice. Există situații în care utilizarea unor valori non-numerice poate ajuta echipele să estimeze mult mai exact. Pe de altă parte, o astfel de abordare poate duce și la apariția unor situații:
Nu putem aduna sau calcula story points (SP). Prin urmare, echipa nu poate spune concret managementului că va termina munca în 3 medium, 4 large și 2 small.
Dacă am întreba echipa cât de mare este un item și cât de mare este altul, vom obține probabil un răspuns inconsistent. Estimarea relativă se bazează pe reformularea acestei întrebări și cere echipei să compare cele două itemuri, adică să decidă cu cât este mai complex un item față de celălalt. Spre exemplu, un item cu o valoare de 2 story points trebuie să fie de două ori mai complex decât unul cu valoarea de 1 SP, iar unul cu o valoare de 3 SP va fi de trei ori mai complex decât unul cu valoarea de 1 SP.
Astfel, se pornește de la premisa că putem să comparăm itemurile între ele mult mai rapid și mai precis decât dacă le-am descompune și am analiza fiecare item în parte. Mai exact, în loc să împartă un story în taskuri (iar apoi să estimeze aceste taskuri), echipa compară efortul necesar pentru a realiza story-ul cu efortul depus anterior pentru un alt story pe care l-a estimat deja. Ideea este ca echipa să determine efortul necesar pentru a finaliza un story bazându-se pe trei factori: complexitate, repetiție și risc. În acest sens, putem avea un story care să nu presupună un număr mare de linii de cod, dar să presupună multă analiză sau putem avea un story care să necesite modificări semnificative la nivel de HTML pe mai multe tipuri și versiuni de browser. Deși nu este o muncă complexă, este una repetitivă, care poate duce la multe încercări și erori. Un alt scenariu poate fi integrarea unei componente noi, nemaifolosită anterior. Aceasta poate aduce cu sine numeroase riscuri, cu toate că munca propriu-zisă nu pare foarte complexă. Din acest motiv, sfătuim echipele să ia în calcul toți acești factori atunci când estimează relativ.
Ca un plus, această tehnică încurajează utilizarea estimărilor în alte unități de măsură decât timpul și, astfel, ne ajută să evităm confuzia dintre estimări și angajamente (estimation vs. commitment).
Recomandăm folosirea acestei tehnici pentru a estima un număr mare de user stories (unele articole o recomandă pentru mai mult de 25 de stories). Dacă trebuie să estimăm mai puține, putem utiliza cu succes tehnica Planning Poker.
Pentru estimările bazate pe afinitate, avem nevoie de un backlog ordonat, iar story-urile le grupăm în funcție de asemănări. Putem să creăm o coloană specială pentru story-urile care implică un anumit grad de necunoscut sau care nu respectă sintagma Definition of Ready. De obicei, echipa alege un story de referință, pe care îl plasează în coloana aferentă, iar în funcție de acesta, fiecare membru aranjează story-uri pe categorii sau mută story-urile pe cele deja clasificate. Această tehnică implică discuții și argumente pentru plasarea story-urilor în diferitele categorii existente.
Orice estimare are ca punct de plecare unitatea de măsură și definirea complexității itemului în story points. De-a lungul timpului s-a observat faptul că, în cadrul echipelor Scrum, încep să apară percepții greșite despre ce înseamnă o estimare în story points, lucru care duce la apariția următoarelor situații:
Beneficiul estimărilor ca unitate abstractă (dar semnificativă pentru echipă) se pierde atunci când apar tot felul de "calcule" precum: "un story point=opt ore" sau "un story point/om/zi".
Unele persoane devin mult prea prinse în cifre și uită că aceasta este doar o estimare și că poate avea o marjă de eroare.
Unele persoane devin foarte preocupate de a avea dreptate, pe când altele cedează voinței majorității fără să încerce să-și argumenteze poziția.
Toate acestea duc la o alterare a modului de a estima efortul într-o echipă Scrum și afectează velocitatea echipei. Pornind de la experiența mea ca Scrum Master, sfătuiesc echipele Scrum să nu uite de ce estimează. Atunci când ne estimăm efortul, secretul este să avem o înțelegere comună, pentru a lăsa pe un loc secund problematica cifrelor.
O mare parte a criticilor aduse story pointurilor se concentrează asupra faptului că însemnătatea lor diferă pentru fiecare membru al echipei. Acest lucru se observă foarte ușor în cadrul sesiunilor de estimări, iar cea mai bună cale pe care am găsit-o, a fost să ajut echipa să ajungă la o viziune comună asupra estimării efortului în SP pentru story-uri.
Totuși, un anumit număr de SP atribuite unui user story nu măsoară complexitatea unui feature; ceea ce trebuie să înțelegem este faptul că SP reprezintă o unitate de măsură a efortului necesar pentru dezvoltarea acelui feature. Din acest motiv, nu este obligatoriu să ne raportăm întotdeauna la cifre. Putem folosi valori non-numerice precum T-shirt size sau chiar gummy bears (culori). De asemenea, nu trebuie să uităm faptul că un SP reprezintă o unitate de măsură arbitrară folosită pentru a estima "dimensiunea" unui story raportat la alte user stories similare.
Un alt aspect al estimării în Agile este faptul că, în general, presupunem că persoana "potrivită" va face munca propriu-zisă. Dar realitatea ne arată că ocazional, o persoană "nepotrivită" pentru un task va munci la el, iar acest lucru va fi rareori atât de dramatic precum sună în acest exemplu. Așadar, SPs reprezintă efortul necesar pentru realizarea acelui story.
Echipe, ajustați estimările astfel încât să înglobeze riscurile și incertitudinea. Asta așteaptă și stakeholderii!
Împreună cu echipa în care sunt Scrum Master, am realizat un experiment care s-a dovedit a fi benefic și de succes. Tocmai pentru a evita situațiile în care ne raportăm prea mult la cifre, am decis cu toții să ne dezvoltăm un sistem propriu de estimări folosind valori non-numerice pentru SPs. Astfel, am luat niște etaloane legate de produsul nostru și le-am ordonat crescător. Le-am asociat valori din șirul lui Fibonacci, dar inițial, (timp de mai multe sprinturi), aceste valori au fost ascunse echipei. Doar Scrum Masterul avea această evidență pentru a putea cunoaște și calcula velocitatea echipei. Am folosit tehnica de estimare relativă pentru fiecare sesiune de grooming și am estimat/grupat storyurile în categoriile (ordonate) pe care le-am stabilit de la început. După scurt timp s-a observat o stabilizare a estimărilor acestei echipe. La momentul actual, valorile numerice echivalente etaloanelor non-numerice sunt cunoscute, însă acest fapt nu mai influențează modul de estimare al echipei, deoarece membrii acesteia și-au dezvoltat o înțelegere comună asupra efortului necesar pentru un story, încadrându-l în același etalon.
Tot legat de tehnicile de estimare, aș dori să vă împărtășesc impresiile pe care le-am adunat de la diferite echipe participante la un workshop despre estimări pe care l-am organizat:
Relative estimation: "Estimarea relativă pare să meargă cel mai bine."
"E mai ușor de estimat așa. Ne ajută să calculăm de câte ori e mai mare un story față de altul. Minimul și maximul sunt dificil de estimat. Per total, e o tehnică de estimare ușoară pentru grupuri."
Affinity estimation: "Merge mai lent, membrii echipei se contraziceau des."
"Seamănă a Waterfall și e mai greu de estimat așa. Este o estimare individuală, în care ești influențat de către ceilalți. E OK atunci când membrii echipei se cunosc bine."
Planning Poker: "Pare cumva mai ușor să ajungi la un consens cu această tehnică."
Relative estimation: "90% din timp ne-a luat să decidem dimensiunile. E foarte bine că există referințe. Ca tehnică, pare mai aproape de realitate și este mai precisă."
Affinity estimation: "Durează mult. Forțează fiecare individ să estimeze, e greu de trișat/eschivat de la asta, dar influența celorlalți se simte."
Planning Poker cu story-uri relative pare sa meargă.
Relative estimation: "În mod cert, a fost mult mai ușor decât cu alte tehnici. Faptul că are un punct de referință ajută foarte mult; cel mai greu e să găsești acea referință. Cel mai ușor este să lucrezi cu story-uri cât mai mici."
Affinity estimation: "E foarte greu pentru echipe care conțin persoane remote. Merge prea încet și influențează deciziile celorlalți. Nu e practică, mai ales pentru echipe mari. E mai interactivă decât Planning Poker, deoarece provoacă lumea la discuții."
Planning Poker: "E o tehnică familiară. Durează mai mult decât altele. Forțează echipa să discute."
Ca o concluzie, estimarea relativă a dat rezultate pozitive pentru echipa noastră, însă și celelalte tehnici de estimare au avantajele lor. Fiecare echipă e diferită, iar etalonul folosit de o anumită echipă poate să nu se potrivească alteia. Folosiți-vă de ședințele de retrospectivă pentru a analiza modul în care echipa își estimează efortul și pentru a alege tehnica cea mai potrivită pentru fiecare situație.
Analizați estimările din iterațiile trecute și răspundeți cinstit la întrebarea: "Cât de încrezători sunteți în aceste estimări?"