Produktový backlog je jediným zdrojem úkolů vykonávaných Scrum týmem. Je to seznam plánovaných funkcionalit a vylepšení produktu. Jeho podoba je měnitelná a ne všechny úkoly zahrnuté v produktovém backlogu budou dokončeny. Evolvuje během diskuzí se zainteresovanými stranami. Je také neustále vylepšován. To znamená, že čím blíže je termínu, tím podrobnější úkol se stává.
Co je produktový backlog? – obsah:
- Úvod
- Co obsahuje produktový backlog?
- Podoba produktového backlogu
- Vylepšení produktového backlogu
- Shrnutí
Úvod
Produktový backlog je největší z Scrum artefaktů. Odráží stav práce na produktu vzhledem k cíli produktu. Na druhou stranu, když je práce na produktu dokončena, jeho backlog se stává úplným seznamem úkolů vykonaných Scrum týmem k vytvoření produktu. Nicméně neobsahuje podrobné technické řešení.
Co obsahuje produktový backlog?
Produktový backlog je vytvářen během schůzek Product Ownera se zainteresovanými stranami. Product Owner je jediným vlastníkem a osobou odpovědnou za tento zdroj úkolů.
Obchodní jazyk charakterizuje položky v produktovém backlogu. Jinými slovy, popisují hodnotu produktu z pohledu zainteresovaných stran.
Popisy úkolů zahrnuté v seznamu úkolů potřebují koherenci a jasnost. Obsahují funkce a vylepšení produktu, obvykle prezentované ve formě uživatelských příběhů, kterým věnujeme samostatný příspěvek. Zde pouze zmíníme, že se jedná o popisy částečných funkcionalit produktu, které odpovídají na otázky týkající se následujících problémů:
- Rozsah úprav produktu
- Účel úpravy produktu
- Typ uživatele, pro kterého tato úprava vzniká
Podoba produktového backlogu
Pořadí úkolů zahrnutých v produktovém backlogu se mění s vývojem produktu. Během práce na něm Scrum tým formuje a vylepšuje jeho funkcionality. Při setkání s překážkami umožňují jeho implementované akce všem přemýšlet a definovat budoucí adekvátní řešení, a ta se také budou měnit v závislosti na nepředvídaných dalších překážkách. Proto neexistuje jasný a definovaný pořádek akcí, vše je měnitelné. Vylepšení produktového backlogu je zaměřeno na jeho kontinuální aktualizaci a přípravu na další úkoly. Z tohoto důvodu je to kontinuální proces.
Úkoly s vzdáleným termínem jsou typicky velké, obecné celky. Jejich popis neobsahuje detaily, ale pouze nástin funkcionality, která by měla být realizována. Mezi nimi je také možné najít úkoly, které nikdy neskončí.
Položky v produktovém backlogu mohou představovat alternativní řešení. A také nápady zákazníka, které mohou zastarat, být neprofitabilní nebo z nějakého jiného důvodu nikdy nevstoupí do fáze implementace. Proto je produktový backlog někdy žertem nazýván „seznam přání zákazníka“.
Dalším důvodem pro změny v podobě produktového backlogu je přeformulování řešení. Někdy se ukáže, že určitý problém byl již vyřešen při vytváření jiné funkcionality produktu. Nebo se očekávaná funkcionalita stala nadbytečnou v důsledku změn v jiných řešeních.
Jednou z základních činností během vylepšování produktového backlogu je rozdělení úkolů obsažených v produktovém backlogu na části. Díky tomu je obecný nástin funkcionality prezentován ve formě menších, podrobnějších a přesně definovaných jednotek.
Úkoly navržené pro bližší implementaci se stávají podrobnějšími. Také se zmenšují, obsahují detaily řešení. Detaily se objevují během vývoje produktu. A díky znalosti aktuálního stavu produktu a aktuálních očekávání zainteresovaných stran doplňuje Product Owner nadcházející úkoly o jejich popis, pořadí a velikost. Poté vybírá nejlépe popsané úkoly pro další Sprint Backlog.
Vylepšení produktového backlogu
Během práce na produktu Product Owner modifikuje a upřesňuje produktový backlog ve spolupráci s vývojovým týmem. Na základě návrhů Product Ownera tým během plánování sprintu vybírá funkce k implementaci z produktového backlogu. Ty jsou poté přesunuty do Sprint Backlogu a rozděleny na úkoly, které mají být dokončeny. Úkoly přesunuté do Sprint Backlogu jsou popsány technickým jazykem, který je pro vývojáře nejvíce užitečný.
Velikost úkolu je důležitou metrikou z pohledu vývojového týmu. Jeho správné odhadnutí se stává obzvlášť kritickým při výběru uživatelských příběhů z produktového backlogu do Sprint Backlogu.
Vývojový tým se časem učí správně odhadnout čas a úsilí potřebné k dokončení konkrétního uživatelského příběhu. To se vyjadřuje v dnech, člověko-hodinách nebo Story Points a poskytuje odhad hodnoty nazývané Team Velocity.
Shrnutí
Produktový backlog je neustále vylepšovaný seznam úkolů vedoucích k cíli produktu. Obsah produktového backlogu je obvykle vyjádřen ve formě uživatelských příběhů. A čím kratší je čas zbývající k dokončení úkolu, tím:
- Popis práce je podrobnější
- Rozsah úkolu je menší
- Rozsah úkolu je lépe definován
Scrum tým se stará o úkoly. Product Owner spravuje a modifikuje produktový backlog.
Pokud se vám náš obsah líbí, připojte se k naší komunitě pilných včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube, Pinterestu.
Caroline Becker
Jako projektová manažerka je Caroline odbornicí na hledání nových metod, jak navrhnout nejlepší pracovní postupy a optimalizovat procesy. Její organizační dovednosti a schopnost pracovat pod časovým tlakem z ní činí nejlepší osobu, která dokáže složité projekty přetavit ve skutečnost.
Scrum Guide:
- Slovník základních pojmů, rolí a představ
- Co je Scrum?
- Hodnoty Scrumu
- Jak implementovat Scrum ve vaší společnosti?
- Scrum tým - co to je a jak to funguje?
- Kdo je Product Owner?
- Nejčastější chyby Product Ownera
- Kdo je Scrum Master?
- Nejčastější chyby Scrum Mastera
- Jaké statistiky a metriky by měl Scrum Master sledovat?
- Vývojový tým ve Scrumu
- Nejčastější chyby vývojářů
- Scrum artefakty
- Škálování Scrumu
- Sprint Backlog
- Co je to Product Backlog?
- Co jsou uživatelské příběhy?
- Vytváření nejlepší uživatelské příběhu s INVEST
- Nejčastější chyby v uživatelských příbězích
- Kritéria přijetí uživatelského příběhu
- Odhad a příběhové body ve Scrumu
- Plánovací poker
- Hra o odhadování týmu
- Definování přírůstku
- Scrum události
- Co je to burndown chart?
- Výhody a nevýhody burndown grafu
- Kanbanové tabule ve Scrumu a Scrumbanu
- Rychlost v Scrum - Rychlost vývojového týmu
- Denní Scrum
- Plánování sprintu
- Sprintová revize
- Co je to Sprint Retrospektiva?
- Běžné chyby během retrospektivy sprintu
- Péče o produktový backlog
- Jak vytvořit a interpretovat burndown chart?