Ken Schwaber & Jeff Sutherland

The Scrum Guide
Scrum Sprievodca: Pravidlá hry

November 2020Účel Scrum Sprievodcu
Scrum sme vyvinuli začiatkom 90. rokov. Prvú verziu Scrum Sprievodcu sme napísali v roku 2010, aby
sme pomohli ľuďom na celom svete porozumieť Scrumu. Odvtedy sme Sprievodcu rozvíjali pomocoumalých, funkčných zmien.
Tento Sprievodca obsahuje definíciu Scrumu. Každý prvok tohto rámca slúži konkrétnemu účelu, ktorý jepotrebný na to, aby Scrum priniesol celkovú zamýšľanú hodnotu a výsledky. Zmeny základného
nastavenia alebo princípov Scrumu, vynechanie prvkov alebo nedodržiavanie pravidiel Scrumu zakrýva
problémy a obmedzuje jeho prínosy, čo ho môže dokonca urobiť nepoužiteľným.
Sledujeme rastúci počet užívateľov Scrumu v neustále rastúcom komplexnom svete. S pokorou
sledujeme adopciu Scrumu v mnohých oblastiach, stojacich prevažne na komplexnej práci, ktorá je veľmi
vzdialená vývoju softvérových produktov, kde má Scrum svoje korene. Ako sa Scrum šíri, pracujú s ním
developeri, výskumníci, analytici, vedci a ďalší špecialisti. Slovo „developeri“ nepoužívame na vylúčenie
ostatných, ale na zjednodušenie. Pokiaľ je pre vás Scrum užitočný, je pre vás.
Pri používaní Scrumu môžete nájsť, aplikovať či navrhnúť vlastné vzory a procesy, ktoré sú v súlade so
Scrumom, ako je popísaný v tomto Sprievodcovi. Ich popis presahuje účel Sprievodcu, pretože závisí odkontextu a výrazne sa líši podľa situácie. Takéto postupy sa v rámci Scrumu môžu významne líšiť a sú
popísané inde.
Ken Schwaber & Jeff Sutherland November 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.

1Účel Scrum Sprievodcu

1

Definícia Scrumu

4

Teória Scrumu

4

Transparentnosť

4

Preskúmanie

5

Prispôsobenie

5

Hodnoty Scrumu

5

Scrum Team

6

Developeri

6

Product Owner

7

Scrum Master7

Scrum Podujatia

8

Sprint8

Sprint Planning

9

Daily Scrum

10

Sprint Review

10

Sprint Retrospective

11

Scrum Artefakty
Product Backlog
Záväzok: Product Goal
Sprint Backlog
Záväzok: Sprint Goal
Increment
Záväzok: Definition of Done

11
11
12
12
12
13
13

Slovník

13

Poznámka na záver

14Poďakovanie

14

Ľudia

14

História Scrum Sprievodcu

14Poďakovanie prekladateľom

15

Rozdiely medzi Scrum Sprievodcami 2017 a 2020

15
2

Ešte menej normatívne

15

Jeden tím, zameraný na jeden produkt

15

Zavedenie Product Goalu

15

Miesto pre Sprint Goal, Definition of Done a Product Goal

15

Samoriadenie namiesto sebaorganizovanie

16

Tri témy Sprint Planningu

16

Celkové zjednodušenie jazyka pre širšie publikum

16

3

Definícia Scrumu
Scrum je jednoduchý rámec, ktorý pomáha ľuďom, tímom a organizáciám tvoriť hodnotu pomocou
adaptívnych riešení komplexných problémov.
Stručne povedané, Scrum potrebuje Scrum Mastera, aby vytváral prostredie, kde:
1. Product Owner zadáva prácu na komplexnom probléme do Product Backlogu.
2. Scrum Team počas Sprintu pretaví zvolenú prácu na prírastok hodnoty v podobe Incrementu.
3. Scrum Team a zainteresované strany skontrolujú výsledok a prispôsobia svoje požiadavky naďalší Sprint.
4. Opakujte od bodu 1.
Scrum je jednoduchý. Vyskúšajte ho bezo zmien a zistite, či vám jeho filozofia, teória a štruktúra
pomáhajú pri dosahovaní cieľov a vytváraní hodnoty. Scrumový rámec je neúplný zámerne, definuje ibačasti potrebné na implementáciu teórie Scrumu. Scrum je postavený na kolektívnej inteligencií ľudí, ktorí
ho používajú. Namiesto poskytovania podrobného návodu, pravidlá Scrumu skôr riadia vzťahy ainterakcie ľudí.
Do rámca môžu byť zavedené rôzne procesy, techniky a metódy. Scrum buď príjme existujúce praktiky,
alebo sa stanú nepotrebnými. Scrum zviditeľní relatívnu účinnosť súčasného riadenia, pracovného
prostredia a techník tak, aby bolo možné vykonať zlepšenie.

