Sprint je základní časová jednotka v Scrum frameworku – pevně stanovené období, typicky 1–4 týdny, během kterého tým pracuje na vybraných položkách z product backlogu s cílem dodat funkční inkrement produktu. Sprint má fixní délku, která se nemění, a na jeho konci by měl existovat potenciálně dodatelný výsledek. Je to jádro iterativního přístupu k vývoji, které umožňuje pravidelnou zpětnou vazbu a adaptaci.
Tradiční projektové řízení plánuje na měsíce nebo roky dopředu. Problém je, že v nejistém prostředí tyto plány rychle zastarávají. Požadavky se mění, objevují se nové informace, původní předpoklady se ukazují jako chybné. Sprint nabízí alternativu – plánujte jen na krátké období, na jeho konci vyhodnoťte a adaptujte.
Pravidelné dodávky vytváří rytmus a disciplínu. Místo vágního „dokončíme, až to bude hotové” je konkrétní závazek: „na konci tohoto sprintu ukážeme toto”. Deadline každé dva týdny nutí k rozhodnutím, prioritizaci a dokončování. Práce se nehromadí do nekonečna.
Pro stakeholdery sprint přináší transparentnost a předvídatelnost. Každé dva týdny vidí pokrok, mohou poskytnout zpětnou vazbu a ovlivnit další směr. To je lepší než čekat měsíce na výsledek, který neodpovídá očekáváním.
Sprint planning na začátku sprintu stanoví cíl a vybere práci. Product Owner prezentuje prioritní položky z backlogu. Tým diskutuje, co je realistické stihnout a jak to udělá. Výstupem je Sprint Goal (cíl, kterého chce tým dosáhnout) a Sprint Backlog (konkrétní položky a úkoly).
Během sprintu tým pracuje na položkách ze Sprint Backlogu. Daily Scrum (standup) každý den synchronizuje tým – co bylo včera, co bude dnes, jaké jsou překážky. Práce se obvykle vizualizuje na tabuli nebo v nástroji, kde je vidět stav každé položky.
Sprint Review na konci prezentuje výsledky stakeholderům. Tým ukazuje, co bylo dokončeno, získává zpětnou vazbu a diskutuje, co dál. Není to formální prezentace, ale interaktivní dialog o produktu.
Sprint Retrospective je reflexe procesu. Co fungovalo? Co ne? Co zlepšit? Retrospektiva se zaměřuje na způsob práce, ne na produkt. Výstupem jsou konkrétní akce pro zlepšení v dalším sprintu.
Délka sprintu by měla být konzistentní. Měnící se délka narušuje rytmus a ztěžuje plánování. Dvoutýdenní sprint je nejběžnější – dostatečně krátký pro rychlou zpětnou vazbu, dostatečně dlouhý pro smysluplnou práci. Kratší sprinty (týden) fungují pro zkušené týmy nebo urgentní projekty. Delší (měsíc) pro komplexnější práci.
Sprint commitment je závazek, ne odhad. Když tým vybere práci do sprintu, zavazuje se k jejímu dokončení. Změny během sprintu by měly být výjimečné – narušují focus a prediktabilitu. Pokud se rozsah mění často, problém je v plánování nebo v kultuře organizace.
Definition of Done definuje, co znamená „hotovo”. Položka není dokončena jen napsáním kódu – musí být otestovaná, zreviewovaná, dokumentovaná podle dohodnutých standardů. Jasná DoD zajišťuje kvalitu a předchází situacím, kdy „hotová” práce vyžaduje další práci.
Velocity je metrika měřící, kolik práce tým typicky dokončí za sprint. Slouží pro plánování – pokud víte, že tým má velocity 30 bodů, můžete lépe odhadnout, co je realistické. Velocity se stabilizuje po několika sprintech a je specifická pro každý tým.
Nedokončená práce na konci sprintu signalizuje problém s plánováním nebo odhadem. Přetahování položek mezi sprinty se stává normou a sprint ztrácí smysl. Řešením je konzervativnější plánování a lámání práce na menší části, které lze skutečně dokončit.
Scope creep během sprintu – přidávání práce po zahájení – narušuje focus a prediktabilitu. Product Owner by měl nové požadavky směřovat do backlogu pro další sprint, ne do aktuálního. Výjimky by měly být skutečně výjimečné.
Sprint jako mini-waterfall je dysfunkce, kdy práce probíhá sekvenčně (analýza → vývoj → test) místo průběžně. Výsledkem je, že testování se hromadí na konci sprintu a odhaluje problémy pozdě. Průběžná integrace a testování jsou klíčem k prevenci.
Ignorování retrospektiv znamená ztrátu příležitosti ke zlepšování. Pokud tým opakovaně naráží na stejné problémy, retrospektivy buď neprobíhají, nebo jejich výstupy se nerealizují. Kontinuální zlepšování je jádrem agilního přístupu.
Sprint pro sprinty, bez jasného cíle, degraduje na pouhý timeboxing bez hlubšího smyslu. Každý sprint by měl mít Sprint Goal – sjednocující cíl, který dává smysl celku, ne jen seznam nesouvisejících položek.
Sprint je mechanismus, který strukturuje práci do pravidelných iterací s definovaným začátkem, koncem a výstupem. Umožňuje rychlou zpětnou vazbu, adaptaci na změny a průběžné zlepšování procesu. Klíčem k úspěchu je konzistence délky, disciplína v dodržování závazků a využití každé retrospektivy k posunu vpřed.
« Zpátky na Slovník pojmůObjevili jste v článku nepřesnosti, nebo byste ho naopak chtěli doplnit? Napište mi!