Plán | Zuzi's Blog o Agilu a Scrumu

Jak naplánovat Sprint bez odhadů?

Jeden z nejčastějších nešvarů Scrum implementací je odhadování tásků v hodinách a jejich následné poměřování vůči kapacitě týmu. Je to krásná myšlenka, ale v praxi je to nesmysl, který trvá zbytečně dlouho a nic nepřináší. Snad jen to, že můžete nakreslit další zbytečnost – Sprint Burndown.

Myšlenka vychází z nepochopení Scrumu. Je to pozůstatek tradičního myšlení Organizace 1.0 kde jsme věřili, že lidi alias zdroje jsou stejně jen líná banda individuí, kteří když je nebudeme hlídat, tak nic neudělají. Scrum dává práci mnohdy ztracený smysl a tak generuje daleko motivovanější lidi, kteří se sami zlepšují a vymýšlejí jak dělat věci lépe. A kteří toho udělají víc i bez mikromanagementu a detailního vykazování.

Když tedy přestaneme odhadovat kvůli kontrole lidí v týmu, zbývá se podívat, jestli mohou být takhle detailní odhady přínosné týmu samotnému. Podívejme se nejprve na reálnou přesnost takových odhadů. V podstatě, každý odhad je jen jakási předpověď. Slovní spojení ‘přesný odhad‘ je oxymoron. Nemůže nastat. Proto také ve Scrumu neodhadujeme, kdy bude jedna konkrétní věc hotová, ale kolik Product Backlog Items se nám vejde do Sprintu. Nečekané vlivy, které se týmu za Sprint stanou, se tím zprůměrují. Každá individuální story může být výrazně jiná, než jsme čekali, ale v globálu to vyjde. Jedna bude náročnější, jiná snazší, někde se zasekneme, jinde to půjde lépe, než jsme čekali a obavy se nenaplní. Jediné, co je pro plánování Sprintu potřeba, je dobré porozumění Backlogu a jednotlivým Stories. Nikdy bychom neměli do Sprintu plánovat věci, kterým nerozumíme – ale v takovém případě ani pokus o odhady tásků nepomůže.

Praktika, která týmům pomůže porozumět položkám Backlogu a na základě toho je naplánovat do Sprintu je rozpadnout Stories na tásky/aktivity, o kterých věří, že je dokáží dokončit za maximálně den (tedy od Standupu do Standupu). Některé takové tásky budou trvat třeba i tři, čtyři dny, jiné tým dokončí za pár hodin. Není důležité zkoumat tyto výjimky, ty se stanou, ať budete dělat, co budete dělat. A jestli to nejsou výjimky a všechny tásky se ukázaly být příliš malé nebo příliš velké, příští Sprint to napravte tak, aby byly v průměru dokončitelné za den. Je to zdánlivě to samé, také odhadujeme, ale je ohromný rozdíl, jestli na takovou tásku napíšete 8h a nebo se jen každý Standup z odstupu podíváte na vaší Scrum tabuli a zhodnotíte celková posun týmu. Není třeba nic počítat. Scrum je empirický proces, koriguje se sám. Někde začněte a uvidíte. Obecně je nejlepším odhadem včerejší počasí. Stačí naplánovat tolik položek Backlogu, kolik jste dokončili minule. Co se tásků týče, když vám rozpadlé aktivity vyjdou na tak cca na polovinu dní, bude to tak akorát. Obvykle se totiž některé tásky v průběhu rozpadnou na menší kousky a jiné vzniknou. To je zcela normální, neboť řešení vniká teprve v průběhu Sprintu. Zkuste to a uvidíte, jak to půjde. Příští Sprint můžete cokoli změnit tak, abyste našli správný balanc a rytmus.

Jaké to je když vám vyjde kniha

První pocit? Překvapení. Přijde tlustý balíček se třemi autorskými výtisky. Jen tak, z ničeho nic. Jeeeee už je to tady! Ta je pěkná 🙂 a pak se vám začne honit hlavou, jak to celé bylo. Já v podstatě knihu psala v nejrůznějších koutech světa. Doma prostě nebyl čas se zastavit a přemýšlet. Proto tak ráda cestuju. Je to osvěžující. Kde to celé začalo? Já myslím, že v Indii. Seděli jsme u bazénu při konferenci a říkali si, že by bylo fajn napsat knihu. A vymysleli osnovu. A pak osnova pak dlouho ležela u ledu… A pak jsme začali pomalu psát. Kousek po kousku. Ale jak říkám doma mi to moc nešlo. Psát knihu je děsně práce. Trvá to nekonečně dlouho. Pořád to není hotové.

