Scrum a ako ho zaviesť – kompletný návod

Počuli ste už o Scrume [skrame]? To je tá “vec”, ktorá by vám mala pomôcť manažovať vaše projekty a rýchlo priniesť hodnotu. A to by malo byť to, čo chcete dosiahnuť, pretože:

1. Podnikateľské prostredie sa mení čoraz rýchlejšie.

Nové trhy, noví zákazníci, nové požiadavky. Ak sa chcete udržať v hre, potrebujete reagovať rýchlo a ponúkať vašim zákazníkom tie najlepšie produkty, ktoré budú riešiť ich problémy.

2. Projektový manažment je čoraz náročnejší.

Nemôžete si dovoliť stráviť priveľa času analýzou, plánovaním a vytváraním produktu, po ktorom vaší zákazníci túžia. Ak to bude trvať pridlho, zákazníci ho už nebudú chcieť.

Ak teraz zvažujete alebo ste už aj rozhodnutí používať Scrum, pravdepodobne sa pýtate 4 otázky:

1. Čo presne je Scrum?
2. Je Scrum vhodný pre mňa/môj tím/moju organizáciu?
3. Čo potrebujem, než začnem používať Scrum?
4. Ako mám vlastne používať Scrum?

Dobrou správou je, že tomto článku ich všetky zodpovieme.

#1 Čo je Scrum?

Podľa Príručky Scrumu (dostupná aj v slovenčine), ktorú napísali autori Scrumu Jeff Sutherland a Ken Schwaber, je definícia nasledovná:

Scrum je rámec v ktorom je možné riešiť komplexné adaptívne problémy, a súčasne produktívne a kreatívne vytvárať produkty s najvyššou možnou hodnotou.

Ak sa opäť pozriete na horeuvedené dva body o podnikateľskom prostredí a projektovom manažmente, uvidíte, že definícia Scrumu na nich perfektne sedí.

Príručka Scrumu taktiež hovorí:

Scrum nie je proces, technika alebo jasná metóda. Je to rámec, ktorý vám umožňuje použiť rôzne procesy a techniky.

Tento rámec rozoberieme hlbšie v časti #4, ale už teraz môžeme povedať, že hoci Scrum pomáha riešiť vaše problémy, neexistuje podrobný návod, ktorý vám krok po kroku povie, čo presne by ste mali robiť.

Na jednej strane je to fajn, pretože každá organizácia je iná a neexistuje proces, ktorý by rovnako dobre fungoval pre všetkých.

Na druhej strane, ak vo vašej organizácii práve začínate so zavádzaním Scrumu, môže byť náročné nájsť ten správny proces a radšej by ste mali k dispozícii konkrétne príklady a inštrukcie. Tomu sa budeme venovať v časti #4.

Scrum vs. agilný

Scrum je často označovaný ako agilná metóda. Niekedy sa dokonca pojmy Scrum a agilný zamieňajú. Pojem agilný sa ale v definícii Scrumu nespomína… Poďme vyriešiť ten zmätok.

Čo je agilný projektový manažment?

Je to taký spôsob projektového manažmentu, pri ktorom sa produkt dodáva postupne počas celého trvania projektu. Postupné pridávanie nových vlastností umožňuje tímu reagovať na zmeny a prispôsobiť sa im.

Aký je rozdiel medzi agilným prístupom a Scrumom?

Je niekoľko agilných rámcov (angl. framework) a Scrum je jeden z nich. To znamená, že Scrum je agilný, ale agilný nerovná sa (len) Scrum (napr. Kanban je taktiež agilným rámcom).

#2 Je Scrum vhodný pre vašu organizáciu/tím?

Kedy použiť Scrum?

Keď vyvíjate alebo manažujete komplexné projekty.

Komplexné projekty majú v sebe vždy nejakú úroveň neurčitosti. Neurčitosť znamená, že pred začiatkom projektu nemáte k dispozícii všetky informácie. Možné príklady:

• Dlhodobá marketingová kampaň.

Určite je potrebné začať s približným plánom. Ten ale budete upravovať na základe priebežných výsledkov.

• Stavba domu.

Nie je možné sľúbiť, že dom postavíte presne za X dní. Možno pri budovaní základov narazíte na archeologické vykopávky. Alebo bude veľa pršať. Alebo sa investor rozhodne, že chce inú farbu omietky – po tom, čo uvidí tú aktuálnu.

• Vývoj novej aplikácie.

Môžete naraziť na technické problémy. Alebo zákazník uprostred vývoja zistí, že vlastne chcel niečo iné. Alebo sa mu bude aplikácia tak páčiť, že do nej bude chcieť pridať ďalšie funkcie.

Ak vo vašom projekte nie je žiadna neurčitosť, Scrum nepotrebujete. Vystačíte si s klasickými metódami projektového manažmentu a naplánujete celý projekt ešte pred jeho štartom. V súčasnom svete je ale čoraz menej pravdepodobné, že projekt nebude mať v sebe žiadnu neurčitosť.

Na čo sa Scrum môže použiť?

Na takmer každý druh projektu.

Ak si do vyhľadávača zadáte Scrum, s veľkou pravdepodobnosťou narazíte na aspoň jeden článok o použití Scrum na vývoj softvéru. Programátori sa rýchlo chopili Scrumu, pretože to videli už veľakrát: zákazník vyskúša dodaný hotový softvér a zistí, že to nie je to, čo vlastne chcel.

Samozrejme to ale neznamená, že Scrum sa dá použiť iba na vývoj softvéru!

(Vedeli ste, že všadeprítomný suchý zips prerazil najprv ako praktická pomôcka vyhradená pre astronautov?)

Autori Príručky Scrumu videli použitie Scrumu na rôznych miestach:

• v školách,
• na úradoch,
• v marketingu,
• v riadení organizácií,

… a na manažovanie “takmer všetkého, čo používame v bežnom živote, ako jednotlivci aj ako spoločnosť.”

Teraz, keď už viete, že Scrum je aj pre vás, možno sa pýtate:

#3 Čo potrebujete, aby ste mohli používať Scrum?

Mali by ste byť pripravení veľa komunikovať.

Príručka Scrumu hovorí, že “základom Scrumu je malý tím ľudí.”

Scrum robia ľudia pre ľudí, takže s nimi určite budete musieť komunikovať, aby ste:

1. Získali súhlas a podporu zúčastnených strán (stakeholderov).
2. Vybudovali váš Scrum tím.
3. Dohodli sa, čo znamená hotový (tzv. definícia hotového).

Získajte súhlas a podporu stakeholderov

Kto sú stakeholderi?

Za stakeholdera [stejkholdera] (možno voľne preložiť ako “zúčastnenú stranu”) sa v Scrume považuje “každá osoba mimo Scrum tím, ktorá má záujem o produkt a znalosť produktu potrebnú na postupné objavovanie” [Scrum Glossary].

V závislosti na štruktúre vašej organizácie, stakeholderi môžu byť:

• váš priamy nadriadený alebo manažér,
• iní manažéri alebo vedúci,
• zákazníci/používatelia.

