Čo je produktový backlog

Produktový backlog (PB) je prioritizovaný zoznam pripravený pre vývojový tím. Odvodený je od produktovej mapy a jej požiadaviek. Najdôležitejšie položky sú zobrazené navrchu produktového backlogu. Tím jednoducho tak rozpozná, čo doručiť ako prvé.

Produktový backlog stransparentňuje zatiaľ nedoručenú potenciálnu hodnotu. Jeho tvorba je výsadou produktového vlastníka, ktorý maximalizuje hodnotu produktu a zodpovedá zaň.

Ako produktový backlog zapadá do projektového rámca?

Tím spolu so ScrumMastrom vytváraju Sprint Backlog na začiatku každého sprintu. Je to zoznam úloh definovaných na dokončenie v nadchádzajúcom období (zvyčajne 2-3 týždne). Sprint Backlog čerpá z veľkého produktového backlogu, ktorý je kompletným zoznamom všetkých vlastností a funkčností produktu.

Potreby zákazníka reprezentuje produktový vlastník a je zodpovedný za prioritizáciu požiadaviek.

Produktový backlog je zoradený vertikálne, to znamená, že najdôležitejšie položky sú navrchu zoznamu. Tím vyberá úlohy podľa priority do sprintového backlogu. Produktový backlog sa mení a vyvíja v čase podľa požiadaviek a technologického trendu.

Tip: produktový backlog sa používa aj v iných metodikách agilného rámca, ako napríklad Kanban, ktorý je namiesto využívania fixných dĺžok sprintu založený na limitovaní práce v procese.

Produktový backlog musí byť priebežne udržiavaný. Bez jeho aktualizácie by sa stal neusporiadaným, pretože priority sa môžu v čase meniť, úlohy sa dokončujú a vznikajú nové nápady.

Vytvorenie prvého produktového backlogu

Na začiatok tvorby produktového backlogu odporúčame použitie produktovej mapy. Produktová mapa je strategický plán, ktorý ponúka dlhodobé vyhliadky produktu. V praxi sa častokrát stretáme s tým, že manažéri a produktoví vlastníci zameriavajú svoju pozornosť na „šperkovanie“ požiadaviek a strácajú tak celkový obraz (Big Picture).

Produktová mapa zvyčajne obsahuje dlhodobé ciele v niekoľkých releasoch, zatiaľ čo produktový backlog je podrobnejšie zameraný na vybrané funkčnosti v nasledujúcom release. V praxi by sa mal používať vždy jeden backlog. Pri veľkých a rozsiahlych projektoch, na ktoré je potrebné zapojiť viacero tímov by to nebolo ale praktické. V takýchto prípadoch je možné použiť backlog na úrovni veľkých funkčností a samostatný backlog pre každú súvisiacu oblasť práce.

Ako detailne musia byť položky produktového backlogu napísané?

Ultimátnym cieľom Agile je prinášať obchodnú hodnotu tak skoro a tak často ako sa len dá. Všetky artefakty a ceremónie sa technicky považujú za mimoriadne výdaje. Na to, aby artefakt bol užitočný, jeho výsledná hodnota musí presiahnuť úsilie vynaložené na jeho vytvorenie. Vzhľadom na to, že hodnota používateľského príbehu je fixná, čím menej nákladov vynaložíte na jeho vytvorenie, tým vyššia bude návratnosť investície.

Ak je konkrétny používateľský príbeh dostatočne podrobný na to, aby ho tím spoločne pochopil, odhadol, doručil a následne produktový vlastník mohol preveriť, či tím doručil to, čo sa požadovalo, používateľský príbeh má dostatočnú granulitu a akékoľvek ďalšie detaily sú zbytočné.

Ako dobrá pomôcka na ohodnotenie správnej granulity slúži pravidlo INVEST, ktoré sa skladá z nasledovných kritérií:

• INDEPENDENT – príbehy majú byť nezávislé od seba
• NEGOTIABLE – príbeh nie je kontrakt, je to pozvánka na diskusiu
• VALUEABLE – ak príbeh nemá jednoznačnú hodnotu, nemalo by sa na ňom pracovať
• ESTIMABLE – príbeh má byť odhadnutý a prioritizovaný
• SMALL – príbeh má byť dostatočne malý na to, aby mohol byť doručený v jednom sprinte
• TESTABLE – každý príbeh má byť otestovaný, aby splnil podmienku HOTOVO

Príbehy prinášajú obchodnú hodnotu, nemali by to byť len vývojové úlohy. Skúška správnosti je taká, že príbeh by mal obsahovať formu „Ako … , potrebujem …, aby som mohol … .“

Aké iné položky patria do produktového backlogu?

Položky produktového backlogu môžu zahŕňať špecifikácie, požiadavky, epiky, používateľské príbehy alebo dokonca chyby a časovo limitované výskumné úlohy.

Každý produktový backlog spĺňa nasledovné vlastnosti:

• Popis: Aký je cieľ daného backlogu
• Hodnota: obchodná hodnota produktového backlogu určená produktovým vlastníkom
• Odhad: tím odhaduje relatívnu pracnosť, ktorá bude potrebná na dokončenie backlogu
• Poradie: Produktový vlastník prioritizuje backlog poďla relatívnej hodnoty