A tak jsem se rozhodla s tím pohnout a první rozumně velký kus jsem napsala v Indonésii. Bangka Island. Každý den po odpoledním ponoru, až do večeře. Jsou tam úžasné soft korály. Jedny z nejhezčích na světě. To je stejně můj sen, pracovat někde pod palmičkou. Pak bylo po dovolené. Pak další části vznikaly v letadlech a při čekání na letištích do Kalifornie – v San Fransicsu je úžasně, taky je tam moře. Pak cestou do Kieva, Rigy, Barcelony, Talinu, Kodaně, Krakova, Moskvy, New Yorku, v Las Vegas – nic jsem v casinech nevyhrála. Škoda, pár miliónů by se mi ke splnění snu sedět pod palmičku hodilo.

Další velký kus jsem napsala na Filipínách. Zase potápění. Odpolední dvě hodinky po ponorech na Moalboalu, pak v thajské restauraci na pláži v Boholu a finální části v Coronu, kde mají Japonské vraky plné podmořského života. Nádhera. Ale pořád to tak nějak nebylo hotové. Už mi to začínalo vadit, nemám ráda dlouho nekonečnou práci… a tak jsem poslední kusy dopsala ve Vietnamu v Saigonu nebo Ho Chi Minh City chcete-li. Hodina taxíkem do práce, hodina zpět do hotelu. Tam jsem ve finále četla i celou knihu ještě jednou v rámci finálního review. To si teprve uvědomíte, kolik jste toho napsali. To už bylo povzbudivé. Skoro hotovo. A jsem moc ráda, že jsem na knihu nebyla sama. Vždycky je daleko větší zábava s někým spolupracovat.

A pak nastal ten největší problém, kde sehnat vydavatele. Nakonec to šlo celkem snadno. A tak děkujeme nakladatelství Computer Press za vydání naší knihy “Agilní metody řízení projektů“ a doufáme, že se vám bude líbit. Co se dočtete?

„Snažili jsme se čtivou formou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na Agilní metody mohou potkat. Kniha nepopisuje jen teorii, co to Agilní metody jsou, jak funguje Scrum Proces a Kanban, a jak by jednotlivé artefakty těchto procesů měly správně vypadat, ale primárně se snaží vysvětlit filozofii Agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení co dělat a čeho se naopak vyvarovat.

Kniha se zabývá Agilními metodikami vývoje software v různých typech společností, od malých firem až po nadnárodní korporace. V první části knihy jsou popsány základní stavební prvky Agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Čtenář se dozví všechny potřebné informace k adopci Agilních metodik, kulturní odlišnosti Agilních firem a další základní stavební kameny nutné pro úspěšnou adopci Agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky vyskytují v Agilně řízených firmách. Vedle těchto popisů obsahuje kniha i “kuchařky”, resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy firem.“

Dejte nám prosím vědět, jak se vám kniha líbila, co vás zaujalo, nebo co byste viděli příště raději jinak. Hezké čtení. Naší knihu Agilní metody řízení projektů můžete získat zde.

Super User Story, User Story a Epics

Jak už jsem psala v minulém příspěvku, User Story musí vytvářet obrázek, být nezávislá, popsatelná, přinášet hodnotu, ohodnotitelná, malá a testovatelná – tedy v originále: Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (zkráceně “INVEST”). Tedy něco, do čeho chcete investovat úsilí a potažmo peníze. Po té co se pokusíte User Story takto definovat, často zjistíte, že potřebujete ještě něco co je širší, co vám drží globální kontext a jednotlivé User Story pohromadě.

K dispozici jsou dva koncepty. První se na User Story dívá jako na entitu, která jde v podstatě donekonečna škálovat a zavádí tak pojem Super User Story – např. Jedu na výlet do Evropy – nebo jen do Německa – nebo jen do Berlína – nebo chci navštívit Berlínské Egyptské museum. Je to takový strom vnořených User Story. Samozřejmě že když to takto rozdrobíme, budou se nám jednotlivé User Story (listy toho stromu) samostatně jen velice špatně prodávat jako super zájezd. Ale na druhou stranu, asi si umíte představit zájezd jen s památkami bez jídla a zájezd all inclusive. A s vaším produktem je to podobné. Také obvykle existuje funkcionalita, kterou můžete oželet a která vlastně není tak prioritní.

Druhý koncept zavádí pojem Epics, kde Epics je něco co jednotlivé User Story zastřešuje – tedy taková souhrnná Super User Story. Epics se ovšem již nepíše ve formátu ‘jako uživatel, chci funkcionalitu, abych dostal business value‘, ale zároveň se jako takový nedá naplánovat do sprintu a ani nechat reálně týmem ohodnotit. Na to je v něm skrytá moc velká dávka nejistoty.