Veľké organizácie majú iné štruktúry a procesy než menšie firmy s jedným alebo zopár tímami. Váš prístup a komunikáciu so zúčastnenými stranami musíte prispôsobiť vašej organizácii.

Uvedieme základné myšlienky, pre ktoré potrebujete získať podporu, a tiež odpovede na najčastejšie otázky a obavy od stakeholderov.

Prečo potrebujem súhlas stakeholderov?

Pretože keď začnete používať Scrum, vaše výstupy sa môžu zmeniť:

1. Budete produkovať časté a malé prírastky k produktu.
2. Budete od nich chcieť spätnú na tieto prírastky.
3. Budete dávať odhady (nie presné termíny vytesané do kameňa), kedy budú dodané nové vlastnosti.

To môže (a zrejme aj bude) od stakeholderov vyžadovať zmenu aj v ich chovaní a očakávaniach, takže to bez ich súhlasu nepôjde.

Možno boli zvyknutí, že diskusia o požiadavkách prebiehala len na začiatku a potom už dostali len hotový produkt.

Teraz sa budú musieť aktívne a často zapájať do vývoja produktu.

Na to potrebujete ich súhlas.

Možno boli zvyknutí, že hneď po dokončení úvodnej špecifikácie dostali presný dátum dodania.

Teraz budú musieť akceptovať, že 1) špecifikácia sa vyvíja spolu s produktom a 2) namiesto jedného dátumu dodania dostanú odhady a časté nové prírastky.

Na to potrebujete ich súhlas.

V súhlase zúčastnených strán je skrytá aj dôvera. Stakeholderi potrebujú mať dôveru vo váš tím, v jeho schopnosti a v to, že je schopný dodať finálny produkt. Bez dôvery nie je súhlas úplný.

Uistite sa už na začiatku, že máte dôveru!

Ako získam súhlas stakeholderov?

Vysvetľovaním, že získajú lepšie výsledky (a všetci budú nakoniec spokojní).

Keď im poviete, že by sa mali aktívne zúčastňovať na vývoji produktu, možno sa budú obávať, že im len pridáte ďalšiu položku do ich plných kalendárov,

Vysvetlite im, že ich znalosti a spätná väzba sú neoceniteľné na to, aby ste:

1. Dodali hodnotný produkt – a aby zákazníci boli spokojní.
2. Nedodali zbytočné alebo neužitočné vlastnosti – a zbytočne tak nemíňali čas a peniaze (čo tiež poteší zákazníkov).

Keď im poviete, že pred začiatkom práce nevytvoríte presnú a nemennú špecifikáciu, možno sa budú obávať, že nedostanú to, čo chcú.

Vysvetlite im, že do žijúcej špecifikácie budete môcť začleniť ich spätnú väzbu. To znamená, že je oveľa väčšia šanca, že dostanú to, čo chcú. Budú mať lepší prehľad o tom, na čom sa pracuje, a budú môcť navrhnúť zmeny, keď uvidia jednotlivé prírastky. 

Ak máte k dispozícii príklad už ukončeného projektu, kde úvodná špecifikácia nepokryla všetko a projekt vyžadoval neplánovanú prácu navyše, určite ho použite.

Keď im poviete, že nedostanú presný dátum dodanie, možno začnú rovno panikáriť.

Vysvetlite im, že budete dodávať odhady, ktoré budete priebežne spresňovať podľa toho, aké nové informácie sa vynoria počas práce na projekte.

Termíny sa často určia a nedododržia, sklz býva v týždňoch i mesiacoch.

Stalo sa to na nejakom minulom projekte? Vysvetlite, že namiesto konkrétnych a neistých dátumov dodáte širšie, no realistické odhady. Nemá zmysel pracovať s termínom, ktorý sa nedá dodržať (a každý to už dávno vie).

Nezabudnite tiež, že absencia špecifického a detailného zadania nie je dôvodom na anarchiu a na to, aby si tím robil, čo chce. 

Vždy potrebujete mať víziu vo forme používateľských scenárov a odpovedí na otázky:

Prečo to potrebujeme? Čo tým chceme dosiahnuť?

Nepotrebujeme diktát, ako to má vyzerať.

Príkladom môže byť “Scrum verzia” slávneho citátu od Henryho Forda:

Špecifikácia (nie-Scrum spôsob): Kôň, ktorý je rýchlejší ako iné kone.

Používateľský scenár (Scrum spôsob): Potrebujem sa dostať z Bostonu do New Yorku za 4 hodiny.

Výsledok práce Scrum tímu: Tu je vaše nové auto.

Vybudujte Scrum tím

Možno vám napadlo, že najjednoduchším spôsobom, ako vybudovať Scrum tím, by bolo zobrať váš súčasný tím a dať mu nálepku “Scrum tím”. Scrum tím ale musí spĺňať viac požiadaviek než iba to, aby to bola nejaká skupina ľudí. Samozrejme, aj váš súčasný tím sa môže stať Scrum tímom, ale vyžaduje to viac práce a úsilia než len onálepkovať ľudí.

Aké sú schopnosti Scrum tímu?

Príručka Scrumu hovorí, že “Scrum tímy sú samoorganizujúce a interdisciplinárne”.

Taktiež vysvetľuje, čo sa myslí pod pojmami samoorganizujúci a interdisciplinárny.

Samoorganizujúce tímy si sami vyberú spôsob, ako najlepšie vykonať svoju prácu, namiesto toho, aby to určil niekto zvonku tímu.

Z toho vyplývajú dve dôležité veci:

1. Členovia tímu musia dostať zodpovednosť a dôveru. Mikromanažment je zakázaný.
2. Členovia tímu musia prebrať zodpovednosť za ich prácu. Nemôžu veci robiť len vtedy, keď im to niekto prikáže. Nemôžu ignorovať problémy len preto, že im nikto nepovedal, aby ich neignorovali.

Buďme úprimní: v niektorých organizáciách môže táto myšlienka pôsobiť až radikálne. Na druhej strane, zmene sa nedá vyhnúť. Ako sme spomenuli v úvode, prostredie sa mení rýchlejšie než kedykoľvek predtým. Aby organizácie mohli adekvátne reagovať, musia sa tiež zmeniť.

Expert na riadenie zmien John Kotter uvádza vo svojom bestselleri Náš ľadovec sa roztápa zoznam kritických krokov vo vedení zmeny. Medzi tieto kroky patrí aj “uvoľnenie bariér, ktoré zabraňujú ľuďom konať”, a jednou z týchto bariér sú “neefektívne procesy a hierarchie”.

Interdisciplinárne tímy majú všetky schopnosti na vykonanie svojej práce bez toho, aby záviseli na niekom mimo tímu.

Je jasné, že ak je cieľom postaviť dom, v tíme musí byť murár. 

Inokedy to ale nie je také jednoznačné, hlavne vtedy, ak produkt nie je fyzická vec.

Ak má tím spustiť kampaň na sociálnych sieťach, nemôže sa stať, že by grafický dizajnér tímu povedal, že musí najprv dokončiť iný projekt a až potom dodá obrázky a infografiky. Takto by tím nebol sebestačný – závisel by na niekom (dizajnérovi), kto nie je súčasťou tímu.