Spoločne tieto vlastnosti vytvárajú DoR (Definition of Ready). S dobrým backlogom môžeme zdvojnásobiť rýchlosť tímu. V ideálnom prípade backlog odráža potreby zákazníkov alebo zainteresovaných strán.

Prioritizácia a usporiadanie produktového backlogu

Šikovný produktový vlastník vie, že neusporiadaný produktový backlog vedie k nesprávnemu rozhodovaniu, časovým stratám a dokonca môže vyvolať nedôveru v tíme.

V zmysle prioritizácie PB je kľúčovým slovom „minimálny“. Hoci môžu byť jednotlivé funkčnosti hodnotné, ešte to nemusí automaticky znamenať, že sú aj potrebné. Rozdiel medzi týmito dvomi krokmi sa stáva dôležitejším pri časových obmedzeniach a zdrojoch. V praxi sa často využíva MoSCoW analýza na rozdelenie jednotlivých funkčností podľa dôležitosti:

• Must Have – musí byť.
• Should Have – malo by byť, ak je to možné.
• Could Have – mohlo by byť, ak je to možné.
• Won’t Have – teraz to nie je potrebné, ale vítané v budúcnosti.

Po pridaní položiek do produktového backlogu a priradení úvodnej priority je možné použiť aj jednoduchšie, trojúrovňové hodnotenie podľa:

• Kritické pre dosiahnutie obchodných cieľov.
• Prospešné, ale nie kritické.
• Dobrá pridaná hodnota, ak sa to urobí.

Niektorí uprednostňujú metódu WSJF, ktorá uprednostňuje položky na základe trvania úlohy a vážených nákladov z oneskorenia. Úlohy tak zostávajú v produktovom backlogu dovtedy, pokiaľ nie sú vyriešené alebo kým produktový vlastník nerozhodne, že už nie sú potrebné.

Každá položka produktového backlogu by mala riešiť problém používateľa. V opačnom prípade by nemala byť na zozname.

Ako vytvoriť produktový backlog zjednodušene?

Úroveň detailu položiek produktového backlogu závisí od pochopenia vývojového tímu. Pri jeho tvorbe je dôležité do diskusie zapojiť aj samostatný tím, zlepší sa tak konečný výsledok a prehĺbi dôvera medzi produktovým vlastníkom a tímom. Dobre definované položky majú priamy vzťah s úspešnosťou projektu a vedú k úspore času, zdrojom a v konečnom dôsledku prispievajú aj k úspechu celého tímu.

Nasledujúce kroky slúžia ako zakladná pomôcka na začiatku tvorby backlogu:

• Prehľadná produktová mapa.
• Spísané požiadavky potrebné pre dokončenie projektu.
• Prioritizácia požiadaviek podľa obchodnej hodnoty.
• Odhad release plánu – ktoré funkčnosti zoskupiť do jedného releasu.
• Dostatočné množstvo položiek na naplnenie niekoľko sprintov a ich popis v znení obchodnej hodnoty a výstupu.

Tipy na manažovanie produktového backlogu

• Využívajte jeden nástroj na správu položiek – nepoužívajte viac systémov na sledovanie chýb, požiadaviek a prác. Vývojové práce ponechávajte v jednom backlogu.
• Každá zmena v produktovom backlogu by mala zodpovedať produktovej vízií.
• Produktový backlog by mal byť zoradený podľa priority, hodnoty, závislostí a rizika. V praxi sa často zvažuje len priorita a hodnota. Pritom pri stavbe rodinného domu sa strecha bez silného základu neudrží. Preto berte do úvahy aj závislosti a riziko.
• Produktový vlastník je zodpovedný za celý produktový backlog. Tím by mal poskytnúť potrebné vstupy. V prípade zmeny vie následne produktový vlastník vymedziť používateľské príbehy podľa pripravenosti tímu.
• Produktový backlog by mal byť dostupný všetkým členom tímu.
• Produktový backlog je transparetný, dostupný všetkým zainteresovaným stranám, nie je zložitý a je jednoduché z neho rozpoznať aktuálny stav.
• Pre evidenciu produktového backlogu využívajte nástroj, ktorý vám uľahčuje jeho správu a používanie.
• Používajte princíp DEEP (detailný, rýchly, odhadnutý, prioritný) a INVEST (nezávislý, obchodovateľný, hodnotný, odhadnuteľný, malý, testovateľný) na kontrolu používateľských príbehov.
• Používajte prioritizačnú maticu, MoSCoW, … ako podporu pri prioritizovaní.
• Uistite sa, že produktový backlog je dostatočne plný na naplánovanie aspoň dvoch, troch šprintov.
• Zamerajte sa na ČO a PREČO – produktový vlastníci sa často zameriavajú na hľadanie a popis riešenia, pripravujú obchodné alebo technické analýzy a vytvárajú funkčný dizajn. Hoci to fundamentálne nie je nesprávne, netreba zabúdať na synergický efekt tímu. Tím ľudí dokáže byť kreatívnejší a lepšie riešiť problémy ako jedna osoba.