Scrum Guide

Záměr Průvodce Scrumem

Scrum jsme vyvinuli počátkem 90. let. První verzi Průvodce Scrumem jsme napsali v roce 2010, abychom pomohli lidem na celém světě Scrumu porozumět. Od té doby jsme průvodce rozvíjeli skrze malé, funkční změny.

Tento průvodce obsahuje definici Scrumu. Každý prvek tohoto frameworku slouží konkrétnímu účelu, který je nezbytný k tomu, aby Scrum přinesl celkovou zamýšlenou hodnotu a výsledky.  Změny základního nastavení nebo principů Scrumu, vynechání prvků nebo nedodržování pravidel Scrumu zakrývá problémy a omezuje jeho přínosy, což ho může dokonce učinit nepoužitelným.

Sledujeme rostoucí počet uživatelů Scrumu ve stále narůstajícím světě komplexity. S pokorou sledujeme adopci Scrumu v mnoha oblastech, stojících převážně na komplexní práci, velmi vzdálených vývoji softwarových produktů, kde má Scrum své kořeny. Jak se Scrum šíří, pracují s ním vývojáři, výzkumníci, analytici, vědci a další specialisté. Slovo “vývojáři” nepoužíváme k vyloučení ostatních, ale ke zjednodušení. Pokud je pro vás Scrum užitečný, je pro vás.

Při používání Scrumu můžete najít, aplikovat či navrhnout vlastní vzory a procesy, které jsou v souladu se Scrumem, jak je popsán v tomto průvodci. Jejich popis přesahuje účel průvodce, protože závisí na kontextu a výrazně se liší dle situace. Takové postupy se v rámci Scrumu mohou i významně lišit a jsou popsány jinde.

Ken Schwaber & Jeff Sutherland Listopad 2020

Definice Scrumu

Scrum je jednoduchý framework, který pomáhá lidem, týmům a organizacím vytvářet hodnotu skrze adaptivní řešení komplexních problémů.

V kostce, Scrum vyžaduje Scrum Mastera, aby pěstoval prostředí, kde:

1. Product Owner řadí práci na komplexním problému do Backlogu Produktu.
2. Scrumový tým přetvoří během Sprintu zvolené položky z Backlogu v hodnotný Inkrement.
3. Scrumový tým a další zainteresované strany (stakeholders) revidují výsledek a přizpůsobí náležitě své budoucí plány pro další Sprint.
4. Opakujte

Scrum je jednoduchý. Vyzkoušejte jej tak, jak je definován, a zjistěte, zda vám jeho filozofie, teorie a struktura pomáhají v dosahování cílů a ve vytváření hodnoty. Framework Scrum je záměrně neúplný, definuje pouze části potřebné k implementaci jeho teorie. Scrum je postaven na kolektivní inteligenci lidí, kteří jej používají. Spíše, než aby poskytoval lidem podrobné pokyny, pravidla Scrumu definují jejich vztahy a interakce.

V rámci frameworku mohou být použity různé procesy, techniky a metody. Scrum zahrnuje stávající postupy nebo je činí zbytečnými. Scrum zviditelňuje relativní účinnost současného řízení, prostředí a pracovních technik tak, aby bylo možné provést zlepšení.

Teorie Scrumu

Scrum je založen na empirismu a štíhlém myšlení (lean thinking). V empirismu znalosti vycházejí ze zkušeností a rozhodování na základě pozorování. Štíhlé myšlení omezuje plýtvání a zaměřuje se na to podstatné.

Scrum využívá iterativní, inkrementální přístup k optimalizaci předvídatelnosti a k řízení rizika. Scrum zapojuje skupiny lidí mající společně všechny potřebné dovednosti a odborné znalosti k tomu, aby mohli vykonávat danou práci a sdílet nebo získávat tyto dovednosti podle potřeby.

Scrum kombinuje čtyři formální události pro prozkoumávání (inspection) a přizpůsobení (adaptation), a to v rámci souhrnné události, která nazývá Sprint. Tyto události fungují, protože implementují empirické pilíře Scrumu – transparentnost, pozorování (inspection) a přizpůsobení.

Transparentnost