Teória Scrumu
Scrum je založený na empirizme a lean myslení. Empirizmus tvrdí, že vedomosti pochádzajú zo
skúseností a rozhodovanie sa zakladá na výsledkoch pozorovaní. Lean myslenie odstraňuje zbytočnosti asústredí sa na podstatu.
Scrum využíva iteratívny, inkrementálny prístup na optimalizáciu predpovedateľnosti a riadenie rizika.
Scrum zapája skupiny ľudí, ktorí spolu už majú všetky potrebné zručnosti a odborné znalosti na to, abymohli vykonávať danú prácu a podľa potreby takéto zručnosti zdieľať alebo získavať.
Scrum v súhrnnom podujatí s názvom Sprint, združuje štyri oficiálne podujatia s cieľom preskúmať aprispôsobiť sa. Tieto stretnutia majú zmysel, pretože stoja na empirických pilieroch Scrumu –transparentnosti, preskúmania a prispôsobenia sa.

Transparentnosť
Vznikajúce procesy a práca musia byť viditeľné pre tých, ktorí prácu vykonávajú, ako aj pre tých, ktorí
hotovú prácu prijímajú. V Scrume sú dôležité rozhodnutia založené na vnímaní stavu jeho troch4

oficiálnych artefaktov. Artefakty, ktoré majú nízku transparentnosť, môžu viesť k rozhodnutiam, ktoréznižujú hodnotu a zvyšujú riziko.
Transparentnosť umožňuje preskúmanie. Preskúmanie bez transparentnosti je zavádzajúce a zbytočné.

Preskúmanie
Artefakty Scrumu a postup smerom k dohodnutým cieľom musia byť často a svedomito preskúmané,
aby sa zistili potenciálne nežiaduce odchýlky alebo problémy. Pre uľahčenie preskúmavania, Scrum
ponúka pravidelné opakovanie vo forme svojich piatich podujatí.
Preskúmanie otvára možnosť prispôsobovať. Preskúmanie bez prispôsobenia je považované zabezvýznamné. Scrum podujatia sú navrhnuté tak, aby vyprovokovali zmenu.

Prispôsobenie
Ak sa niektoré aspekty procesu odchyľujú mimo prijateľné limity alebo ak je výsledný produkt
neprijateľný, tak aplikovaný proces alebo vytvorená hodnota musia byť upravené. Úprava musí byť
vykonaná čo najskôr, aby sa minimalizovala ďalšia odchýlka.
Ak zúčastnené osoby nie sú plne poverené alebo samoriadiace, tak je prispôsobovanie sa obtiažne.
Očakáva sa, že Scrum Team sa prispôsobí hneď ako sa prostredníctvom preskúmania naučí niečo nové.

Hodnoty ScrumuÚspešné použitie Scrumu závisí od toho, ako zdatne zvládnu ľudia napĺňať týchto päť hodnôt:
Odhodlanosť, Zacielenosť, Otvorenosť,Rešpekt a Odvaha
Scrum Team je odhodlaný dosahovať svoje ciele a vzájomne sa podporovať. Primárne mieri na prácu v
rámci Sprintu tak, aby dosiahol čo najlepší pokrok pri plnení týchto cieľov. Scrum Team a zainteresované
strany sú ohľadom práce a výziev otvorení. Členovia Scrum Teamu sa navzájom vnímajú ako schopní,nezávislí ľudia, a tak isto sú rešpektovaní aj ďalšími spolupracovníkmi. Členovia Scrum Teamu majúodvahu robiť správne veci a pracovať na náročných problémoch.
Tieto hodnoty udávajú smer Scrum Teamu s ohľadom na jeho prácu, konanie a správanie. Rozhodnutia
ktoré urobia, prijaté opatrenia a spôsob akým sa Scrum používa, by mali tieto hodnoty posilniť, nie ichznížiť alebo podkopať. Členovia Scrum Teamu sa učia a preskúmavajú hodnoty pri práci so Scrum
podujatiami a Scrum artefaktmi. Keď Scrum Team a spolupracovníci žijú hodnotami Scrumu, tak skrz
empirické piliere Scrumu transparentnosti, preskúmavania a prispôsobenia budujú dôveru v tíme.
5

