Na první pohled vypadalo všechno správně. V Jira existoval Requirement, pod ním Feature a pod ní několik Stories. Položky byly propojené, měly přiřazené vlastníky a zobrazovaly se ve správných reportech.
Přesto tým během refinementu nedokázal odpovědět na několik základních otázek:
- Jaký problém zákazníka vlastně řešíme?
- Co už bylo schváleno a o čem se stále diskutuje?
- Je navržené řešení povinnou součástí požadavku, nebo pouze jednou z možností?
- Co přesně má tým dodat jako první použitelný výsledek?
- Podle čeho poznáme, že byla Feature úspěšně dokončena?
Když jsme otevřeli jednotlivé položky, ukázalo se, že Requirement, Feature i Stories obsahují z velké části stejný text. Informace se mezi úrovněmi především kopírovaly. Nevznikalo nové porozumění ani nové rozhodnutí.
Organizace měla správně nakreslenou hierarchii. Neměla však funkční systém, který by převáděl potřebu stakeholdera do konkrétního výsledku a následně do práce týmu.
Requirement, Feature a Story nemají být jen tři různé velikosti ticketu. Každá úroveň má sloužit jinému rozhodnutí.
Requirement, Feature a Story nejsou jen velká, střední a malá položka
Častá definice hierarchie zní přibližně takto:
- Requirement je velký požadavek.
- Feature je menší část požadavku.
- Story je malý úkol pro tým.
Takové vysvětlení je jednoduché, ale pro praktické řízení práce nestačí. Velikost totiž není hlavním rozdílem mezi jednotlivými úrovněmi.
Poměrně malý požadavek může být realizován jednou Story. Jiný Requirement může vést k několika Features pro více produktových oblastí. Některá Feature bude vyžadovat deset Stories, jiná dvě. A Story nemusí být malá proto, že stojí nejníže v Jira. Malá má být proto, aby ji tým dokázal v krátkém čase dokončit a ověřit.
Užitečnější je proto definovat jednotlivé úrovně podle otázky, kterou mají zodpovědět:
| Úroveň | Hlavní otázka | Typický výsledek |
|---|---|---|
| Requirement | Co potřebujeme změnit a proč? | Objasněná potřeba |
| Feature | Jaký ucelený výsledek se rozhodneme dodat? | Rozhodnutý rozsah dodávky |
| Story | Jaký malý a ověřitelný inkrement tým dokončí? | Implementovatelná položka týmového backlogu |
Nejde o univerzální definici, kterou musí každá firma převzít. Organizace může používat jiné názvy: Initiative, Epic, Capability, Feature, Enabler, Story nebo Product Backlog Item. Podstatné je, aby jednotlivé úrovně představovaly různé druhy rozhodnutí.
Podobný princip popisujeme také v článku Tři úrovně řízení práce bez frameworku: investice → doručení → inkrement. Jakmile se do jednoho backlogu promíchají investiční, doručovací a týmová rozhodnutí, leadership začne řešit příliš velký detail a týmy naopak ztrácejí potřebný kontext.
Requirement: co potřebujeme změnit a proč
Requirement má zachytit potřebu, nikoliv předem nadiktovat kompletní řešení.
Dobře objasněný Requirement by měl typicky vysvětlit:
- koho se potřeba týká,
- jaká je současná situace,
- co se má změnit,
- proč je změna důležitá,
- jaký výsledek stakeholder očekává,
- jaká omezení musíme respektovat,
- které otázky zatím zůstávají otevřené.
Představme si například požadavek:
Přidejte na hlavní stránku tlačítko „Změnit adresu“ a pošlete zadané údaje do systému X.
Formálně jde o požadavek. Ve skutečnosti však obsahuje již navržené uživatelské rozhraní, umístění prvku i technickou integraci. Není jasné, jaký problém má změna vyřešit.
Při rozhovoru se stakeholderem můžeme zjistit, že skutečná potřeba zní jinak:
Zákazníci musí při změně doručovací adresy volat na podporu. Chceme umožnit samoobslužnou změnu adresy a snížit počet souvisejících kontaktů zákaznického centra.
Tato formulace ponechává prostor pro hledání vhodného řešení. Současně vysvětluje očekávaný výsledek. Tlačítko i systém X mohou být součástí řešení, ale nejsou automaticky nedotknutelnou součástí původní potřeby.
Requirement nemusí vždy vytvořit Feature
Hierarchie by neměla fungovat jako povinná výrobní linka, kterou musí projít každý ticket.
Po objasnění Requirementu může nastat několik různých situací:
- požadavek nedává dostatečnou hodnotu a nebude realizován,
- je duplicitní a sloučí se s jiným požadavkem,
- vyřeší jej již existující Feature,
- jde o malou změnu, která může přejít přímo do Story,
- jde o větší výsledek, pro který vznikne jedna nebo více Features,
- nejprve potřebujeme discovery, technické posouzení nebo experiment.
Pokud je pravidlem, že každý Requirement musí automaticky vytvořit Feature a každá Feature musí obsahovat několik Stories, organizace si nevytváří transparentnost. Vytváří si povinné administrativní mezikroky.
Feature: jaký ucelený výsledek se rozhodneme dodat
Feature představuje rozhodnutí o dodávce. Potřeba už byla dostatečně pochopena a nyní určujeme, jaký konkrétní výsledek má produkt nebo řešení nabídnout.
V našem příkladu může Feature znít například takto:
Zákazník může v zákaznickém portálu bezpečně změnit doručovací adresu bez kontaktování podpory.
Takto formulovaná Feature popisuje ucelenou schopnost. Ještě nepředepisuje každý technický krok, ale vytváří dostatečně konkrétní rámec pro prioritizaci, rozdělení práce a ověření výsledku.
Feature by měla typicky objasnit:
- komu má výsledek pomoci,
- jaké chování nebo schopnost se změní,
- co je součástí rozsahu a co už ne,
- jakým způsobem výsledek ověříme,
- jaká rizika a závislosti známe,
- jak lze dodávku rozdělit do menších inkrementů.
Jako užitečnou inspiraci lze využít také pojetí Features ve Scaled Agile Frameworku. SAFe pracuje s Feature jako s položkou ART Backlogu, která přináší hodnotu a má být realizovatelná v rámci jednoho PI. Není nutné toto pravidlo mechanicky převzít, ale nutí nás uvažovat o Feature jako o výsledku s omezeným časovým horizontem, nikoliv jako o dlouhodobém kontejneru na libovolné množství práce.
Feature není obálka na nesouvisející Stories
V mnoha organizacích vznikají takzvané container Features. Nemají vlastní zákaznický ani business výsledek. Existují především proto, aby se týmové Stories zobrazily v programovém reportu nebo aby každá Story měla povinného rodiče.
Typické názvy mohou vypadat například takto:
- Frontend práce pro PI 3,
- Backend improvements,
- Technické změny týmu A,
- Implementace požadavků trhu,
- Ostatní změny zákaznického portálu.
Taková položka může být z technických nebo reportingových důvodů dočasně potřebná. Neměla by se ale zaměňovat za skutečnou Feature. Ze samotného názvu ani obsahu totiž nelze poznat, jaký výsledek se má změnit pro zákazníka nebo organizaci.
Story: jaký ověřitelný inkrement tým dokončí
Story je jednotka týmové spolupráce a dodávky. Má být dostatečně malá, aby ji tým dokázal v krátkém čase dokončit, a dostatečně smysluplná, aby šel její výsledek ověřit.
Feature se samoobslužnou změnou adresy můžeme rozdělit například na tyto Stories:
- zákazník vidí svou aktuální doručovací adresu,
- zákazník zadá a nechá ověřit novou adresu,
- zákazník změnu bezpečně potvrdí,
- zákazník obdrží potvrzení o provedené změně,
- pracovník podpory vidí auditní stopu změny.
Každá položka představuje pozorovatelnou část chování systému. Naproti tomu následující rozpad by byl výrazně problematičtější:
- Story pro analýzu,
- Story pro návrh databáze,
- Story pro frontend,
- Story pro backend,
- Story pro testování.
Takové položky mohou být užitečné jako úkoly uvnitř týmu, ale jednotlivě nepředstavují dokončený inkrement. Hodnota vznikne až ve chvíli, kdy jsou hotové všechny. Rozpracovanost roste a každá specializace optimalizuje svou část, zatímco skutečný výsledek stále čeká.
Scrum mimochodem nepředepisuje povinnou hierarchii Requirement–Feature–Story. Scrum Guide pracuje obecně s položkami Product Backlogu a jejich průběžným zpřesňováním. User Story je užitečná technika, nikoliv povinný objekt Scrumu.
Stejně tak by Story neměla být považována za připravenou jen proto, že má vyplněná povinná pole nebo přidělený odhad. Jak ukazujeme v článku Když odhad není skutečný odhad, číslo může vzniknout i bez skutečného týmového porozumění. Odhad pak pouze zakrývá neodhalené otázky, závislosti a rizika.
Proč správná hierarchie v Jira problém nevyřeší
Jira umí uložit typy položek, jejich pole, workflow a vzájemné vazby. Umožňuje také konfigurovat hierarchii nad standardními work items. Technická konfigurace ale sama neurčí, jaká rozhodnutí mají lidé na jednotlivých úrovních dělat. Přehled základních možností nabízí dokumentace Atlassianu k typům práce v Jira.
Pokud organizace nemá dohodnutý obsah a smysl jednotlivých úrovní, Jira pouze přesně zaznamená nejasnost, která existuje mimo ni.
Chybí pravidla pro přechod mezi úrovněmi
Nejdůležitější není jen obsah jednotlivých ticketů. Důležité je, co se má stát při přechodu z jedné úrovně na druhou.
Přechod z Requirementu do Feature by měl znamenat například to, že:
- potřeba byla objasněna se stakeholdery,
- rozumíme očekávanému výsledku,
- bylo rozhodnuto, že má smysl hledat nebo připravit řešení,
- vznikl první smysluplný rozsah dodávky,
- někdo převzal odpovědnost za další refinement.
Přechod z Feature do Stories by měl přidat další rozhodnutí:
- jak výsledek rozdělíme na menší inkrementy,
- který inkrement potřebujeme jako první,
- co dokáže realizovat jeden tým,
- jak budeme výsledek ověřovat,
- které nejistoty musíme odstranit před zahájením práce.
Pokud přechod pouze vytvoří nový ticket a zkopíruje do něj popis rodiče, žádný skutečný refinement se neodehrál.
Chybí cadence a rozhodovací fórum
Workflow se stavy Open, In Specification, Ready nebo Implementation nevytvoří samo o sobě tok práce. Musí být jasné, kdo a kdy má s jednotlivými položkami pracovat.
Každá úroveň obvykle potřebuje jinou cadence:
- intake a clarification pro nové Requirements,
- produktovou nebo programovou prioritizaci pro Features,
- průběžný refinement pro rozdělení Features,
- týmový refinement a pull do realizace pro Stories.
Užitečnou inspiraci nabízí Open Guide to Kanban, který zdůrazňuje potřebu definovat workflow, aktivně řídit položky a vytvářet explicitní pravidla jejich toku. Nejde přitom o to, zda tým používá Scrum, Kanban nebo škálovaný framework. Bez explicitních pravidel se tok práce spoléhá především na individuální interpretaci.
Chybí přímá komunikace mezi lidmi
Dalším problémem bývá řetězec předávání informací:
- Stakeholder vysvětlí potřebu business analytikovi.
- Analytik ji zapíše do Requirementu.
- Product Owner z Requirementu připraví Feature.
- Feature se rozpadne na Stories.
- Vývojář dostane Story, ale k původnímu stakeholderovi se už nedostane.
Business analytik i Product Owner mohou v tomto procesu odvést výbornou práci. Přesto při každém předání část kontextu zmizí a část interpretace se přidá. Hierarchie pak začne fungovat jako telefonní hra.
Dobře nastavený proces neobchází analytiky ani produktové role. Umožňuje ale přímé dovysvětlení tam, kde je potřeba produktový, technický nebo doménový detail. Ticket nenahrazuje rozhovor. Má pomoci zachovat jeho výsledek.
Pozor na rozpad podle komponent a organizačních sil
Hierarchie práce často začne nevědomky kopírovat organizační nebo technickou strukturu firmy.
Jeden zákaznický výsledek se rozdělí například na:
- frontendovou Feature,
- backendovou Feature,
- integrační Feature,
- testovací Feature.
Každá položka má vlastní tým, vlastní plán a vlastní status. Žádná z nich ale samostatně nepřináší použitelný výsledek. Všechny musí být dokončeny, aby mohl zákazník změnit svou adresu.
Lepší je hledat vertikální inkrementy, například:
- zákazník může změnit adresu u jednoduchého typu objednávky,
- změnu lze použít také u rozpracované objednávky,
- systém zvládne regulované nebo jinak omezené případy,
- podpora má k dispozici audit a možnost asistovaného řešení.
Technické komponenty samozřejmě nezmizí. Týmy na nich stále musí spolupracovat. Rozpad backlogu ale zůstává orientovaný na postupně použitelné výsledky, nikoliv na vytížení jednotlivých specializací.
Pět testů funkční hierarchie
1. Každá úroveň má vlastní účel
Lidé dokážou jednou větou vysvětlit, proč existuje Requirement, proč Feature a proč Story. Odpověď není jen „protože je to povinné v Jira“.
2. Přechod přidává nové rozhodnutí
Text se pouze nekopíruje. Přechodem mezi úrovněmi vzniká nové porozumění, rozhodnutí o investici, rozsahu, prioritě nebo způsobu dodání.
3. Ne každá změna musí projít celou hierarchií
Malá a dobře pochopená změna může přejít přímo z požadavku do týmového backlogu. Nejasná změna může nejprve potřebovat experiment. Hierarchie podporuje rozhodování, nikoliv povinné zakládání ticketů.
4. Položky představují dokončitelné výsledky
Feature se nezavírá jen proto, že skončilo PI nebo byly uzavřeny všechny technické úkoly. Story není hotová, pokud chybí testování nebo integrace potřebná pro její ověření.
5. Vazby pomáhají odpovídat na důležité otázky
Z hierarchie dokážeme zjistit:
- proč konkrétní Story realizujeme,
- který požadavek řeší,
- jaký výsledek už byl skutečně dodán,
- které Requirements stále čekají na rozhodnutí,
- které Features jsou příliš velké nebo dlouho rozpracované.
Typické chyby
- Stejný obsah na všech úrovních. Requirement, Feature i Story obsahují zkopírovaný text, ale nepřidávají nové rozhodnutí.
- Definice založená pouze na velikosti. Lidé rozlišují položky podle Story Points nebo odhadované délky, nikoliv podle jejich účelu.
- Povinný průchod celou hierarchií. I drobná změna potřebuje Requirement, Feature a několik Stories.
- Requirement jako hotové řešení. Stakeholder předepíše obrazovku, komponentu i technickou integraci ještě před společným pochopením problému.
- Feature jako reportingový kontejner. Položka nepopisuje výsledek, pouze sdružuje práci týmu nebo období.
- Rozpad podle komponent. Frontend, backend a testování mají vlastní položky, ale použitelný výsledek vznikne až po dokončení všech.
- Stories vznikají příliš pozdě. Velká Feature se začne dělit až těsně před plánováním, kdy už není čas odhalit závislosti a nejistoty.
- Povinná pole se zaměňují za připravenost. Ticket je označen jako Ready, protože obsahuje odhad, acceptance criteria a vlastníka, přesto mu tým nerozumí.
- Analytik funguje jako jediný komunikační most. Vývojáři nemají možnost dovyjasnit odborný nebo technický detail přímo se stakeholderem.
- Hierarchie kopíruje organizační strukturu. Každý tým, systém nebo dodavatel potřebuje vlastní Feature bez ohledu na zákaznický výsledek.
- Rodič se zavírá podle statusu potomků. Nikdo neověřuje, zda bylo skutečně dosaženo očekávaného výsledku.
- Jeden model se vnucuje všem typům práce. Stejnou hierarchií musí procházet produktová změna, produkční chyba, technický dluh i drobný regulatorní požadavek.
Příliš velké nebo nejasné Stories se následně promítají také do plánování. Tým sice práci přijme, ale během realizace objevuje další rozsah, technické komplikace nebo chybějící rozhodnutí. Výsledkem bývá spillover a přeplněný sprint. Více se této souvislosti věnujeme v článku Sprint overcommitment: proč tým nestíhá plán, i když pracuje naplno.
Jak začít v praxi
Nedoporučuji začínat vytvořením nové směrnice ani překreslením celého Jira workflow. Začněte nad skutečnou prací.
1. Vyberte pět konkrétních dodávek
Ideální je vzít:
- jednu malou změnu,
- jednu větší dodávku,
- jeden nejasný požadavek,
- jeden požadavek zasahující více týmů,
- jeden případ, který se výrazně zpozdil nebo nedopadl podle očekávání.
2. Zrekonstruujte skutečný tok rozhodnutí
U každého případu si položte otázky:
- Kdy a od koho přišla původní potřeba?
- Kdo objasnil, co se má změnit?
- Kdo rozhodl, jaký výsledek se skutečně dodá?
- Kdy byl zapojen vývojový tým?
- Kdy se objevily technické a produktové nejistoty?
- Kde se čekalo na rozhodnutí nebo informace?
- Který ticket v Jira představoval které rozhodnutí?
Velmi často zjistíte, že největší prodleva nevznikla při programování. Vznikla mezi přijetím požadavku, rozhodnutím o jeho prioritě a okamžikem, kdy se jím tým začal skutečně zabývat.
3. Popište účel každé úrovně jednou větou
Například:
- Requirement popisuje objasněnou potřebu, o jejímž dalším zpracování máme rozhodnout.
- Feature popisuje prioritizovaný a ucelený výsledek určený k dodání.
- Story popisuje ověřitelný inkrement, který může dokončit jeden tým.
Pokud nedokážete rozdíl vysvětlit bez slov „větší“ a „menší“, je účel jednotlivých úrovní pravděpodobně stále nejasný.
4. Vytvořte jednoduchou policy card
Pro každou úroveň si na jednu stránku napište:
- účel položky,
- kdo ji může vytvořit,
- kdo ji vlastní,
- jaké minimum informací potřebuje,
- kdo rozhoduje o prioritě,
- jaké podmínky platí pro další posun,
- jak se položka rozděluje,
- podle čeho se považuje za dokončenou.
Není nutné okamžitě měnit Jira. Nejprve ověřte, že pravidlům lidé rozumějí a dokážou je používat na skutečných příkladech.
5. Otestujte jedno pravidlo po dobu čtyř týdnů
Prvním experimentem může být například následující dohoda:
Každá nová Feature musí popsat očekávanou změnu pro uživatele nebo business, hranici rozsahu a způsob ověření. Feature nesmí vzniknout pouze jako obálka na Stories.
Po čtyřech týdnech vyhodnoťte:
- zda týmy dostávají více potřebného kontextu,
- zda se Features daří rozdělovat dříve,
- zda ubylo kopírování textu,
- zda se rychleji odhalují závislosti,
- zda je jasnější, kdo má učinit další rozhodnutí.
Teprve potom má smysl upravovat workflow, povinná pole nebo automatizace.
Kdy už problém není jen v backlogu
Někdy se při práci s hierarchií ukáže, že skutečný problém leží výše:
- stakeholdeři nedokážou rozhodovat o prioritách,
- týmy dostávají příliš mnoho paralelních požadavků,
- není jasné, kdo vlastní produktový výsledek,
- programová úroveň pouze sbírá statusy, ale neřídí tok práce,
- strategie se nepřekládá do konkrétních rozhodnutí o kapacitě,
- každý tým používá jiný význam stejných pojmů.
V takové situaci další úprava Jira obvykle nestačí. Je potřeba podívat se na širší způsob řízení práce, rozhodovací pravomoci a propojení mezi businessem a delivery.
Pokud si nejste jistí, kde přesně se práce zadrhává, může pomoci krátké zmapování reality v rámci Agile Reality Checku. Pro organizace, které potřebují propojit strategické priority s programovými a týmovými backlogy, je bližší služba Strategy-to-Execution. Při nastavování spolupráce více týmů a společného programového backlogu může být relevantní také ART / Tribe Launch & PI Planning.
Nejde přitom o zavedení dalších typů ticketů. Cílem je nastavit minimální funkční model, ve kterém lidé vědí, jaké rozhodnutí mají udělat, jaké informace k němu potřebují a jak se výsledek překládá do práce týmů.
Závěr: nejdřív model rozhodování, potom konfigurace Jira
Requirement, Feature a Story mohou vytvořit užitečný most mezi stakeholdery, produktovým řízením a vývojovými týmy. Samotné propojení ticketů však tento most nevytvoří.
Funkční hierarchie potřebuje:
- jasný účel každé úrovně,
- rozdílné otázky a rozhodnutí,
- vlastníky a rozhodovací pravomoci,
- pravidla přechodu mezi úrovněmi,
- pravidelný refinement a prioritizaci,
- přímou komunikaci mezi lidmi,
- možnost zjednodušit cestu pro malou nebo specifickou práci.
Jira má tento model podporovat a zviditelňovat. Nemůže ho za organizaci vymyslet.
Než do Jira přidáte další úroveň, zkuste nejprve popsat, jaké nové rozhodnutí má tato úroveň umožnit. Pokud žádné nenajdete, pravděpodobně nepotřebujete další typ ticketu.
Chcete si pravidla jednotlivých úrovní navrhnout sami?
V Agile Brothers Academy postupně zveřejňujeme praktické šablony, toolkity a taháky pro práci s backlogem, tokem práce a týmovým zlepšováním. Mohou vám pomoci připravit první návrh pravidel bez zavádění další složité metodiky.
Pokud je problém širší a různé části organizace si pod stejnými pojmy představují něco jiného, můžeme se společně podívat na několik skutečných Requirements, Features a Stories a najít místo, kde se tok rozhodnutí rozpadá. Někdy stačí několik jasných pravidel. Jindy se ukáže, že je potřeba upravit způsob prioritizace nebo spolupráce mezi týmy.