Jak prioritizovat funkce v backlogu: metody, které dávají smysl

01Nejdřív pojmenujte cíl a problém

Napište, jaký výsledek má nejbližší práce přinést. Například umožnit zákazníkovi dokončit objednávku bez telefonátu, zkrátit ruční kontrolu podkladů nebo odstranit chybu při přihlášení. Formulace „vylepšit aplikaci“ nedává při střetu požadavků dostatečnou oporu. Cíl má být konkrétní, ale nemá předem zamknout jediné technické řešení.

Ke každé kandidátní položce přidejte uživatele, jeho problém, podklad a očekávanou změnu. Požadavek „přidat export“ může skrývat pravidelnou povinnost vůči účetnímu, jednorázovou kontrolu nebo zvyk používat tabulku. Tyto situace mají odlišnou naléhavost. Ptejte se, jak uživatel pracuje dnes a co mu současný postup znemožňuje.

• Pro koho problém řešíme a v jakém kroku práce vzniká?
• Jak víme, že se problém opravdu vyskytuje?
• Jak poznáme, že navržená změna pomohla?
• Co je zatím odhad a co máme ověřené?

Ve Scrumu je Product Backlog uspořádaný seznam práce pro zlepšení produktu a odpovědnost za jeho správu a pořadí nese Product Owner. Scrum Guide zároveň počítá s průběžným zpřesňováním položek. Odpovědnost za rozhodnutí tedy neznamená, že jeden člověk musí sám vymyslet požadavky nebo odhadovat práci vývojářů.

U nového produktu nejprve oddělte potřebu ověřit zájem od potřeby stavět plný provoz. Pomůže postup od nápadu k MVP. V backlogu pak jasně označte, zda položka přináší funkci, ověření předpokladu nebo nutnou přípravu další práce.

02MoSCoW použijte pro domluvu rozsahu

Agile Business Consortium rozlišuje Must Have, Should Have, Could Have a Won’t Have this time. Pro konkrétní období určíte, bez čeho dodávka nedává smysl, co je důležité, co lze vypustit a co odložit.

Must Have podmiňuje použitelnou a bezpečnou dodávku. U Should Have existuje náhradní postup, Could Have má menší dopad při vynechání. Won’t Have this time znamená odložení z tohoto rozsahu. Před diskusí sjednoťte význam skupin pro vaše vydání.

Představte si interní systém pro žádosti zaměstnanců. Odeslání žádosti a rozhodnutí oprávněného vedoucího mohou tvořit nezbytný průchod. Volba barev přehledu může počkat. U automatických připomínek ověřte, zda lze dočasně použít provozně únosný postup. Tento příklad pouze ukazuje způsob uvažování; konkrétní zařazení závisí na vaší službě a závazcích.

Když všechno skončí v první skupině, vraťte se k hranici vydání. Někdy je položka příliš široká a obsahuje jak nutné jádro, tak doplňky. Rozdělte ji podle použitelných výsledků. Přesunutí štítku nemá zakrývat práci, bez které nelze funkci bezpečně nasadit.

03RICE pomáhá porovnat doložené odhady

Metoda RICE popsaná Intercomem používá dosah, dopad, důvěru v odhady a pracnost. Dosah, dopad a důvěra se násobí a výsledek se dělí pracností. Dosah musí mít společné období a jednotku. Pracnost zahrnuje práci potřebných členů týmu, nikoli jen samotné programování.

Při použití v týmu si ujasněte, jaký dopad vlastně hodnotíte. Zlepšení dokončení objednávky není stejné jako úspora práce správce. U každého odhadu připojte podklad a datum. Když informace chybí, přiznejte nejistotu. Více desetinných míst nenahradí rozhovor s uživatelem nebo kontrolu provozních dat.

Intercom výslovně upozorňuje, že výsledné skóre není pevné pravidlo a pořadí mohou změnit závislosti. Berte ho jako podklad k diskusi. Dva blízké výsledky často neodůvodňují dlouhé přepočítávání; důležitější může být možnost dříve ověřit zásadní předpoklad.

Skóre nepřepočítávejte pokaždé, když se někomu nelíbí výsledek. Nejprve ukažte, který podklad se změnil. Úprava čísel jen kvůli požadovanému pořadí vytváří zdání dohody, zatímco skutečný důvod zůstává skrytý.

04Odklad posuzujte podle konkrétního důsledku

U některých položek rozhoduje čas. Je rozdíl odložit pohodlnější filtr a odložit změnu, bez které skončí provoz důležité integrace. Zapište, co se při odkladu stane, kdy se to projeví a kdo dopad ponese. Samotné slovo „urgentní“ nestačí. Termín také rozlište na skutečný vnější závazek a přání některého oddělení.

Při hrubém porovnání hodnoty a pracnosti používejte několik srozumitelných úrovní. Ke každému zařazení napište důvod. Tým tak může rychle odhalit nápad, který přináší malou změnu a vyžaduje velkou přípravu. Současně se ptejte, zda zdánlivě náročnou funkci lze ověřit menším krokem.