Scrum Team
Základnou jednotkou Scrumu je malý tím ľudí, Scrum Team. Scrum Team pozostáva z jedného Scrum
Mastera, jedného Product Ownera a Developerov. V rámci Scrum Teamu neexistujú žiadne podtímy ani
hierarchia. Je to súdržná jednotka profesionálov zameraná na jeden cieľ v danom čase, na Product Goal.
Scrum Teamy sú multiznalostné, čo znamená, že členovia majú všetky zručnosti potrebné na vytváranie
hodnoty počas každého Sprintu. Tiež sú samoriadiace, čo znamená, že interne rozhodujú o tom, kto čo,
kedy a ako robí.
Scrum Team je dostatočne malý na to, aby zostal svižný a dostatočne veľký na to, aby dokončilvýznamnú prácu v rámci Sprintu, zvyčajne s 10 alebo menej ľuďmi. Zistili sme, že menšie tímy vo
všeobecnosti lepšie komunikujú a sú produktívnejšie. Ak sa Scrum Teamy stanú príliš veľkými, mali byzvážiť reorganizáciu do viacerých súdržných Scrum Teamov, z ktorých každý je zameraný na rovnaký
produkt. Preto by mali zdieľať rovnaký Product Goal, Product Backlog a Product Ownera.
Scrum Team je zodpovedný za všetky aktivity súvisiace s produktom od spolupráce zainteresovaných
strán, verifikáciu, podporu, prevádzku, experimentovanie, výskum, vývoj a čokoľvek iné, čo môže byť
potrebné. Sú štruktúrované a splnomocnené organizáciou riadiť svoju vlastnú prácu. Práca v Sprintoch vudržateľnom tempe zlepšuje zacielenie a konzistentnosť Scrum Teamu.
Celý Scrum Team je zodpovedný za vytvorenie hodnotného a užitočného Incrementu v každom Sprinte.
Scrum definuje tri dedikované zodpovednosti v rámci Scrum Teamu: Developeri, Product Owner a Scrum
Master.

Developeri
Developeri sú ľudia v Scrum Teame, ktorí sú odhodlaní vytvoriť akékoľvek vyhotovenie použiteľného
Incrementu v každom Sprinte.
Špecifické zručnosti, ktoré Developeri potrebujú, sú často široké a budú sa líšiť v závislosti od oblasti
práce. Developeri sú však vždy zodpovední za:●●●●

Vytvorenie plánu pre Sprint, Sprint Backlog;Udržiavanie kvality v súlade s Definition of Done;
Prispôsobenie svojho plánu každý deň voči Sprint Goalu; aVzájomné vedenie sa k zodpovednosti ako profesionáli.

6

Product Owner
Product Owner je zodpovedný za maximalizáciu hodnoty produktu, ktorá je výsledkom práce Scrum
Teamu. Spôsob, akým sa to robí, sa môže značne líšiť v rámci rôznych organizácií, Scrum Teamov ajednotlivcov.
Product Owner je tiež zodpovedný za efektívne riadenie Product Backlogu, ktoré zahŕňa:●●●●Vytvára a zrozumiteľne komunikuje Product Goal;
Tvorí a jasne komunikuje položky v Product Backlogu;
Usporiadava položky Product Backlogu; aZabezpečuje, aby Product Backlog bol transparentný, viditeľný a pochopiteľný.

Product Owner môže vykonávať vyššie uvedené práce sám alebo môže delegovať zodpovednosť nainých. Bez ohľadu na to, zodpovedným stále zostáva Product Owner.
Aby boli Product Owneri úspešní, celá organizácia musí rešpektovať ich rozhodnutia. Tieto rozhodnutia
sa odrážajú na obsahu a usporiadaní Product Backlogu a prostredníctvom preskúmateľného Incrementu
počas Sprint Review.
Product Owner je jedna osoba, nie komisia. Product Owner môže zastupovať potreby mnohých
zainteresovaných strán v Product Backlogu. Tí, ktorí chcú zmeniť Product Backlog to môžu urobiť tak, že
sa pokúsia presvedčiť Product Ownera.

Scrum MasterScrum Master je zodpovedný za zavedenie Scrumu tak, ako je definovaný v Scrum Guide. Robia to tak, žepomáhajú každému porozumieť teórii a praxi Scrumu, a to v rámci Scrum Teamu aj organizácie.
Scrum Master je zodpovedný za efektivitu Scrum Teamu. Robia to tak, že umožňujú Scrum Teamu zlepšiť
svoje postupy v Scrum rámci.
Scrum Masteri sú skutoční lídri, ktorí slúžia Scrum Teamu a širšej organizácii.
Scrum Master slúži Scrum Teamu niekoľkými spôsobmi, vrátane:●●●●

