Existuje důvod, proč vám předpovědi počasí říkají, že je 70% šance na déšť, místo aby slibovaly, že bude pršet přesně v 15:00. Využívají dostupné informace, zohledňují nejistotu a aktualizují se, jakmile přijdou nové údaje. Stále si podle nich můžete naplánovat odpoledne, pokud si předpověď nespletete s jistotou.
Plánování sprintu funguje na podobném principu. Scrumový tým má produktový backlog, odhad své dostupné kapacity a cíl, kterého chce dosáhnout. Některé detaily práce se však vyjasní až v průběhu sprintu. Plánování s hodinovým předstihem ponechává málo prostoru pro tato zjištění, zatímco zahájení sprintu bez společného směru ztěžuje rozhodování o tom, čemu je třeba věnovat pozornost.
Cílem je dohodnout se na hodnotném výsledku a odhadnout, kolik práce tým dokáže dokončit, aby ho dosáhl. Na tomto základě může tým svůj plán přizpůsobovat podle nových poznatků, aniž by ztratil ze zřetele cíl sprintu.
Tato příručka se zabývá přípravou backlogu, časovým plánem, praktickými výpočty kapacity a konkrétním příkladem, který ukazuje, jak plán během sprintu upravit.
TL;DR Plánování sprintu sdružuje Scrumový tým, aby se dohodl na jednom cíli sprintu, vybral položky z backlogu a stanovil počáteční plán dodání:
- Připravte se tím, že upřesníte nadcházející práci a zkontrolujete dostupnost, nedokončené položky, závislosti a definici dokončení.
- Prognózu založte na skutečné kapacitě a dosavadních výsledcích, zohledněte dovolené, schůzky, podpůrné úkoly a nejistotu, aniž byste závazky počítali dvakrát.
- Na konci plánování vytvořte společný sprintový backlog a poté upravujte plán dodání podle toho, jak tým získává nové poznatky, přičemž zachovejte cíl sprintu.
- Využijte dvouhodinový vzorový program a praktický příklad výpočtu kapacity jako výchozí body a přizpůsobte je potřebám svého týmu.
Co je plánování sprintu?
Plánování sprintu je událost v rámci Scrumu, která se koná na začátku každého sprintu s cílem dohodnout se na tom, čeho chce tým dosáhnout a jakým způsobem bude k práci přistupovat. Shromažďuje celý Scrum tým, včetně produktového vlastníka, Scrum Mastera a vývojářů. Zúčastnit se mohou i další odborníci, jako jsou bezpečnostní inženýři nebo vedoucí pracovníci v kontaktu se zákazníky, pokud by jejich příspěvek pomohl týmu učinit informovaná rozhodnutí.
Podle Scrum Guide by každá plánovací schůzka měla přinést tři věci: cíl sprintu, který vysvětluje hodnotu práce, výběr položek produktového backlogu, které tento cíl podporují, a počáteční plán jejich dodání. Společně tvoří sprintový backlog, který vývojáři v průběhu sprintu průběžně aktualizují.
Průvodce Scrumem stanovuje maximální délku měsíčního sprintu na osm hodin, přičemž kratší sprinty obvykle vyžadují méně času. S dobře propracovaným backlogem se níže uvedený program vejde do dvou hodin.
Pokud vám některé z těchto pojmů nejsou známé, v našem slovníčku najdete základní pojmy z oblasti agilního vývoje a Scrumu.
Tři otázky, na které sprintové plánování odpovídá
Každá schůzka plánování sprintu se točí kolem tří otázek:
- Proč je tento sprint cenný?
- Čeho můžeme dosáhnout?
- A jak tu práci zvládneme?
Průvodce Scrumem organizuje plánování kolem těchto otázek, počínaje hodnotou, kterou chcete dodat. Jakmile je to všem jasné, je snazší rozhodnout, které položky backlogu si zaslouží pozornost a kolik práce může váš tým rozumně zvládnout.
| Otázka | Kdo vede | Výstup | Příklad pro dvoutýdenní sprint |
|---|---|---|---|
| Proč je tento sprint cenný? | Produktový vlastník navrhuje; celý tým souhlasí | Cíl sprintu | Noví zákazníci mohou při placení u pokladny platit kartou, aniž by museli kontaktovat prodejní oddělení |
| Co lze v tomto sprintu stihnout? | Vývojáři vybírají společně s produktovým vlastníkem | Vybrané položky backlogu | Formulář pro platbu kartou, integrace platebního poskytovatele, e-mail s potvrzením, zpracování chyb |
| Jak bude vybraná práce provedena? | Vývojáři | Počáteční plán úkolů | Položky se rozdělí na úkoly, z nichž každý trvá často jeden den nebo méně, přičemž se předem dohodnou počáteční odpovědnosti |
Proč je sprint důležitý
Cíl sprintu dává týmu směr, na který se má zaměřit, a pomáhá zainteresovaným stranám pochopit, co mohou očekávat. Na tomto cíli se se svým Scrum týmem dohodněte ještě před koncem plánovacího setkání.
Popište výsledek, který lidé dokážou rozpoznat, například „Uživatelé zkušební verze mohou pozvat kolegy z týmu“, namísto cíle v podobě pracovního objemu, jako je „Dokončit 34 story pointů“. Pokud se objeví neočekávaný problém, cíl pomůže týmu rozhodnout, kterou práci upravit, a přitom zachovat zamýšlený výsledek.
Přečtěte si více: Jak formulovat efektivní cíle sprintu (+ příklady)
Co tým dokáže v tomto sprintu dokončit
Jakmile se shodnete na cíli, je čas zjistit, co tým reálně dokáže dodat.
Vývojáři vybírají položky backlogu v diskusi s produktovým vlastníkem, přičemž zohledňují dostupnou kapacitu, dosavadní výkonnost a definici dokončení. Toto je také vhodná příležitost k přezkoumání všech stávajících závazků, které by mohly ovlivnit, kolik času má tým k dispozici pro práci ve sprintu.
Mnoho týmů používá story pointy k porovnání relativní náročnosti a složitosti položek backlogu. Fibonacciho stupnice může pomoci strukturovat tyto diskuse, zejména pokud není jasné, jaké úsilí daná položka vyžaduje.
Pokud jste se story pointy teprve začínáte nebo chcete vidět, jak se používají v praxi, zde najdete podrobný návod k procesu odhadování.
Jak bude tým práci provádět
Po výběru položek z backlogu vývojáři vymyslí, jak z nich vytvoří hotový inkrement produktu, který splňuje definici dokončení. Průvodce Scrumem doporučuje rozdělit větší položky na menší části práce, jejichž velikost je často nastavena tak, aby jejich zpracování trvalo jeden den nebo méně.
To neznamená, že musíte naplánovat každou hodinu sprintu. Prvních několik dní může vyžadovat podrobnější plán, zatímco pozdější úkoly mohou zůstat otevřené úpravám, jakmile se objeví nové podrobnosti. Pokud budete počáteční odhady považovat za pevné závazky, může to na tým vyvíjet tlak, aby splnil původní čísla, i když se rozsah práce v průběhu sprintu změní.
Jak vysvětluje Dave West, generální ředitel Scrum.org:
Prognóza použitá k obhájení termínu přímo vybízí k chování, které podkopává důvěru, jako je nadhodnocování odhadů, skrývání rizik nebo tiché předefinování pojmu „hotovo“ za účelem dosažení stanoveného čísla.
Prognóza použitá k obhájení termínu přímo vybízí k chování, které podkopává důvěru, jako je nadhodnocování odhadů, skrývání rizik nebo tiché předefinování pojmu „hotovo“, aby se dosáhlo stanoveného čísla.
Jaký je rozdíl mezi plánováním sprintu a upřesňováním backlogu?
Upřesnění backlogu poskytne vašemu týmu jasnější přehled o nadcházející práci ještě předtím, než nastane čas rozhodnout, co bude součástí příštího sprintu. Plánování sprintu navazuje na tuto přípravu a slouží k dohodnutí cíle, výběru položek z backlogu a stanovení počátečního plánu dodání.
Tyto dvě činnosti mají ve Scrumu odlišný účel:
| Dimension | Upřesnění backlogu | Plánování sprintu |
|---|---|---|
| Účel | Ujasněte si, rozdělte a odhadněte nadcházející položky backlogu | Stanovte cíl sprintu, vyberte úkoly a naplánujte dodání |
| Časový rozvrh | Probíhá po celou dobu sprintu | Na začátku každého sprintu |
| Stav Scrumu | Průběžná činnost | Formální událost v rámci Scrumu s časovým limitem |
| Kdo se účastní | Produktový vlastník a příslušní vývojáři | Celý Scrumový tým |
| Výstup | Položky backlogu s jasnějšími podrobnostmi, odhady a rozsahem | Sprintový backlog: cíl sprintu, vybrané položky a plán dodání |
Mějte připraveno dostatečné množství položek z backlogu, aby měl tým během plánování sprintu jasné možnosti výběru. Míra užitečnosti přípravy závisí na tom, jak rychle se mění priority a kolik nejistoty zůstává. Položky, které jsou v backlogu dále, mohou zůstat méně podrobné, dokud se nepřiblíží k výběru.
Přečtěte si také: Další pokyny najdete v našich článcích o údržbě backlogu a o tom, jak udržovat produktový backlog uspořádaný a seřazený podle priorit.
Jak se připravit na plánování sprintu
Několik dní předem zkontrolujte, zda je seznam nevyřízených úkolů v pořádku a zda mají všichni k dispozici informace potřebné k rozhodování. Takto můžete během sezení věnovat čas diskusi o tom, co dodáte a jak k tomu přistoupíte, aniž byste museli řešit každý požadavek od nuly.
Zde je kontrolní seznam, který si projděte před vaším dalším sprintem:
- Návrh cíle sprintu: Nechte produktového vlastníka navrhnout výsledek, který podporuje širší cíl produktu, a poskytněte tak týmu konkrétní body k diskusi
- Projděte si produktový backlog: Ujistěte se, že položky s nejvyšší prioritou jsou seřazeny, srozumitelné a v případě potřeby odhadnuty.
- Zjistěte dostupnost týmu: Požádejte vývojáře, aby sdělili plánovanou dovolenou, střídání v podpoře a další závazky, které by mohly ovlivnit jejich kapacitu
- Vraťte se k nedokončené práci: Projděte si úkoly přenesené z předchozího sprintu a veškerá zlepšení identifikovaná během retrospektivy
- Identifikujte závislosti: Označte úkoly, které vyžadují spolupráci nebo schválení jiného týmu, a ujasněte, kdo to bude koordinovat
- Zkontrolujte definici dokončení: Ujistěte se, že všichni chápou standardy kvality, které musí splňovat každá dokončená položka backlogu.
Pokud plánujete retrospektivu sprintu a plánovací schůzku těsně po sobě, vyhraďte si dostatek času na řádnou diskusi v obou případech. Závěry z retrospektivy by měly být podkladem pro plán příštího sprintu, proto se ujistěte, že ani jedna ze schůzek nebude působit uspěchaně.
Program plánování sprintu: Příklad s časovým rozvrhem pro dvoutýdenní sprint
U dvoutýdenního sprintu začněte dvouhodinovou plánovací schůzkou, zejména pokud již byl backlog upřesněn. Počítejte s časovou rezervou, pokud práce zahrnuje složité závislosti nebo několik rozhodnutí, která vyžadují diskusi.
Tento vzorový program můžete přizpůsobit potřebám svého týmu.
| Čas | Bod programu | Kdo vede | Očekávaný výstup |
|---|---|---|---|
| 0:00–0:10 | Zhodnoťte výsledky předchozího sprintu, nedokončenou práci a opatření vyplývající z retrospektivy | Scrum Master vede schůzku | Společné porozumění tomu, čemu je třeba věnovat pozornost |
| 0:10–0:30 | Prodiskutujte cíl sprintu navržený produktovým vlastníkem a dohodněte se na požadovaném výsledku | Celý Scrumový tým | Návrh cíle sprintu, kterému všichni rozumí |
| 0:30–0:45 | Ověřte dostupnost týmu a zkontrolujte případná omezení kapacity | Vývojáři | Realistický obraz dostupné kapacity |
| 0:45–1:15 | Vyberte položky backlogu, které podporují tento cíl | Vývojáři společně s produktovým vlastníkem | Výběr úkolů, o kterých je tým přesvědčen, že je dokáže dokončit |
| 1:15–1:45 | Rozčleňte vybrané položky a prodiskutujte přístup k realizaci | Vývojáři | Počáteční plán pro dokončení práce |
| 1:45–2:00 | Zkontrolujte závislosti, ověřte si jistotu a finalizujte cíl sprintu. | Celý Scrumový tým | Dohodnutý cíl sprintu a seznam úkolů pro sprint připravený k použití týmem |
Před závěrem můžete využít rychlou kontrolu důvěry, jako je například Fist of Five, při které každý ohodnotí svou důvěru v plán pomocí počtu prstů od nuly do pěti. Pokud někdo udělí nízké skóre, zeptejte se, co je příčinou jeho obav. Může se jednat o nevyřešenou závislost, příliš ambiciózní prognózu nebo požadavek, který vyžaduje další diskusi.
Cílem je odhalit případné problémy, dokud je ještě čas plán upravit.
Jak provést plánování sprintu v 6 krocích
Jakmile připravíte seznam úkolů a potvrdíte účastníky, zahajte plánovací schůzku. Cílem je pomoci týmu proměnit jeho priority a dostupnou kapacitu v plán, o kterém je tým přesvědčen, že jej dokáže splnit.
Krok 1: Zhodnoťte předchozí práci a dohodněte se na cíli sprintu
Začněte stručným přehledem toho, co bylo dokončeno, co zůstalo nedokončeno a zda by nějaké závěry z retrospektivy měly ovlivnit příští sprint. Zaměřte se na vše, co by mohlo změnit priority nebo přístup týmu, místo toho, abyste znovu procházeli celou revizi sprintu.
Poté nechte produktového vlastníka představit navrhovaný cíl sprintu a vysvětlit, jak podporuje širší cíl produktu. Dejte vývojářům prostor, aby zpochybnili jeho rozsah, upozornili na závislosti a navrhli úpravy.
Například pokud je cílem umožnit zákazníkům dokončit platbu bez nutnosti kontaktovat prodejní oddělení, dohodněte se, jak má úspěšná platba vypadat. Zahrnuje potvrzení platby a řešení chyb? Je automatické zasílání potvrzení o platbě nezbytné pro první verzi?
Tyto diskuse vám pomohou definovat výsledek, na kterém může tým pracovat. Formulace se může měnit v závislosti na výběru položek backlogu, ale všichni by se měli na konečném cíli shodnout ještě před ukončením plánování.
Krok 2: Vypočítejte dostupnou kapacitu týmu
Než vyberete úkoly, zjistěte, kolik času mohou vaši vývojáři reálně věnovat sprintu.
Začněte s počtem pracovních dnů a předpokládanou dostupností jednotlivých osob. Poté zohledněte plánovanou dovolenou, scrumové události, podpůrné povinnosti a další známé závazky. Pokud vývojář stráví polovinu týdne řešením problémů v produkčním prostředí, jsou tyto hodiny již vyčleněny a nejsou k dispozici pro plánovanou práci ve sprintu.
Jednoduchý výpočet zní: Dostupná kapacita = Celkový počet pracovních hodin − Známé závazky
Například vývojář s 80 pracovními hodinami za dva týdny může mít 8 hodin dovolené, 10 hodin schůzek a 12 hodin podpůrných činností. To znamená, že mu zbývá 50 hodin, a to ještě před zohledněním jakýchkoli dalších nejistot.
Porovnejte tento údaj s dosavadními výsledky týmu. Velocity ukazuje, kolik práce tým dokončil v předchozích sprintech, zatímco kapacita odráží čas, který je k dispozici pro tento sprint.
Tip od profesionála: Pokud při plánování kapacity používáte hodiny, oddělte je od story pointů. Jedná se o dvě odlišné veličiny a neexistuje mezi nimi žádný univerzální přepočet.
Krok 3: Znovu vyhodnoťte nedokončenou práci z předchozího sprintu
Nedokončené položky backlogu si zaslouží další posouzení, než je přidáte do nového sprintu. Položka, která byla důležitá před dvěma týdny, mohla změnit svou prioritu, nebo se tým mohl dozvědět něco, co ovlivňuje rozsah zbývající práce.
Projděte si každý bod s produktovým vlastníkem a zvažte:
- Relevance: Podporuje to stále navrhovaný cíl sprintu nebo jinou důležitou prioritu produktu?
- Zbývající úsilí: Kolik práce zbývá, když byla část položky dokončena?
- Závislosti: Brání týmu v pokroku něco?
- Priorita: Měla by tato položka mít přednost před nově upřesněnými položkami backlogu?
U práce, která stále patří do sprintu, využijte zbývající úsilí k odhadu, kolik kapacity bude potřebovat. Polovičně dokončená položka může vyžadovat méně práce, než byl původní odhad, ale stále se počítá jako nedokončená, dokud nesplní definici dokončení.
Krok 4: Vyberte položky backlogu, které podporují tento cíl
Díky přehledu o kapacitě a zbývající práci si vývojáři mohou vybrat položky produktového backlogu, o kterých se domnívají, že je budou schopni dokončit.
Začněte s položkami, které přímo podporují cíl sprintu. Prodiskutujte jejich akceptační kritéria, technické závislosti a případné nejistoty, které by mohly ovlivnit dodání. Pokud je položka příliš rozsáhlá nebo nejasná, zvažte její rozdělení na menší části, které mohou přinést hodnotu v rámci daného sprintu.
Možná budete mít prostor i pro údržbu nebo jiné priority produktu, ale zkontrolujte, zda by přijetí této práce mohlo ohrozit hlavní cíl.
Jakou kapacitu byste si měli rezervovat?
Plánování pouze 80 % dostupné kapacity může být rozumným výchozím bodem pro týmy, které pravidelně řeší neočekávané podpůrné úkoly, ale Scrum nepředepisuje žádné pevné procento.
Pokud váš tým čelil častým přerušením, můžete mu vyhradit 10–20 % jeho upravené kapacity a porovnat tuto rezervu s tím, co bylo potřeba během předchozích sprintů. Tým se stabilním objemem práce a malým počtem přerušení může potřebovat méně. Tým, který zajišťuje provoz živé služby s častými incidenty, může potřebovat více.
Vyhněte se dvojímu započítání stejného závazku. Pokud již byly v kroku 2 odečteny naplánované hodiny podpory, měla by dodatečná rezerva pokrýt nejistotu nad rámec tohoto známého pracovního zatížení. Výslednou kapacitu použijte jako vodítko pro diskusi, nikoli jako cíl, který je třeba splnit.
Pamatujte: Sprint s volnou kapacitou nemusí nutně znamenat, že je nedostatečně naplánován. Pokud jste vybrali dostatek práce k dosažení cíle sprintu, vyplnění zbývajících hodin nesouvisejícími úkoly může vést ke vzniku konkurenčních priorit. Někdy je realističtější volit konzervativnější odhad, zejména pokud vybraná práce s sebou nese značnou míru nejistoty.
Krok 5: Rozčleňte práci a zkontrolujte závislosti
Jakmile vyberete položky backlogu, mohou vývojáři promyslet, jak je dodají. To může zahrnovat rozdělení větších položek na úkoly týkající se vývoje, testování, integrace a revize.
Pečlivě si prohlédněte pořadí prací. Pokud rozhraní pokladny závisí na integraci s poskytovatelem platebních služeb, měl by tým vědět, kdy musí být tato integrace připravena. Pokud musí jiný tým schválit změnu v zabezpečení, ujasněte si, jak a kdy k tomuto rozhodnutí dojde.
Naplánujte bezprostřední práci podrobněji a pozdější úkoly nechte otevřené pro další diskusi. Průvodce Scrumem doporučuje rozčlenit vybrané položky na menší pracovní úkoly, obvykle v rozsahu jednoho dne nebo méně, ale o tom, jak práci zorganizovat a rozdělit, rozhodují vývojáři.
Zkontrolujte, zda plán zohledňuje definici dokončení (Definition of Done), včetně nezbytných testů a integračních prací. Pokud by nějaká závislost mohla bránit dodání, přehodnoťte vybrané položky nebo upravte přístup k dodání ještě před finálním schválením plánu.
Krok 6: Dokončete a sdílejte sprintový backlog
Zaznamenejte cíl sprintu, vybrané položky produktového backlogu a počáteční plán dodání na místo, ke kterému má tým přístup a kde jej může aktualizovat. Společně by tyto informace měly jasně ukázat, čeho chce tým dosáhnout a které úkoly je třeba řešit jako další.
Před ukončením schůzky se ujistěte, že všichni souhlasí s cílem, a dejte každému možnost vyjádřit případné zbývající obavy ohledně prognózy. Pokud zůstane nevyřešený důležitý problém týkající se závislostí nebo kapacity, prodiskutujte, co je třeba změnit, než tým zahájí práci.
Během sprintu dává denní scrum vývojářům příležitost zkontrolovat pokrok směrem k cíli a upravit sprintový backlog. Graf burndownu nebo burnupu může pomoci znázornit změny v pokroku, zatímco podrobnosti poskytují jednotlivé úkoly. Pokud nové informace ovlivní vybraný rozsah, mohou vývojáři projednat úpravy s produktovým vlastníkem, aniž by ohrozili cíl sprintu.
Příklad plánování sprintu: tým se 6 vývojáři
Podívejme se, jak tato rozhodnutí fungují v praxi.
Představte si, že plánujete dvoutýdenní sprint pro produkt v oblasti B2B fakturace. Váš tým má šest vývojářů a navrhovaný cíl sprintu: „Noví zákazníci mohou při placení u pokladny platit kartou, aniž by museli kontaktovat obchodní oddělení.“
Než vyberete položky backlogu, musíte vědět, kolik času má tým k dispozici. V tomto příkladu předpokládejme, že každý vývojář má k dispozici šest hodin soustředěné práce na projektu denně, a to před odečtením plánovaných Scrumových událostí a dalších závazků.
Takto funguje výpočet kapacity na 10 pracovních dnů:
| Výpočet kapacity | Hodiny |
|---|---|
| Základní kapacita: 6 vývojářů × 10 dní × 6 hodin | 360 |
| Plánovaná dovolená: 1 vývojář bude 2 dny nepřítomný | −12 |
| Pohotovostní služba: 1 vývojář s 50% dostupností | −30 |
| Scrumové události: 8 hodin na vývojáře | −48 |
| Dostupná kapacita | 270 |
| Vyhraďte si 20 % na neočekávané úkoly | −54 |
| Kapacita dostupná pro plánovanou práci | 216 |
Po vyčlenění orientační 20% rezervy máte nyní k dispozici 216 hodin na plánovanou práci. V praxi byste tuto rezervu zvolili na základě toho, do jaké míry neplánovaná práce narušila předchozí sprinty.
Vyberte úkoly, které podporují cíl sprintu
Po stanovení kapacity vývojáři společně s produktovým vlastníkem procházejí položky backlogu související s checkoutem.
Zde je ilustrativní výběr založený na jejich počátečních odhadech náročnosti na úrovni úkolů:
| Položka backlogu | Odhadované úsilí |
|---|---|
| Vytvořte formulář pro platbu kartou | 48 hodin |
| Integrujte poskytovatele platebních služeb | 88 hodin |
| Řešení neúspěšných plateb a chyb při ověřování | 50 hodin |
| Přidejte potvrzení platby a doručení účtenky | 24 hodin |
| Celkový objem plánované práce | 210 hodin |
Tyto odhady ponechávají 6 hodin v rámci rezervy pro plánovanou práci, plus 54hodinovou rezervu pro neočekávané úkoly. Tým má v produktovém backlogu také vylepšení reportovacího dashboardu. Ačkoli je to užitečné, nepřispívá to přímo k cíli sprintu. Produktový vlastník a vývojáři se shodli, že to nechají na příští sprint.
Plán upravte, jakmile dojde ke změně
Šestého dne poskytovatel platebních služeb zavede změnu v API, která naruší část integrace. Vývojáři situaci prošetří a odhadnou rozsah dodatečné práce, která bude zapotřebí.
Místo toho, aby pokračovali podle původního pořadí úkolů, projednají dopad s produktovým vlastníkem. Pokud se oprava vejde do zbývající kapacity, mohou ji upřednostnit a odložit volitelný styl účtenky nebo jiný úkol s nižší prioritou. Potvrzení platby a další nezbytné práce musí i nadále splňovat definici dokončení.
Pokud je rozsah opravy větší, než se očekávalo, bude třeba přehodnotit zbývající rozsah práce a posoudit, zda je cíl sprintu stále dosažitelný.
Tým může skončit s menším počtem dokončených položek backlogu, než se původně předpokládalo. Pokud však zákazníci mohou dokončit platbu tak, jak bylo zamýšleno, a práce splňuje definici dokončení, byl cíl sprintu splněn.
Příklady cílů sprintu pro jiné týmy
Stejný přístup k plánování můžete uplatnit i na práci mimo oblast vývoje softwaru, ačkoli Scrum samotný je specifický rámec s definovanými odpovědnostmi a událostmi.
Například marketingový tým by si mohl stanovit cíl typu „Zveřejnit vstupní stránku webináře a umožnit návštěvníkům registraci bez manuální pomoci.“ Provozní tým by se mohl zaměřit na cíl „Zajistit, aby každý zaměstnanec v příští skupině nováčků měl již první den k dispozici potřebné vybavení a přístup k systému.“
Oba cíle popisují výsledky, které mohou vést rozhodnutí týmu během celého sprintu. Položky backlogu a plány dodání se budou lišit, ale tým i tak musí zohlednit svou kapacitu a dohodnout se na tom, jak bude úspěšné dodání vypadat.
Časté chyby při plánování sprintu a jak je napravit
Při plánování sprintu mohou nastat problémy, pokud týmy používají story pointy k hodnocení individuálního výkonu, přinášejí na schůzku nejasné položky backlogu, přidělují práci příliš striktně nebo přehlížejí požadavky na testování a externí závislosti.
Pár drobných úprav vám pomůže odhalit tyto problémy dříve, než ovlivní dodávku.
| Chyba | Proč to způsobuje problémy | Jak to napravit |
| Využití story pointů k měření individuálního výkonu | Porovnávání vývojářů podle počtu dokončených bodů může vést k nadhodnocování odhadů nebo k vyhýbání se složitým úkolům. | Zaměřte body příběhu na prognózy na úrovni týmu. Zhodnoťte dokončenou práci z několika sprintů a během upřesňování projednejte změny v odhadech. Posuzujte individuální výkon na základě kvality kódu, spolupráce a výsledků. |
| Zařazení nejasných položek backlogu do plánování | Chybějící akceptační kritéria nebo nezodpovězené technické otázky promění plánování v diskusi o tom, co se má vytvořit, čímž zbývá méně času na plánování dodání. | Vyřešte otázky během upřesňování backlogu, aby vývojáři mohli vytvořit rozumný odhad. Pokud nejistota přetrvává, zvažte menší a lépe srozumitelný úkol. Usilujte spíše o dostatečnou jasnost pro rozhodnutí než o dokonalé specifikace. |
| Přiřazení každého úkolu konkrétní osobě ještě před zahájením práce | Pevně stanovené úkoly ztěžují přizpůsobení se, když se změní priority nebo když jeden vývojář dokončí práci dříve, zatímco jiný potřebuje pomoc. | Nechte vývojáře, aby si práci zorganizovali sami. Dohodněte se na bezprostředních odpovědnostech a zapojení specialistů, poté umožněte členům týmu, aby si během sprintu úkoly převzali, pracovali na nich ve dvojicích nebo je přerozdělili. Zajistěte, aby práce byla viditelná pro celý tým. |
| Nerozřešené externí závislosti | Chybějící přihlašovací údaje k API, bezpečnostní kontroly nebo výstupy jiného týmu mohou způsobit, že tým bude čekat na práci, kterou nemůže ovlivnit. | Než dokončíte sprintový backlog, určete potřebné vstupy, kdo je bude koordinovat a kdy se očekává jejich dodání. Pokud zůstává kritická závislost nejistá, zvažte alternativní položku nebo menší rozsah, který tým dokáže realizovat samostatně. |
Pokud se stejné problémy opakují v několika sprintech, zařaďte je do sprintové retrospektivy a dohodněte se na změně, kterou můžete vyzkoušet během příštího sprintu. Tyto šablony pro sprintovou retrospektivu vám pomohou zaznamenat postřehy a navazující akce.
Na konci sprintu využijte schůzku k revizi sprintu k tomu, abyste společně se zainteresovanými stranami zkontrolovali dokončený inkrement a prodiskutovali, čím by se tým měl zabývat dál.
Jak provést plánování sprintu v ClickUp
Plánování sprintu vyžaduje více úsilí, pokud jsou úkoly, odhady kapacity a plánovací rozhodnutí roztříštěna mezi různými nástroji. ClickUp tyto informace sjednocuje, takže tým může posoudit práci ve vztahu ke kapacitě a přehodnotit plánovací rozhodnutí, když dojde ke změnám v plánu.
Začněte s šablonou pro agilní plánování sprintu v ClickUp. Její přehledy backlogu, stavu vývoje a zdrojů vám pomohou zhodnotit nadcházející práci a připravit se na plánovací diskusi.
Zde je návod, jak postupovat při klíčových rozhodnutích:
- Usnadněte si hodnocení nadcházející práce: Uchovávejte požadavky, kritéria přijetí, priority a závislosti v seznamu nevyřízených úkolů v ClickUp. Tyto podrobnosti pomáhají vývojářům prodiskutovat rozsah a odhadnout náročnost před výběrem úkolů. Jakmile se tým na plánu shodne, přidejte vybrané úkoly do sprintu.
- Stanovte jednotné plánovací období: Nastavte délku sprintu a data zahájení v ClickUp Sprints. Využijte sprintové body nebo časové odhady k posouzení náročnosti a pomozte týmu odhadnout, kolik práce je schopen zvládnout.
- Zkontrolujte, zda je práce vhodná: Porovnejte přidělenou práci s kapacitou jednotlivých osob v zobrazení pracovní zátěže v ClickUp. Zkontrolujte nerovnoměrné rozložení pracovní zátěže a prodiskutujte případné změny před finalizací prognózy.
- Program a rozhodnutí udržujte v těsné souvislosti s prací: Pro časově rozvržený program, navrhovaný cíl sprintu a odkazy na příslušné úkoly použijte ClickUp Docs. Během sezení zaznamenávejte rozhodnutí o rozsahu a nevyřešené otázky, aby se k nim tým mohl v průběhu práce vrátit.
- Zaznamenejte diskusi o plánování: ClickUp AI Notetaker dokáže zaznamenávat schůzky v aplikacích Zoom, Google Meet, Microsoft Teams nebo SyncUps a ukládat shrnutí, klíčová rozhodnutí a úkoly do dokumentu. Projděte si poznámky a poté aktualizujte úkoly sprintu o dohodnuté následné kroky.
- Využijte údaje o postupu prací jako vodítko pro diskuse: Přidejte karty Sprint Burndown nebo Burnup do dashboardů ClickUp, abyste mohli zkontrolovat dokončenou práci a zbývající úsilí. Pokud se postup liší od plánu, zkontrolujte příslušné úkoly, zda neobsahují zpoždění nebo změny rozsahu, které vyžadují pozornost.
Před dalším plánovacím zasedáním se zeptejte Brain²: „Jaké nevyřešené závislosti se objevily na našem posledním zasedání k plánování sprintu?“ Brain dokáže načíst kontext ze zaznamenaných poznámek ze schůzky. Porovnejte tyto podrobnosti s aktuálními úkoly, než je použijete jako podklad pro další prognózu.
Ceny služby ClickUp
Vhodné zejména pro: Scrumové týmy, které řídí více sprintů, sdílené závislosti a měnící se pracovní zátěž a potřebují v jednom pracovním prostoru spravovat backlog, plánovat kapacitu a podávat zprávy o pokroku. Hodí se také pro týmy, které koordinují práci ve sprintech s širšími produktovými nebo obchodními projekty.
Přeskočte to, pokud: Váš tým potřebuje pouze základní Scrum tabuli s malým backlogem a minimálními požadavky na reportování. Flexibilita ClickUp spočívá v možnostech nastavení sprintů, zobrazení a polí. Některé pokročilé funkce pro reportování a automatizaci sprintů také vyžadují tarify vyšší úrovně, které mohou být pro jednoduchý pracovní postup zbytečné.
Kolik času byste měli věnovat plánování před začátkem sprintu?
Po skončení schůzky plánování sprintu by měl mít tým dostatečnou jasnost, aby mohl zahájit práci.
Výše uvedený časový plán a příklad výpočtu kapacity slouží jako výchozí bod. Přizpůsobte je pracovnímu vytížení týmu a poté porovnejte prognózu s dokončenou prací a přerušeními, abyste mohli vylepšit plánování pro příště.
V ClickUp můžete propojit poznámky k plánování s úkoly sprintu a aktualizovat sprintový backlog podle toho, jak se práce mění. Tým se může při rozhodování o tom, co upravit, vrátit k dohodnutému plánu.
Často kladené otázky ohledně plánování sprintu
Jaký je rozdíl mezi plánováním sprintu a plánováním vydání?
Plánování sprintu se zaměřuje na to, čeho chce váš tým během jednoho sprintu dosáhnout a jak tuto práci zrealizuje. Plánování vydání zohledňuje delší časový horizont, například které funkce by mohly být k dispozici v rámci několika sprintů a kdy by je uživatelé mohli obdržet. Prognózy vydání se mohou měnit s tím, jak týmy získávají více informací, zatímco každý cíl sprintu určuje směr práce v rámci daného sprintu.
Potřebujete pro plánování sprintu definici připravenosti?
Ne. Scrum nevyžaduje formální definici připravenosti. Některé týmy ji používají k nastavení společných očekávání ohledně položek backlogu před jejich výběrem, jako jsou jasné požadavky, zvládnutelný rozsah a známé závislosti. Udržujte tato kritéria dostatečně flexibilní, aby podporovala diskusi, aniž by bránila týmu v upřesňování položek, když je to potřeba.
Lze sprint po plánování zrušit?
Ano. Sprint může zrušit pouze produktový vlastník a ke zrušení dochází v případě, že cíl sprintu ztratí smysl, například kvůli významné změně obchodních priorit nebo tržních podmínek. Samotný obtížný úkol nebo nepřesný odhad ještě nemusí být dostatečným důvodem ke zrušení.
Jaký je rozdíl mezi sprintem a agilním přístupem?
Agilní přístup je širší způsob řízení práce založený na hodnotách a principech Agilního manifestu. Sprint je v rámci metodiky Scrum pevně stanovené období trvající maximálně jeden měsíc, během kterého tým pracuje na splnění cíle sprintu a vytváří použitelný inkrement. Agilní principy lze dodržovat i bez použití sprintů. Například metoda Kanban podporuje plynulý tok práce, aniž by vyžadovala iterace s pevně stanovenou délkou.
Může mít jeden sprint více cílů?
Scrum definuje jeden cíl sprintu jako jediný záměr sprintu. Můžete vybrat položky backlogu, které podporují jiné priority, pokud tím neohrozíte tento cíl. Pokud váš tým pravidelně potřebuje několik nesouvisejících cílů, před plánováním prodiskutujte, zda daná práce podporuje širší společný výsledek, nebo zda je třeba vyřešit protichůdné priority.
Měli byste při plánování sprintu odhadovat chyby v bodech příběhu?
Body příběhu jsou ve Scrumu volitelné, a to i u chyb. Týmy, které odhadují chyby, by se měly dohodnout na tom, kdy a proč tak činí. Známé vady lze posoudit během plánování, zatímco chyby objevené během vývoje mohou spadat do práce, která je již nutná ke splnění definice dokončení. Vyhněte se dvojímu započítávání stejného úsilí.