Na začátku čtvrtletí vedení představilo nové OKR. Jedním z hlavních cílů bylo výrazně zjednodušit zákaznický onboarding. V prezentaci zazněla čísla, očekávané business výsledky i naléhavost celé změny.
O několik dní později jsme se podívali do backlogů týmů. V jednom se řešil redesign administrace, ve druhém technický upgrade, ve třetím požadavky lokálních trhů a ve čtvrtém několik měsíců staré stakeholder requesty. Každý tým měl práci na několik sprintů dopředu. Téměř nikdo ale nedokázal vysvětlit, která část backlogu má očekávaný onboarding skutečně zlepšit.
Nešlo o nezkušené týmy ani o špatně napsaná OKR. Firma měla strategii, roadmapy, portfolio iniciativ, Product Ownery i správně nakonfigurovanou Jira. Přesto mezi strategickým cílem a každodenním rozhodováním o práci chybělo spojení.
Strategie se ve firmách často neztrácí při její formulaci. Ztrácí se ve chvíli, kdy má změnit pořadí práce, alokaci kapacity a konkrétní rozhodnutí o backlogu.
OKR a backlog tak začnou fungovat jako dva paralelní světy. Leadership sleduje cíle a Key Results. Delivery organizace sleduje Features, Stories, milníky, sprinty a termíny. Oba systémy mohou vypadat profesionálně, ale navzájem se ovlivňují jen velmi málo.
OKR nejsou plán práce
První problém vzniká už při samotném překladu strategického cíle. OKR mají popsat, jaké změny chceme dosáhnout a podle čeho poznáme, že nastala. Nemají automaticky určovat kompletní seznam práce ani předem potvrdit konkrétní řešení.
Představme si následující příklad:
- Objective: Noví zákazníci dokážou začít naši službu používat snadno a bez zbytečné pomoci podpory.
- Key Result: Zvýšit podíl zákazníků, kteří úspěšně dokončí onboarding, z 55 % na 75 %.
- Key Result: Snížit počet kontaktů podpory souvisejících s onboardingem o 30 %.
Takto formulované OKR ještě neříká, že potřebujeme nový onboardingový systém, kompletní redesign aplikace nebo chatbota. Popisuje změnu, které chceme dosáhnout.
Konkrétní iniciativa – například redesign onboardingu – je teprve hypotézou, jak daného výsledku dosáhnout. Backlog následně obsahuje výzkum, experimenty, produktové změny, technické úpravy a další práci, prostřednictvím které hypotézu ověřujeme a realizujeme.
Cíl, iniciativa a backlog nejsou totéž
Užitečné je rozlišit čtyři různé otázky:
| Úroveň | Hlavní otázka |
|---|---|
| Strategický cíl / Objective | Jakou změnu chceme ve firmě, u zákazníka nebo na trhu dosáhnout? |
| Key Result | Podle čeho poznáme, že změna skutečně nastává? |
| Iniciativa | Do čeho jsme připraveni investovat, protože věříme, že to výsledek ovlivní? |
| Backlog | Jakou práci, experimenty a inkrementy nyní považujeme za nejlepší další krok? |
Jakmile se tyto úrovně smíchají, vznikají například Key Results typu „nasadit nový portál“ nebo „dokončit migraci systému“. To ale nejsou výsledky. Jsou to výstupy, u kterých teprve potřebujeme zjistit, zda něco důležitého změnily.
Podrobněji rozdíl mezi cílovými a provozními metrikami popisujeme také v článku OKR a KPI: jak je používat společně, aby metriky podporovaly byznys, ne škodily.
Kde se strategie cestou k backlogu ztrácí
Mezera mezi OKR a backlogem obvykle nevzniká na jednom místě. Strategie se postupně oslabuje při několika překladech – mezi vedením, portfoliem, produktovým řízením a delivery týmy.
1. Nové cíle nepřinesou žádné rozhodnutí o kapacitě
Leadership stanoví nové priority, ale organizace současně pokračuje ve všech dříve zahájených iniciativách. Strategický cíl se tak nepřekládá do změny investic. Pouze přidává další práci k tomu, co už běží.
Typický výsledek vypadá takto:
- nová strategická iniciativa je označena jako nejvyšší priorita,
- starší projekty však stále mají slíbené termíny,
- každá business oblast očekává pokračování svých požadavků,
- týmy rozdělí kapacitu mezi všechny směry,
- nikde nevznikne dostatečný fokus na dosažení jednoho výsledku.
Strategie se neprojevuje tím, že přidáme nový sloupec do roadmapy. Projevuje se tím, že některá práce dostane více kapacity a jiná ji naopak ztratí.
2. Strategický cíl se okamžitě změní na velký projekt
Jakmile se objeví problém nebo příležitost, organizace často velmi rychle schválí konkrétní řešení. Cíl „snížit náklady zákaznické podpory“ se například automaticky přeloží jako „implementovat chatbota“.
Tím se ale uzavře prostor pro důležité otázky:
- Proč zákazníci podporu kontaktují?
- Které typy dotazů tvoří největší objem nebo náklad?
- Nevznikají kontakty kvůli chybě nebo složitosti samotného produktu?
- Pomůže chatbot problém vyřešit, nebo pouze vytvoří další komunikační kanál?
- Existuje jednodušší změna s rychlejším dopadem?
Iniciativa se tím mění z hypotézy na závazek dodat předem vybrané řešení. Týmy už nehledají nejlepší cestu k výsledku. Hledají způsob, jak dodat schválený scope.
3. Portfolio funguje jako sběrné místo požadavků
Mnoho portfolio backlogů není skutečně prioritizovaných. Jsou pouze seřazené. Obsahují desítky iniciativ s různými vlastníky, business cases a očekávanými termíny. Prakticky všechny jsou označené jako důležité.
Pořadí v nástroji však nepomůže, pokud se současně rozpracuje prvních dvacet položek. Stejně jako na úrovni týmu potřebuje i portfolio kontrolovat rozpracovanost a aktivně řídit tok iniciativ.
Open Guide to Kanban popisuje Kanban jako strategii optimalizace toku hodnoty prostřednictvím definování a vizualizace workflow, aktivního řízení položek a průběžného zlepšování flow. Tyto principy nejsou omezené na týmovou tabuli. Lze je použít i pro strategické iniciativy, které procházejí od prvního nápadu přes rozhodnutí o investici až po ověření výsledku.
4. Roadmapa slibuje výstupy, ne výsledky
Roadmapa často obsahuje konkrétní projekty, Features a data dodání. Neříká však, jaký problém jednotlivé položky řeší ani podle čeho poznáme jejich úspěch.
Například položka „Nový klientský portál – Q3“ může být velmi významnou investicí. Sama o sobě však neříká:
- které zákaznické chování chceme změnit,
- jaký business výsledek očekáváme,
- které předpoklady jsou nejrizikovější,
- co potřebujeme dodat jako první,
- za jakých okolností bychom iniciativu změnili nebo zastavili.
Roadmapa se pak stává kalendářem slíbených výstupů, nikoliv nástrojem pro komunikaci strategických voleb.
5. Mezi strategií a backlogem chybí použitelný cíl
Tým může znát celofiremní Objective, ale ten bývá pro každodenní prioritizaci příliš vzdálený. „Posílit vedoucí postavení na trhu“ neposkytuje dostatečný kontext pro rozhodnutí, zda má být v příštím sprintu dříve dokončena samoobslužná změna adresy, nový reporting nebo technická migrace.
Mezi strategií a konkrétními položkami proto obvykle potřebujeme produktový, programový nebo jinak ohraničený cíl. Ten má popsat dosažitelnou změnu, ke které může daný produkt, ART, tribe nebo skupina týmů reálně přispět.
Scrum Guide používá Product Goal jako dlouhodobější cíl produktu a závazek spojený s Product Backlogem. Zbytek backlogu vzniká tak, aby definoval, co pomůže Product Goal naplnit. Tento princip je užitečný i mimo Scrum: backlog potřebuje směr, který je konkrétnější než obecná strategie, ale stále ponechává flexibilitu v řešení.
6. Backlog postupně ovládnou lokální priority
I dobře vytvořený backlog časem přitahuje nové požadavky. Přicházejí produkční problémy, regulatorní změny, technický dluh, lokální požadavky, drobná zlepšení i témata důležitých stakeholderů.
Každá položka může mít rozumné vysvětlení. Problém vzniká ve chvíli, kdy se jejich přidávání neposuzuje vůči společnému cíli a dostupné kapacitě.
Product Owner pak formálně odpovídá za prioritu backlogu, ale ve skutečnosti pouze hledá místo pro všechny očekávané požadavky. Pořadí se řídí naléhavostí, politickou silou, historickými sliby nebo tím, která práce je právě připravená.
Takový backlog může být velmi dobře udržovaný, rozdělený a odhadnutý. Přesto nemusí být strategický.
7. Reporting sleduje dokončený scope, ne změnu výsledku
Poslední ztráta nastává při vyhodnocování. Iniciativa je označena jako zelená, protože bylo dokončeno 80 % rozsahu, milníky jsou splněné a většina Features je uzavřená.
Nikdo ale zatím neví, zda se změnilo chování zákazníků, snížily náklady, zvýšila konverze nebo vznikla očekávaná schopnost organizace.
Dokončený scope je užitečná informace o průběhu dodávky. Není to však důkaz dosaženého výsledku. Více o propojení delivery metrik s reálným dopadem popisujeme v článku Metriky byznys výsledků: jak propojit metriky výkonnosti dodávky s dopadem na zákazníka.
Jak může vypadat funkční cesta od strategie k backlogu
Neexistuje jedna povinná hierarchie, která bude fungovat v každé firmě. Někde organizace používá strategická témata, jinde OKR, iniciativy, epiky, Product Goals, programové cíle nebo Features.
Podstatnější než názvy jednotlivých úrovní je, aby cesta obsahovala rozdílné druhy rozhodnutí:
Strategie → měřitelný výsledek → investiční volba → iniciativa → produktový nebo programový cíl → backlog možností → inkrementy a experimenty → ověřený dopad
Tato cesta nemá fungovat pouze jedním směrem shora dolů. Výsledky experimentů, reakce zákazníků, technické poznatky a změny trhu se musí vracet zpět a ovlivňovat iniciativu, alokaci kapacity i samotný strategický předpoklad.
Mezi OKR a backlog patří investiční hypotéza
Každá významnější iniciativa by měla jednoduše vysvětlit:
- jaký výsledek chceme změnit,
- pro koho má změna hodnotu,
- proč věříme, že právě tato iniciativa pomůže,
- které předpoklady jsou nejisté,
- kolik kapacity jsme připraveni investovat,
- jaký první důkaz očekáváme a kdy jej vyhodnotíme.
Jednoduchá formulace může vypadat například takto:
Věříme, že zjednodušením prvních tří kroků registrace pro nové zákazníky zvýšíme dokončení onboardingu z 55 % alespoň na 65 %. První výsledek ověříme na omezené skupině uživatelů během šesti týdnů.
Taková hypotéza dává týmu směr, ale nepředepisuje kompletní řešení. Současně umožňuje po šesti týdnech rozhodnout, zda investici rozšířit, upravit, nebo zastavit.
Podobný přístup lze najít také ve Scaled Agile Frameworku při práci s většími iniciativami. Epiky zde mají popisovat očekávané outcomes a business přínosy, procházet portfolio Kanbanem a být schváleny nebo zamítnuty jako investice. Není nutné přebírat celý framework, ale princip aktivního rozhodování o velkých sázkách je velmi užitečný.
Backlog nemá kopírovat strategii, ale reagovat na ni
Častou reakcí na chybějící strategickou vazbu je požadavek, aby každá Story měla povinně přiřazené OKR. Výsledkem bývá další pole v Jira a rychle rostoucí administrativa.
Vazba na strategii nemusí být stejně podrobná na každé úrovni. Nejsilnější má být zejména u:
- strategických iniciativ,
- produktových nebo programových cílů,
- větších backlogových položek,
- rozhodnutí o alokaci kapacity.
U jednotlivé Story má být především srozumitelný její produktový kontext a vazba na větší výsledek. Nemusí nést kompletní řetězec strategických objektů.
Správná technická hierarchie sama o sobě vazbu na strategii nevytvoří. Této problematice se podrobněji věnujeme v článku Requirement, Feature, Story: proč nestačí mít hierarchii v Jira.
Jednoduchý test: řídí vaše OKR skutečně backlog?
Zkuste si nad jedním důležitým OKR odpovědět na následujících šest otázek:
- Dokážou týmy vysvětlit, který strategický výsledek jejich hlavní práce podporuje?
- Je u každé velké iniciativy popsán očekávaný outcome, nikoliv pouze scope?
- Změnila nová OKR pořadí práce nebo reálnou alokaci kapacity?
- Existuje práce, kterou jsme kvůli nové strategii odložili nebo zastavili?
- Sledujeme vedle průběhu dodávky také změnu Key Results nebo jiného očekávaného výsledku?
- Mohou týmy změnit řešení nebo scope, pokud najdou lepší cestu k výsledku?
Pokud většina odpovědí zní „ne“, problém pravděpodobně není v kvalitě samotných OKR. Organizace má spíše oddělený systém strategického reportingu a oddělený systém řízení delivery.
Co měřit místo procent dokončeného scope
Pro řízení cesty od strategie k backlogu potřebujeme kombinovat alespoň tři typy informací.
1. Strategický dopad
Sledujeme, zda se mění skutečný výsledek:
- konverze, retence nebo adopce,
- náklady a výnosy,
- chování zákazníků,
- snížení rizika,
- změna příslušného Key Result.
2. Validace iniciativy
Sledujeme, zda naše investiční hypotéza dává smysl:
- které předpoklady jsme ověřili nebo vyvrátili,
- jak zákazníci nové řešení skutečně používají,
- jak rychle jsme získali první důkaz,
- zda má smysl iniciativu rozšířit.
3. Schopnost systému reagovat
Sledujeme, zda organizace dokáže strategická rozhodnutí převést do pohybu práce:
- počet současně rozpracovaných iniciativ,
- doba od prvního návrhu k rozhodnutí o investici,
- doba od schválení iniciativy k prvnímu ověřitelnému výsledku,
- portfolio throughput,
- podíl kapacity investovaný do hlavních strategických priorit.
Metriky přitom nemají sloužit jako prostředek hodnocení jednotlivých týmů nebo obhajoby předem přijatých rozhodnutí. Mají pomáhat rychleji zjistit, zda se pohybujeme správným směrem. Rizikům nevhodného používání měření se věnujeme také v článku Proč se agilní týmy bojí metrik.
Typické chyby
- Kaskádování OKR až na každého člověka a každou Story. Vzniká velké množství formálních vazeb, ale lidé přestávají rozlišovat skutečný cíl od administrativního přiřazení.
- Key Results popisují milníky a výstupy. Organizace měří, zda byl systém spuštěn, nikoliv zda něco důležitého změnil.
- Každý strategický cíl automaticky vytvoří projekt. Řešení se schválí dříve, než se ověří problém a hlavní předpoklady.
- Nové priority se přidávají bez zastavení staré práce. Strategie rozšiřuje portfolio, místo aby soustředila investice.
- Portfolio backlog nemá limit rozpracovanosti. Všechny iniciativy postupují pomalu a soupeří o stejné lidi.
- Roadmapa je chápána jako pevný kontrakt na scope. Týmy nemohou změnit řešení ani tehdy, když získají nové poznatky.
- Product Owner odpovídá za prioritu, ale nemůže nic odmítnout. Backlog se stává evidencí očekávání stakeholderů.
- Hierarchie v Jira je považována za strategický alignment. Propojené tickety ukazují strukturu, nikoliv kvalitu rozhodnutí.
- Úspěch iniciativy se hodnotí podle procenta dokončeného scope. Delivery může být úspěšné, i když se očekávaný outcome nedostavil.
- OKR se kontrolují pouze na konci čtvrtletí. Výsledky se reportují příliš pozdě na to, aby mohly ovlivnit další investice a backlog.
- Každá iniciativa má svého sponzora, ale nikdo nemá mandát ji zastavit. Portfolio se postupně plní rozpracovanou prací bez jasného ukončení.
Společným znakem těchto chyb je snaha vytvořit strategickou vazbu prostřednictvím dokumentace, hierarchie a reportingu. Tyto věci mohou pomoci, ale nenahradí skutečná rozhodnutí o investicích, kapacitě a ukončování práce.
Jak začít v praxi
Není nutné hned překreslovat celou organizační strukturu, zavádět nový portfolio nástroj nebo měnit všechny backlogy. Začněte s jedním důležitým strategickým cílem a skutečnou prací, která už ve firmě běží.
1. Vyberte jedno důležité OKR
Vyberte cíl, který má být pro následující období skutečnou prioritou. Ne ten, který se nejsnáze popisuje, ale ten, u kterého má organizace skutečně změnit své chování a investice.
2. Zmapujte reálnou práci a kapacitu
Ke zvolenému cíli přiřaďte:
- běžící iniciativy,
- produkty nebo oblasti, kterých se týká,
- větší backlogové položky,
- zapojené týmy,
- přibližnou část jejich kapacity.
Cílem není vytvořit dokonalý diagram. Potřebujete pravdivě vidět, zda za deklarovanou prioritou stojí také reálná investice.
Při mapování je užitečné oddělit různé úrovně rozhodování. Praktickou inspiraci najdete v článku Tři úrovně řízení práce bez frameworku: investice → doručení → inkrement.
3. Najděte čtyři typy nesouladu
V mapě označte:
- práci bez jasné vazby na aktuální priority,
- prioritu, za kterou není přidělena dostatečná kapacita,
- více nekoordinovaných iniciativ sledujících stejný výsledek,
- iniciativy bez měřitelného očekávaného dopadu.
Už toto jednoduché cvičení často ukáže, že problém není v tom, že by lidé strategii neznali. Organizace ji pouze nikdy nepřeložila do společných rozhodnutí.
4. Formulujte investiční hypotézu
Pro každou důležitou iniciativu zkuste doplnit jednu větu:
Věříme, že investicí do [změny nebo schopnosti] pro [cílovou skupinu] ovlivníme [měřený výsledek]. První důkaz očekáváme do [časový horizont].
Pokud tuto větu nelze rozumně doplnit, iniciativa pravděpodobně potřebuje více objasnění, nikoliv rychlejší rozpad na Stories.
5. Udělejte skutečný prioritizační řez
Rozdělte iniciativy do čtyř skupin:
- pokračovat,
- nejprve ověřit,
- pozastavit,
- ukončit.
Nepoužívejte pátou skupinu „budeme pokračovat, jakmile bude kapacita“, pokud ve skutečnosti nikdo neočekává, že kapacita vznikne.
6. Nastavte pravidelnou rozhodovací cadence
Jednou měsíčně nebo v jiném rozumném rytmu vyhodnoťte:
- změnu strategických výsledků,
- nové důkazy a poznatky,
- stav hlavních nejistot,
- množství rozpracovaných iniciativ,
- potřebu změnit investici nebo prioritu.
Takové setkání nemá být status meetingem. Jeho výstupem mají být rozhodnutí: pokračovat, změnit směr, investovat více, omezit scope nebo práci zastavit.
7. Dejte týmům prostor upravit cestu
Leadership má držet strategický směr, očekávané výsledky, investiční hranice a priority. Produktové a delivery týmy potřebují prostor upravovat konkrétní řešení, pořadí experimentů a obsah backlogu podle toho, co se průběžně učí.
Bez tohoto prostoru se OKR mění jen na další formu řízení scope shora. Strategie sice doputuje až do backlogu, ale ztratí schopnost reagovat na realitu.
Co frameworky a nástroje samy nevyřeší
Scrum může vytvořit vazbu mezi Product Goal, Sprint Goal a konkrétní prací. Kanban může pomoci řídit tok iniciativ a omezit rozpracovanost. SAFe nabízí strategická témata, portfolio Kanban, epiky a PI Objectives. Product management přináší outcome roadmapy, discovery a práci s hypotézami.
Všechny tyto přístupy mohou být užitečné. Žádný z nich ale automaticky nevyřeší situaci, kdy:
- leadership nechce dělat trade-offy,
- každá business oblast očekává vlastní kapacitu,
- staré iniciativy nelze zastavit,
- úspěch se hodnotí především podle dodaného scope,
- týmy nemají pravomoc reagovat na získané poznatky.
Také SAFe popisuje strategická témata jako měřitelné business cíle, které mají poskytovat kontext pro rozhodování portfolia, ARTů a týmů. Samotná existence této vrstvy však nezaručí, že začne ovlivňovat reálné pořadí práce.
Mezeru mezi OKR a backlogem nevyplní další typ ticketu. Vyplní ji kvalitnější investiční rozhodnutí, omezení rozpracovaných iniciativ a pravidelná zpětná vazba mezi výsledky a kapacitou.
Závěr: strategie musí být vidět v rozhodnutích
Funkční propojení strategie a backlogu se nepozná podle počtu vazeb v Jira ani podle toho, zda každá iniciativa obsahuje odkaz na některé OKR.
Pozná se podle toho, že:
- strategické cíle mění alokaci kapacity,
- organizace dokáže některou práci odmítnout nebo zastavit,
- iniciativy mají měřitelné očekávané výsledky,
- backlog se průběžně mění podle získaných důkazů,
- týmy rozumějí nejen tomu, co mají dodat, ale také proč,
- úspěch se nehodnotí pouze podle dokončeného scope.
Dokud nová OKR pouze přidávají další práci a nemění pořadí, kapacitu ani pravidla rozhodování, nejsou skutečným řídicím systémem. Jsou jen další vrstvou reportingu.
Pokud ve vaší organizaci existují strategické cíle, portfolio iniciativ i týmové backlogy, ale vazba mezi nimi se při každodenním rozhodování ztrácí, může pomoci společně zmapovat skutečný tok od strategie k delivery. V rámci služby Strategy-to-Execution se zaměřujeme právě na prioritizační pravidla, portfolio backlog, rozhodovací cadence a propojení strategických výsledků s reálnou prací týmů.
Chcete si vazbu mezi strategií a backlogem nejprve projít sami?
V Agile Brothers Academy postupně zveřejňujeme praktické šablony, toolkity, taháky a krátké mikrokurzy pro práci s backlogem, prioritami, tokem práce a měřením výsledků. Mohou vám pomoci připravit první mapu současného stavu a pojmenovat místa, kde se strategický kontext ztrácí.