Obě varianty jsou v podstatě podobné, a pomáhají vám udělat si představu o backlogu, ujasnit si co má jakou prioritu a kde je jaká přidaná hodnota.

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
Lepítka na jednotlivé user story v backlogu.
Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:

Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10

Odbory prosadily kratší pracovní týden – 5b

Je Den Železničářů, v poledne se jde do hospody – 4b

Včera pršelo, vypili jsme moc rumu – 3b

Ale také třeba takto:

Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b

Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b

V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

Větší hodiny měřící délku Sprintu, my jsme zvolili:

5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint

5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

Zákazníka – toho budete pravděpodobně hrát Vy – který může:

Chtít vidět další města

Změnit svá přání

Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.

Scrum jako interní proces

Určitě jste se setkali s jistou nedůvěrou zákazníků ke Scrum procesu. Takže co s tím? Otevřete-li si knihu Art of War od vojevůdce Sun Tsu, jedna z nabízených strategií je “When you are going to attack nearby, make it look as if you are going to go a long way; when you are going to attack far away, make it look as if you are going just a short distance.” Tedy jinými slovy, proč vše zákazníkovi říkat explicitně a tím ho vyděsit? Honosné názvy, za kterými zákazník neví, co si představit moc nepomůžou, navíc při představě, že se bude pravidelně muset účastnit plánování spolu s týmem v něm nutně musí vzbudit podezření, že na něj chcete hodit Vaší práci. A demo? No ukažte mu produkt, až bude hotový, a neotravujte s nedodělky. Nemá přeci čas se Vám pravidelně věnovat tolik času. I to se Vám může stát. Takže co v takových případech dělat? Zkuste pozvolna a po malých krůčkách zákazníka naučit, v čem je Scrum pro něj výhodný. Ukažte mu, že jednotlivé kroky pro něj mají smyls. Komunikujte a naslouchejte. A hlavně, zákazník přeci nutně vědět, že to, co zcela neformálně děláte, se jmenuje Scrum.

Prvním bodem bude účast na pre-planningu. Jestli-že nejste schopni zákazníka dostat na váš pre-planning přímo, vždy máte možnost se s ním před meetingem zkontaktovat a to buď osobně, a nebo klidně i po telefonu. Dejte mu na výběr, co by on nejvíce ocenil, co by rád viděl nejdříve. Jeho přání pak následně můžete hájit na pre-planningu vy. Ušetříte tak zdánlivě jeho čas. Následně, po ukončení sprintu, zákazníkovi ukažte, co se udělalo. Zajeďte za ním, a vyžádejte si jeho zpětnou vazbu. Nedělejte příliš formální customer dema. Ty můžete udělat pro týmy navzájem, ale pro zákazníka udělejte soukromou prezentaci. Až si na vaše návštěvy zvykne, můžete ho postupně začít zapojovat. V dnešní době velice pěkně poslouží i různé internetem přenášené prezentace (WebEx), takže zákazník vlastně ani nemusí nikam cestovat a neztrácí čas.

Scrum má primární cíl pro Vás. Má Vám pomáhat jak být efektivní, jak zorganizovat tým, jak motivovat lidi. Jak úspěšně dokončit projekt. Nedílnou součástí je samozřejmě i zapojení zákazníka. Ale cest, kterými to docílíte, je mnoho. A nemusí být zdaleka přímočaré. Psychologie je nejmocnějším nástrojem.

Jak nejlépe sledovat aktuální stav úloh

V minulém příspěvku jsem doporučovala Excel pro vizualizaci výsledků Sprintu a zobrazení Burndown grafu, jako jednoduchou, levnou a efektivní metodu. Podobně se můžeme postavit k trackování statusu jednotlivých úloh, plánování na sprinty a sledování úloh v backlogu. Systémy navržené na Scrum proces Vám samozřejmě dají všechny informace o aktuálním stavu, plánu, atd. nicméně často je to velmi komplexní řešení, jehož filozofii musíte přizpůsobit svůj Scrum proces, alespoň do jisté míry. Každý produkt má své pro a proti, těžko vybrat ideální.

Jedním z možných řešení, které je zdarma, a je poněkud lepší než uchovávat backlog úloh a jejich status v Microsoft Excelu, je Mantis (bug tracking system). Originálně je to systém na trackování chyb, ale poměrně jednoduše jde použít na sledování statusu jednotlivých úloh, přiřazení úloh konkrétním lidem, plán. Mantis umožňuje posílat automatické notifikace emailem, nastavit různá práva, automaticky zobrazuje historii změn. Vzhledem k velmi dobrému filtrování si každý může přednastavit takové zobrazení, které vyhovuje jeho roli (vlastní úlohy, naplánované úlohy, backlog pro danou story, …).

