Na první pohled vypadala Feature docela zdravě. Měla vlastníka, stav In Progress, několik týmových Stories a dokonce i přiřazenou Business Value. Jmenovala se „Technical Improvements – PI 4“.
Když jsme ji ale během kontroly backlogu otevřeli, našli jsme pod ní aktualizaci knihovny, změnu logování, úpravu jednoho formuláře, nový monitoring, požadavek lokálního trhu a opravu integračního rozhraní.
Položil jsem jednoduchou otázku: „Co bude po dokončení této Feature jinak pro zákazníka nebo pro organizaci?“
Nikdo nedokázal odpovědět. Jediné, co měly položky společné, byl tým, který je měl realizovat.
Právě v podobných situacích vznikají takzvané Container Features. Ne vždy jsou chybou. Mohou být pragmatickou pomůckou pro agregaci drobné, technické nebo provozní práce. Stejně snadno se z nich ale stane backlogový odpadkový koš: místo, kam se ukládají položky, o jejichž účelu, hodnotě a prioritě se organizaci nechce rozhodovat.
Co je Container Feature
Container Feature není obecně standardizovaný agilní pojem s jednou závaznou definicí. V praxi se tímto označením obvykle myslí nadřazená backlogová položka, která vznikla především proto, aby seskupila několik Stories.
Na rozdíl od běžné Feature však tyto Stories nevytvářejí jeden ucelený výsledek. Spojuje je například:
- stejný tým,
- stejná technická komponenta,
- stejný typ práce,
- stejný kvartál nebo PI,
- stejný zdroj požadavků,
- nebo pouze povinnost mít v nástroji vyplněného rodiče.
Pracovní definice tedy může znít následovně:
Container Feature je nadřazená backlogová položka vytvořená především pro seskupení Stories, nikoliv pro řízení jednoho uceleného zákaznického, provozního nebo business výsledku.
Samotná hierarchie přitom ještě nezaručuje, že backlog dává smysl. Této otázce se podrobněji věnujeme také v článku o tom, proč je potřeba rozlišovat různé úrovně řízení práce. Investiční, doručovací a týmová úroveň představují různé typy rozhodnutí, nikoliv pouze různě velké tickety.
Jak se liší od skutečné Feature
| Otázka | Skutečná Feature | Container Feature |
|---|---|---|
| Co spojuje její Stories? | Jeden rozpoznatelný výsledek | Tým, období, technologie nebo typ práce |
| Jak se prioritizuje? | Podle hodnoty a naléhavosti výsledku | Často musí být prioritizována každá Story zvlášť |
| Kdy je dokončená? | Po dosažení definovaného výsledku | Po skončení období nebo ve chvíli, kdy už se nepřidává další práce |
| Má jasnou hranici? | Měla by mít | Často se průběžně rozšiřuje |
| Lze ověřit přínos? | Ano, alespoň pomocí hypotézy a důkazů | Obvykle pouze na úrovni jednotlivých Stories |
Například Scaled Agile Framework popisuje Feature jako funkcionalitu, která naplňuje potřebu stakeholdera, přináší hodnotu a je možné ji dokončit v rámci jednoho PI. Není to jediná použitelná definice Feature, ale poskytuje dobrý kontrolní bod: existuje zde konkrétní potřeba, rozpoznatelný výsledek a časová hranice.
Scrum naproti tomu žádnou povinnou hierarchii Epic–Feature–Story nepředepisuje. Oficiální Scrum Guide pracuje obecně s položkami Product Backlogu. Povinnost, aby každá Story měla rodičovskou Feature, tedy obvykle nevychází ze Scrumu. Vychází z konkrétního organizačního nebo nástrojového nastavení.
Proč Container Features vznikají
Container Features obvykle nevznikají proto, že by někdo chtěl záměrně poškodit backlog. Častěji jde o pragmatickou reakci na reálný problém.
Nástroj vyžaduje rodičovskou položku
Jira, Azure DevOps nebo firemní reporting mohou být nakonfigurované tak, že každá Story musí patřit pod Feature. Když přirozená Feature neexistuje, lidé vytvoří náhradního rodiče.
Drobné položky jsou příliš malé na samostatnou Feature
Tým průběžně řeší menší změny, které samostatně nedosahují úrovně programové Feature. Může jít o drobné požadavky lokálních trhů, údržbu, aktualizace knihoven, malé regulatorní změny nebo technická zlepšení.
Leadership chce vidět celou spotřebu kapacity
Programový backlog ukazuje strategické Features, ale část kapacity mizí v supportu, maintenance nebo technické práci. Container Feature může tuto práci zviditelnit.
Organizace chce rezervovat část kapacity
Například deset procent kapacity na technický dluh nebo bezpečnostní aktualizace. Container Feature pak funguje jako plánovací obálka.
Tým nemá jiný vstupní kanál
Do již schválené Container Feature lze často vložit novou Story snáze než vytvořit novou Feature, obhájit její hodnotu a dostat ji do programové prioritizace. Právě zde se z praktické pomůcky začíná stávat problém.
Kdy může Container Feature skutečně pomáhat
Odmítnout všechny Container Features jako antipattern by bylo příliš jednoduché. V některých situacích mohou být rozumným kompromisem.
Agreguje předvídatelnou drobnou práci
Představme si tým, který každý kvartál realizuje sadu malých regulatorních úprav. Jednotlivé změny jsou příliš malé pro samostatné Features, ale jejich realizace je povinná a dohromady spotřebují předvídatelnou část kapacity.
Container Feature „Drobné regulatorní změny – Q4“ může fungovat, pokud má:
- jasně omezené období,
- definovaný typ přípustné práce,
- kapacitní limit,
- vlastníka rozhodujícího o vstupu,
- a samostatné pořadí jednotlivých položek.
To, že jsou položky ve společném kontejneru, nesmí znamenat, že jsou všechny automaticky schválené.
Zviditelňuje provozní a údržbovou práci
Pokud programový reporting dlouhodobě ignoruje maintenance, bezpečnostní aktualizace nebo provozní změny, může Container Feature ukázat jejich skutečný dopad na kapacitu.
Je však dobré ověřit, zda by stejnou potřebu nevyřešil lépe jiný atribut: typ práce, komponenta, třída služby, label, samostatný swimlane nebo reportingové pole. Hierarchie není jediný způsob, jak práci agregovat.
Je dočasnou pomůckou během změny
Při migraci backlogu, slučování týmů nebo zavádění nového pracovního modelu může být dočasný kontejner praktičtější než okamžitá rozsáhlá změna nástroje.
Klíčové je slovo dočasný. Měl by mít vlastníka, důvod existence a konkrétní datum, kdy bude odstraněn nebo nahrazen vhodnějším řešením.
Kdy Container Feature zakrývá nefunkční backlog
Container Feature se stává nebezpečnou ve chvíli, kdy přestane pouze agregovat práci a začne nahrazovat rozhodnutí, která by organizace měla dělat jinde.
Nemá vlastní výsledek
Pokud dokončení Feature nic konkrétního nezmění pro zákazníka, stakeholdera, provoz nebo budoucí schopnost organizace, je těžké ji považovat za skutečnou Feature.
„Backend improvements“ není výsledek. „Zkrácení doby zpracování objednávky z pěti minut na méně než jednu minutu“ už výsledkem být může.
Jediným pojítkem je tým nebo komponenta
Feature nazvaná „Frontend Team Work“ pouze kopíruje organizační strukturu. To, že stejný tým realizuje několik Stories, ještě neznamená, že mají společný produktový smysl.
Příslušnost k týmu nebo komponentě je užitečná reportingová informace. Není to ale automaticky vhodný důvod pro vytvoření nadřazené backlogové položky.
Zůstává otevřená několik PI nebo kvartálů
Některé Container Features fungují jako předplacená popelnice. Pokaždé, když se blíží jejich dokončení, přibydou další Stories.
Taková položka nemá konečný rozsah ani smysluplnou podmínku dokončení. Její stav nevypovídá o výsledku, ale pouze o administrativním zvyku.
Každá Story má jinou prioritu
Jestliže jedna Story řeší kritickou zranitelnost, druhá kosmetickou úpravu uživatelského rozhraní a třetí požadavek jednoho lokálního trhu, nedává smysl prioritizovat Container Feature jako celek.
Společný rodič v tomto případě vytváří pouze iluzi jednoho rozhodnutí. Ve skutečnosti je potřeba udělat tři odlišná rozhodnutí.
Obchází prioritizaci
Jedním z největších rizik je možnost přidávat nové Stories pod již schválenou Feature bez opětovného posouzení hodnoty a kapacity.
Container Feature pak funguje jako otevřený rozpočet. Jakmile jednou projde plánováním, mohou se pod ní průběžně schovávat další požadavky. Výsledkem není flexibilita, ale nekontrolovaný přísun práce.
Vytváří falešnou transparentnost
Dashboard ukazuje, že je Feature dokončena ze sedmdesáti procent, protože sedm z deseti Stories je hotových. To ale nemusí říkat vůbec nic o dosaženém výsledku.
U skutečné Feature můžeme sledovat nejen dokončené položky, ale také to, zda vznikla použitelná funkcionalita nebo ověřitelný přínos. U náhodného kontejneru sledujeme pouze počet uzavřených ticketů.
Pět testů zdravé Container Feature
Nejdůležitější otázka není, zda používáte Container Features. Důležitější je, zda máte jasná pravidla, podle kterých poznáte jejich legitimní použití.
1. Test účelu
Dokážeme jednou větou vysvětlit, proč kontejner potřebujeme a proč nestačí label, komponenta, typ práce nebo jiné reportingové pole?
Jestliže jedinou odpovědí je „protože Jira vyžaduje parent Feature“, řešíme technické omezení nástroje. To může být legitimní, ale měli bychom to otevřeně přiznat a nehovořit o položce jako o skutečné produktové Feature.
2. Test hranice
Je předem jasné, co do Container Feature smí vstoupit a co už ne?
Například do kontejneru „Security updates – Q4“ mohou vstoupit aktualizace související s konkrétním seznamem zranitelností. Neměl by se do něj automaticky vejít libovolný technický dluh jen proto, že má také technický charakter.
3. Test času
Má Container Feature konkrétní časový horizont a okamžik uzavření?
Jedno PI, kvartál nebo definovaná migrační etapa může být rozumnou hranicí. „Budeme ji používat, dokud ji budeme potřebovat“ hranicí není.
4. Test kapacity
Existuje limit, kolik kapacity smí kontejner spotřebovat?
Bez limitu začne drobná práce postupně vytlačovat důležitější výsledky. Kapacitní limit však nesmí být automatickým nárokem. Vyhrazených deset procent neznamená, že je nutné za každou cenu deset procent spotřebovat.
5. Test integrity priorit
Musí každá nová Story projít skutečným rozhodnutím o prioritě, nebo se pod rodičem automaticky schová?
Pokud společný kontejner obchází triage, pořadí backlogu nebo rozhodnutí o kapacitě, je nebezpečný bez ohledu na to, jak dobře je pojmenovaný.
Pokud Container Feature nemá účel, hranici, časový horizont, kapacitní limit a pravidlo prioritizace, nejde o pomůcku. Jde o neřízený vstupní kanál do backlogu.
Konkrétní příklady z praxe
Drobné změny trhů – PI 3
Pod jednou Feature je dvacet pět požadavků z různých zemí: změna textace, nové pole ve formuláři, úprava notifikace, lokální validační pravidlo a export do dalšího systému.
Jednotlivé Stories nemají společný výsledek ani stejnou prioritu. Container Feature zde může dočasně pomoci s agregací, ale pouze pokud má kapacitní limit a každý požadavek prochází samostatnou prioritizací.
Pro dlouhodobé řešení bude pravděpodobně vhodnější zachytit původ požadavku pomocí pole „Market“ nebo „Request source“ a větší změny formulovat jako samostatné výsledkové Features.
Security updates – Q4
Předem známá sada aktualizací knihoven má odstranit konkrétní skupinu bezpečnostních zranitelností do konce kvartálu.
Tento kontejner může fungovat dobře. Má jasný typ práce, vlastníka, časovou hranici a ověřitelný provozní výsledek. Musí se ale zabránit tomu, aby se pod něj začal ukládat veškerý technický dluh.
Frontend improvements
Feature obsahuje Stories ze šesti různých zákaznických cest. Jediné, co mají společné, je realizace frontendovým týmem.
Zde kontejner zakrývá skutečnou strukturu hodnoty. Stories by měly být připojeny k výsledkovým Features podle změny, kterou pomáhají vytvořit. Frontendovou příslušnost lze evidovat pomocí komponenty nebo odpovědného týmu.
Maintenance – 10 % kapacity
Tým oprávněně potřebuje průběžně věnovat část kapacity údržbě. Container Feature tuto spotřebu zviditelní.
Problém nastane, když se deset procent kapacity začne chápat jako bianco šek. I maintenance položky potřebují pořadí, vstupní pravidla a rozhodnutí, co se nyní dělat nebude.
Co použít místo Container Feature
Ne každé seskupení práce potřebuje rodičovskou backlogovou položku. Vhodná alternativa závisí na účelu.
Skutečná Feature orientovaná na výsledek
Pokud část Stories skutečně přispívá ke společné změně, seskupte je podle výsledku. Ne podle technologie nebo týmu.
Například místo „Database changes“ může vzniknout Feature „Zkrácení vyhledání zákazníka pod dvě sekundy“. Databázové změny jsou způsob realizace, nikoliv samotný výsledek.
Samostatný typ práce
Pokud maintenance, provozní změny nebo regulatorní položky procházejí zásadně jiným rozhodovacím procesem, může dávat smysl samostatný typ práce.
Není cílem vytvořit deset nových issue typů. Jde o to přiznat, že některá práce má jinou povahu a neměla by být uměle vydávána za produktovou Feature.
Label, komponenta nebo reportingové pole
Potřebujete-li položky pouze filtrovat nebo agregovat podle trhu, komponenty, týmu či typu nákladů, použijte datový atribut. Reportingová klasifikace nemusí vytvářet novou úroveň backlogu.
Technický outcome nebo Enabler
Technická práce nemusí mít bezprostředně viditelný zákaznický výstup. To ale neznamená, že nemůže mít konkrétní výsledek.
- zkrácení nasazení z dvou hodin na patnáct minut,
- odstranění konkrétního bezpečnostního rizika,
- zvýšení dostupnosti služby,
- snížení nákladů na infrastrukturu,
- umožnění budoucí produktové změny.
Takto formulovaná technická Feature nebo Enabler je podstatně lépe řiditelná než obecný kontejner „Technical improvements“.
Typické chyby
- Každá Story musí mít Feature. Z nástrojové konvence se stane domnělé agilní pravidlo.
- Feature je chápána pouze jako větší položka. Velikost sama o sobě nevytváří společný výsledek.
- Společný tým se zamění za společnou hodnotu. Organizační struktura začne určovat strukturu backlogu.
- Container Feature zůstává otevřená několik období. Nová práce se do ní přidává rychleji, než se dokončuje.
- Business Value se přidělí celému kontejneru. Přitom každá Story může mít jinou hodnotu, naléhavost i riziko.
- Procento dokončených Stories se vydává za pokrok výsledku. Uzavřené tickety ještě neznamenají dosažený outcome.
- Kontejner obchází prioritizaci. Nová Story se považuje za schválenou jen proto, že se vešla pod existujícího rodiče.
- Do jednoho kontejneru se smíchá produktová, technická, provozní a regulatorní práce. Každý typ přitom může vyžadovat jiný způsob rozhodování.
- Dočasné řešení nemá datum ukončení. Po několika měsících už nikdo neví, proč bylo zavedeno.
- Organizace nejprve mění Jira a až potom diskutuje pravidla. Nová konfigurace pouze přesněji automatizuje původní nejasnosti.
Jak nastavit Container Feature, když ji opravdu potřebujete
Legitimní Container Feature by měla mít krátkou a viditelnou policy. Může být uvedena přímo v popisu položky nebo na společné stránce s pravidly backlogu.
- Účel: Proč kontejner existuje?
- Přípustný obsah: Jaké položky do něj mohou vstoupit?
- Zakázaný obsah: Co do něj naopak nepatří?
- Časový horizont: Kdy bude uzavřen?
- Kapacitní limit: Kolik práce smí spotřebovat?
- Vlastník: Kdo rozhoduje o přijetí nové položky?
- Prioritizace: Jak se řadí jednotlivé Stories?
- Podmínka uzavření: Co přesně znamená Done?
- Plán náhrady: Má být kontejner v budoucnu nahrazen lepším reportingovým řešením?
Tento přístup odpovídá obecnějšímu principu explicitních pravidel. Aktuální Kanban Guide zdůrazňuje potřebu jasně definovat workflow, řízení rozpracovanosti a pravidla, podle kterých mohou položky systémem proudit.
Container Feature tedy nemusí být popsána v konkrétním frameworku. Musí ale být transparentní a řiditelná.
Pojmenování by nemělo zakrývat realitu
Jestliže jde o technický nebo reportingový kontejner, pojmenujte jej tak.
Lepší názvy:
- [CONTAINER] Maintenance – Q4 2026
- [CONTAINER] Drobné regulatorní změny – PI 3
- [CONTAINER] Security updates – časově omezený balík
Rizikové názvy:
- Platform Improvements
- Customer Experience
- Technical Excellence
- Other Features
Obecný produktově znějící název může vytvářet dojem skutečného výsledku, i když jde pouze o administrativní obálku.
Jak začít v praxi
Není potřeba okamžitě překreslovat celou hierarchii backlogu nebo měnit konfiguraci Jira. Začněte krátkým auditem existujících Features.
Audit Container Features za 60 minut
- Vyberte všechny Features, které byly otevřené během posledních dvou PI nebo kvartálů.
- Označte položky obsahující názvy jako „improvements“, „technical“, „support“, „maintenance“, „other“, název týmu nebo časové období.
- U každé podezřelé Feature vyberte tři náhodné Stories.
- Zkuste jednou větou formulovat jejich společný výsledek.
- Ověřte, zda má položka alespoň jasný účel, hranici, limit a datum ukončení.
- Rozdělte ji do jedné ze tří kategorií: skutečná Feature, řízený kontejner, backlogový odpadkový koš.
- Vyberte jeden odpadkový koš a během nejbližšího refinementu jej opravte.
Rozdělte existující položky do tří skupin
- Skutečné Features: mají společný výsledek, hranici a lze je prioritizovat jako celek.
- Řízené kontejnery: mají legitimní agregační účel, limit, časový horizont a explicitní pravidla.
- Odpadkové koše: obsahují nesouvisející práci, nemají hranici a obcházejí prioritizaci.
Opravte nejprve jediný případ
Vyberte jednu Container Feature a:
- oddělte Stories, které tvoří skutečný společný výsledek,
- vytvořte pro ně výsledkovou Feature,
- ostatní položky seřaďte podle priority,
- pro reporting použijte vhodný atribut,
- a nastavte jedno jednoduché pravidlo pro vznik dalších kontejnerů.
Teprve na základě této zkušenosti rozhodujte, zda je potřeba měnit issue typy, workflow nebo programový reporting.
Po jednom období ověřte dopad
Sledujte například:
- počet dlouhodobě otevřených Features,
- stáří rozpracovaných položek,
- množství nově přidané práce během realizace,
- počet Stories bez jasného výsledku,
- objem práce přijaté mimo běžnou prioritizaci,
- podíl kapacity spotřebovaný jednotlivými kontejnery.
Metriky mají pomoci s rozhodováním, ne pouze vytvořit hezčí dashboard. Kanban Guide mezi základní flow metriky řadí například rozpracovanost, throughput, stáří položek a cycle time. Pro práci s Container Features bude často nejzajímavější jejich stáří a množství práce, která do nich přibývá po zahájení.
Problém často není v typu ticketu
Container Feature bývá viditelným příznakem hlubšího problému. Organizace například nemá jasno:
- jak se strategické priority překládají do backlogu,
- která rozhodnutí patří na programovou a která na týmovou úroveň,
- kdo může přijímat novou práci,
- jak se pracuje s neplánovanými požadavky,
- jaký typ práce má přednost při omezené kapacitě,
- nebo co vlastně znamená dokončení Feature.
V takové situaci nepomůže pouze přejmenovat Container Feature nebo přidat nové povinné pole. Je potřeba sladit prioritizaci, role, rozhodovací pravidla a samotnou strukturu backlogu.
Pokud se strategie a priority při překladu do práce týmů pravidelně ztrácejí, může být užitečné podívat se na přístup Strategy-to-Execution. Je zaměřený na propojení strategických cílů s prioritami, backlogy a pravidly, podle kterých se v organizaci skutečně rozhoduje.
Další praktické materiály, krátké kurzy a toolkity pro práci s flow, předvídatelností a řízením backlogu postupně přidáváme také do Agile Brothers Academy.
Shrnutí: problém není kontejner, ale rozhodnutí, která nahrazuje
Container Feature není automaticky chyba. Může být užitečnou pomůckou pro agregaci drobné, provozní nebo technické práce, zejména pokud současný nástroj nebo reporting neumí tuto práci zachytit jinak.
Musí však být zřejmé, že nejde o skutečnou výsledkovou Feature. Potřebuje jasný účel, hranici, časový horizont, kapacitní limit, vlastníka a pravidla prioritizace.
Jakmile kontejner zůstává otevřený několik období, přijímá nesouvisející Stories nebo umožňuje obcházet rozhodování o hodnotě a kapacitě, začíná zakrývat nefunkční backlog.
Backlog není funkční proto, že má každá Story rodiče. Je funkční tehdy, když je z něj patrné, proč práci děláme, jaký výsledek očekáváme, kdo rozhodl o její prioritě a kdy ji můžeme považovat za skutečně dokončenou.
Pokud ve svém backlogu nacházíte několik nekonečných kontejnerů a není jasné, který problém řešit jako první, můžeme se společně podívat na konkrétní Features a Stories. Často stačí krátký pohled zvenčí, aby bylo možné odlišit nástrojový kompromis od problému v prioritizaci nebo řízení práce.