Koučuje členov tímu v samoriadení a v multiznalostnosti;
Pomáha Scrum Teamu zamerať sa na vytvorenie Incerementov s vysokou hodnotou, ktoréspĺňajú požiadavky Definition of Done;
Pomáha s odstránením prekážok Scrum Teamu; aZabezpečí, aby sa všetky Scrum podujatia uskutočnili a boli pozitívne, produktívne a časovoohraničené.

7

Scrum Master slúži Product Ownerovi niekoľkými spôsobmi, vrátane:●●●●

Pomáha pri hľadaní techník na efektívne definovanie Product Goalu a riadení Product Backlogu;
Pomáha Scrum Teamu pochopiť potrebu jasných a stručných položiek Product Backlogu;
Pomáha pri vytváraní empirického plánovania produktu v komplexnom prostredí; aFacilituje spoluprácu zainteresovaných strán podľa požiadaviek a potrieb.

Scrum Master slúži organizácii niekoľkými spôsobmi, vrátane:●●●●

Vedie, školí a koučuje organizáciu pri zavádzaní Scrumu;
Plánuje a radí pri implementácii Scrumu v organizácii;Pomáha zamestnancom a zainteresovaným stranám pochopiť a zaviesť empirický prístup pre
komplexnú prácu; aOdstraňuje bariéry medzi zainteresovanými stranami a Scrum Teamami.

Scrum Podujatia
Sprint zastrešuje všetky ostatné podujatia v Scrume. Každé podujatie v Scrume predstavuje oficiálnu
príležitosť na preskúmanie a prispôsobenie Scrumových artefaktov. Tieto podujatia sú zámerne
navrhnuté tak, aby zabezpečili požadovanú transparentnosť. Nevykonanie predpísaných podujatí má zanásledok stratu príležitosti na preskúmanie a prispôsobenie. Scrum podujatia slúžia na zavedenie
pravidelnosti a minimalizujú potrebu iných podujatí, ktoré Scrum nedefinuje. Pre zníženie komplexnostisa všetky podujatia dejú ideálne v rovnakom čase a na rovnakom mieste.

SprintSprinty predstavujú srdce Scrumu, v ktorom sa nápady menia na hodnotu.
Je to udalosť s konzistentne pevnou dĺžkou trvania jeden mesiac alebo menej. Nový Sprint začína hneďpo skončení predchádzajúceho Sprintu.
V Sprinte prebiehajú všetky práce potrebné na dosiahnutie Product Goalu, vrátane Sprint Planningu,
Daily Scrumov, Sprint Review a Sprint Retrospective.
Počas Sprintu:●●●●

Nie sú vykonávané žiadne zmeny, ktoré by ohrozovali Sprint Goal;
Nedochádza k znižovaniu kvality;
Product Backlog sa vylepšuje podľa potreby; aS pribúdajúcimi poznatkami je možné upresniť a prejednať rozsah práce s Product Ownerom.

8

Sprinty umožňujú predpovedateľnosť tak, že aspoň raz za mesiac zabezpečia preskúmanie aprispôsobenie postupu smerom k Product Goalu. Pokiaľ je trvanie Sprintu príliš dlhé, Sprint Goal sa zatiaľ
môže stať neplatným, môže narásť komplexnosť alebo riziko. Krátke Sprinty ponúkajú tvorbu viacerých
cyklov učenia a obmedzenie rizika nákladov a úsilia na kratšie časové obdobie. Každý Sprint možno
považovať za krátky projekt.
Existujú rôzne praktiky na predpovedanie postupu prác, ako napríklad burn-down či burn-up grafy alebo
kumulatívny flow. I keď sa tieto praktiky ukázali ako užitočné, nenahrádzajú dôležitosť empirického
prístupu. V komplexom prostredí nie je možné predpovedať čo sa stane. Pri rozhodovaní o budúcom
postupe sa teda dá oprieť iba o to, čo sa už stalo.
Sprint môže byť zrušený v prípade, že sa Sprint Goal stane zastaralým. Právo zrušiť Sprint má výlučne iba
Product Owner.

