PI Objectives bez divadla: jak z nich udělat nástroj řízení, ne formalitu

Do konce PI Planningu zbývá necelá hodina. Týmy mají připravené plány, rozkreslené závislosti a přibližnou představu o kapacitě. Teď ještě musí dokončit PI Objectives.

Na obrazovce postupně vznikají věty jako:

Implementovat nový onboardingový formulář.

Dokončit migraci integrační platformy.

Dodat Features A, B a C.

Business Owners k nim doplní čísla od jedné do deseti, tým cíle prezentuje a PI Planning může být formálně uzavřen. O dva týdny později se už ale na Objectives téměř nikdo nedívá. Na synchronizacích se probírají Features, termíny a blokace. Ve status reportu se sleduje procento dokončených ticketů. K PI Objectives se organizace vrátí až na konci období, kdy je potřeba doplnit Actual Business Value.

Proces proběhl. Artefakt existuje. Přesto PI Objectives nic neřídí.

Tohle není drobná chyba ve formulaci. Je to promarněná příležitost vytvořit mezi strategií a backlogem srozumitelnou dohodu o tom, čeho chceme dosáhnout, proč na tom záleží a podle čeho budeme během PI rozhodovat.

PI Objective není zkrácený seznam Features

PI Objective má popsat výsledek, ke kterému tým nebo celý ART směřuje. Features, Stories a další backlogové položky představují aktuálně zvolenou cestu, jak tohoto výsledku dosáhnout.

Rozdíl je důležitý zejména ve chvíli, kdy se původní plán přestane potkávat s realitou.

Představme si například následující cíl:

Implementovat nový self-service proces pro reset hesla.

Taková věta popisuje řešení. Neříká ale, proč ho vytváříme ani co má být po jeho dokončení jinak. Užitečnější Objective může znít:

Umožnit zákazníkům obnovit přístup k účtu bez zásahu zákaznické podpory.

Druhá formulace dává týmu více směru a současně více prostoru. Možná zjistí, že původně navržený proces je příliš složitý. Může změnit způsob ověření identity, zjednodušit první verzi nebo začít pouze s nejčastější skupinou uživatelů. Konkrétní rozsah se změní, ale smysl práce zůstane zachovaný.

Podobný princip využívá Scrum u Sprint Goal. Cíl má vysvětlovat, proč je daný Sprint hodnotný, vytvářet společné zaměření a současně ponechávat flexibilitu v přesné práci potřebné k jeho dosažení.

PI Objectives fungují ve větším časovém a organizačním měřítku, jejich praktický smysl je však podobný:

• propojit záměr s prací týmů,
• vytvořit společnou definici úspěchu,
• pomoci rozhodovat při změně priorit nebo rozsahu,
• zviditelnit rizika a potřebná rozhodnutí,
• umožnit průběžně posuzovat skutečný pokrok.

Pokud Objective nepomůže odpovědět na otázku, co chránit a co naopak změnit, když se objeví problém, pravděpodobně jde pouze o jinak pojmenovaný plán práce.

PI Objectives jako řídicí vrstva mezi strategií a backlogem

V řadě organizací se do jednoho systému smíchají tři odlišné typy rozhodnutí:

1. Investiční rozhodnutí: proč do tématu investujeme a jaký dopad očekáváme.
2. Rozhodnutí o výsledku: čeho chceme během konkrétního období dosáhnout.
3. Rozhodnutí o realizaci: jaké Features, Stories, experimenty nebo technické změny provedeme.

PI Objective patří do prostřední vrstvy. Není ještě detailním plánem realizace, ale musí být konkrétnější než obecná strategická priorita typu „zlepšit zákaznickou zkušenost“.

Této souvislosti se podrobněji věnujeme v článku Tři úrovně řízení práce bez frameworku: investice → doručení → inkrement. Jakmile jsou strategický záměr, výsledek dodávky a konkrétní práce popsané stejným jazykem nebo dokonce stejným ticketem, leadership sklouzává do detailu a týmy naopak ztrácejí kontext.