Scrum tím pracuje v cykloch – šprintoch. Šprint je časový rámec, najčastejšie 1-4 týždne, počas ktorého sa na produkte vyrobí nový prírastok. Dĺžka šprintu je pre jeden tím vždy rovnaká, ale rôzne tímy môžu preferovať rôznu dĺžku. O organizácii šprintu budeme detailnejšie hovoriť v časti #4.

Aké roly sú v Scrum tíme?

Scrum tím sa skladá z:

• Product Ownera
• Development tímu
• Scrum Mastera

Product Owner

(Možné preložiť ako “Produktový vlastník”, kde sa “vlastniť” používa vo význame “mať niečo na starosť” – ďalej v článku sa prikloníme k pôvodnému anglickému termínu.)

Podľa Príručky Scrumu:

Product Owner [prodakt ouner] je zodpovedný za maximalizáciu hodnoty produktu, ktorý je výsledkom práce Development tímu. To, ako to dosiahne, sa môže v rôznych organizáciách, Scrum tímoch a u jednotlivcov líšiť.

Product Owner je, čo sa týka špecifikácie produktu (reprezentovanej Produktovým backlogom [beklogom]), medzičlánkom medzi Development tímom a vonkajším svetom (reprezentovaným stakeholdermi).

Stakeholderi môžu mať rôzne názory alebo požiadavky na produkt. Úlohou Product Ownera je podporovať ich komunikáciu a na jej základe robiť rozhodnutia. Product Owner je jediný zodpovedný za spravovanie Produktového Backlogu:

Product Owner je jedna osoba, nie komisia. Product Owner môže v Produktovom Backlogu reprezentovať priania nejakej komisie, ale ak chce niekto zmeniť prioritu položky Produktového Backlogu, musí sa obrátiť na Product Ownera.

Čo by teda mal mať a zvládať dobrý Product Owner?

• Komunikačné schopnosti – Product Owner musí aktívne komunikovať s Development tímom a stakeholdermi o Produktovom Backlogu.
• Rozhodnosť – Product Owner musí spracovať všetky žiadosti na pridanie/odobratie/zmenu položiek v Produktovom Backlogu a rozhodnúť, ktorým z nich vyhovie.
• Transparentnosť – všetky rozhodnutia o Produktovom Backlogu musia byť viditeľné, aby každý videl, na čom sa bude v blízkej dobe pracovať.
• Dôvera a empatia – Product Owner musí veriť odbornosti a schopnostiam Development tímu aj stakeholderov a brať ich do úvahy pri rozhodovaní.

Typický scenár môže vyzerať nasledovne:

Stakeholder požiada o pridanie novej položky do Produktového Backlogu. 

Product Owner ju analyzuje: Prináša hodnotu? Ako ovplyvní už existujúce položky? Aké sú dôsledky do budúcnosti? Čo všetko bude treba zmeniť?

Potom Product Owner prediskutuje položku s Development tímom. Tím zhodnotí, že ide o zložitú vlastnosť, práca na ktorej by trvala pomerne dlho, ale navrhne zmenu, ktorá prinesie podobný efekt, no dá sa dokončiť rýchlejšie.

Product Owner sa obráti na stakeholderov: Akceptovali by navrhovanú zmenu? Je kompromis s kratším časom vývoja výhodný? Ak áno, Product Owner pridá položku do Produktového Backlogu.

Ale môže sa stať, že stakeholderi majú ďalšie nápady a navrhnú iný kompromis. Product Owner to znovu analyzuje a cyklus sa opakuje…

Development tím

(Možné preložiť ako “vývojový tím”, kde sa pod termínom “vývoj” (angl. development) myslí práca na produkte všeobecne).

Development tím sa skladá z profesionálov (Developerov), ktorí pracujú na produkte a dodávajú k nemu prírastky.

(O tom, ako sa prírastky plánujú, dodávajú a kontrolujú, budeme hovoriť neskôr v časti Scrum udalosti.)

Development tím je interdisciplinárny a:

• Je samoorganizujúci:

Developeri sa sami rozhodujú, ako z položiek Produktového Backlogu vyrobia prírastok. Sú experti vo svojej oblasti a vedia, ktoré nástroje, materiály, technológie a pod. majú použiť.

• Nie sú v ňom tituly a podtímy:

Jednotliví Developeri môžu mať rôzne zameranie a schopnosti (napr. biznis analýza alebo dizajn), ale zodpovednosť leží na tíme ako celku. 

Scrum sa chce vyhnúť situáciám, kde Developer A povie: “Nemohol som dokončiť svoju časť, ale nie mojou vinou, musel som čakať, kým Developer B dokončí svoju časť.” Aby sa predišlo takýmto situáciám, v tíme musí prebiehať aktívna komunikácia.

V skratke: V Development tíme potrebujete mať ľudí, ktorí majú znalosti na to, aby mohli pracovať na produkte, a ktorí taktiež dokážu pracovať spoločne ako tím. Nemusia (a ani nemôžu) byť dokonalí od začiatku. Dôležitejšie je, že sa chcú neustále zlepšovať (Scrum má na to dokonca špeciálnu udalosť – viac v časti Šprint retrospektíva).

Scrum Master

Pozrime sa opäť, čo hovorí Príručka Scrumu:

Scrum Master je zodpovedný za propagáciu a podporu používania Scrumu tak, ako to definuje Príručka Scrumu. Robí to tak, že pomáha každému porozumieť teórii Scrumu, jeho aktivitám, pravidlám a hodnotám.

To vyzerá veľmi… abstraktne. Áno, Scrum Master je najviac abstraktná rola v tíme, ale stále cenná.

Najdôležitejšie je, že Scrum Master je “sluha-líder” (angl. servant-leader) pre Scrum tím.

Všetko, čo Scrum Master robí, je služba: služba Product Ownerovi, služba Development tímu, služba organizácii.

Samozrejme, neznamená to, že Scrum Master varí kávu splní každé prianie. Tak by bol len sluhom, má byť ale sluhom-lídrom. Scrum Master vedie a učí ľudí o tom, ktoré ich konanie je prospešné a ktoré by mali zmeniť, aby maximalizovali hodnotu, ktorú Scrum tím dodáva. Scrum Master taktiež vedie tím k tomu, aby dodržiaval časové limity pre jednotlivé udalosti a mítingy.

Vráťme sa ešte k situácii z predošlej časti o Development tíme, kde Developer B blokoval Developera A. Ak by takáto situácia nastala, Scrum Master môže zakročiť a navrhnúť, aby sa A a B porozprávali. Môže A s niečím pomôcť B, aby to spoločne dokončili rýchlejšie? Ak áno, vo výsledku z toho profituje celý tím.

Čo by teda mal mať a zvládnuť dobrý Scrum Master?

• Postoj sluhu-lídra – Scrum Master musí vedieť odložiť svoje ego bokom. Jeho cieľom nie je vyzerať skvelo, ale pomôcť ostatným, aby boli ešte viac skvelí než doteraz. V skutočnosti je najvyšším Scrum Mastera, aby už ani nebol potrebný.
• Empatia a asertivita – Scrum Master musí svoje posolstvá podávať takým spôsobom, aby ich ostatní chceli akceptovať.
• Komunikačné schopnosti – v podstate všetko, čo Scrum Master robí, zahŕňa ľudí, takže komunikácia je základ.