Sprint Planning
Sprint Planning sa deje na začiatku Sprintu a jeho cieľom je navrhnúť plán práce ktorá sa bude
vykonávať. Tento plán je výsledkom spolupráce celého Scrum Teamu.
Product Owner zabezpečí, že účastníci sú pripravení prediskutovať najdôležitejšie položky ProductBacklogu a ako sa viažu na Product Goal. Scrum Team môže prizvať ďalších účastníkov na Sprint Planningaby poskytli poradenstvo.
Sprint Planning sa venuje nasledovným témam:Prvá téma: Prečo má tento Sprint zmysel?
Celý Scrum Team potom spolupracuje na definovaní Sprint Goalu, ktorý zainteresovaným stranám
vysvetľuje, akú hodnotu Sprint prinesie. Sprint Goal musí byť hotový pred ukončením Sprint Planningu.

Druhá téma: Čo môže byť dokončené v tomto Sprinte?
Developeri, na základe diskusie s Product Ownerom, vyberú položky z Product Backlogu ktoré pôjdu do
tohto Sprintu. Scrum Team môže počas toho vybrané položky upresňovať, aby im lepšie rozumel a bol si
istejší.
Určiť koľko práce sa dá počas Sprintu dokončiť, môže byť náročné. Čím viac však Developeri vedia osvojich predošlých výkonoch, plánovanej kapacite a svojej Definition of Done, tým presnejší budú vo
svojich prognózach Sprintu.

Tretia téma: Ako sa bude vybraná práca vykonávať?
9

Pre každú vybratú položku Product Backlogu, naplánujú Developeri prácu potrebnú na vytvorenie
Incrementu, ktorý spĺňa Definition of Done. Často sa to robí rozdelením položiek Product Backlogu na
menšie pracovné položky v trvaní jedného dňa alebo menej. Je na výhradnom uvážení Developerov ako
k tomu pristúpia. Nikto im nehovorí, ako meniť položky Product Backlogu na hodnotné Incrementy.
Sprint Goal, položky Product Backlogu vybrané do Sprintu a plán na ich splnenie, sa spoločne nazývajú
Sprint Backlog.
Sprint Planning je časovo ohraničený na maximálne osem hodín pre jednomesačný Sprint. Pre kratší
Sprint je podujatie zvyčajne kratšie.

Daily ScrumÚčelom Daily Scrumu je preskúmať postup smerom k Sprint Goalu a podľa potreby upraviť ďalšiu
naplánovanú prácu.
Daily Scrum je 15 minútové podujatie pre Developerov Scrum Teamu. Pre zníženie komplexnosti saorganizuje v rovnakom čase a na rovnakom mieste každý pracovný deň Sprintu. Pokiaľ Product Owner
alebo Scrum Master aktívne pracujú na položkách Sprint Backlogu, účastnia sa stretnutia ako by boli
Developeri.
Pokiaľ Developeri dodržia podmienku, že sa budú sústrediť na postup smerom k Sprint Goalu a vytvoriaakčný plán na ďalší pracovný deň, môžu si na vedenie Daily Scrumu zvoliť ľubovolnú štruktúru atechniku. To zacieli pozornosť a zlepšuje samoriadenie.
Daily Scrumy zlepšujú komunikáciu, identifikujú prekážky, podporujú rýchle rozhodovanie a následne
eliminujú potrebu ďalších stretnutí.
Daily Scrum nie je jedinou príležitosťou, kedy môžu Developeri prispôsobiť svoj plán. Často sa stretávajú
aj v priebehu dňa, kvôli podrobnejším diskusiám ohľadom prispôsobenia a preplánovania zostávajúcej
práce v Sprinte.

Sprint ReviewÚčelom Sprint Review je preskúmať výsledok Sprintu a určiť prispôsobenia do budúcnosti. Scrum Teamprezentuje výsledky svojej práce kľúčovým zainteresovaným stranám a spoločne diskutujú o pokroku
smerom k Product Goalu.
Počas stretnutia Scrum Team a zainteresované strany vyhodnocujú, čo sa v Sprinte dosiahlo a čo sa v ich
oblasti zmenilo. Na základe týchto informácií, účastníci spoluvytvárajú ďalší postup. Product Backlog satiež môže upraviť tak, aby zohľadňoval nové príležitosti. Sprint Review je pracovné podujatie a Scrum
Team by ho nemal obmedzovať len na prezentáciu.
10

Sprint Review je predposledné podujatie Sprintu a je časovo ohraničené na maximálne štyri hodiny pre
jednomesačný Sprint. Pre kratší Sprint je podujatie zvyčajne kratšie.