Vznikající proces a práce musí být viditelné jak pro osoby provádějící práci, tak pro ty, kteří přijímají výsledky. U Scrumu jsou důležitá rozhodnutí založená na vnímaném stavu jeho tří formálních artefaktů. Artefakty, které mají nízkou transparentnost, mohou vést k rozhodnutím, která snižují hodnotu a zvyšují riziko.

Transparentnost umožňuje pozorování. Pozorování bez transparentnosti je zavádějící a plýtvavé.

Pozorování (Inspection)

Artefakty Scrumu a pokrok směrem k dohodnutým cílům musí být často a svědomitě pozorovány tak, aby se zjistily potenciálně nežádoucí odchylky nebo problémy. Aby pomohl s pozorováním, Scrum poskytuje rytmus v podobě svých pěti událostí.

Pozorování umožňuje přizpůsobení. Pozorování bez přizpůsobení je považováno za zbytečné. Scrumové události jsou navrženy tak, aby vyprovokovaly změnu.

Přizpůsobení (Adaptation)

Pokud se některé aspekty procesu odchylují mimo přijatelné limity nebo je-li výsledný Produkt nepřijatelný, musí být aplikovaný proces nebo vytvářené výsledky upraveny. Úprava musí být provedena co nejdříve, aby se minimalizovala další odchylka.

Adaptace se stává obtížnější, když zúčastnění lidé nejsou zmocněni nebo sebeřízení. Očekává se, že se Scrumový tým přizpůsobí v okamžiku, kdy se prostřednictvím pozorování naučí něco nového.

Hodnoty Scrumu

Úspěšné použití Scrumu závisí na tom, jak zdatně zvládnou lidé naplňovat těchto pět hodnot:

odhodlání (commitment), zaměření (focus), otevřenost (openness), respekt (respect) a kuráž (courage)

Scrumový tým je odhodlaný k dosažení svých cílů a vzájemné podpoře. Jeho primární zaměření je na práci v rámci Sprintu tak, aby dosáhl co nejlepšího pokroku při plnění těchto cílů. Scrumový tým a jeho stakeholdeři jsou ohledně práce a výzev otevřeni. Členové Scrumového týmu se navzájem respektují, aby z nich byli schopní, nezávislí lidé, a jsou tak respektováni i dalšími spolupracovníky. Členové Scrumového týmu mají kuráž dělat správnou věc a pracovat na náročných problémech.

Tyto hodnoty udávají směr Scrumového týmu s ohledem na jeho práci, jednání a chování. Rozhodnutí, která učiní, přijatá opatření a způsob, jakým se Scrum používá, by měla tyto hodnoty posílit, nikoli je snížit nebo podkopat. Členové Scrumového týmu se učí a prozkoumávají hodnoty při práci s událostmi a artefakty Scrumu. Když Scrumový tým a jeho spolupracovníci žijí těmito hodnotami, empirické pilíře transparentnosti, pozorování a přizpůsobení Scrumu přichází k životu a budují důvěru.

Scrumový tým

Základní jednotkou Scrumu je malý tým lidí, Scrumový tým. Scrumový tým se skládá z jednoho Scrum Mastera (obvykle se nepřekládá), jednoho Product Ownera (Vlastníka Produktu, obvykle se používá anglický termín) a Vývojářů (Developers).

V Scrumovém týmu nejsou žádné dílčí týmy ani hierarchie. Jedná se o soudržnou jednotku profesionálů zaměřenou vždy jen na jeden cíl naráz, na Cíl Produktu.

Scrumové týmy jsou multi-oborové (cross-functional), což znamená, že členové týmu mají v souhrnu všechny dovednosti potřebné k vytvoření hodnoty v každém Sprintu. Jsou také sebeřídící (self-managing), což znamená, že interně rozhodují, co kdo dělá, kdy a jak.

Scrumový tým je dostatečně malý, aby zůstal svižný, a dostatečně velký, aby byl schopen dokončit v rámci Sprintu významnou práci. Obvykle do 10 lidí. Obecně jsme zjistili, že menší týmy lépe komunikují a jsou produktivnější. Pokud Scrumový tým příliš naroste, měl by zvážit reorganizaci do více soudržných Scrumových týmů, zaměřených na stejný Produkt. Tudíž by měly sdílet stejný Cíl Produktu, Backlog Produktu a Product Ownera.