Ako vidíte, na zozname nie je Scrum Master certifikácia.

Ľudia sa často pýtajú: Potrebujem mať Scrum Master certifikáciu?
Odpoveď je: Áno a nie.

Niektoré organizácie (hlavne tie veľké) požadujú certifikát ako formálny dôkaz o schopnostiach uchádzača. Ak chcete pracovať pre takúto organizáciu, musíte získať certifikáciu.

Tip: Scrum tréning a certifikáciu ponúka mnoho organizácií, ale niektoré z nich sú viac rešpektované než iné. Vždy si radšej dopredu overte, aké certifikácie váš potenciálny zamestnávateľ akceptuje.

Certifikát sám o sebe z vás ale neurobí dobrého Scrum Mastera.
Samozrejme, že potrebujete mať teoretické znalosti princípov a hodnôt Scrumu. Tieto informácie sa dajú nájsť na internete alebo v knihách.
Dôležité je, aby ste vedeli tieto znalosti aplikovať. Vlastnosti Scrum Mastera uvedené vyššie vám to umožnia.

Koľko členov by mal mať Scrum tím?

Na začiatok započítajme Product Ownera a Scrum Mastera ako dvoch členov.

Príručka Scrumu explicitne nehovorí, že to musia byť dvaja rôzni ľudia – hovorí o rolách, nie o členoch. Sú tímy, v ktorých obe role napĺňa jedna osoba. Vo všeobecnosti sa ale takýto prístup dôrazne neodporúča. 

Product Owner má robiť rozhodnutia o produkte a Scrum Master má slúžiť tímu (vrátane Product Ownera). To sú dve rôzne veci a môžu byť niekedy v konflikte, takže by ich mali robiť rôzni ľudia.

Optimálna veľkosť Development tímu je dosť malá, aby zostal svižný, a zároveň dosť veľká, aby počas šprintu dokázal dokončiť signifikantné množstvo práce.

Je mnoho názorov na veľkosť Development tímu. Príručka Scrumu uvádza len horný limit 9 a žiadny dolný limit. 

Prekvapivo, Jeff Sutherland, jeden z autorov Príručky Scrumu, na svojom webe odporúča ako horný limit 7, a to pre celý Scrum tím, nielen Development tím!

My odporúčame, aby bol počet Developerov 4 až 7. 

Dokopy by teda Scrum tím mal mať 6 až 9 členov.

Dohodnite si definíciu hotového

Na konci každého šprintu by mal tím dodať hotový prírastok produktu.

Najprv ale musíte zadefinovať, čo znamená hotový. Ak sa vám zdá zbytočné premýšľať nad tak jednoznačnou vecou, zadržte!

Niekedy je až prekvapivé, ako veľmi sa môžu líšiť očakávania tímu a stakeholderov.

Uvedieme príklad z vývoja softvéru: jeden Developer si môže myslieť, že práca je hotová, lebo napísal kód. Iní developeri si môžu myslieť, že kód je potrebné otestovať a až tak bude práca hotová. A stakeholderi očakávajú, že budú môcť nové funkcie budú bežať na nejakom testovacom prostredí a oni ich tam budú môcť vidieť.

Preto je dôležité spoločne sa dohodnúť na definícii hotového.

Malo by na to postačovať stretnutie, na ktorom bude prítomný tím a kľúčoví stakeholderi. Definícia sa časom môže zmeniť, ale opäť sa na tom všetci (tím + stakeholderi) musia dohodnúť.

Teraz by už mali byť všetci vo vašej organizácii nadšení myšlienkou používať Scrum. Ďalšia otázka je: Ako vlastne používať Scrum?

#4 Ako používať Scrum?

Príručka Scrumu hovorí, že Scrum je:

• jednoduchý,
• ľahký na pochopenie,
• ťažký na zvládnutie.

Prvé dva body sme už zvládli. Poďme sa teraz pozrieť na praktické kroky, ako zvládnuť aj tretí.

Nebude to ľahké – nezabudnite ale, že Scrum je o neustálom zlepšovaní sa. Nemusíte urobiť všetko správne hneď na prvý raz. Dôležité je, aby ste sa z toho poučili a nabudúce to urobili lepšie.

Aby ste zvládli techniku Scrumu a efektívne pracovali na produkte, budete potrebovať:

• mať Scrum artefakty,
• mať Scrum udalosti,
• kontrolovať proces.

Scrum artefakty

V Scrume sú tri artefakty:

• Produktový Backlog
• Šprint Backlog
• Prírastok

Produktový Backlog

Čo je Produktový Backlog a čo obsahuje?

Anglický termín backlog [beklog] je možné voľne preložiť ako “zoznam nedokončených vecí”. 

Produktový Backlog reprezentuje všetko, čo sa má dodať na danom produkte. Vlastní a udržiava ho Product Owner (angl. owner = vlastník). Požiadavky na produkt sú reprezentované niekoľkými typmi položiek Produktového Backlogu.

User story [júzer stori] (= “používateľský príbeh”, množné číslo user stories) je najčastejší spôsob, ako zachytiť a formulovať požiadavku na produkt. Je to “krátky popis vlastnosti produktu z pohľadu toho, kto si túto novú vlastnosť želá – zvyčajne je to používateľ alebo zákazník systému” [Mike Cohn].

User story väčšinou dodržiava jednoduchú šablónu:

Ako < typ používateľa > chcem < nejaký cieľ >, aby < nejaký dôvod >. 

Zopár príkladov:

• Ako zákazník chcem pridať položku do košíka, aby som si ju neskôr mohol objednať.
• Ako predajca chcem vidieť všetky objednávky, aby som vedel, ktoré položky mám odoslať.
• Ako zákazník chcem dostať emailom potvrdenie objednávky.

Ako vidieť, tretia časť (“aby…”) sa môže vynechať, ak nie je potrebná.

Produktový Backlog môže okrem user stories obsahovať aj ďalšie typy položiek – napr. technické úlohy alebo epics. Epic [epik] je podobný user story, ale zvyčajne reprezentuje väčšie množstvo práce než user story. Počas Plánovania šprintu sa epics rozdelia na jednotlivé user stories.

Epics, user stories, technické úlohy – to všetko sú validné položky Produktového Backlogu, len s rôznou úrovňou granularity.

Prioritizácia Produktového Backlogu

Ďalšou dôležitou vlastnosťou Produktového Backlogu je, že je to prioritizovaný zoznam položiek.

Položky s najvyššou prioritou sú navrchu a bude sa na nich pracovať najskôr. Mali by tiež byť viac granulárne a podrobné než položky s nižšou prioritou.

Položkám Produktového Backlogu priraďuje prioritu Product Owner v spolupráci so stakeholdermi a Development tímom. Priority odzrkadľujú aktuálne potreby biznisu, no zároveň rešpektujú náväznosti medzi jednotlivými položkami. 