Sprint RetrospectiveÚčelom Sprint Retrospective je určiť si spôsob ako zvýšiť kvalitu a efektívnosť.
Scrum Team preskúma ako prebehol posledný Sprint s ohľadom na ľudí, interakcie, procesy, nástroje aich Definition of Done. Skúmané prvky sa často líšia vzhľadom na oblasť práce. Identifikujú sa
predpoklady, ktoré ich odchýlili, a skúma sa ich pôvod. Scrum Team diskutuje o tom, čo počas Sprintu
fungovalo dobre, na aké problémy narazili a ako boli (alebo neboli) tieto problémy vyriešené.
Scrum Team identifikuje zmeny, ktoré by najviac prispeli k zlepšeniu jeho efektívnosti. Zlepšenia s
najväčším dopadom sa implementujú hneď ako je to len možné. Môžu byť dokonca pridané do Sprint
Backlogu nasledujúceho Sprintu.
Sprint Retrospective uzatvára Sprint. Je časovo ohraničené na maximálne tri hodiny pre jednomesačný
Sprint. Pre kratší Sprint je podujatie zvyčajne kratšie.

Scrum Artefakty
Scrum artefakty symbolizujú prácu alebo hodnotu. Sú postavené tak, že kľúčové informácie súmaximálne transparentné. Vďaka tomu má každý kto ich preskúmava rovnaký základ na prispôsobenie.
Každý artefakt obsahuje záväzok, ktorý má za úlohu poskytovať také informácie, ktoré zvyšujú
transparentnosť a zacielenie, voči ktorému je možné merať pokrok:●●●

Pre Product Backlog je to Product Goal.
Pre Sprint Backlog je to Sprint Goal.
Pre Increment je to Definition of Done.

Tieto záväzky existujú za účelom posilnenia empirizmu a Scrum hodnôt pre Scrum Team azainteresované strany.

Product Backlog
Product Backlog je neustále sa vyvíjajúci zoradený zoznam toho, čo je potrebné urobiť pre vylepšenie
produktu. Ide o jediný zdroj práce ktorú vykonáva Scrum Team.
Položky Product Backlogu ktoré sú pripravené a ktoré môže Scrum Team dokončiť v rámci jedného
Sprintu, sa vyberajú počas Sprint Planningu. Tento stupeň transparentnosti obvykle dosiahnu po rade11

upresňujúcich a vyjasňovacích aktivít. Product Backlog Refinement je akt rozloženia a detailnejšia
definícia jeho položiek na menšie, presnejšie položky. Jedná sa o neustále prebiehajúcu aktivitu, počas
ktorej sú pridávané podrobností ako je popis, poradie a veľkosť. Atribúty sa často líšia podľa oblasti
práce.
Za určovanie náročnosti sú zodpovední Developeri, ktorí budú danú prácu robiť. Product Owner môžeusmerňovať Developerov tým, že im ju pomáha pochopiť a zvoliť si kompromis.

Záväzok: Product Goal
Product Goal popisuje budúci stav produktu ktorý slúži ako cieľ voči ktorému Scrum Team plánuje.
Product Goal je súčasťou Product Backlogu. Zvyšok Product Backlogu postupne v čase definuje “čo”
bude napĺňať Product Goal.
Produkt je prostriedok na doručenie hodnoty. Má jasné hranice, známe zaintersované strany,
dobre definovaných užívateľov alebo zákazníkov. Produktom môže byť služba, fyzický produkt
alebo niečo abstraktnejšie.
Product Goal je pre Scrum Team dlhodobý zámer. Scrum Team musí najprv splniť (alebo opustiť) jeden
Product Goal, než sa pustí do ďalšieho.

Sprint Backlog
Sprint Backlog sa skladá zo Sprint Goalu (prečo), skupiny položiek Product Backlogu vybraných pre Sprint(čo) a akčného plánu pre dodanie Incrementu (ako).
Sprint Backlog je plán vytvorený Developermi a určený pre nich samých. Ide o veľmi jasný stav práce v
reálnom čase, ktorú Developeri plánujú dokončiť počas Sprintu, aby dosiahli Sprint Goal. Na základenových poznatkov sa počas Sprintu priebežne aktualizuje. Mal by obsahovať dostatok podrobností na to,aby bolo možné preskúmať postup počas Daily Scrumu.