Scrumový tým je odpovědný za všechny činnosti související s Produktem, od spolupráce se stakeholdery, ověřování, údržby, provozu, experimentování, výzkumu a vývoje a čehokoliv dalšího, co může být potřeba. Organizace je strukturuje a zmocňuje k řízení vlastní práce. Práce ve Sprintech udržitelným tempem zlepšuje zaměření a konzistentnost Scrumového týmu.

Celý Scrumový tým je odpovědný za vytváření hodnotného a užitečného Inkrementu v každém Sprintu. Scrum definuje tři specifické odpovědnosti ve Scrumovém týmu: Vývojáři, Product Owner a Scrum Master.

Vývojáři (Developers)

Vývojáři jsou lidé ve Scrumovém týmu, odhodlaní vytvářet jakýkoliv aspekt použitelného Inkrementu v každém Sprintu.

Specifické dovednosti, které Vývojáři potřebují, jsou často široké a budou se lišit podle oblasti či domény práce. Nicméně Vývojáři vždy:

• vytváří plán Sprintu a Backlogu Sprintu,
• zajišťují kvalitu dodržováním Definition of Done (definice hotového),
• přizpůsobují svůj plán směrem k Cíli Sprintu a
• nesou odpovědnost jeden vůči druhému jako profesionálové.

Product Owner (Vlastník Produktu)

Product Owner je odpovědný za maximalizaci hodnoty Produktu vytvářeného Scrumovým týmem. Způsob, jakým toho dosahuje, se výrazně liší napříč organizacemi, Scrumovými týmy i jednotlivci.

Product Owner je také odpovědný za efektivní správu Backlogu Produktu, tedy:

• rozvíjí a otevřeně komunikuje Cíl Produktu,
• vytváří a jasně komunikuje položky Backlogu Produktu,
• řadí položky Backlogu Produktu a
• zajišťuje, že Backlog Produktu je transparentní, viditelný a pochopený.

Product Owner může provádět výše uvedenou práci sám, nebo ji může delegovat na někoho jiného. Bez ohledu na to ale za ni zůstává Product Owner odpovědný.

Aby Product Owneři uspěli, musí celá organizace respektovat jejich rozhodnutí. Tato rozhodnutí se odrážejí v obsahu a řazení Backlogu Produktu a prostřednictvím Inkrementů prověřovaných během Vyhodnocení Sprintu (Sprint Review).

Product Owner je jedna osoba, ne skupina lidí. Product Owner může v rámci jednoho Backlogu Produktu reprezentovat potřeby mnoha zainteresovaných stran (stakeholderů). Ti, kdo chtějí změnit Backlog Produktu, se o tom mohou pokusit přesvědčit Product Ownera.

Scrum Master

Scrum Master je odpovědný za zavedení Scrumu tak, jak je definován v Průvodci Scrumu. Pomáhá ostatním porozumět teorii a praxi Scrumu, a to jak v rámci Scrumového týmu, tak v rámci celé organizace.

Scrum Master odpovídá za efektivnost Scrumového týmu. Umožňuje mu vylepšovat své postupy, v rámci Scrumu.

Scrum Masteři jsou skuteční lídři, kteří slouží Scrumovému týmu a širší organizaci.

Scrum Master slouží Scrumovému týmu mimo jiné tím, že:

• koučuje členy týmu v sebeřízení a multi-oborovosti,
• pomáhá Scrumovému týmu zaměřit se na vytváření hodnotých Inkrementů, které splňují Definition of Done,
• iniciuje odstraňování překážek v práci Scrumového týmu a
• zajišťuje, aby se uskutečňovaly všechny Scrumové události a byly pozitivní, produktivní a držely se v časovém rámci.

Scrum Master slouží Product Ownerovi mimo jiné tím, že:

• pomáhá nacházet techniky pro efektivní definici Cíle Produktu a správu Backlogu Produktu,
• pomáhá Scrumovému týmu pochopit potřebu jasných a stručných položek Backlogu Produktu;
• pomáhá zavádět empirické plánování Produktu v komplexním prostředí a
• facilituje spolupráci zainteresovaných stran dle potřeby, nebo když je požádán.