Stejný problém vzniká, když se stejný text kopíruje mezi Requirementem, Feature, Story a PI Objective. Formálně jsou položky propojené, ale žádná z nich nepřidává nové rozhodnutí. Více o tomto anti-patternu najdete v článku Requirement, Feature, Story: proč nestačí mít hierarchii v Jira.

Pět znaků PI Objective, podle kterého lze opravdu řídit

1. Popisuje výsledek, ne pouze aktivitu

Slabé Objective často začíná slovesy jako implementovat, migrovat, vytvořit nebo dokončit. Tato slovesa nejsou automaticky špatná, ale obvykle popisují práci, nikoliv její smysl.

Porovnejme dvě formulace:

• Aktivita: Migrovat integrační vrstvu na novou platformu.
• Výsledek: Odstranit omezení integrační vrstvy, které brání bezpečnému nasazování změn bez odstávky.

Technický cíl je zcela legitimní. Nemusíme ho převlékat za falešný zákaznický outcome. Musíme ale umět vysvětlit, jaká schopnost vznikne nebo jaké riziko bude odstraněno.

2. Říká, komu nebo čemu vznikne hodnota

Příjemcem hodnoty nemusí být vždy koncový zákazník. Může jím být pracovník podpory, interní uživatel, obchodní tým, provoz, jiný ART nebo technologický systém.

Důležité je vyhnout se vágním formulacím jako „zlepšit platformu“, „podpořit digitalizaci“ nebo „zvýšit efektivitu“. Bez jasnějšího kontextu podle nich nelze rozhodnout, co do cíle patří a co už ne.

3. Má pozorovatelnou definici úspěchu

U každého Objective bychom měli umět odpovědět:

Co bychom na konci PI museli vidět, abychom mohli říct, že se cíl podařil?

Důkazem může být například:

• nová schopnost dostupná konkrétní skupině uživatelů,
• end-to-end scénář fungující v produkčním nebo produkci blízkém prostředí,
• snížení manuální práce, čekání nebo chybovosti,
• ověřená produktová nebo technická hypotéza,
• odstranění konkrétního provozního či regulatorního rizika,
• prokazatelná adopce řešení,
• měřitelná změna zákaznického nebo provozního chování.

Ne každý cíl potřebuje sofistikovaný dashboard. Potřebuje ale důkaz, který je silnější než informace, že byly uzavřeny všechny Stories.

4. Umožňuje měnit scope bez ztráty směru

Dobré Objective pomůže týmu rozlišit tři skupiny práce:

• práci nezbytnou pro dosažení cíle,
• preferované řešení, které lze při problému změnit,
• práci, která se cíle netýká a pouze soupeří o kapacitu.

Představme si, že tým chce snížit manuální zpracování standardních žádostí. Původní plán obsahuje nový formulář, automatickou validaci, integraci tří datových zdrojů a reporting.

Během PI se ukáže, že třetí datový zdroj nebude dostupný. Pokud Objective zní „dodat čtyři komponenty“, tým může pouze hlásit zpoždění. Pokud zní „umožnit automatické zpracování standardních žádostí bez zásahu operátora“, může hledat menší skupinu případů, pro kterou lze výsledku dosáhnout i bez blokované integrace.

Cíl tak nebrání změně plánu. Naopak poskytuje kritérium, podle kterého plán měníme.

5. Má vlastníka hodnoty a rytmus kontroly

Nestačí určit člověka, který Objective zapíše do nástroje. Musí být jasné:

• kdo reprezentuje očekávanou hodnotu,
• kdo koordinuje realizaci,
• kdo může rozhodnout o změně priority nebo rozsahu,
• kdy a na jakém fóru se bude cíl kontrolovat.

Bez tohoto rozhodovacího rytmu se z Objective rychle stane dokumentace toho, čemu jsme věřili v den PI Planningu.

Pět otázek, které odhalí slabé PI Objective

Business Value má vyvolat diskusi, ne vyrobit žebříček týmů

Planned Business Value může být užitečné, pokud vede Business Owners a týmy k rozhovoru o prioritách:

• Který cíl je skutečně nejdůležitější?
• Proč má právě tento cíl větší hodnotu než jiný?
• Co máme chránit při kapacitním konfliktu?
• Kde potřebuje tým rychlé rozhodnutí leadershipu?
• Jaké riziko podstupujeme, když cíl odložíme?

Samotné číslo ale hodnotu neobjektivizuje. Desítka není přesnější jen proto, že je vyšší než osmička. Business Value nenahradí dobře formulovaný cíl ani srozumitelnou strategii.

Ještě problematičtější je používání Actual Business Value jako známky výkonu týmu. Jakmile lidé získají pocit, že podle výsledného skóre budou hodnoceni, začnou:

• formulovat bezpečné a snadno dosažitelné cíle,
• skrývat nejistotu,
• vyjednávat skóre místo výsledku,
• přizpůsobovat interpretaci cíle tomu, co se podařilo dokončit,
• vyhýbat se experimentům s nejistým výsledkem.

Nízké skóre navíc nemusí automaticky znamenat špatnou práci týmu. Původní hypotéza mohla být chybná. Mohla se změnit situace na trhu. Klíčová závislost nemusela být dostupná. Leadership mohl během PI změnit prioritu.

Tým například vytvoří experiment, který prokáže, že zákazníci navrhovanou funkci nepotřebují. Feature nakonec nevznikne, ale organizace zastaví nevýhodnou investici. Z pohledu objemu dodávky jde o málo. Z pohledu učení a ochrany investice může jít o velmi dobrý výsledek.

Proto je vhodné při vyhodnocení oddělit:

• stav dosažení cíle,
• kvalitu původní hypotézy,
• nově získané poznatky,
• změny prostředí,
• systémové překážky mimo kontrolu týmu,
• rozhodnutí, která v průběhu PI učinil management.

Podobně opatrně je potřeba pracovat i s dalšími metrikami. V článku OKR a KPI: jak je používat společně, aby metriky podporovaly byznys, ne škodily vysvětlujeme, proč cíle a průběžné metriky plní odlišnou roli a proč jejich mechanické smíchání vede spíše k reportingu než k lepšímu řízení.

PI Objectives se musí používat během PI

Největší slabinou většiny PI Objectives není jejich formulace. Je jí skutečnost, že se po PI Planningu přestanou používat.

Organizace dále sleduje Features, Stories, termíny a závislosti, ale už se pravidelně neptá, jak se vyvíjí dosažení cíle. Tím se řízení nenápadně vrací od výsledků zpět k aktivitě.

Oficiální popis System Demo ve Scaled Agile Frameworku zdůrazňuje integrované fungující řešení a objektivní kontrolu pokroku směrem k PI Objectives. Smyslem tedy není pouze odprezentovat, na čem jednotlivé týmy pracovaly, ale získat důkaz o vývoji společného výsledku.

Při každém relevantním review se proto vyplatí položit několik jednoduchých otázek:

• Jaký nový důkaz máme o dosažení cíle?
• Co jsme se od poslední kontroly naučili?
• Je plánovaný rozsah stále nejlepší cestou?
• Jaké riziko dnes cíl nejvíce ohrožuje?
• Potřebujeme rozhodnutí Product Managementu nebo Business Ownera?
• Je cíl stále relevantní?

Není nutné kvůli tomu zavádět další hodinovou ceremonii. Kontrola může být součástí System Demo, ART Syncu, produktového review nebo pravidelného delivery review.

Inspiraci lze čerpat také z Open Guide to Kanban. Kanban nestaví řízení pouze na vizualizaci položek, ale na aktivním řízení práce, explicitních pravidlech, pravidelné kontrole rozpracovaných položek a zpětné vazbě. Stejný princip platí pro cíle: zapsaná karta sama o sobě nic neřídí.

Místo procent dokončení reportujte důkazy

Věta „Objective je hotové ze 70 %“ obvykle skrývá více, než odhaluje. Sedmdesát procent čeho? Počtu Stories? Odhadované pracnosti? Plánovaných komponent?

Užitečnější průběžný report popisuje:

• jaká část výsledku už funguje,
• komu byla demonstrována,
• co jsme ověřili,
• co ještě brání skutečnému použití,
• které předpoklady se změnily,
• jaké rozhodnutí nyní potřebujeme.

Takový popis může být méně pohodlný než jedno číslo, ale poskytuje leadershipu výrazně lepší základ pro rozhodování.

Kdy Objective změnit nebo opustit

PI Objective nemá být neměnné jen proto, že vzniklo během slavnostního dvoudenního plánování.

Změna nebo opuštění cíle může být správné rozhodnutí, když:

• se původní předpoklad ukázal jako chybný,
• změnila se regulace nebo situace na trhu,
• řešení neposkytuje očekávanou hodnotu,
• klíčová závislost nebude dostupná,
• objevil se výrazně hodnotnější cíl,
• pokračování už nedává ekonomický smysl.

Důležité je, aby změna neproběhla potichu prostřednictvím postupných úprav backlogu. Má jít o transparentní rozhodnutí, které objasní:

• co jsme se dozvěděli,
• proč původní cíl měníme,
• jaký to má dopad na další cíle a závislosti,
• kam přesouváme kapacitu,
• kdo změnu schválil.

Agilita neznamená libovolně měnit scope. Znamená umět měnit plán na základě nových důkazů, aniž bychom ztratili transparentnost a odpovědnost za investiční rozhodnutí.

Typické chyby

• Objective je přepsaný název Feature. Formulace popisuje dodávku, nikoliv změnu, kterou má přinést.
• Každá Feature má vlastní Objective. Místo několika skutečných priorit vznikne dlouhý katalog plánované práce.
• Cíle se píší až na konci PI Planningu. Neovlivní výběr práce ani diskusi o kapacitě, pouze dodatečně popíšou hotový plán.
• Jeden tým má deset nebo patnáct prioritních cílů. Slovo priorita tím ztrácí význam.
• Chybí definice úspěchu. Na konci nelze rozlišit dokončenou aktivitu od dosaženého výsledku.
• Business Value přiděluje RTE nebo Product Owner bez skutečné diskuse s Business Owners. Číslo potom pouze vyplní povinné pole.
• Actual Business Value se odvozuje od procenta hotových Stories. Výsledek se zamění za objem dokončené práce.
• Skóre se používá k porovnávání týmů. Lidé začnou optimalizovat hodnocení místo učení a výsledku.
• Technické cíle se maskují falešným byznysovým jazykem. Místo konkrétní schopnosti nebo rizika vznikne neurčitý slogan.
• Uncommitted Objectives jsou považovány za práci navíc. Ve skutečnosti mohou vyjadřovat nejistotu, závislost nebo cíl, který zatím nelze odpovědně zahrnout do závazku.
• ART Objective je jen seznam týmových Objectives. Nevyjadřuje společný výsledek vyžadující koordinaci napříč týmy.
• Cíle se kontrolují až na konci PI. Organizace tak ztrácí možnost včas upravit plán nebo odstranit systémovou překážku.

Jak začít v praxi

Není nutné před příštím PI překreslit celý proces, přeškolit ART ani měnit konfiguraci Jira. Začněte nad skutečnými cíli a zaveďte několik malých pravidel.

1. Projděte Objectives z posledního PI

U každého cíle zkuste určit, co ve skutečnosti popisuje:

• výsledek,
• výstup,
• aktivitu,
• seznam scope,
• neurčitý slogan.

Nehledejte zatím viníka ani ideální formulaci. Potřebujete získat společný obraz současné reality.

2. Doplňte dvě věty

Ke každému Objective doplňte:

Na konci PI bude jinak to, že…

Poznáme to podle…

Už tento jednoduchý krok často odhalí, že organizace nerozumí očekávanému výsledku nebo nemá dohodnutý způsob jeho ověření.

3. Omezte počet skutečných priorit

Neexistuje univerzální správný počet Objectives. Tým ale obvykle potřebuje několik srozumitelných cílů, ne samostatný cíl pro každou Feature.