Záväzok: Sprint Goal
Sprint Goal je jediným cieľom, ktorý tím v Sprinte má. Hoci je Sprint Goal záväzkom Developerov,
poskytuje flexibilitu v rámci toho ako presne vykonať prácu, ktorá je potrebná na jeho dosiahnutie.
Sprint Goal podporuje súdržnosť a zacielenie, povzbudzuje Scrum Team k spolupráci skôr než aby sa
pracovalo na samostatných iniciatívach.
Sprint Goal je vytvorený počas Sprint Planningu a potom je pridaný do Sprint Backlogu. Developeri majú
počas Sprintu neustále na pamäti Sprint Goal . Pokiaľ sa ukáže, že treba robiť niečo neočakávané, takpočas Sprintu Developeri s Product Ownerom spolupracujú na dojednaní zmeny rozsahu prác v Sprint
Backlogu tak, aby nebol ovplyvnený Sprint Goal.
12

Increment
Increment je jedným zo stavebných kameňov na dosiahnutie Product Goalu. Každý Increment sa pridáku všetkým predchádzajúcim Incrementom a je dôkladne verifikovaný, že s nimi funguje. Aby mal
hodnotu, musí byť Increment použiteľný.
V Sprinte môže byť vytvorených viacero Incrementov. Súhrn Incrementov je prezentovaný počas Sprint
Review, čo podporuje empirizmus. Increment však môže byť zainteresovaným stranám doručený aj predukončením Sprintu. Sprint Review by sa nikdy nemalo považovať za podmienku na doručenie hodnoty.
Prácu nemožno považovať za súčasť Incrementu pokiaľ nespĺňa Definition of Done.

Záväzok: Definition of Done
Ak Increment spĺňa požadované parametre kvality pre daný produkt, tak Definition of Done formálne
popisuje stav jeho dokončenia.
Increment vznikne v okamihu, keď položka Product Backlogu spĺňa Definition of Done.
Definition of Done podporuje transparentnosť tak, že všetci rovnako rozumejú tomu, aká práca bola na
Incremente dokončená. Ak položka Product Backlogu nespĺňa Definition of Done, nemôže byť doručená
alebo dokonca prezentovaná na Sprint Review. Namiesto toho sa vráti do Product Backlogu preopätovné zváženie.
Pokiaľ je Definition of Done pre Increment súčasťou štandardov celej organizácie, musia ju dodržiavať
všetky Scrum Teamy ako minimum. Pokiaľ sa nejedná o štandard v celej organizácii, musí Scrum Team
vytvoriť vhodnú Definition of Done pre každý produkt.
Developeri sú povinní dodržiavať Definition of Done. Pokiaľ na produkte spolupracuje viac Scrum
Teamov, musia spoločne definovať a dodržiavať rovnakú Definition of Done.

Slovník
Commitment
Daily Scrum
Definition of Done
Developers
Framework
Increment
Inspect & adapt
Product Backlog
Product Goal

ZáväzokDenný Scrum
Definícia hotového
Developeri
Rámec
Inkrement
Preskúmanie & prispôsobenie
Produktový backlog
Produktový cieľ13

Product Owner
Scrum
Scrum Artefacts
Scrum Events
Scrum MasterScrum Team
Scrum Values
SprintSprint Backlog
Sprint Goal
Sprint Planning
Sprint Retrospective
Sprint Review

Produktový vlastník
Scrum
Scrum artefakty
Scrum podujatia
Scrum MasterScrum Tím
Scrum hodnoty
SprintBacklog sprintuCieľ sprintu
Plánovanie sprintu
Retrospektíva sprintu
Vyhodnotenie sprintu

Poznámka na záver
Scrum je zadarmo a ponúkaný v tomto Sprievodcovi. Scrum rámec tak, ako je v tomto dokumentenačrtnutý, je nemenný. Aj keď je možné implementovať iba časti Scrumu, výsledkom nie je Scrum.
Scrum existuje iba ako celok a funguje dobre ako rámec pre ďalšie techniky, metodiky a postupy.

PoďakovanieĽudiaZ tisícok ľudí, ktorí Scrumu prispeli, by sme chceli spomenúť tých, ktorí boli pri samom zrode: Jeff
Sutherland pracoval s Jeffom McKennom a Johnom Scumniotalesom a Ken Schwaber s Mikom Smithoma Chrisom Martinom a všetci spolupracovali dohromady. Mnoho ďalších v nasledujúcich rokoch prispelo
a bez ich pomoci by Scrum nebol vycibrený tak, ako je tomu dnes.