Scrum Master slouží organizaci mimo jiné tím, že:

• vede, školí a koučuje organizaci v adopci Scrumu,
• plánuje a radí při zavádění Scrumu v rámci organizace,
• pomáhá zaměstnancům a zainteresovaným stranám porozumět a ustanovit empirický přístup pro komplexní práci a
• odstraňuje bariéry mezi zainteresovanými stranami a Scrumovými týmy.

Scrumové události (Scrum Events)

Sprint obsahuje všechny ostatní události Scrumu. Každá událost ve Scrumu představuje formální příležitost k empirickému pozorování a následnému přizpůsobení Scrumových artefaktů.

Tyto události jsou specificky navrženy tak, aby umožňovaly potřebnou transparentnost. Pokud nepovedete události, jak je zde předepsáno, ztratíte příležitosti k inspekci a adaptaci (inspect and adapt). Události ve Scrumu vytvářejí pravidelnost a minimalizují potřeby schůzek, které Scrum nedefinuje.

Všechny události jsou ideálně ve stejný čas na stejném místě, což snižuje komplexitu.

Sprint

Sprinty tvoří ve Scrumu přirozený rytmus, ve kterém jsou idey přetvářeny v hodnotu.

Sprinty mají pro konzistentnost pevnou délku jednoho měsíce nebo méně. Nový Sprint začíná ihned po skončení předchozího Sprintu.

Ve Sprintech probíhá veškerá práce nezbytná k dosažení Cíle Produktu, včetně Plánování Sprintu (Sprint Planning), Denních Scrumů (Daily Scrums), Vyhodnocení Sprintu (Sprint Review) a Retrospektivy Sprintu (Sprint Retrospective).

Během Sprintu:

• Nejsou prováděny žádné změny, které by ohrozily Cíl Sprintu.
• Nedochází ke snižování kvality.
• Backlog Produktu je vyjasňován podle potřeby.
• Jak během Sprintu zjišťujete nové informace, můžete dopřesnit a projednat rozsah práce (scope) s Product Ownerem.

Sprinty umožňují předvídatelnost tím, že alespoň jednou za měsíc zajistí prozkoumání a přizpůsobení postupu směrem k Cíli Produktu. Pokud je délka Sprintu příliš dlouhá, Cíl Sprintu může zastarat, nebo může narůst komplexita anebo riziko. Kratší Sprinty vytváří rychlejší učící cyklus a snižují nákladové riziko na kratší období. Každý Sprint lze považovat za krátký projekt.

Pro předvídání postupu existují různé praktiky, jako jsou burn-down či burn-up grafy nebo kumulativní flow. I když se tyto praktiky ukázaly jako užitečné, nenahrazují důležitost empirického přístupu. V komplexních prostředích není možné předpovídat, co nastane. K rozhodování o budoucím postupu tak lze použít pouze to, co již nastalo.

Sprint může být zrušen, pokud Cíl Sprintu zastará. Oprávnění zrušit Sprint má pouze Product Owner.

Plánování Sprintu (Sprint Planning)

Sprint je zahájen Plánováním Sprintu k rozvržení práce, která má být ve Sprintu provedena. Tento výsledný plán spoluvytváří celý Scrumový tým.

Product Owner zajišťuje, že účastníci jsou připraveni diskutovat nejdůležitější položky Backlogu Produktu a jak souvisí s Cílem Produktu. Scrumový tým může přizvat další účastníky, aby poradili a pomohli.

Plánování Sprintu pokrývá následující témata:

První téma: Proč je tento Sprint hodnotný?

Product Owner navrhuje, jak by Produkt mohl v tomto Sprintu zvýšit svou hodnotu a přínos. Celý Scrumový tým poté spolupracuje na definování Cíle Sprintu, který stakeholderům říká, jakou hodnotu jim Sprint přinese. Cíl Sprintu musí být definován před koncem Plánování Sprintu.

Druhé téma: Co lze tento Sprint dokončit?

Na základě diskuse s Product Ownerem vyberou  Vývojáři z Backlogu Produktu položky pro tento Sprint. Scrumový tým může během tohoto procesu vybrané položky upřesňovat a vyjasňovat, aby jim lépe rozuměl a byl si jistější.

