Scrum Guide | 40. Péče o produktový backlog

Údržba Product Backlogu je jedním z hlavních úkolů Product Ownera. Proces údržby zahrnuje formulaci, podrobné zpracování a přidávání nových User Stories do Product Backlogu. Nejvýznamnějším úkolem údržby je však zajistit, aby byly položky umístěny v Backlogu ve správném pořadí, tj. aby byly prioritizovány.

Údržba Product Backlogu – obsah:

1. Úvod
2. Účel údržby Product Backlogu
3. Chyby v údržbě Product Backlogu
4. Údržba Backlogu vs. metriky používané ve Scrumu
5. Shrnutí

Úvod

Product Backlog je jedním z artefaktů Scrumu. Obsahuje prioritizovaný seznam práce potřebné k vytvoření produktu. Jinými slovy, je to seznam User Stories nezbytných k dosažení cíle produktu. Podrobný popis toho, co jsou User Stories, naleznete v tomto článku. A zde jsou podrobnosti o charakteristikách a jak udržovat Product Backlog.

Údržba Product Backlogu se také nazývá:

• Prioritizace Backlogu,
• Vylepšení Backlogu,
• Škálování Backlogu.

Účel údržby Product Backlogu

Product Owner spravuje Product Backlog. Klíčové dovednosti zahrnují prioritizaci úkolů blížící se k jejich termínu. Důvodem je, že cílem údržby Product Backlogu je zajistit, aby funkce produktu měly nejvyšší obchodní hodnotu, tj. ty, které jsou z pohledu zákazníka nejdůležitější, byly na vrcholu seznamu úkolů. A jejich popis je jasný a podrobný, aby jejich implementace mohla začít hned v následujícím Sprintu.

Product Backlog může být aktualizován denně, pokud je to potřeba. Product Owner může přidávat nové User Stories do Product Backlogu po rozhovoru se Stakeholdery a vývojovým týmem, nebo na základě závěrů a reformulace již napsaných User Stories v Product Backlogu.

Povinná aktualizace Backlogu je jedním z úkolů prováděných během Sprint Review. Tento proces jsme podrobně popsali v tomto článku. Obvykle během této schůzky Scrum tým diskutuje nejen o úkolech, které je třeba dokončit v následujícím Sprintu. Také předběžně specifikuje User Stories a jejich implementaci v následujících dvou nebo třech Sprintech. Tento způsob práce umožňuje Scrum týmu a jeho aktivitám získat širší pohled na dlouhodobý směr. Umožňuje přemýšlet o úkolech, které se aktuálně provádějí, z pohledu jejich vývoje v následujících Sprintech.

Chyby v údržbě Product Backlogu

Jedním z nejčastějších problémů týkajících se údržby Product Backlogu je umožnění jeho nekontrolovatelného rozšiřování. Důvodem je, že při práci na produktu se spontánně objevují různé další funkce a úkoly navržené jak Stakeholdery, tak členy Scrum týmu. Proto je omezení růstu rozsahu Product Backlogu (scope creep) jedním z nejdůležitějších úkolů, které Product Owner vykonává. Nejčastější chyby, které Product Ownři dělají, se týkají:

1. Odchylka od cíle produktu – přidávání příliš mnoha nápadů do Product Backlogu nad rámec základního cíle produktu není dobrá praxe, protože to výrazně snižuje jeho čitelnost. Lépe funguje shromažďovat nápady na další funkce v samostatném dokumentu.
2. Duplicita obsahu – zadávání opakovaných nebo velmi podobných nápadů od různých Stakeholderů do Backlogu – před přidáním další položky do Backlogu by se Product Owner měl ujistit, že nová položka neduplikuje žádnou z existujících.
3. Chybějící širší perspektiva – měli byste řadit položky Product Backlogu podle jejich hodnoty vzhledem k cíli produktu. Přesto mějte na paměti, že prioritizace by měla brát v úvahu následující několik Sprintů, aby byly úkoly prováděné v daném Sprintu bezproblémově propojeny jak s předchozím Sprintem, tak s bezprostředně následujícím.

Chybám tohoto druhu se nelze vyhnout. Nicméně, povědomí o jejich výskytu může učinit Product Ownera opatrnějším při přidávání nových User Stories do Product Backlogu, aby se dosáhlo správné rovnováhy. Důvodem je, že je také chybou příliš omezit Backlog a eliminovat položky, které obsahují podobné úkoly, které se liší. Například popisovat podobné funkce produktu, které se výrazně liší v aplikaci.

Údržba Backlogu vs. metriky používané ve Scrumu

Product Backlog obsahuje popis zbývající práce po celou dobu projektu. Nicméně pouze aktuální a pravidelně udržovaný Backlog může přesně odhadnout poměr množství dokončené práce k celkovému. K zobrazení množství dokončené práce byste měli použít Burndown Chart, o kterém jsme psali v tomto článku.

Další populární metrikou k popisu práce Scrum týmu je Velocity. Můžete ji měřit porovnáním počtu položek Product Backlogu převedených na Increment během jednoho Sprintu. O Velocity jsme podrobněji psali v tomto článku.

Shrnutí

Product Owner provádí údržbu Product Backlogu. Když je Product Backlog dobře udržován, Scrum tým má jasný přehled o zbývající práci. Může také získat širší, dopředu orientovaný pohled na to, jak vypadá cesta k cíli produktu. Proto je důležité, aby Product Owner zajistil, že User Stories zahrnuté v Product Backlogu jsou seřazeny podle priority pro dokončení. A také, že úkoly k dokončení v nadcházejících Sprintech jsou popsány v nejmenších detailech.

Pokud se vám náš obsah líbí, připojte se k naší komunitě aktivních včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube, Pinterestu.