Co je produktový backlog

Produktový backlog (PB) je prioritizovaný seznam připravený pro vývojový tým. Je odvozený od produktové mapy a jejích požadavků a nejdůležitější položky jsou zobrazené nahoře, takže tým jednoduše pozná, co doručit jako první.

Produktový backlog ztransparentňuje zatím nedoručenou potenciální hodnotu. Jeho tvorba je výsadou produktového vlastníka, který maximalizuje hodnotu produktu a zodpovídá za něj.

Jak produktový backlog zapadá do projektového rámce

Tým společně se Scrum masterem vytvářejí Sprint Backlog na začátku každého sprintu. Je to seznam úkolů určených k dokončení v nadcházejícím období (obvykle 2–3 týdny). Sprint Backlog čerpá z velkého produktového backlogu, který je kompletním seznamem všech vlastností a funkcionalit produktu.

Potřeby zákazníka reprezentuje produktový vlastník a je zodpovědný za prioritizaci požadavků.

PB je seřazený vertikálně, což znamená, že nejdůležitější položky jsou navrchu seznamu a tým si z něj vybírá úkoly podle priority do sprintového backlogu. Produktový backlog se mění a vyvíjí v čase podle požadavků a technologického trendu.

Tip: Produktový backlog se používá i v jiných metodikách agilního rámce, například Kanban, který je místo využívání fixních délek sprintu založený na limitování práce v procesu.

Produktový backlog musí být průběžně udržovaný. Bez aktualizace by se stal neuspořádaným, protože priority se mohou v čase měnit, úkoly se dokončují a vznikají nové nápady.

Vytvoření prvního produktového backlogu

Na začátek tvorby PB doporučujeme použití produktové mapy. Produktová mapa je strategický plán, který ukazuje dlouhodobé vyhlídky produktu. V praxi se často setkáváme s tím, že manažeři a produktoví vlastníci zaměřují svoji pozornost na „vyšperkování“ požadavků a ztrácejí tak celkový obraz (big picture).

Produktová mapa obvykle obsahuje dlouhodobé cíle v několika releasech, zatímco produktový backlog je podrobněji zaměřený na vybrané funkčnosti v následujícím releasu. V praxi by se měl používat vždy jen jeden backlog.

U velkých a rozsáhlých projektů, do nichž je potřeba zapojit více týmů, by to ale nebylo praktické. Proto je v těchto případech možné použít backlog na úrovni velkých funkcionalit a samostatné backlogy pro každou související oblast práce.

Jak detailně musí být položky produktové backlogu zapsané

Ultimátním cílem Agile je přinášet obchodní hodnotu tak brzo a často, jak to jen jde. Všechny artefakty a ceremonie se technicky považují za mimořádné výdaje. Na to, aby byl artefakt užitečný, jeho výsledná hodnota musí přesáhnout úsilí vynaložené na jeho vytvoření.

S ohledem na to, že hodnota uživatelského příběhu je fixní, tak čím méně nákladů vynaložíte na jeho vytvoření, tím vyšší bude návratnost investice.

Pokud je konkrétní uživatelský příběh dostatečně podrobný na to, aby ho tým společně pochopil, odhadl, doručil a následně produktový vlastník mohl prověřit, jestli tým doručil to, co se požadovalo, má uživatelský příběh dostatečnou granulitu a jakékoliv další detaily jsou zbytečné.

Jako dobrá pomůcka na vyhodnocení správné granulity slouží pravidlo INVEST, které je složené z následujících kritérií:

• INDEPENDENT – příběhy mají být na sobě nezávislé
• NEGOTIABLE – příběh není kontrakt, je to pozvánka k diskuzi
• VALUEABLE – pokud příběh nemá dostatečnou hodnotu, nemělo by se na něm pracovat
• ESTIMABLE – příběh má být odhadnutý a prioritizovaný
• SMALL – příběh má být dostatečně malý na to, aby mohl být doručený v jednom sprintu
• TESTABLE – aby příběh splnil podmínku HOTOVO, musí být otestovaný

Příběhy přinášejí obchodní hodnotu, neměly by to být jen vývojové úkoly. Zkouška správnosti je taková, že by příběh měl obsahovat formulaci „Jako …, potřebuji …, abych mohl … .“

Jaké další položky patří do produktového backlogu

Položky produktového backlogu mohou zahrnovat specifikace, požadavky, epiky, uživatelské příběhy nebo dokonce chyby a časově omezené výzkumné úkoly.

Každý produktový backlog splňuje následující vlastnosti:

• Popis: Jaký je cíl daného backlogu
• Hodnota: Obchodní hodnota produktového backlogu určená produktovým vlastníkům
• Odhad: Tým odhaduje relativní pracnost, která bude potřebná k dokončení backlogu
• Pořadí: Produktový vlastník prioritizuje backlog podle relativní hodnoty