Šprint Backlog

Šprint Backlog reprezentuje všetko, na čom sa pracuje v aktuálnom šprinte. Vlastní ho Development tím.

Počas Plánovania šprintu Development tím berie položky z vrchu Produktového Backlogu a dáva ich do Šprint Backlogu.

Prírastok

Podľa Príručky Scrumu:

Prírastok je suma všetkých položiek Produktového Backlogu, ktorá sa dokončili počas šprintu, a hodnota všetkých prírastkov z predošlých šprintov.

Prvá časť definície (“Prírastok je suma všetkých položiek Produktového Backlogu, ktorá sa dokončili počas šprintu”) naznačuje, že prírastok je delta – to, čo sa pridalo počas šprintu.

Druhá časť (“a hodnota všetkých prírastkov z predošlých šprintov”) sa ale zdá byť mätúca. Dokonca aj Scrum.org, organizácia, ktorú založil Ken Schwaber, jeden z autorov Príručky Scrumu, uvádza na svojej stránke trochu inú definíciu:

Prírastok: kus funkčného softvéru pridaný k predošlým prírastkom, kde suma všetkých prírastkov dokopy tvorí produkt. 

(Vidíme, že dokonca aj autor Scrumu skĺzol k vývoju softvéru a použil termín softvér. Bez obáv môžete tento termín nahradiť vaším produktom.)

Druhá definícia neodporuje prvej, ale viac smeruje k pochopeniu prírastku ako delty – toho, čo bolo pridané v tomto šprinte. Aj ďalej v článku budeme pod pojmom prírastok myslieť deltu.

Prírastok musí spĺňať dve ďalšie podmienky:

• Musí naplniť definíciu hotového.
• Musí byť v použiteľnom stave – bez ohľadu na to, či sa ho Product Owner rozhodne uvoľniť zákazníkovi.

Tri piliere empirickej kontroly procesu

Scrum je založený na teórii empirickej kontroly procesu, alebo empirizme. Empirizmus tvrdí, že poznanie vychádza zo skúseností a rozhodnutí na základe toho, čo je známe.

Na realizáciu empirickej kontroly procesu sú nevyhnutné tri piliere:

• transparentnosť 
• kontrola
• adaptácia

Transparentnosť

Príručka Scrumu hovorí, že “dôležité aspekty procesu musia byť viditeľné pre tých, ktorí sú zodpovední za výsledok” a tiež, že “všetci účastníci musia pri komunikácii o procese zdieľať jeden jazyk”.

Scrum tím otvorene zdieľa so stakeholdermi informácie o jeho práci a o tom, ako ju robí. Stakeholderi vedia:

• Ako sa práca špecifikuje a kto je za to zodpovedný – všetky požiadavky musia ísť cez Product Ownera.
• Ako sa práca vykonáva – tím pracuje v šprintoch a na konci každého dodáva prírastok k produktu, ktorý spĺňa definíciu hotového.

Kontrola

Používatelia Scrumu musia často kontrolovať artefakty Scrumu voči cieľu šprintu, aby odhalili neželané odchýlky. Kontrola by ale nemala byť tak častá, že by bránila samotnej práci.

Kto je používateľ Scrumu? Príručka Scrumu tento termín nespomína na žiadnom inom mieste, ale myslíme si, že každý člen Scrum tímu je zároveň používateľ Scrumu.

Dôležitá je druhá časť, ktorá hovorí, že kontrola by nemala byť príliš častá. Product Owneri, Scrum Masteri alebo ich manažéri majú niekedy sklony k mikromanažmentu a neustále chcú od Development tímu vedieť, aký je aktuálny stav a na čom Developeri práve pracujú. Vo všeobecnosti sa mikromanažment považuje za nesprávny postup, ktorý znižuje efektivitu práce.

Aj keď to Príručka Scrumu nepredpisuje, takmer každý Scrum tím používa Scrum nástenku na komunikáciu aktuálneho stavu dovnútra i navonok.

Scrum nástenka

Scrum nástenka je nástenka so stĺpcami reprezentujúcimi stavy úloh a s kartičkami reprezentujúcimi položky Šprint Backlogu. Môže tiež obsahovať stĺpec vyhradený pre položky Produktového Backlogu.

Keď sa zmení stav kartičky, nástenka sa aktualizuje. Za aktualizáciu zodpovedá ten, kto na danej úlohe pracuje.

Scrum Master vysvetľuje Developerom, prečo je dôležité udržiavať nástenku aktuálnu, ale nie je jeho úlohou robiť samotnú aktualizáciu. Presuny na nástenke sa môžu diať priebežne alebo môžu byť súčasťou denných mítingov.

Nástenka môže byť fyzická alebo digitálna. Fyzická nástenka môže mať formu tabule, veľkého kusu papiera na stene alebo len prázdnej steny – musí to byť jednoducho niečo, čo viete rozdeliť na stĺpce a prilepiť na to lepiace papieriky.

Tímy, ktoré pracujú čiastočne či úplne na diaľku alebo pracujú vo viacerých budovách, nemôžu samozrejme používať fyzickú nástenku. Riešením sú digitálne nástenky.

Je mnoho softvérových nástrojov, v ktorých môžete vytvárať a spolupracovať na digitálnej nástenke, napr. Jira, Trello alebo Lumeer.

V závislosti na nástroji, ktorý si vyberiete, môžete využiť aj extra funkcie ako reporty alebo notifikácie o zmenách.

Adaptácia

Ak inšpektor zistí, že jeden alebo viac aspektov procesu sa odchýlilo mimo akceptovateľných hraníc, a že výsledný produkt nebude akceptovateľný, proces alebo spracovávaný materiál musí byť upravený. Úprava sa musí urobiť čo najskôr, aby nedošlo k ďalším odchýlkam.

Kontrola (inšpekcia) by bola zbytočná, ak by ju nenasledovala adaptácia. Adaptácia je príležitosť zmeniť produkt alebo proces práce na produkte tak, aby prinášal väčšiu hodnotu.

Ak stakeholderi prehlásia, že nejaká vlastnosť produktu potrebuje zmenu, aby bola užitočnejšia, tak sa originálna špecifikácia upraví a vlastnosť (a teda aj produkt) sa zmení. Udeje sa zmena v tom, na čom tím pracuje.

Ak tím zistí, že môže dosiahnuť lepšie výsledky nejakou zmenou v spôsobe svojej práce (napr. použitím nového nástroja), tak adaptuje svoj proces a začne používať nový nástroj. Udeje sa zmena v tom, ako tím pracuje.

Scrum udalosti

Scrum udalosti (Scrum ceremónie) sa nazývajú aj Šprint udalosti, pretože sa dejú vnútri šprintov. Šprint je hlavná udalosť a je to kontajner pre všetky ostatné udalosti.

Príručka Scrumu predpisuje 4 udalosti, ktoré sú navrhnuté tak, aby podporovali transparentnosť a kontrolu:

• Plánovanie šprintu
• Denný Scrum
• Revízia šprintu
• Retrospektíva šprintu