Neporovnávejte domnělé tržby s přesně spočítanými náklady, jako by šlo o stejně jisté veličiny. Kde nemáte podklad, pracujte se scénáři a hranicí, při které by se rozhodnutí změnilo. Prioritizace má nejistotu ukázat, ne ji schovat za tabulku.

05Závislosti a provozní práci posuzujte otevřeně

Funkce může mít vysokou hodnotu a přesto nemůže začít jako první. Potřebuje oprávnění, kvalitnější data nebo rozhraní, které zatím neexistuje. Uveďte tyto závislosti přímo u položky. Tým musí vidět, co odemyká další práci a co lze řešit nezávisle. Pořadí v seznamu samo o sobě neurčuje možnost souběžného vývoje.

Technický dluh popište přes jeho důsledek. Obecné „musíme předělat architekturu“ bývá pro ostatní obtížně posouditelné. Srozumitelnější je doložit opakovanou chybu, riziko ztráty dat, problém s aktualizacemi nebo překážku konkrétní funkce. K návrhu přidejte rozsah opravy, dočasné opatření a riziko dalšího čekání.

Bezpečnostní incident a závažná provozní porucha vyžadují postup odpovídající jejich dopadu. Nečekejte na běžné bodování nových funkcí. Po zásahu ale zapište, která plánovaná práce se posunula a proč. Skrytá kapacita spotřebovaná provozem vede k plánu, který vypadá proveditelně jen na papíře.

Pro běžnou údržbu dohodněte způsob plánování s vývojovým a provozním týmem. Žádný univerzální poměr kapacity nezajistí správnou rovnováhu. Rozhodujte podle stavu služby a ověřených rizik. Odhad zahrnuje také testování, migraci dat, dokumentaci a přípravu podpory, pokud je změna potřebuje.

06Rozhodnutí ukončete pořadím a důvodem

Na schůzku přineste omezený seznam položek, které soupeří o stejné období a kapacitu. Každá musí mít dost podkladů pro dané rozhodnutí. U neurčitého návrhu může být správným dalším krokem krátké ověření. Není nutné předstírat, že už znáte cenu celého řešení.

1. Potvrďte cíl, hranice období a dostupnou kapacitu.
2. Oddělte nutné závazky a závažná provozní rizika.
3. Porovnejte ostatní kandidáty a jejich závislosti.
4. Zapište pořadí, důvod a okolnost pro nové posouzení.

U každé přijaté položky zapište také to, co se do aktuální práce nevešlo. Obchod nebo vedení mají vidět důsledek svého požadavku. Zrychlení jedné dodávky může znamenat odklad jiné. Tento záznam je užitečnější než neurčitý příslib, že tým „nějak zvládne obojí“.

Neshodu řešte u konkrétního předpokladu. Pokud obchod očekává nový zákaznický segment a podpora vidí opakované potíže současných klientů, zjistěte podklady k oběma potřebám. Výsledkem může být menší ověření obchodní příležitosti a oprava nejvážnější překážky. Rozhodnutí musí mít vlastníka a jasně popsanou odpovědnost.

Pořadí sdílejte i s lidmi, kteří na schůzce nebyli. Uživatelé podpory, obchodníci nebo správci potřebují vědět, co mohou slíbit a s čím mají zatím pracovat. Oznámení rozhodnutí má obsahovat potřebné souvislosti, nikoli pouze nový seznam čísel a termínů.

07Backlog pravidelně čistěte a ověřujte výsledky

Po dodání porovnejte očekávaný přínos s tím, co uživatelé skutečně dělají. Změna může být technicky dokončená, ale stále neřešit původní problém. Podle typu funkce sledujte dokončené úkoly, chybové stavy nebo potřebu ruční pomoci. Metriku vyberte před vývojem a vysvětlete její omezení.

Staré položky nemají automaticky nárok na realizaci. U odloženého požadavku ověřte, zda stále existuje problém, uživatel a důvod. Sloučte duplicity, odstraňte překonané návrhy a archivujte rozhodnutí. Menší srozumitelný seznam se posuzuje snáz než zásoba nápadů, které nikdo nedokáže vysvětlit.

Pořadí přezkoumejte při významné změně podkladů, závazků nebo kapacity. Ve Scrumu zároveň respektujte cíl probíhajícího sprintu; průběžná úprava Product Backlogu není povolením neustále rušit rozdělanou práci. Rozdíl mezi způsoby řízení popisuje srovnání agilního vývoje a waterfallu.

Zaveďte jednoduchý záznam: rozhodli jsme se takto, protože jsme věděli toto; vrátíme se k tomu při této změně. Nový člen týmu pak pochopí souvislosti a původní vlastník nemusí opakovaně obhajovat zapomenuté rozhodnutí. Metoda funguje až tehdy, když vede k práci, kterou lze dokončit a vyhodnotit.

08Časté otázky k prioritizaci backlogu