Pokud není možné určit, který cíl chránit při konfliktu o kapacitu, nejsou priority dostatečně jasné.

4. Zaveďte krátké Objective Review

Jednou za iteraci nebo v jiné smysluplné kadenci projděte:

• nový důkaz dosažení cíle,
• největší aktuální riziko,
• změnu předpokladů,
• potřebné rozhodnutí,
• případnou změnu scope.

Review nemusí trvat dlouho. Musí se ho ale účastnit lidé, kteří dokážou potřebné rozhodnutí skutečně udělat.

5. Na konci nehodnoťte jen skóre

Ke každému cíli zaznamenejte:

• čeho jsme dosáhli,
• jaký důkaz máme,
• co jsme se naučili,
• co zabránilo lepšímu výsledku,
• jaké rozhodnutí nebo pravidlo změníme v příštím PI.

Tím se z vyhodnocení stane zdroj učení pro další plánování, ne pouze administrativní uzavření období.

Když problém není v jedné špatně napsané větě

Někdy se Objectives podaří zlepšit pomocí několika praktických pravidel. Jindy však slabé cíle pouze odhalují hlubší problém:

• strategie se nepřekládá do konkrétních priorit,
• Product Management nemá pravomoc rozhodovat o scope,
• Business Owners se účastní pouze začátku a konce PI Planningu,
• týmy dostávají příliš mnoho paralelních požadavků,
• závislosti nemají vlastníky,
• programová úroveň sbírá statusy, ale nepomáhá dělat rozhodnutí,
• leadership hodnotí aktivitu místo výsledku.

V takové situaci nestačí workshop o lepším psaní Objectives. Je potřeba podívat se na propojení strategie, prioritizace, programového backlogu, kapacity a rozhodovacího rytmu.

Pro organizace, které potřebují převést strategické priority do srozumitelných programových a týmových rozhodnutí, je určený náš produkt Strategy-to-Execution. Pokud je hlavním tématem nastavení nebo restart spolupráce více týmů, příprava PI a fungování společného plánování, může být relevantnější ART / Tribe Launch & PI Planning.

Nejde přitom o instalaci dalšího frameworku. Cílem je nastavit minimální funkční model, ve kterém cíle pomáhají týmům i leadershipu rozhodovat také několik týdnů po skončení plánovacího workshopu.

Závěr: kvalitu PI Objective poznáte podle rozhodnutí

Dobré PI Objective není to, které vypadá profesionálně na prezentaci z PI Planningu. Je to cíl, který pomůže odpovědět na praktické otázky:

• Co je teď nejdůležitější?
• Jaký výsledek skutečně chráníme?
• Který scope můžeme změnit?
• Jaký důkaz už máme?
• Co nám brání postoupit?
• Kdo musí učinit další rozhodnutí?

Plán se během PI téměř jistě změní. PI Objective má zajistit, že se nezmění pouze nahodile.

PI Objective není slavnostní popis plánu. Je to dočasná dohoda mezi týmem, produktovým řízením a leadershipem o výsledku, jeho hodnotě a způsobu, jakým budou společně posuzovat pokrok.

Pokud cíle po PI Planningu mizí, nezačínejte dalším povinným polem v Jira. Vezměte několik skutečných Objectives, projděte je s týmy a Business Owners a zjistěte, při kterých rozhodnutích vám dnes nepomáhají. Právě tam se obvykle nachází první smysluplná změna.

---

Chcete si kvalitu svých Objectives nejprve ověřit sami?

V Agile Brothers Academy postupně zveřejňujeme praktické toolkity, checklisty a krátké materiály pro práci s cíli, backlogem a delivery. Mohou vám pomoci připravit první změny bez zavádění další složité metodiky.

Pokud zjistíte, že problém není jen ve formulaci Objectives, ale také v prioritách, rolích nebo rozhodování během PI, můžeme se společně podívat na několik reálných cílů a průběh vašeho plánování. Často už takový rozbor ukáže, zda stačí upravit několik pravidel, nebo je potřeba řešit širší způsob řízení ARTu.