Zvolit, kolik práce lze ve Sprintu dokončit, může být náročné. Čím více však Vývojáři vědí o své dosavadní výkonnosti, nadcházející kapacitě a Definition of Done, tím jistější budou ve svých předpovědích pro nadcházející Sprint.

Téma třetí: Jak bude vybraná práce provedena?

Vývojáři naplánují pro každou vybranou položku Backlogu Produktu práci nezbytnou k vytvoření Inkrementu, který naplňuje Definition of Done. To se často provádí rozpadem položek Backlogu Produktu na menší pracovní položky v rozsahu jeden den nebo méně. Jak k tomu přistoupí, závisí čistě na úsudku Vývojářů. Nikdo jiný jim neříká, jak proměnit položky Backlogu Produktu na hodnotné Inkrementy.

Cíl Sprintu, položky Backlogu Produktu vybrané pro Sprint a plán, jak budou dodány, se společně označují jako Backlog Sprintu.

Plánování Sprintu je časově omezeno, a to maximálně osmi hodinami pro Sprint o délce jednoho měsíce. Pro kratší Sprinty je událost obvykle kratší.

Denní Scrum (Daily Scrum)

Účelem Denního Scrumu je prozkoumat postup směrem k Cíli Sprintu a podle potřeby upravit na plánovanou práci Backlogu Sprintu.

Denní Scrum je 15ti minutová událost pro Vývojáře Scrumového týmu. Pro jednoduchost se koná ve stejný čas a na stejném místě každý pracovní den Sprintu. Pokud Product Owner nebo Scrum Master aktivně pracují na položkách Backlogu Sprintu, účastní se společně s Vývojáři.

Vývojáři mohou pro vedení Denního Scrumu zvolit libovolnou strukturu a techniky, dokud dodrží podmínku, že se zaměřují na postup směrem k Cíli Sprintu a vytvoří akční plán na další pracovní den. To zajišťuje pozornost a rozvíjí sebeřízení.

Denní Scrum zlepšuje komunikaci, identifikuje překážky, podporuje rychlé rozhodování a následně eliminuje potřebu dalších schůzek.

Denní Scrum není jedinou příležitostí, kdy Vývojáři mohou upravit svůj plán. Často se setkávají i v průběhu dne, aby diskutovali detaily zbývající práce ve Sprintu a přizpůsobili ji aktuální situaci nebo ji přeplánovali.

Vyhodnocení Sprintu (Sprint Review)

Účelem Vyhodnocení Sprintu je prozkoumat výsledek Sprintu a určit budoucí změny. Scrumový tým prezentuje výsledky své práce klíčovým stakeholderům a společně diskutují o pokroku směrem k Cíli Produktu.

Během události Scrumový tým a stakeholdeři vyhodnocují, čeho bylo ve Sprintu dosaženo a co se změnilo v jejich prostředí. Na základě těchto informací účastníci spolupracují na dalším postupu. Backlog Produktu může být také upraven tak, aby zohledňoval nové příležitosti. Vyhodnocení Sprintu je pracovním setkáním a Scrumový tým by ji neměl omezovat pouze na prezentaci.

Vyhodnocení Sprintu je předposlední událostí Sprintu a je časově omezena maximálně čtyřmi hodinami pro Sprint o délce jednoho měsíce. Pro kratších Sprinty je událost obvykle kratší.

Retrospektiva Sprintu (Sprint Retrospective)

Účelem Retrospektivy Sprintu je naplánovat způsoby, jak zvýšit kvalitu a efektivnost.

Scrumový tým zkoumá, jak proběhl poslední Sprint s ohledem na jednotlivce, interakce, procesy, nástroje a svou Definition of Done. Zkoumané prvky se často liší vzhledem k oblasti práce. Scrumový tým identifikuje mylné předpoklady a zkoumá jejich původ. Diskutuje o tom, co šlo během Sprintu dobře, na jaké problémy narazil a jak byly (nebo nebyly) tyto problémy vyřešeny.

Scrumový tým určuje změny, které by nejvíce pomohly ke zlepšení své efektivnosti. Vylepšení s největším dopadem řeší, co nejdříve je to možné. Mohou být dokonce přidány do Backlogu Sprintu pro příští Sprint.