Niektoré tímy si do svojho rozvrhu pridávajú aj ďalšiu udalosť: Vylepšovanie Produktového Backlogu. To sa môže diať ako formálna udalosť alebo priebežne.

Všetky Scrum udalosti maju ohraničené trvanie – horný limit sa počíta podľa dĺžky šprintu.

Plánovanie šprintu

Počas Plánovania šprintu tím spoločne vytvorí plán práce, ktorá sa má vykonať počas šprintu.

Maximálne trvanie plánovania je 8 hodín pre 4-týždňový šprint (4 hodiny pre 2-týždňový atď.).

Plánovanie Šprintu má zodpovedať dve otázky:

1. Na čom sa bude pracovať?

Členovia tímu prediskutujú vlastnosti, ktoré sa majú dodať. Vezmú položky z vrchu Produktového Backlogu (s najvyššou prioritou), ale vezmú do úvahy aj ďalšie faktory, napr. náväznosti.

2. Ako sa tá práca vykoná?

Developeri navrhujú riešenie a zvyčajne pritom rozdeľujú položky Produktového Backlogu na menšie úlohy. Product Owner pomáha objasniť detaily vybraných položiek a robí kompromisy, ak Developeri zistia, že to predstavuje priveľa alebo primálo práce.

Product Owner nemôže Developerom prikázať, na koľkých položkách majú pracovať – Development tím sa zaväzuje k dokončenie položiek, a tak len Development tím môže rozhodnúť, koľko si naloží na plecia. Berie pritom do úvahy predpokladanú kapacitu a výsledky v minulosti.

Ako by malo vyzerať Plánovanie šprintu?

Otázka by sa dala preformulovať na “Ako vlastne vyzerá proces vytvárania Šprint Backlogu?” To závisí od granularity a komplexity položiek Produktového Backlogu, vyspelosti tímu atď. Nižšie uvádzame vzorový scenár. Neberte ho ale ako jediný správny spôsob, ako viesť vaše Plánovanie šprintu!

Vzorový scenár Plánovania šprintu

Časť 1: Predstavenie nových položiek
Product Owner predstaví položky z vrchu Produktového Backlogu. Pre Developerov tieto položky nie sú úplne nové, zoznámili sa už s nimi počas predošlých neformálnych diskusií či na Upratovaní Produch Backlogu.Tento prístup obzvlášť odporúčame pre vývoj softvéru, aby sa Developeri mohli zamyslieť nad položkami vopred a ušetrili čas počas plánovania. Samozrejme, riešenie by malo byť navrhnuté spoločne, ale Developeri sa môžu nad vecami zamyslieť najprv individuálne, aby mohli prísť s nápadmi.

Časť 2: Odhadovanie
Developeri odhadnú položky Produktového Backlogu (Product Owner a Scrum Master neodhadujú). Aj táto časť sa môže udiať mimo mítingu. Odhadovanie je obšírna téma a budeme sa jej neskôr venovať v samostatnej časti.

Časť 3: Výber položiek a dizajn
Tím sa dohodne, ktoré položky pôjdu do Šprint Backlogu. To znamená, že Developeri musia urobiť aspoň základný návrh a priradiť prácu. Môžu tiež rozdeliť user stories na menšie úlohy. Prediskutujú náväznosti a zoradia položky tak, aby podľa možností nikto nebol blokovaný.

Denný Scrum

Denný Scrum sa uskutočňuje v každý deň šprintu. Development tím kontroluje postup smerom k cieľu šprintu a plánuje prácu na ďalší deň.

Horná hranica trvania je 15 minút. Často nazýva aj Standup Meeting [stendap míting] (angl. stand up = postaviť sa). Je to preto, že by mal byť naozaj krátky – tím môže počas neho aj stáť a nie je potrebné rezervovať špeciálnu miestnosť s miestom pre každého člena tímu.

Ako by mal vyzerať Denný Scrum?

Štruktúru mítingu určuje Development tím. Scrum Master iba zaistí podmienky pre to, aby sa míting udial.

Stáva sa, že sa Product Owner alebo iní manažéri snažia nastaviť štruktúru Denného Scrumu a zaobchádzajú s ním ako s denným hlásením aktuálneho stavu. 

Je úlohou Scrum Mastera naučiť ich, že vlastníkom Denného Scrumu je Development tím. Iní účastníci by ho nemali narúšať ani meniť jeho priebeh.

Najčastejšia forma je, že každý Developer zodpovie 3 otázky:

1. Na čom som pracoval včera (čo pomohlo Development tímu naplniť cieľ šprintu)?
2. Na čom budem pracovať dnes (čo pomôže Development tímu naplniť cieľ šprintu)?
3. Viem o nejakej prekážke (ktorá bráni mne alebo Development tímu naplniť cieľ šprintu)?

Členovia tímu sa väčšinou stretnú (alebo si zavolajú, ak nie sú v jednej miestnosti) hneď po Dennom Scrume kvôli detailnejším diskusiám alebo kvôli zmene či preplánovaniu práce vo zvyšku šprintu.

Revízia šprintu

Revízia šprintu sa koná na konci šprintu. Prebieha počas nej kontrola prírastku a adaptácia Produktového Backlogu (ak je potrebná). Scrum tím a stakeholderi spoločne preberajú, čo sa dokončilo počas šprintu.

Zúčastňuje sa Scrum tím a kľúčoví stakeholderi, ktorých pozve Product Owner. Časový limit je 4 hodiny pre 4-týždňový šprint.

Nie je nutné, aby sa zúčastnili všetci stakeholderi (môže ich byť príliš veľa), ak tí zúčastnení majú dosť znalostí a kompetencií na to, aby podali spätnú väzbu a aktívne sa zapájali diskusie.

Revízia šprintu by mala prebehnúť pred Plánovaním šprintu, pretože môže poskytnúť cenné vstupy pre tvorbu plánu.

Ako by mala vyzerať Revízia šprintu?

Revízia šprintu je neformálny míting. Nemá to byť iba hlásenie o stave – cieľom je získať spätnú väzbu a podporiť kolaboráciu. Preto by mala obsahovať nasledujúce prvky:

• Prezentácia a diskusia prírastku
• Diskusia o tom, na čom sa bude najbližšie pracovať

Prezentácia a diskusia prírastku

Product Owner vysvetlí, ktoré položky Produktového Backlogu boli dokončené. Development tím ich odprezentuje a zodpovie otázky.

Príručka Scrumu tiež hovorí, že “Development tím diskutuje o tom, čo sa počas šprintu podarilo, na aké problémy narazil a ako ich vyriešil”, čo sa sčasti prekrýva s obsahom Retrospektívy šprintu.

Odporúčame preberať len problémy zapríčinené vonkajšími okolnosťami, nie problémy so samotným Scrum procesom.

Napríklad: Tím zistil, že komponent (fyzická súčiastka / ingrediencia jedla / softvérová knižnica…), ktorý mal v úmysle použiť, je nedostupný. Podarilo sa mu nájsť náhradu, ale chvíľu to trvalo a nestihla sa kvôli tomu dokončiť daná položka Produktového Backlogu.

Diskusia o tom, na čom sa bude najbližšie pracovať 

