Scrum Guide | 40. Starostlivosť o produktový backlog

Starostlivosť o Product Backlog je jednou z hlavných úloh Product Ownera. Proces starostlivosti zahŕňa formulovanie, podrobné spracovanie a pridávanie nových User Stories do Product Backlogu. Najdôležitejšou úlohou starostlivosti je však zabezpečiť, aby boli položky umiestnené v Backlogu v správnom poradí, t.j. aby sa stali prioritizovanými.

Starostlivosť o Product Backlog – obsah:

1. Úvod
2. Účel starostlivosti o Product Backlog
3. Chyby v údržbe Product Backlogu
4. Údržba Backlogu vs. metriky používané v Scrume
5. Zhrnutie

Úvod

Product Backlog je jedným z artefaktov Scrumu. Obsahuje prioritizovaný zoznam práce potrebnej na vytvorenie produktu. Inými slovami, je to zoznam User Stories potrebných na dosiahnutie cieľa produktu. Podrobný popis toho, čo sú User Stories, nájdete v tomto článku. A tu sú podrobnosti o charakteristikách a o tom, ako udržiavať Product Backlog.

Starostlivosť o Product Backlog sa tiež nazýva:

• Prioritizácia Backlogu,
• Refinovanie Backlogu,
• Škálovanie Backlogu.

Účel starostlivosti o Product Backlog

Product Owner spravuje Product Backlog. Kľúčové zručnosti zahŕňajú prioritizáciu úloh s blížiacim sa termínom. Dôvodom je, že cieľom starostlivosti o Product Backlog je zabezpečiť, aby funkcie produktu mali najvyššiu obchodnú hodnotu, t.j. tie, ktoré sú z pohľadu zákazníka najdôležitejšie, boli na vrchole zoznamu úloh. A ich popis je jasný a podrobný, aby sa ich implementácia mohla začať hneď v nasledujúcom Sprinte.

Product Backlog sa môže aktualizovať denne, ak je to potrebné. Product Owner môže pridať nové User Stories do Product Backlogu po rozhovore so Stakeholdermi a vývojovým tímom, alebo na základe záverov a reformulovania už napísaných User Stories v Product Backlogu.

Povinná aktualizácia Backlogu je jednou z úloh vykonávaných počas Sprint Review. Tento proces sme podrobne opísali v tomto článku. Zvyčajne počas tohto stretnutia Scrum tím diskutuje nielen o úlohách, ktoré je potrebné dokončiť v nasledujúcom Sprinte. Taktiež predbežne špecifikuje User Stories a ich implementáciu v nasledujúcich dvoch alebo troch Sprinte. Tento spôsob práce umožňuje Scrum tímu a jeho aktivitám získať širší pohľad na dlhodobý smer. Umožňuje premýšľať o úlohách, ktoré sa aktuálne vykonávajú, z pohľadu ich rozvoja v nasledujúcich Sprinte.

Chyby v údržbe Product Backlogu

Jedným z najbežnejších problémov týkajúcich sa starostlivosti o Product Backlog je umožnenie jeho nekontrolovateľného rozširovania. Dôvodom je, že pri práci na produkte sa spontánne objavujú rôzne ďalšie funkcie a úlohy navrhnuté ako Stakeholdermi, tak aj členmi Scrum tímu. Preto je obmedzenie rastu rozsahu Product Backlogu (scope creep) jednou z najdôležitejších úloh vykonávaných Product Ownerom. Najbežnejšie chyby, ktorých sa Product Owneri dopúšťajú, sa týkajú:

1. Odchýlenie od cieľa produktu – pridávanie príliš mnohých nápadov do Product Backlogu nad rámec základného cieľa produktu nie je dobrá prax, pretože to výrazne znižuje jeho čitateľnosť. Lepšie je zbierať nápady na ďalšie funkcie v samostatnom dokumente.
2. Duplicita obsahu – zadávanie opakovaných alebo veľmi podobných nápadov od rôznych Stakeholderov do Backlogu – pred pridaním ďalšej položky do Backlogu by sa Product Owner mal uistiť, že nová položka neduplikuje žiadnu z existujúcich.
3. Chýbajúci širší pohľad – mali by ste usporiadať položky Product Backlogu podľa ich hodnoty vzhľadom na cieľ produktu. Stále však majte na pamäti, že prioritizácia by mala zohľadňovať nasledujúcich niekoľko Sprintov, aby úlohy vykonávané v danom Sprinte boli bezproblémovo prepojené s predchádzajúcim Sprintom a Sprintom, ktorý nasleduje bezprostredne po ňom.

Chybám tohto druhu sa nedá vyhnúť. Avšak vedomosť o ich výskyte môže urobiť Product Ownera opatrnejším pri pridávaní nových User Stories do Product Backlogu, aby sa dosiahla správna rovnováha. Dôvodom je, že je tiež chybou príliš zúžiť Backlog a eliminovať položky, ktoré obsahujú podobné úlohy, ktoré sa líšia. Napríklad opisovanie podobných funkcií produktu, ktoré sa výrazne líšia v aplikácii.

Údržba Backlogu vs. metriky používané v Scrume

Product Backlog obsahuje popis zostávajúcej práce počas celého projektu. Avšak iba aktuálny a pravidelne udržiavaný Backlog môže presne odhadnúť pomer množstva vykonanej práce k celkovému. Na zobrazenie množstva vykonanej práce by ste mali použiť Burndown Chart, o ktorom sme písali v tomto článku.

Ďalšou populárnou metrikou na opis práce Scrum tímu je Rýchlosť. Môžete ju merať porovnaním počtu položiek Product Backlogu premenených na Increment počas jedného Sprinte. Rýchlosť sme podrobnejšie opísali v tomto článku.

Zhrnutie

Product Owner vykonáva starostlivosť o Product Backlog. Keď je Product Backlog dobre udržiavaný, Scrum tím má jasný prehľad o práci, ktorá zostáva. Môže tiež získať širší, dopredu orientovaný pohľad na to, ako vyzerá cesta k cieľu produktu. Preto musí Product Owner zabezpečiť, aby boli User Stories zahrnuté v Product Backlogu usporiadané podľa priority na dokončenie. A tiež, aby boli úlohy na dokončenie v nadchádzajúcich Sprinte opísané v najjemnejších detailoch.

Ak sa vám náš obsah páči, pridajte sa k našej komunite usilovných včiel na Facebooku, Twitteri, LinkedIn, Instagrame, YouTube, Pinterest.