Na ART syncu zazní zdánlivě jednoduchý požadavek: „Od příštího PI bychom chtěli, aby každý tým začal sledovat tři týmová KPIs. Nechceme nic složitého, jen něco, co podpoří trvalé zlepšování.“
Na papíře to dává smysl. Tři metriky nejsou přehnané. Management chce lepší přehled. RTE nebo transformační tým chce vidět, kde se daří a kde se věci zasekávají. Scrum Master nebo Agile Coach ví, že bez dat se o zlepšování často mluví jen pocitově.
Jenže hned přijde praktická otázka: které tři metriky?
Jeden tým má hodně práce rozpracované, ale málo dokončené. Jiný tým pravidelně přelévá práci ze sprintu do sprintu. Další tým je zahlcený supportem a urgentními požadavky. Jiný tým dodává rychleji, ale roste počet chyb. A produktový tým možná uzavírá spoustu ticketů, ale nikdo pořádně neví, jestli dodané změny zákazníkům opravdu pomáhají.
Pokud těmto týmům dáme stejnou sadu metrik, bude to vypadat manažersky čistě. Prakticky to ale často nebude dávat smysl.
V předchozím článku Proč se agilní týmy bojí metrik a jak zavést měření tak, aby pomáhalo, ne škodilo jsme řešili bezpečný rámec měření: proč metriky nesmí být bičem, proč neporovnávat týmy mezi sebou a proč čísla bez kontextu spíš škodí. Tady půjdeme o krok dál. Budeme řešit praktickou otázku: jak si tým vybere tři metriky podle své konkrétní situace.
Největší chyba: vybírat metriky podle seznamu, ne podle problému
Když se v organizaci řekne „týmová KPIs“, často se rychle objeví seznam známých metrik: velocity, throughput, cycle time, počet bugů, planned vs done, spokojenost týmu, možná nějaká customer satisfaction metrika.
Na jednotlivých metrikách nemusí být nic špatného. Problém vzniká ve chvíli, kdy je tým vybere jen proto, že „se v agile běžně měří“. Metrika bez vazby na konkrétní problém je jen další číslo na dashboardu.
Dobrá sada týmových KPIs by neměla začínat otázkou:
Jaké metriky bychom měli měřit?
Měla by začínat otázkou:
Jaký problém potřebujeme lépe vidět, abychom se mohli zlepšit?
To je zásadní rozdíl. Pokud v týmu řešíte pomalé dokončování práce, budete potřebovat jiné metriky než tým, který má hlavní problém v kvalitě. Pokud tým bojuje s neplánovanou prací, nepomůže mu stejná sada jako produktovému týmu, který chce lépe měřit dopad na uživatele.
Neexistuje univerzální sada tří týmových KPIs. Existují ale dobré principy, jak si smysluplnou trojici vybrat.
Pravidlo vyvážené trojice
Začít třemi metrikami je rozumné. Tři metriky jsou dost málo na to, aby se v nich tým neztratil, a zároveň dost na to, aby jedna metrika nedeformovala celé chování týmu.
Dobrá trojice by ale neměla být náhodná. Obvykle dává smysl, aby pokryla tři různé pohledy:
- jednu metriku toku práce — jak práce proudí systémem,
- jednu metriku stability, kapacity nebo predikovatelnosti — zda tým pracuje v realistickém režimu,
- jednu metriku kvality nebo dopadu — aby tým neoptimalizoval jen rychlost nebo objem.
První metrika ukazuje, jestli práce skutečně teče. Druhá pomáhá porozumět tomu, zda tým zvládá závazky, priority a kapacitu. Třetí chrání před lokální optimalizací: například před tím, že tým začne dokončovat více položek, ale za cenu horší kvality nebo mizivého dopadu.
V oblasti flow metrik se často pracuje se čtveřicí WIP, cycle time, work item age a throughput. Kanban Guide je popisuje jako základní metriky toku, které pomáhají porozumět zdraví systému práce a informovat rozhodování o tom, jak je dodávána hodnota.
Podobně Scrum stojí na empirii, tedy na transparentnosti, inspekci a adaptaci. Metriky proto dávají smysl hlavně tehdy, když pomáhají týmu lépe vidět realitu a upravit způsob práce. Ne když nahrazují úsudek týmu.
Nejdřív diagnostika: jaký problém tým opravdu řeší?
Než tým vybere metriky, měl by si pojmenovat hlavní bolest. Níže je pět typických situací z praxe. V reálném životě často narazíte na jejich kombinaci, ale pro začátek je dobré vybrat jednu dominantní.
1. Hodně rozpracováno, málo dokončeno
Tým má dlouhé stand-upy. Každý něco řeší, ale hotových věcí je málo. V Jira, Azure DevOps nebo jiném nástroji leží hodně položek ve stavech In Progress, Review, QA nebo Waiting. Lidé přepínají mezi úkoly, čekají na odpovědi, review nebo testování. Všichni jsou vytížení, ale tok práce je slabý.
Typická otázka pro tento tým není „pracujeme dost?“, ale:
Kolik práce držíme otevřené a která z ní začíná nebezpečně stárnout?
2. Sprinty nebo iterace pravidelně přetékají
Tým plánuje sprint, ale část práce se opakovaně přesouvá dál. Příčinou mohou být příliš velké položky. Jindy během sprintu přijdou nové priority. V dalších případech refinement neodhalí závislosti nebo technickou složitost.
Problém nemusí být v tom, že tým „neplní závazky“. Tým může plánovat nereálně. Jindy mu někdo v průběhu práce mění scope. Problémem může být také neschopnost dobře oddělit forecast od závazku nebo práce s příliš velkými položkami.
Klíčová otázka zní:
Proč opakovaně nedokončujeme to, co jsme si společně naplánovali?
3. Tým je zahlcený supportem a urgentní prací
Na plánování všechno vypadá rozumně. Jenže během sprintu nebo týdne přicházejí incidenty, dotazy, urgentní požadavky, „malé věci“, produkční problémy nebo požadavky od stakeholderů. Na konci období tým vypadá nespolehlivě, protože nedodal plán. Ve skutečnosti ale pracoval na věcech, které v plánu vůbec nebyly.
Tady je potřeba, abyste zviditelnili neplánovanou práci. Ne proto, aby se na ni hledal viník, ale aby šla řídit kapacita.
Dobrá otázka zní:
Kolik naší kapacity reálně spotřebuje práce, kterou jsme neplánovali?
4. Tým zrychluje, ale roste počet chyb nebo reworku
Na první pohled to může vypadat dobře. Tým dokončuje více položek, throughput roste, sprinty se daří uzavírat. Jenže zároveň přibývá bugů, hotfixů, návratů z testování nebo oprav po releasu. Část kapacity se ztrácí v reworku.
Takový tým nepotřebuje jen další tlak na rychlost. Potřebuje vidět, zda rychlost nevzniká na dluh.
Klíčová otázka:
Dodáváme rychleji, nebo jen posouváme náklady do budoucího reworku?
5. Tým dodává hodně, ale není jasný dopad
Tým má plný backlog, pravidelně releasuje a uzavírá položky. Stakeholdeři vidí aktivitu. Jenže chybí jasná odpověď na otázku, zda dodané změny opravdu pomohly zákazníkům nebo byznysu.
Tady už samotné delivery metriky nestačí. Produktový tým potřebuje alespoň jednoduchý signál dopadu: adopci, použití funkce, změnu chování, snížení manuální práce, rychlejší dokončení procesu nebo kvalitativní zpětnou vazbu.
Hlavní otázka:
Jak poznáme, že dokončená práce skutečně pomohla zákazníkovi nebo byznysu?
Pět doporučených sad tří metrik podle situace
Následující sady nejsou dogma. Berte je jako praktické startovací kombinace. Každý tým by je měl upravit podle svého workflow, typu práce a dostupnosti dat.
Sada A: Flow tým — hodně rozpracováno, málo dokončeno
Doporučené metriky:
- WIP — kolik práce má tým aktuálně rozpracováno.
- Work item age — jak dlouho už běží rozpracované položky.
- Throughput — kolik položek tým dokončuje za zvolený časový úsek.
Tahle sada pomáhá týmu přestat startovat další a další práci a začít dokončovat. WIP ukáže přetížení systému. Work item age upozorní na položky, které stárnou a pravděpodobně se zasekly. Throughput ukáže skutečné dokončování.
Příklad z praxe: Tým má osm lidí a v jednu chvíli patnáct rozpracovaných položek. Některé čekají na review, jiné na QA, další na odpověď od businessu. Na stand-upu každý reportuje aktivitu, ale skoro nic se neposouvá do Done. První experiment nemusí být složitý: snížit WIP, každý den se podívat na nejstarší rozpracovanou položku a domluvit se, co je potřeba udělat pro její dokončení.
Typické akce: zavést WIP limit, zastavit startování nové práce, aktivně dokončovat stárnoucí položky, zviditelnit bottleneck ve workflow.
Pokud je hlavním problémem pomalý tok práce, bottlenecky a přetížené workflow, může na podobné situace navazovat služba Flow Accelerator.
Sada B: Sprintový tým — nízká predikovatelnost plánu
Doporučené metriky:
- Planned vs done — kolik z plánované práce bylo skutečně dokončeno.
- Spillover rate — kolik práce pravidelně přetéká do další iterace.
- Scope change během sprintu nebo iterace — kolik práce bylo přidáno nebo významně změněno po plánování.
Tahle sada pomáhá rozlišit, jestli je problém v plánování, velikosti práce, kapacitě, závislostech nebo změnách zadání. Bez metriky scope change může tým vypadat nespolehlivě, i když mu do sprintu každý týden vstupují nové urgentní požadavky.
Příklad z praxe: Tým pravidelně dokončuje jen 70 % plánované práce. Leadership začne mluvit o nízké spolehlivosti. Když se ale tým podívá na data, zjistí, že během sprintu pravidelně přibývá 25–30 % nové práce. Problém tedy není jen plánování týmu. Problém je i v tom, že organizace přidává práci bez jasného trade-off rozhodnutí.
Typické akce: zmenšit stories, zlepšit refinement, plánovat kapacitu realističtěji, zavést pravidlo pro urgentní změny, při přidání práce explicitně říkat, co se vyřazuje.
Pokud jsou plány nevěrohodné a scope se mění za běhu, dává smysl řešit predikovatelnost cíleně — například přes Predictability Reset.
Sada C: Support / ad hoc tým — příliš mnoho neplánované práce
Doporučené metriky:
- Poměr plánované vs neplánované práce — kolik kapacity spotřebují požadavky mimo původní plán.
- Počet urgentních / expedite položek — kolik práce obchází standardní tok.
- Aging blokovaných položek — jak dlouho stojí práce kvůli čekání, závislostem nebo rozhodnutí.
Tahle sada je užitečná pro týmy, které nemají čistý produktový vývoj. Typicky řeší support, provoz, incidenty, integrační dotazy, ad hoc požadavky nebo podporu jiných týmů. Pokud neplánovaná práce není vidět, tým bude vždycky vypadat hůř, než jaká je realita.
Příklad z praxe: Tým plánuje vývoj na celý sprint, ale ve skutečnosti tráví třetinu kapacity podporou produkce a dotazy z jiných týmů. Protože tato práce není v plánu ani v reportingu, na konci sprintu se řeší jen nedodané stories. Jakmile tým začne sledovat poměr plánované a neplánované práce, diskuse se změní. Už nejde o to, že tým „nestíhá“. Jde o rozhodnutí, kolik kapacity má být vědomě vyhrazeno na support.
Typické akce: vyhradit kapacitu na support, nastavit triage, definovat explicitní policy pro urgentní práci, vizualizovat blokery, eskalovat opakované příčiny urgentních požadavků.
Sada D: Kvalitativně přetížený tým — rychlost roste, ale kvalita padá
Doporučené metriky:
- Escaped defects / production bugs — kolik chyb uniká mimo tým nebo do produkce.
- Rework rate — kolik kapacity se spotřebuje opravami a návraty práce.
- Cycle time pro opravy / defekty — jak dlouho trvá odstranit chybu nebo dokončit opravnou práci.
Tahle sada chrání tým před falešným zlepšením. Pokud tým dokončuje více věcí, ale zároveň roste počet oprav, nemusí jít o vyšší výkonnost. Může jít o přesun nákladů do budoucnosti.
Příklad z praxe: Tým zkrátil cycle time a na review vypadá úspěšně. O měsíc později ale tráví stále více kapacity hotfixy, opravami a analýzou produkčních incidentů. Když se začne měřit rework rate, ukáže se, že část „zrychlení“ vznikla tím, že se některé problémy jen posunuly za hranici Done.
Typické akce: zpřísnit Definition of Done, zlepšit testování, posílit review, dělat root cause analýzu opakovaných chyb, přestat tlačit jen na objem dodávky.
Pokud metriky ukazují, že rychlost roste za cenu stability a kvality, samotný tlak na tým nepomůže. V takové situaci může dávat smysl cíleně řešit systém kvality přes Quality & Reliability Boost.
Sada E: Produktový tým — hodně delivery, málo jasného dopadu
Doporučené metriky:
- Time to usable increment — jak dlouho trvá dostat práci do použitelného stavu pro uživatele.
- Adoption / usage proxy — zda zákazníci nebo uživatelé novou věc skutečně používají.
- Customer feedback / outcome signal — zda dodaná změna zlepšila chování, výsledek nebo zkušenost zákazníka.
Tahle sada je důležitá hlavně pro produktové týmy. Počet dokončených položek, story pointů nebo releasů ještě neříká, jestli tým dodává hodnotu. Produktový tým potřebuje propojit delivery s nějakým signálem dopadu.
Příklad z praxe: Tým dodá novou funkci, kterou stakeholder požadoval několik měsíců. Technicky je hotovo, release proběhl, ticket je zavřený. Po dvou měsících ale nikdo neví, kolik uživatelů funkci používá a jestli se zlepšil proces, kvůli kterému funkce vznikla. Jednoduchá adoption metrika by změnila diskusi: místo „dodali jsme“ by se tým ptal „pomohlo to?“
Typické akce: formulovat produktové hypotézy, rozlišit output a outcome, doplnit telemetry nebo jednoduchý feedback loop, používat outcome signály při prioritizaci.
Pro hlubší práci s propojením delivery a výsledků se hodí také téma OKR a KPI. Na blogu k tomu navazuje článek OKR a KPI: jak je používat společně, aby metriky podporovaly byznys, ne škodily a další texty o metrikách byznys výsledků.
Typické chyby při výběru týmových KPIs
Výběr metrik není jen technická otázka. Každá metrika ovlivňuje chování. Proto je dobré dát si pozor na několik častých chyb.
1. Začít seznamem metrik místo problémem týmu
Dashboard může vypadat profesionálně, ale pokud neodpovídá na konkrétní problém, nepomůže. Tým pak měří, protože „se to má“, ne proto, že podle dat něco mění.
2. Vybrat tři metriky, které měří totéž
Například throughput, počet uzavřených ticketů a počet story pointů jsou všechno varianty objemu. Taková sada může vytvářet tlak na více dodávky, ale nechrání kvalitu, stabilitu ani dopad.
3. Použít velocity jako KPI výkonu
Velocity může být interní plánovací pomůcka týmu. Jakmile se ale stane KPI pro hodnocení výkonu, začne být nebezpečná. Tým může nafukovat odhady, dělit práci uměle nebo se bránit složitějším položkám.
4. Ignorovat neplánovanou práci
Pokud váš tým řeší support, urgentní požadavky nebo incidenty a tato práce není vidět, bude plánování vždycky zkreslené. Neplánovaná práce není selhání. Je to typ práce, který musí být řízený.
5. Měřit flow bez kvality
Rychlejší dokončování je dobrá zpráva jen tehdy, pokud neroste rework, počet chyb nebo incidentů. Flow metrika bez quality guardrailu může vést k tomu, že tým optimalizuje rychlost na úkor stability.
6. Měřit kvalitu bez toku práce
Naopak pouze kvalita bez flow metrik může vést k defenzivnímu chování. Tým zpomalí, aby minimalizoval chyby, ale nikdo neřeší, kde práce stojí, proč je QA bottleneck nebo proč se chyby objevují pozdě.
7. Vnutit stejná KPIs všem týmům
Společné principy dávají smysl. Stejná čísla pro všechny týmy už často ne. Platformní tým, produktový tým, supportní tým a integrační tým mají jiný typ práce. Metriky mají reflektovat kontext, ne vyrábět falešnou srovnatelnost.
8. Nastavit cíle dřív než baseline
Pokud tým nikdy neměřil cycle time, nedává smysl hned říkat, že ho má snížit o 30 %. Nejdřív je potřeba několik týdnů sledovat realitu. Teprve potom má smysl diskutovat zlepšovací ambici.
Jak začít v praxi: 60min workshop pro výběr tří metrik
Výběr prvních týmových KPIs nemusí být velký transformační projekt. Dobře připravený tým si první pracovní verzi dokáže vybrat v jednom hodinovém workshopu.
1. Pojmenujte hlavní bolest týmu — 10 minut
Začněte otázkou:
Kdybychom mohli příští dva měsíce lépe vidět jen jednu věc v našem systému práce, co by to mělo být?
Může to být flow, plánování, neplánovaná práce, kvalita, závislosti nebo dopad. Důležité je, abyste nevybrali všechno najednou.
2. Pojmenujte rozhodnutí, které chcete dělat lépe — 10 minut
Metrika má smysl jen tehdy, když podle ní budete něco rozhodovat. Například:
- Máme snížit WIP?
- Máme plánovat méně práce?
- Máme vyhradit kapacitu na support?
- Máme zpřísnit Definition of Done?
- Máme zlepšit refinement?
- Máme eskalovat opakované závislosti?
- Máme prioritizovat podle dopadu?
3. Vyberte tři signály — 15 minut
Použijte pravidlo vyvážené trojice:
- jedna metrika toku,
- jedna metrika stability, predikovatelnosti nebo kapacity,
- jedna metrika kvality nebo dopadu.
Nemusíte vybrat dokonalé metriky. Vyberte takové, které jsou pro tým srozumitelné, dostupné a použitelné pro první zlepšovací rozhovor.
4. Ověřte riziko špatného chování — 10 minut
Ke každé metrice si položte několik nepříjemných otázek:
- Jak by šlo tuto metriku „vylepšit“ špatným chováním?
- Co by se stalo, kdyby z ní management udělal cíl?
- Může vést k umělému dělení práce?
- Může vést k odmítání složitějších položek?
- Může potlačit transparentnost?
Pokud metrika snadno povede ke gamingu, buď ji nepoužívejte, nebo ji doplňte guardrail metrikou.
5. Dohodněte baseline období — 10 minut
Prvních 4–6 týdnů metriky hlavně pozorujte. Nedělejte z nich cíle. Nehodnoťte tým podle jednotlivých výkyvů. Sledujte trend a učte se, co data vlastně znamenají.
6. Domluvte první improvement rituál — 5 minut
Metriky musí mít místo, kde se čtou. Může to být retrospektiva, team sync, měsíční improvement check nebo krátká část pravidelného týmového meetingu. Důležité je, aby tým u čísel mluvil o příčinách a experimentech, ne jen o tom, jestli je číslo dobré nebo špatné.
Dobré pravidlo zní:
Metrika, podle které tým nic nezmění, není KPI. Je to dekorace dashboardu.
Jak poznat, že jste vybrali dobré metriky
Dobrá trojice týmových KPIs má několik znaků:
- odpovídá na konkrétní problém týmu,
- nepoužívá se k hodnocení jednotlivců,
- nevytváří tlak na umělé zlepšování čísel,
- je srozumitelná týmu i leadershipu,
- dá se získat bez velké administrativní zátěže,
- vede ke konkrétním rozhodnutím,
- je pravidelně diskutovaná s týmem,
- může se po několika měsících změnit.
Poslední bod je důležitý. Týmová KPIs nejsou navždy. Pokud tým vyřeší hlavní problém s WIP, může se posunout k predikovatelnosti. Pokud stabilizuje plánování, může se začít víc dívat na kvalitu nebo dopad. Metriky mají sledovat potřeby týmu, ne žít vlastním životem.
Jemné CTA: když si nejste jistí, začněte diagnostikou
Někdy tým přesně ví, co ho bolí. Jindy má každý jiný názor. Product Owner mluví o prioritách, vývojáři o technickém dluhu, management o nízké predikovatelnosti a Scrum Master o příliš velkém WIP.
V takové situaci není nejlepší začít dashboardem. Lepší je nejdřív zviditelnit realitu práce: jak práce teče, kde stárne, kolik jí přichází mimo plán, kde vzniká rework a jak se to celé promítá do výsledků.
Právě k tomu může sloužit Agile Reality Check: krátká diagnostika, která pomůže pojmenovat skutečný problém a převést ho do konkrétního improvement backlogu. Pokud už víte, že hlavní brzda je flow, predikovatelnost nebo kvalita, dávají smysl cílenější služby jako Flow Accelerator, Predictability Reset nebo Quality & Reliability Boost.
Pokud si chcete téma nejdřív zpracovat sami s týmem, sledujte Agile Brothers Academy. Praktické toolkity, checklisty a mikrokurzy jsou dobrý způsob, jak podobné téma přenést do retrospektivy, team syncu nebo workshopu s leadershipem bez zbytečné teorie.
Závěrečné shrnutí
Tři týmová KPIs mohou být velmi užitečná. Ale jen tehdy, když nejsou vybraná mechanicky.
Nezačínejte seznamem metrik. Začněte problémem týmu. Jinou sadu potřebuje tým, kterému se hromadí rozpracovaná práce. Odlišné metriky pomohou týmu, kterému pravidelně přetékají sprinty. Specifický pohled vyžaduje tým zahlcený supportem a další zase tým s rostoucím reworkem. A jinou produktový tým, který potřebuje lépe chápat dopad.
Dobrá sada metrik není univerzální KPI šablona. Je to malý diagnostický systém. Pomáhá týmu a leadershipu vidět stejnou realitu, mluvit o příčinách a dělat lepší rozhodnutí.
Pro začátek stačí tři otázky:
- Co nás dnes nejvíc brzdí?
- Jaké rozhodnutí chceme dělat lépe?
- Které tři signály nám pomohou vidět realitu bez zbytečného gamingu?
Pokud na tyto otázky dokážete odpovědět, máte mnohem větší šanci, že týmová KPIs budou pomáhat. Ne škodit.