Product Owner popíše aktuálny stav Produktového Backlogu a všetci účastníci diskutujú, na čom sa bude pracovať najbližšie. 

Najbližšie neznamená najbližšie v kontexte šprintov alebo termínov, pretože o tom rozhoduje tím počas Plánovania šprintu.

Najbližšie by malo vyjadrovať prioritu, pretože vlastne chceme odpovedať na otázku: Čo je najhodnotnejšia vec, na ktorej by sme mohli najbližšie pracovať?

Príručka Scrumu nakoniec hovorí, že “výsledkom Revízia šprintu je revidovaný Produktový Backlog, ktorý definuje pravdepodobné položky pre ďalší šprint. Produktový Backlog sa tiež môže celkovo upraviť, aby odzrkadľoval nové príležitosti.”

Retrospektíva šprintu

Retrospektíva šprintu je príležitosť pre Scrum tím, aby zhodnotil seba a svoj proces a vytvoril plán vylepšení, ktoré zavedie v ďalšom šprinte.

Koná sa po Revízii šprintu a pred Plánovaním šprintu. Časový limit je 3 hodiny pre 4-týždenný šprint.

Ako by mala vyzerať Retrospektíva šprintu?

Retrospektíva šprintu je interný míting Scrum tímu – nikto iný sa nezúčastňuje.

Mala by sa tiež odohrávať v pozitívnom a neformálnom duchu, aby sa nikto nebál povedať svoj názor a diskutovať o tom, čo sa nepodarilo.

Tím by mal zodpovedať 3 základné otázky. Nie je nutné, aby každý člen odpovedal na každú otázku, je to skôr skupinová aktivita:

1. Čo sa v tomto šprinte podarilo? (Čo máme robiť aj naďalej?)
2. Čo sa v tomto šprinte nepodarilo? (Čo máme prestať robiť?)
3. Čo by sme mali zlepšiť? (Čo máme začať robiť?)

Tím potom vytvorí plán, ako zaviesť jednotlivé vylepšenia – adaptovať sa.

Niektoré vylepšenia môžu byť krátkodobé aktivity (napr. začať používať nový nástroj, ktorý urýchli prácu), iné sú dlhodobé (napr. počas plánovania prediskutovať položky Backlogu do väčšej hĺbky, aby sa znížila neurčitosť počas sprintu).

Odporúčame sa tiež pozrieť na predošlú retrospektívu a na to, či sa úspešne zaviedli vylepšenia, ktoré na nej tím navrhol.

Vylepšovanie Produktového Backlogu

Vylepšovanie Produktového Backlogu nie je predpísané Príručkou Scrumu nutne ako míting, ale ako neustále bežiaci proces.

Vylepšovanie Produktového Backlogu je dodávanie detailu, odhadov a poradia k položkám Produktového Backlogu. Je to bežiaci proces, v ktorom Product Owner a Development tím kolaborujú na detailoch položiek Produktového Backlogu. Počas Vylepšovania Produktového Backlogu sa položky znovu posudzujú a revidujú.

Odráža to potrebu neustále meniť a aktualizovať Produktový Backlog. Táto aktivita sa sčasti deje aj počas Revízie šprintu, ale vtedy už býva neskoro diskutovať o položkách na vrchu Backlogu, keďže Plánovanie šprintu sa deje krátko potom.

Scrum tím rozhoduje o tom, ako a kedy sa vylepšovanie deje. Nemalo by však zaberať viac než 10% kapacity Development tímu.

Nie všetky tímy majú na vylepšovanie vyhradený míting. Niektoré sú schopné robiť ho priebežne, napr. vďaka neformálnym diskusiám v priebehu šprintu.

Aspoň počas prvých pár šprintov odporúčame mať na túto aktivitu vyhradený míting – i keď veľmi krátky. Pomáha to redukovať neurčitosť počas Plánovania šprintu a stihnúť ho v časovom limite.

Ak sa vylepšovací míting udeje uprostred šprintu, Developeri sa oboznámia s tým, na čom sa pravdepodobne bude najbližšie pracovať, a znalosť širších súvislostí môže ovplyvniť ich rozhodnutia počas práce na položkách aktuálneho Šprint Backlogu.

Poskytuje tiež hodnotné informácie pre Product Ownera a ten ich môže použiť na zmenu priorít.

Odhadovanie

Aj keď Príručka Scrumu spomína odhadovanie položiek Produktového Backlogu hneď na niekoľkých miestach, nepodáva žiadne ďalšie informácie o tom, ako by vlastne odhadovanie malo prebiehať.

Správne odhadovanie je ale z hľadiska biznisu kritické. Umožňuje tímu a stakeholderom robiť projekcie do budúcnosti a vedieť (približne, nie presne) kedy budú dodané prírastky.

Odhadovanie sa deje hlavne počas Vylepšovania Product Backlogu, ale niektoré tímy odhadujú alebo znovuodhadujú aj počas Plánovania šprintu. Aj tak odporúčame robiť väčšinu alebo všetko odhadovanie mimo plánovacieho mítingu.

Kto robí odhady?

Iba Development tím – Príručka Scrumu to potvrdzuje:

Development tím je zodpovedný za všetky odhady. Product Owner môže ovplyvniť Development tím tak, že mu pomôže pochopiť a dohodnúť sa na kompromisoch, ale konečný odhad robia tí, ktorí vykonávajú samotnú prácu.

Mali by sme znovuodhadovať?

Áno. Odhady nie sú vytesané do kameňa – preto sa aj nazývajú odhadmi.

Ak chcete stakeholderom a biznisu všeobecne odovzdávať dobré projekcie, chcete mať aj dobré odhady. Schválne používame slovo “dobrý” a nie “najlepší”, pretože snaha o 100% dokonalé odhady môže byť kontraproduktívna. 

Ak strávite priveľa času odhadovaním, budete mať menej času na samotnú prácu. Predpokladáme, že na odhadovanie sa dá aplikovať Paretov princíp (Pravidlo 80/20) – s 20% úsilia získate 80% presnosti.

Ako sa položka posúva v Produktovom Backlogu nahor, tak sa spresňuje špecifikácia a klesá neurčitosť. Pôvodný odhad položky spred niekoľkých šprintov môže potrebovať úpravu, pretože:

• Tím získal viac informácií o tejto položke, keď pracoval na súvisiacich položkách. Možno zistil, že nejaká časť práce sa môže pridať alebo vynechať, alebo že sa zmenili požiadavky.
• Položka bola príliš veľká a bola rozdelená na niekoľko menších položiek. Je možné (a je to úplne v poriadku), že súčet odhadov menších položiek je väčší alebo menší ako pôvodný odhad veľkej položky.

Potom na základe nového odhadu zmeníte vaše projekcie. To môže znieť ako niečo, čo sa stakeholderom nebude páčiť – čo ak chcú konečné projekcie, ktoré sa nemenia?

Na túto otázku vám ponúkame dva argumenty:

1. Formulujte vaše projekcie pre stakeholderov ako intervaly, nie ako presné dátumy.

Napr.: “Očakávame, že v nasledujúcich 4 až 5 šprintoch dokončíme týchto 10 user stories.”

