Backlog ve vývoji aplikací: co to je, struktura a správa úkolů
Backlog — je uspořádaný seznam všech úkolů, požadavků a vylepšení, které je třeba v projektu realizovat. Je ústředním artefaktem agilních metodik: ve Scrumu spravuje backlog Product Owner, v Kanbanu — celý tým. Podle Scrum Guide, 2020 není backlog nikdy dokončen: neustále se vyvíjí spolu s produktem a požadavky trhu.
Hlavní
- Backlog — seznam všech úkolů projektu, seřazený podle priority a připravenosti k provedení.
- Základní prvky — user story, chyby, technický dluh, průzkumy a úkoly na zlepšení.
- Prioritizace — klíčový proces: úkoly na vrcholu backlogu jsou nejdůležitější a připravené na sprint.
- Product Owner — vlastník backlogu, odpovědný za jeho obsah a priority.
- Grooming (refinement) — pravidelná činnost pro upřesnění, odhad a změnu priorit prvků backlogu.
Co je backlog ve vývoji?
Backlog (z anglického backlog) — je jednotný zdroj požadavků pro všechny změny v produktu. Product Owner je odpovědný za jeho obsah, dostupnost a průhlednost: každý člen týmu by měl chápat, jaké úkoly jsou v backlogu a v jakém pořadí budou realizovány.
Rozdíl mezi Product Backlogem a Sprint Backlogem
Product Backlog obsahuje všechny úkoly projektu v perspektivě — od funkcí pro příští čtvrtletí po nápady na rok. Sprint Backlog — je podmnožinou úkolů z Product Backlogu, které tým bere do aktuálního sprintu. Sprint Backlog se na dobu sprintu zmrazí, zatímco Product Backlog se neustále mění.
Backlog ve Scrumu vs Kanbanu
Ve Scrumu je backlog přísně strukturován: existuje Product Backlog a Sprint Backlog, úkoly se odhadují v story pointech, sprinty mají pevnou délku. V Kanbanu je backlog flexibilnější: úkoly se tahají, jak se programátoři uvolňují, priority se mohou měnit denně a WIP (work in progress) limity regulují tok úkolů.
Prvky backlogu: z čeho se skládá
Kvalitní backlog obsahuje různé typy úkolů, nejen novou funkcionalitu. Vyvážený backlog bere v úvahu všechny aspekty vývoje produktu.
| Typ prvku | Popis | Příklad |
|---|---|---|
| User Story | Nová funkcionalita z pohledu uživatele | „Jako uživatel chci obnovit své heslo” |
| Bug | Vada nebo chyba ve stávající funkcionalitě | „Tlačítko registrace nefunguje na iOS 16” |
| Tech Debt | Zlepšení kódové základny bez viditelného efektu pro uživatele | „Aktualizovat závislosti na nejnovější verze” |
| Spike / Research | Průzkum nebo prototyp pro snížení nejistoty | „Prozkoumat možnost migrace na Jetpack Compose” |
| Improvement | Zlepšení procesů nebo infrastruktury | „Nastavit CI/CD pro automatické sestavení” |
User Story jako hlavní prvek
Hlavním stavebním kamenem backlogu je User Story (uživatelský příběh). Kvalitní User Story popisuje, jakou hodnotu uživatel získá, ne jaké technické úkony je třeba provést. Formát INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Příběh by se měl vejít do jednoho sprintu, jinak je třeba ho rozložit.
Kritéria přijetí
Kritéria přijetí (acceptance criteria) určují, kdy je úkol považován za hotový. Píší se ve formátu Given-When-Then nebo jako jednoduchý seznam podmínek. Například: „Uživatel může obnovit heslo e-mailem, zpráva přijde do 30 sekund, odkaz je aktivní 24 hodin”. Jasná kritéria přijetí odstraňují spory ve fázi dema.
Prioritizace backlogu: metody a přístupy
Prioritizace — nejdůležitější a nejobtížnější proces řízení backlogu. Product Owner musí brát v úvahu obchodní hodnotu, úsilí, rizika a závislosti mezi úkoly.
MoSCoW: Must-Should-Could-Won’t
MoSCoW — klasická metoda prioritizace. Must have — bez úkolu produkt nefunguje. Should have — důležitý úkol, ale lze odložit. Could have — vylepšení, které bychom rádi udělali. Won’t have — úkoly odložené na budoucnost. Rozdělení: 60 % Must, 20 % Should, 20 % Could. Metoda pomáhá soustředit se na kritickou funkcionalitu.
Matice Value vs Effort
Matice „hodnota / úsilí” rozděluje úkoly do čtyř kvadrantů: Quick Wins (vysoká hodnota, nízké úsilí) — děláme první, Big Bets (vysoká hodnota, vysoké úsilí) — plánujeme předem, Fill-ins (nízká hodnota, nízké úsilí) — děláme mezi tím, a Avoid (nízká hodnota, vysoké úsilí) — neděláme. Tento přístup umožňuje maximalizovat hodnotu při omezených zdrojích.
Weighted Shortest Job First (WSJF)
WSJF — metoda prioritizace ze SAFe, založená na vzorci: hodnota / velikost úkolu. Čím větší je poměr hodnoty k velikosti, tím vyšší je priorita. WSJF bere v úvahu obchodní hodnotu, časovou kritičnost a rizika. Metoda je vhodná pro zralé produktové týmy s velkým objemem backlogu.
Jak řídit backlog: nejlepší praktiky
Efektivní řízení backlogu vyžaduje pravidelné činnosti, správné nástroje a disciplínu celého týmu.
Backlog Refinement (Grooming)
Refinement — pravidelné setkání (obvykle jednou týdně), na kterém tým upřesňuje, odhaduje a mění priority prvků backlogu. Scrum Guide doporučuje věnovat refinementu nejvýše 10 % času týmu. Výsledek: horních 20–30 % backlogu je připraveno na plánování sprintu — má odhad, kritéria přijetí a akcept.
Pravidla DEEP pro backlog
- Detailed appropriately — blízké úkoly jsou podrobné, vzdálené — pouze ve formě nápadů.
- Estimated — všechny úkoly vyšší úrovně jsou odhadnuty v story pointech nebo hodinách.
- Emergent — backlog se neustále mění: úkoly se přidávají, odebírají a mění se jejich priority.
- Prioritized — každý úkol má své pořadí, neexistují úkoly se stejnou prioritou.
Nástroje pro vedení backlogu
Nejoblíbenější nástroje pro řízení backlogu: Jira (průmyslový standard s flexibilním nastavením workflow), Linear (rychlý a moderní tracker), Trello (pro malé týmy a Kanban), Notion (flexibilní prostor s databázemi) a Youtrack. Výběr nástroje závisí na velikosti týmu, metodice a rozpočtu.
Typické chyby při vedení backlogu
I zkušení Product Owners dělají chyby v řízení backlogu, které snižují efektivitu týmu a kvalitu produktu.
Backlog jako skládka nápadů
Nejčastější chyba — házet všechny nápady do backlogu bez filtrování a prioritizace. Backlog naroste do stovek úkolů, ve kterých se nelze vyznat. Řešení: pravidelné čištění backlogu — odstraňování zastaralých úkolů, spojování podobných, odkládání neodkladných. Zdravý backlog obsahuje 50–100 prvků, ne tisíce.
Nedostatek technických úkolů
Když se backlog skládá pouze z User Story, technický dluh roste a infrastrukturní vylepšení se odkládají. Dříve či později tým narazí na strop produktivity kvůli zastaralým závislostem, nedostatku testů nebo architektonickým problémům. Pravidlo: 20 % úkolů ve sprintu by mělo být technických — refaktoring, testy, aktualizace.
Příliš podrobný backlog do budoucna
Podrobné popisování úkolů na 3–6 měsíců dopředu je ztráta času. Požadavky se mění, trh se vyvíjí a podrobně napsané úkoly je třeba přepisovat. Detailizujte pouze úkoly, které se dostanou do nejbližších 1–2 sprintů. Pro vzdálené úkoly stačí název a krátký popis.
Ignorování chyb
Malé chyby se nedostávají do backlogu, protože „není čas” nebo „později opravíme”. Časem chyb přibývá, kvalita klesá a produkt ztrácí důvěru uživatelů. Pravidlo: každá chyba je zaznamenána v backlogu, i když má nízkou prioritu. Pokud se nahromadilo mnoho chyb — vyčleňte sprint na jejich opravu.
Často kladené otázky
Čím se liší Product Backlog od Sprint Backlogu?
Product Backlog — je úplný seznam všech úkolů projektu na dlouhodobou perspektivu, spravovaný Product Ownerem. Sprint Backlog — je podmnožinou úkolů z Product Backlogu, které tým bere do aktuálního sprintu. Sprint Backlog se na dobu sprintu zmrazí, Product Backlog se neustále mění.
Kdo je odpovědný za backlog ve Scrumu?
Za backlog je odpovědný Product Owner. Určuje priority, formuluje úkoly a rozhoduje o připravenosti prvků na sprint. Vývojáři mohou navrhovat změny, přidávat technické úkoly a odhadovat složitost, ale konečné rozhodnutí o prioritách zůstává na Product Ownerovi.
Jak často by se měl provádět grooming backlogu?
Grooming se doporučuje provádět jednou týdně nebo alespoň jednou za sprint. Scrum Guide doporučuje věnovat refinementsu nejvýše 10 % času vývojářů. Pro dvoutýdenní sprint je to přibližně 1–2 hodiny týdně. Pravidelný grooming zabraňuje hromadění „odpadu” v backlogu.
Kolik úkolů by mělo být v backlogu?
Zdravý Product Backlog obsahuje 50–100 prvků. Méně — znamená, že tým nemyslí na budoucnost, více — backlog se mění na skládku. Důležitý není počet úkolů, ale jejich kvalita: horních 20–30 % by mělo být připraveno na sprint, zbytek — v různé míře rozpracovanosti.
Lze měnit backlog během sprintu?
Product Backlog lze měnit kdykoli — to je jeho normální stav. Ale Sprint Backlog se na dobu sprintu zmrazí, aby se tým mohl soustředit na cíl. Jedinou výjimkou je, když Product Owner odebere úkol ze sprintu, protože ztratil aktuálnost.
Shrnutí
- Backlog — jednotný zdroj požadavků pro všechny změny v projektu, spravovaný Product Ownerem.
- Základní prvky — User Story, chyby, technický dluh, průzkumy, zlepšení procesů.
- Prioritizace — klíčová dovednost PO: metody MoSCoW, Value vs Effort, WSJF pomáhají stanovovat priority.
- Pravidla DEEP — backlog by měl být přiměřeně podrobný, odhadnutý, proměnlivý a prioritizovaný.
- Grooming — týdenní činnost pro upřesnění a odhad úkolů vyšší úrovně.
- Typické chyby — skládka nápadů, nedostatek technických úkolů, přílišná podrobnost a ignorování chyb.
- Zdravá velikost — 50–100 prvků, horních 30 % připraveno na sprint.
Vyvineme mobilní aplikaci na klíč
IT Sectr vytváří aplikace pro iOS a Android pro startupy a podniky od roku 2017. Poradíme vám a navrhneme nejlepší řešení.
Přečtěte si také