Co je třeba udělat navíc. Pomocí Custom Fields si velice jednoduše přidáte nové položky – pro Scrum proces to bude Points (Body). V ideálním případě, bude-li se Vám chtít, jde pod seznam úloh přidat součet bodů, to už je ale nutné naprogramovat přímo ve zdrojovém kódu. Nic složitého. Nicméně i bez toho je funkcionalita dostatečná. Pro každý projekt dáte do seznamu kategorií (Categories) Sprinty. Mantis neobsahuje ve své originální podobě datum, tedy délku Sprintu si určujete sami. Asi by nebyl problém to doprogramovat, ale nám to vlastně nikdy moc nechybělo. Stavy jednotlivých úloh je zase ve zdrojáku velice snadno možné přejmenovat, aby více odpovídaly vašim zvyklostem. A můžete začít. Naplníte backlog úlohami, tým naplánuje Sprint, přiřadí úlohy jednotlivým lidem, a pak už jen každý den sledujete co se děje.

Bohužel, verze Mantisu se hodně liší, takže výše popisované změny ve zdrojovém kódu nejsou jednoduše popsatelné tak, aby se daly rovnou použít. My máme skoro na každý projekt jinou verzi Mantisu a změny děláme projektu vždy znovu na míru. A není to nijak zvlášť časově náročná aktivita.

Co se týče spojení s Burndown grafem, každý konec sprintu se udělá rychlá synchronizace. Přepíšeme, kolik bodů se z které úlohy dokončilo, které úlohy vznikly, a graf je hotový. Je to jistá část manuální práce, ale zabere pár minut. Komplexní Scrum systém to udělá za vás, ale zase třeba nebude tak jednoduchý a obecný.

Vyhodnocení Sprintu

Posledním krokem Sprint cyklu je vyhodnocení výsledků. Příslušný počet bodů za dokončené úlohy se odečte z produkt backlogu a ze zbývajícího počtu bodů a rychlosti týmu se upraví očekávaný konec projektu. V ideálním případě by tým měl dokončit všechny úlohy, které v rámci plánovacího meetingu naplánoval a které se zavázal splnit. To ovšem v reálu není vždy pravidlem a obzvláště na začátku, než tým dostatečně vstřebá hodnotu bodu a naučí se plánovat, se skutečnost bude od původního záměru odlišovat. Nezapomeňte, že hlavním cílem je naučit tým dobře plánovat a odhadovat svoji práci. Takže po každém Sprintu by měl tým dostatečně dobře vidět, nakolik se od plánu odlišuje, a uvědomit si proč to je. A při příštím plánováni se případných chyb vyvarovat.

Obecně je dobré udělat krátkou prezentaci, kde se porovná plánování a výsledky jednotlivých týmů za končící Sprint. Jednou z oblíbených Agile metod vizualizace jsou Burndown grafy (o tom více v dalším příspěvku). Současně je dobré ukázat progres celého projektu a jeho milestonů, aby týmy přímo viděli, jak se projekt posouvá jako celek a jestli je na tom dobře (Critical Chain úlohy, Concerto graf). Zhodnocení sprintu může pak přímo přejít do plánovacího meetingu, kde jednotlivé týmy připraví plán na další Sprint. Tyto dílčí plánovací meetingy je lepší mít odděleně pro jednotlivé týmy, výsledné plány na nový Sprint by ale týmy měly v rychlosti prezentovat zase veřejně, aby vzniklo povědomí o tom, co dělají jednotlivé skupiny, kolik bodů plánují a jak se jim následně daří plán plnit.

Zapojení zákazníka – Customer demo

Softwarové projekty často neodpovídají očekáváním zákazníka. A to i tehdy když jsou napsané podle specifikace. Ruku na srdce, určitě jste už někdy chtěli nějaký výrobek, popis přesně odpovídal, a když jste to nakonec získali či koupili, nějak to nebylo ono. Často to byly drobnosti, co výrobku chyběli k dokonalosti a praktičnosti. Stejná situace je i s vývojem a specifikací softwaru. Zákazníci očima vývojářů často nevědí, co chtějí. Vývojáři zase většinou nemají potřebný kontext či doménovou znalost prostředí a potřeb zákazníka.