Scrum je určený pre komplexné produkty, a komplexné produkty v sebe vždy obsahujú neurčitosť, ktorá sa nedá zredukovať na nulu. Len zriedkavo sa vám podarí trafiť presný dátum, takže intervaly sú vlastne úprimnejšie.

2. Predpokladajte, že stakeholderi chcú projekcie z nejakého dôvodu – aby podľa nich mohli rozhodnúť o ďalších aktivitách.

Ak má byť vlastnosť dodaná neskôr, než sa pôvodne očakávalo, tak jednoducho bude dodaná neskôr. Môžu sa o tejto zmene dozvedieť hneď, alebo až vtedy, keď je po termíne.

V akých jednotkách by sme mali odhadovať?

Mike Cohn vo svojej knihe Agile Estimating and Planning (Agilné odhadovanie a plánovanie) uvádza dva druhy odhadovania:

• Odhadovanie v ideálnych dňoch
• Odhadovanie v story bodoch

Pre obe jednotky odporúča nepoužívať ľubovoľné čísla, ale jednu z dvoch odhadovacích škál:

• 1, 2, 3, 5, 8… (Fibonacciho postupnosť)
• 1, 2, 4, 8, 16… (každé číslo je dvojnásobkom predošlého)

Tento prístup vychádza z faktu, že ľudia sú dobrí v relatívnych odhadoch, napr. “očakávam, že táto úloha bude dvakrát náročnejšia ako táto už hotová, takže ak tá hotová má komplexitu 2, tak tá nová bude mať komplexitu 4” (pri použití druhej škály).

Môžete tiež o týchto číslach uvažovať ako o priehradkach – napr. ak sa položka nevojde do priehradky s veľkosťou 3, tak patrí do priehradky s veľkosťou 5 (pri použití prvej škály). Ak dáte položku do väčšej z dvoch priehradok, získate zároveň malú rezervu a zvýšite pravdepodobnosť, že úlohu dokončíte včas.

Odhadovanie v ideálnych dňoch

Je založené na časových odhadoch.

Ideálny deň je deň, ktorý Developer strávi iba prácou na zadanej úlohe – bez vyrušení, mítingov, emailov, prepínania medzi úlohami apod. 

Ideálny čas sa nerovná uplynutému času, pretože takmer žiadne (a možno aj všetky) dni nie sú ideálne. To znamená, že budete potrebovať nájsť koeficient, ktorým vynásobíte počet skutočných dní a získate počet ideálnych dní. Môže byť niekde medzi 0,6 a 0,7 (60 až 70%) – číslo pre váš tím zistíte po niekoľkých šprintoch.

Odhadovanie v story bodoch

Ja založené na odhadoch veľkosti.

Story bod je jednotka veľkosti a komplexity. Development tím sa rozhodne, čo reprezentuje jeden story bod. Mal by to byť kus práce, ktorý je malý a všetci Developeri vedia, o čo ide.

Ak by Developeri pracovali v kuchyni, tak by jeden story bod reprezentoval nakrájanie cibule (predpokladáme, že každý, kto pracuje v kuchyni, vie nakrájať cibuľu!). Keď sa všetci Developeri zhodnú na definícii story bodu, budú ho používať ako referenčný bod pri odhadovaní položiek Produktového Backlogu.

A ako so story bodmi robiť projekcie? Pomocou výpočtu rýchlosti. Rýchlosť je priemerný počet story bodov dokončených za jeden šprint.

Počítajú sa iba tie položky Šprint Backlogu, ktoré sú hotové – žiadne čiastočné úspechy typu “Urobili sme polovicu tejto 8-bodovej položky, tak započítajme 4 body ako hotové.” Nedokončená položka sa dokončí v ďalšom šprinte a súčty story bodov z tohto a ďalšieho šprintu sa nakoniec spriemerujú.

Budete potrebovať niekoľko šprintov, aby ste zistili rýchlosť vášho tímu. Potom spočítate súčet odhadov položiek v Produktovom Backlogu, vydelíte ho rýchlosťou a dostanete približný počet šprintov, za ktoré tieto položky dokončíte.

Rýchlosť sa v čase môže meniť. Ako sa tím zlepšuje, môže sa zvyšovať aj rýchlosť jeho práce. Alebo niektorí členovia odídu a rýchlosť práce sa zníži. Ak budete pravidelne prepočítavať rýchlosť, vaše projekcie sa budú spresňovať.

Ideálne dni verzus story body

Odhadovania v ideálnych dňoch aj v story bodoch majú svoje výhody a nevýhody, a vy si potrebujete vybrať, ktoré sa viac hodí pre vaše potreby.

Na prvý pohľad môžu ideálne dni vyzerať ako jasná voľba – môžete ľahko robiť časové predpovede bez toho, aby ste potrebovali nejakú abstraktnú jednotku veľkosti (ako je story bod).

Na druhej strane, každý Developer je iný a tá istá úloha môže jednému zabrať hodinu a inému dve hodiny. So story bodmi môžu všetci odhadnúť (takmer) rovnakú veľkosť a komplexitu, aj keď by každému Developerovi zabralo dokončenie úlohy odlišné množstvo času. 

Ako by sme mali odhadovať?

Najčastejšou technikou je plánovací poker.

(Zostaňte bez obáv, so skutočným pokrom nemá spoločné nič okrem toho, že sa pri ňom používajú karty.)

Potrebujete sadu kariet (napr. kúskov papiera) pre každého Developera. Na karty napíšte čísla z odhadovacej škály (jedno číslo na jednu kartu), takže budete mať napr. karty s číslami 1, 2, 3, 5, 8, 13, 20, 40, 100. Táto škála nie je dokonalá Fibonacciho postupnosť, ale používa sa veľmi často.

A ako “hrať” plánovací poker?

Pravidlá plánovacieho pokru

Opakujte tieto kroky pre každú položku Produktového Backlogu, ktorú idete odhadovať.

1. Product Owner prečíta popis položky a zodpovie na všetky otázky.
2. Každý Developer si tajne vyberie kartu s jeho odhadom.
3. Tím čaká, kým nebudú mať všetci vybranú kartu.
4. Všetky karty sa naraz ukážu. Ak má každý rovnaké číslo, končíte.
5. Ak sú medzi odhadmi rozdiely, Developeri začnú diskusiu. Chcú vysvetliť tímu, prečo si vybrali také číslo, aké si vybrali.
6. Po diskusii sa vrátťe ku kroku 2 – opakujte proces výberu kariet a diskusie, až kým sa tím nezhodne na jednom čísle.

Väčšinou stačí jedno až dve kolá.

Zhrnutie

Scrum je stále považovaný za nový spôsob práce (obzvlášť mimo oblasti vývoja softvéru), no jeho zavedenie do rôznych oblastí môže priniesť veľkú hodnotu.

Po prečítaní Príručky Scrumu ľudia často skončia s viac otázkami, než mali na začiatku. V tomto článku sme sa snažili zodpovedať tie najtypickejšie. Ak stále máte nejaké nezodpovedané otázky, dajte nám vedieť a článok upravíme.

Často kladené otázky