História Scrum Sprievodcu
Ken Schwaber a Jeff Sutherland prvýkrát spoločne predstavili Scrum na konferencii OOPSLA v roku 1995.
V podstate išlo o dokumentáciu toho, čo sa Ken a Jeff v priebehu niekoľkých predchádzajúcich rokov
naučili a čo uverejnili ako prvú formálnu definíciu Scrumu.
Sprievodca Scrumom dokumentuje Scrum tak, ako ho Jeff Sutherland a Ken Schwaber vymysleli, vyvíjali
a udržiavali po dobu viac ako 30 rokov. Existujú aj iné zdroje poskytujúce vzorce, procesy a poznatky,
ktoré dopĺňajú Scrum rámec. Tie môžu zvýšiť produktivitu, hodnotu, kreativitu a spokojnosť svýsledkami.

14

Kompletná história Scrumu je popísaná inde. Aby sme vzdali hold prvým miestam, kde bol vyskúšaný a
kde sa osvedčil, uvádzame spoločnosti Individual Inc., Newspage, Fidelity Investments a IDX (teraz GE
Medical).

Poďakovanie prekladateľom
Táto Príručka Scrumu bola preložená z pôvodnej anglickej verzie, ktorú poskytli jej vyššie ocenení
tvorcovia. K prekladu prispeli Radoslav Ciglanský (radoslav.ciglansky@gmail.com,
https://www.linkedin.com/in/radoslavciglansky/), Dušan Karáč (dusan.karac@gmail.com,
www.linkedin.com/in/dusan-karac) a Diana Rusnáková (rusnakovadia@gmail.com,
https://www.linkedin.com/in/dianarusnakova/)

Rozdiely medzi Scrum Sprievodcami 2017 a 2020
Ešte menej normatívne
V priebehu rokov sa Scrum Sprievodca začal stávať príliš normatívnym. Verzia 2020 má za cieľ priviesť
Scrum späť k minimalistickému a postačujúcemu rámcu odstránením alebo zmiernením normatívneho
jazyka. napr. odstránením povinných otázok v Daily Scrume, zjemnenie jazyka okolo atribútov PBI,
zjemnenie jazyka okolo položiek z retrospektívy v Sprint Backlogu, skrátenie sekcie zrušenia Sprintu apodobne.

Jeden tím, zameraný na jeden produktCieľom bolo eliminovať predstavu samostatného tímu v tíme, ktorá viedla k zavedeniu vzťahov ako„proxy - zástupca“ či „my a oni“ medzi PO a Developermi. Teraz existuje iba jeden Scrum Teamzameraný na rovnaký cieľ, s tromi rôznymi skupinami zodpovedností: PO, SM a Developeri.

Zavedenie Product Goalu
Scrum Sprievodca 2020 predstavuje pojem Product Goal, aby sa Scrum Team zameral na cieľ s vyššou
pridanou hodnotou. Každý Sprint by mal priblížiť produkt k celkovému Product Goalu.

Miesto pre Sprint Goal, Definition of Done a Product Goal
Predchádzajúci Scrum Sprievodcovia popisovali Sprint Goal a Definition of Done bez toho, aby im dalináležité miesto. Neboli to celkom artefakty, ale boli do istej miery spojené s artefaktmi. Verzia 2020 s
pridaním Product Goalu poskytuje v tejto veci vyššiu jasnosť. Každý z troch artefaktov teraz obsahuje
vlastné „záväzky“. Pre Product Backlog je to Product Goal, Sprint Backlog má Sprint Goal a Increment máDefinition of Done (teraz bez úvodzoviek). Existujú preto, aby priniesli transparentnosť a sústredenosť
na progres každého artefaktu.
15

Samoriadenie namiesto sebaorganizovanie
Predchádzajúci Scrum Sprievodcovia hovoria o Developerských tímoch ako o samoorganizujúcich sa
tímoch, ktoré si vyberajú, kto a ako bude pracovať. Verzia 2020, ktorá sa viac zameriava na Scrum Team,
kladie dôraz na samoriadiaci Scrum Team, ten ktorý si vyberá, kto, ako a na čom bude pracovať.

Tri témy Sprint Planningu
Okrem ústredných tém Sprint Planningu tj. „Čo“ a „Ako“, kladie Scrum Sprievodca 2020 dôraz na tretiu
tému a to „Prečo“, teda dôraz na Sprint Goal.

Celkové zjednodušenie jazyka pre širšie publikum
Scrum Sprievodca 2020 kladie dôraz na odstránenie nadbytočných a zložitých tvrdení, ako aj na
odstránenie predošlých súvislosti s IT svetom (ako napr. testovanie, systém, dizajn, požiadavka atď.).
Scrum Sprievodca má teraz menej ako 13 strán.

16