Retrospektiva Sprintu uzavírá Sprint. Pro měsíční Sprint je časově omezena maximálně třemi hodinami. Pro kratší Sprinty je událost obvykle kratší.

Artefakty Scrumu

Artefakty Scrumu symbolizují práci nebo hodnotu. Jsou navrženy tak, aby maximalizovaly transparentnost klíčových informací. Díky tomu má každý, kdo je prozkoumává, stejný podklad pro přizpůsobení.

Každý artefakt obsahuje závazek (commitment) poskytující informace, zvyšující transparentnost a zaměření (focus), a na základě kterých lze měřit postup.

• Pro Backlog Produktu je to Cíl Produktu.
• Pro Backlog Sprintu je to Cíl Sprintu.
• Pro Inkrement je to Definition of Done.

Tyto závazky existují za účelem posílení empirismu a hodnot Scrumu pro Scrumový tým a jejich stakeholdery.

Backlog Produktu

Backlog Produktu je seřazený neustále se vyvíjející seznam všeho, co je potřebné pro vylepšení produktu. Jedná se o jediný zdroj práce prováděné Scrumovým týmem.

Položky Backlog Produktu, které může Scrumový tým dokončit v rámci jednoho Sprintu, se považují za připravené k výběru během Plánování Sprintu. Obvykle získávají tento stupeň transparentnosti po řadě upřesňovacích a vyjasňovacích aktivit.

Zpřesňování (refinement) Backlogu Produktu je akt rozpadu a detailnější definice jeho položek na menší, přesnější položky. Jedná se o neustále probíhající aktivitu, během které jsou přidávány podrobností jako je popis, pořadí a velikost. Atributy se často liší podle oblasti práce.

Za určování velikosti jsou odpovědní Vývojáři, kteří budou danou práci dělat. Product Owner může ovlivňovat Vývojáře tím, že jim pomáhá pochopit a volit kompromisy (trade-offs).

Závazek: Cíl Produktu (Product Goal)

Cíl Produktu popisuje budoucí stav Produktu, vůči kterému Scrumový tým plánuje. Cíl Produktu je v Backlogu Produktu. Zbytek Backlogu Produktu postupně v čase definuje “co” naplní Cíl Produktu.

Produkt je prostředek k doručení hodnoty. Má jasné hranice, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco více abstraktnějšího.

Cíl Produktu je pro Scrumový tým dlouhodobým úkolem. Tým musí nejprve splnit (nebo opustit) jeden cíl, než se pustí do dalšího.

Backlog Sprintu (Sprint Backlog)

Backlog Sprintu se skládá z Cíle Sprintu (proč), sady položek Backlogu Produktu vybraných pro Sprint (co) a akčního plánu pro dodání Inkrementu (jak).

Backlog Sprintu je plán vytvořený Vývojáři a jim také určen. Jedná se o vysoce viditelný obraz práce v reálném čase, kterou Vývojáři plánují dokončit během Sprintu, aby dosáhli Cíle Sprintu. Následně je na základě nových poznatků během Sprintu průběžně aktualizován. Měl by obsahovat dostatek podrobností, aby tým mohl na Denním Scrumu zkoumat svůj postup.

Závazek: Cíl Sprintu (Sprint Goal)

Cíl Sprintu je jediným cílem, který tým ve Sprintu má. Ačkoli je Cíl Sprintu závazkem Vývojářů, poskytuje flexibilitu v rámci konkrétní práce, která je potřebná k jeho dosažení. Cíl Sprintu také vytváří soudržnost a zaměření pozornosti a povzbuzuje Scrumový tým, aby spolupracoval než aby pracoval na samostatných iniciativách.

Cíl Sprintu je vytvořen během Plánování Sprintu a poté přidán do Backlogu Sprintu. Vývojáři mají Cíl Sprintu v jeho průběhu neustále na paměti. Pokud se ukáže, že je třeba dělat něco neočekávaného, spolupracují Vývojáři s Product Ownerem na vyjednání změny rozsahu Backlogu Sprintu v rámci Sprintu tak, aby nebyl ovlivněn Cíl Sprintu.