Na to odpovídá Scrum proces zapojením zástupce zákazníků do procesu plánování. Zástupce zákazníka by měli být přítomni plánování na pre-planning meetingu, aby byli zapojeni do procesu a spolupodíleli se na určování priorit. Zákazník je pak ten kdo říká, co a kdy chce. Agile k tomu dodává praktiku zvanou customer demo, kde zákazník na prezentaci uvidí výsledek zadané práce. Customer demo je vhodné zorganizovat pravidelně na konci každého Sprintu. Zajistí se tak zpětná vazba a úlohy se mohou případně upravit podle potřeb zákazníka hned a předejde se složitému redesignu. Na zákazníka to neklade časově nijak velké nároky, navíc pravidelně, vždy na konci sprintu vidí výsledek, což je často k nezaplacení.

Proces plánování – Sprint planning

Podíváte-li se na běžné softwarové projekty, většina z nich končí daleko po naplánovaném konci. To je samozřejmě způsobeno několika faktory. Tím kdo plán dělá, nakolik je zkušený, nakolik umí odhadnout, co všechno bude potřeba naimplementovat, nakolik je obeznámen s procesem vývoje a samozřejmě kvalitou a spolehlivostí vstupní specifikace. Zkusme ale začít u jednotlivých vývojářů. Kolik z nich umí dobře odhadnout, kdy svoji úlohu dokončí. Kolik z těch úspěšných udělá dobrý odhad high-level oblasti – Story? Kolik z nich odhadne délku celého projektu a s jakou přesností? Asi tušíte, kam mířím. Vývojáři často neodhadnou ani úlohu na týden, natož cokoliv abstraktnějšího. Sprint Backlog Vám zajistí příslušnou granularitu úloh, Sprint pre-planning nastaví priority pro jednotlivé Story a přiřadí je týmům jako vstup na Sprint planning.

Pár zásad na začátek. Tým je ten kdo plánuje konkrétní úlohy na Sprint. Tým je ten kdo je přiřazuje úlohy jednotlivým lidem. Tým je ten kdo zajišťuje změny v přiřazení lidí na úlohy. A konečně tým je ten, kdo je zodpovědný za výslednou kvalitu a dokončení včas v rámci Sprintu. Z čistě psychologického hlediska tým se tím, že plán sám vytvoří, také zaváže k jeho splnění, tedy slíbí, že ho splní. K takovému cíli je samozřejmě psychologicky více vázán než k jakémukoliv direktivnímu nařízení, které nemůže ovlivnit.

Jak probíhá samotné plánování. Tým dostane jako vstup Story z pre-planning meetingu. Každá taková Story obsahuje jednotlivé úlohy v backlogu spolu s ohodnocením. V případě že granularita není dostatečná je čistě v pravomocích týmu úlohy rozdělit tak, aby bylo možné je dokončit v rámci jednoho Sprintu a naplánovat jen to, co věří, že dokončí. Je to jednoduché, ale na začátku se to tak nemusí zdát. Po každém Sprintu by mělo proběhnout vyhodnocení plánu, realita by se neměla moc lišit. V případě že s Agile začínáte, první Sprinty pravděpodobně nebudou naplánované zrovna ideálně. Důležité ale je tým učit a dát mu zpětnou vazbu. Za cca 3 Sprinty by plán měl být už dostatečně věrohodný a kvalitní.

Proces plánování – Sprint pre-planning

Je načase trochu popsat jak probíhá podle Agile a SCRUM plánování. Produkt backlog už máme definovaný, Story či jednotlivé úlohy jsou ohodnoceny body. Před každým začátkem Sprintu sezvěte tzv. expert-tým složený z klíčových lidí. Obecně budete chtít sezvat zástupce jednotlivých týmů, někoho z managementu, hlavního architekta, zástupce zákazníka/zákazníků a to včetně interních zákazníků v rámci firmy. Interním zákazníkem je každá skupina závislá na Vašem výstupu (takže třeba nezávislá skupina zajišťující formální testování). Cílem je zastoupit všechny skupiny jakkoliv zainteresované na výsledku projektu. Ti by pak měli na pre-planning meetingu společně vybrat oblasti, na kterých budou po následující sprint týmy pracovat.

Není úkolem přidělovat jednotlivé úlohy ani konkrétním lidem ani týmům, ale předvybrat pro každý tým příslušné high-level Story. Na konci každého Sprintu se v Burndownu vyhodnotí výsledky a nedokončené úlohy se vrátí zpět to produkt Backlogu. Před začátkem nového Sprintu se svolá další pre-planning meeting a znovu určí priority pro jednotlivé týmy.

Hlavním úkolem pre-planningu je umožnit komunikaci jednotlivých zájmových skupin (zákazník, management, architekt, …), koordinovat a pokud možno uspokojit jejich rozdílné zájmy a nastavit priority práce pro týmy.