Společně tyto vlastnosti vytvářejí DoR (Definition of Ready). V ideálním případě backlog odráží potřeby zákazníků nebo zainteresovaných stran a s dobrým backlogem můžeme zdvojnásobit rychlost týmu.

Prioritizace a uspořádání produktového backlogu

Šikovný produktový vlastník ví, že neuspořádaný produktový backlog vede k nesprávnému rozhodování, časovým ztrátám a dokonce může vyvolat nedůvěru v týmu.

Ve smyslu prioritizace PB je klíčovým slovem„minimální„. Jakkoliv mohou být jednotlivé funkcionality hodnotné, ještě to nemusí automaticky znamenat, že jsou potřebné. Rozdíl mezí těmito dvěma kroky se stává důležitějším při časových omezením a zdrojích. V praxi se často využívá MoSCoW analýza na rozdělení jednotlivých funkčností podle důležitosti:

• Must Have – musí být.
• Should Have – mělo by být, pokud je to možné.
• Could Have – mohlo by být, pokud je to možné.
• Won’t Have – teď to není potřebné, ale je to vítané v budoucnosti.

Po přidání položek do produktového backlogu a přiřazení úvodní priority je možné použít i jednodušší, tříúrovňové hodnocení:

• Kritické pro dosažení obchodních cílů.
• Prospěšné, ale ne kritické.
• Dobrá přidaná hodnota, pokud se to udělá.

Někteří využívají raději metodu WSJF, která upřednostňuje položky na základě trvání úkolu a vážených nákladů plynoucích ze zpoždění. Úkoly tak zůstávají v produktovém backlogu do té doby, dokud nejsou vyřešené nebo dokud produktový vlastník nerozhodne, že už nejsou potřebné.

Každá položka produktového backlogu by měla řešit problém uživatele. V opačném případě by neměla být na seznamu.

Jak zjednodušeně vytvořit produktový backlog

Úroveň detailu položek produktového backlogu záleží na pochopení vývojového týmu. Při jeho tvorbě je důležité do diskuze zapojit i samotný tým, čímž se zlepší konečný výsledek a prohloubí důvěra mezi produktovým vlastníkem a týmem. Dobře definované položky mají přímý vztah s úspěšností projektu a vedou k úspoře času, zdrojů a v konečném důsledku přispívají i k úspěchu celého týmu.

Následující kroky slouží jako základní pomůcka na začátku tvorby backlogu:

• Přehledná produktová mapa.
• Sepsané požadavky potřebné pro dokončení projektu.
• Prioritizace požadavků podle obchodní hodnoty.
• Odhad release plánu – které funkcionality seskupit do jednoho releasu.
• Dostatečné množství položek na naplnění několika sprintů a jejich popis ve znění obchodní hodnoty a výstupu.

Tipy na manažování produktového backlogu

• Využívejte jeden nástroj na správu položek – nepoužívejte víc systémů na sledování chyb, požadavků a prací. Vývojové práce ponechávejte v jednom backlogu.
• Každá změna v produktovém backlogu by měla odpovídat produktové vizi.
• Produktový backlog by měl být seřazený podle priority, hodnoty, závislostí a rizika. V praxi se často zvažuje jen priorita a hodnota a přitom při stavbě rodinného domu se střecha bez silného základu neudrží. Proto berte v úvahu i závislosti a riziko.
• Produktový vlastník je odpovědný za celý produktový backlog. Tým by měl poskytnout potřebné vstupy a v případě změny by měl produktový vlastník následně vymezit uživatelské příběhy podle připravenosti týmu.
• Produktový backlog by měl být dostupný všem členům týmu.
• Produktový backlog je transparentní, dostupný všem zainteresovaným stranám, není složitý a je jednoduché z něj rozpoznat aktuální stav.
• Pro evidenci produktového backlogu využívejte nástroj, který vám usnadňuje jeho správu a používání.
• Používejte princip DEEP (Detailed appropriately, Emergent, Estimated, Prioritized = přiměřeně detailní, naléhavý, odhadnutý, prioritní) a INVEST (nezávislý, obchodovatelný, hodnotný, odhadnutelný, malý, testovatelný) na kontrolu uživatelských příběhů.
• Používejte prioritizační matici, MoSCoW, … jako podporu při prioritizování.
• Ujistěte se, že produktový backlog je dostatečně plný na naplánování aspoň dvou až tří sprintů.
• Zaměřujte se na CO a PROČ – produktoví vlastníci se často zaměřují na hledání a popis řešení, připravují obchodní nebo technické analýzy a vytvářejí funkční design. I když to fundamentálně není špatně, je třeba nezapomínat i na synergický efekt týmu. Tým lidí dokáže být kreativnější a lépe řešit problémy než jedna osoba.