Inkrement

Inkrement je konkrétní krok k dosažení Cíle Produktu. Každý Inkrement se přidá ke všem předchozím Inkrementům a je důkladně verifikován, že s nimi společně funguje. Aby byl hodnotný, musí být Přírůstek použitelný.

Ve Sprintu může být vytvořeno více Inkrementů. Souhrn Inkrementů je prezentován na Review Sprintu, což podporuje empirismus. Inkrement však může být stakeholderům doručen ještě před koncem Sprintu. Review Sprintu by nikdy nemělo být považováno za podmínku k dodání hodnoty (release).

Práci nelze považovat za součást Inkrementu, pokud nesplňuje Definition of Done.

Závazek: Definition of Done (definice hotového)

Definition of Done je formální popis stavu Inkrementu, který splňuje požadované parametry kvality pro daný Produkt.

Přírůstek vznikne v okamžiku, kdy položka Backlogu Produktu splňuje Definition of Done.

Definition of Done vytváří transparentnost tím, že všichni rozumí stejně tomu, jaká práce na Inkrementu byla dokončena. Pokud položka Backlogu Produktu nesplňuje Definition of Done, nemůže být vydána nebo dokonce prezentována na Review Sprintu. Místo toho se vrátí do Backlogu Produktu pro budoucí zvážení.

Pokud je Definition of Done pro Inkrement součástí standardů celé organizace, musí být dodržována minimálně všemi Scrumovými týmy. Pokud se nejedná o standard v dané organizaci, musí Scrumový tým  pro každý Produkt vytvořit vlastní vhodnou Definition of Done.

Vývojáři jsou povinni dodržovat Definition of Done. Pokud na Produktu spolupracuje více Scrumových týmů, musí vzájemně definovat a dodržovat stejnou Definition of Done.

Poznámka na závěr

Scrum je zdarma a je nabízen v tomto Průvodci. Scrumový framework tak, jak je v tomto dokumentu nastíněn, je neměnný. I když je možné implementovat pouze části Scrumu, výsledkem není Scrum. Scrum existuje pouze jako celek a funguje dobře jako rámec dalších technik, metodik a postupů.

Poděkování Lidem

Z tisíců lidí, kteří Scrumu přispěli, bychom chtěli zmínit ty, kteří byli u samého zrodu: Jeff Sutherland pracoval s Jeffem McKennou a Johnem Scumniotalesem a Ken Schwaber s Mikem Smithem a Chrisem Martinem a všichni spolupracovali dohromady. Mnoho dalších v následujících letech přispělo a bez jejich pomoci by Scrum nebyl vytříbený tak, jak je tomu dnes.

Historie Průvodce Scrumu (Scrum Guide)

Ken Schwaber a Jeff Sutherland poprvé společně představili Scrum na konferenci OOPSLA v roce 1995. V podstatě šlo o dokumentaci toho, co se Ken a Jeff během několika předchozích let naučili, a co uveřejnili jako první formální definici Scrumu.

Průvodce Scrumem dokumentuje Scrum tak, jak jej Jeff Sutherland a Ken Schwaber vymysleli, vyvíjeli a udržovali po dobu více než 30 let. Existují i jiné zdroje poskytující vzorce, procesy a poznatky, které doplňují Scrumový framework. Ty mohou zvýšit produktivitu, hodnotu, kreativitu a spokojenost s výsledky.

Kompletní historie Scrumu je popsána jinde. Abychom vzdali hold prvním místům, kde byl vyzkoušen a kde se osvědčil, uvádíme společnosti Individual Inc., Newspage, Fidelity Investments a IDX (nyní GE Medical).

Tato publikace je nabízena k získání licence na základě licence Attribution Share-Alike společnosti Creative Commons, která je přístupná na adrese https://creativecommons.org/licenses/by-sa/4.0/legalcode a je také popsána v souhrnné podobě na adrese https://creativecommons.org /licenses/by-sa/4.0/. Využitím této Příručky Scrumu (Scrum Guide) berete na vědomí a souhlasíte s tím, že jste si přečetli a souhlasíte s tím, že budete vázáni podmínkami licence Attribution Share-Alike licence Creative Commons.