Na první pohled byla story připravená. Měla popis, acceptance criteria, odhad, přiřazenou prioritu i stav Ready. Product Owner ji při plánování představil a tým ji bez větší diskuse přijal.
O dva dny později byla story zablokovaná.
- Vývojáři zjistili, že potřebné API zatím neexistuje.
- Tester neměl přístup k testovacím datům.
- Business analytik čekal na rozhodnutí stakeholdera.
- Část změny měl realizovat jiný tým, který ji neměl ve svých prioritách.
Nic z toho nebylo úplně nepředvídatelné. Většina informací existovala už před plánováním. Jen nebyla součástí rozhodnutí, zda si tým může práci skutečně vzít.
Tento problém se netýká jen nekvalitně napsaných stories. Stejnou situaci vidíme u větších Features, iniciativ, regulatorních změn i závazků vznikajících během PI Planningu. Položka projde formální kontrolou, dostane prioritu a je zařazena do plánu. Teprve po zahájení se ukáže, že ji tým sice mohl začít, ale nemohl ji dokončit.
Práce není připravená jen proto, že je dostatečně popsaná. Musí být také převzitelná a dokončitelná.
Pro tuto vlastnost používám pojem pullability.
Co znamená pullability
Pullability vyjadřuje, zda může tým položku vědomě převzít do práce a s realistickou šancí ji dovést k hodnotnému výsledku.
Nejde o nový framework, povinný artefakt ani další stav v Jira. Je to jednoduchý test, který rozšiřuje pohled na připravenost práce.
Běžná kontrola připravenosti se většinou soustředí na samotnou položku:
- Je dobře popsaná?
- Má acceptance criteria?
- Byla odhadnuta?
- Je dostatečně malá?
Pullability přidává další otázky:
- Rozumí tým očekávanému výsledku?
- Má vše potřebné k dokončení práce?
- Jsou zvládnuté důležité závislosti?
- Má systém skutečně volnou kapacitu?
- Může tým rozhodnout, zda práci nyní převezme?
Položka může být velmi dobře připravená z hlediska obsahu, ale stále nemusí být pullable. Stejně tak může být práce důležitá a urgentní, ale to samo o sobě neznamená, že je možné ji bezpečně zahájit.
Pull není přesun kartičky
V řadě organizací se o pull systému mluví ve chvíli, kdy si vývojář sám přiřadí ticket nebo přesune kartičku do stavu In Progress. To je ale pouze technická operace.
Skutečný pull znamená, že nová práce vstupuje do systému až ve chvíli, kdy vznikla dostupná kapacita a jsou splněna explicitní pravidla workflow. Právě propojení pullu, řízení rozpracovanosti a pravidel toku zdůrazňuje také The Kanban Guide.
Jestliže je tým plně vytížený a manažer mu přidělí další „prioritní“ položku, nejde o pull. Nezáleží na tom, kdo kartičku fyzicky přesunul.
Bez možnosti práci nepřevzít neexistuje pull. Existuje pouze zdvořile zabalený push.
Více o rozdílu mezi řízením pomocí sprintů, skutečným flow a pouhým chaosem popisujeme v článku Potřebujete opravdu sprinty? Možná je pro vás vhodnější flow tým.
Proč Definition of Ready často nestačí
Definition of Ready může být užitečná týmová dohoda. Pomáhá například vyjasnit, jaké minimum informací má položka obsahovat před plánováním nebo zahájením práce.
Problém nastává, když se z ní stane administrativní brána.
Typická Definition of Ready může požadovat:
- vyplněný popis,
- acceptance criteria,
- odhad,
- identifikované závislosti,
- přiřazeného vlastníka,
- schválený design.
Všechna pole mohou být vyplněná a všechny checkboxy zaškrtnuté. Přesto mohou zůstat nezodpovězené podstatné otázky:
- Kdo a kdy udělá otevřené business rozhodnutí?
- Je spolupracující tým připraven dodat svou část?
- Máme dostupnou potřebnou specializaci?
- Dokážeme výsledek integrovat, otestovat a nasadit?
- Máme na další práci prostor, nebo jen dalšího volného vývojáře?
Checklist kontroluje hlavně vlastnosti ticketu. Pullability kontroluje vztah mezi položkou, týmem a celým pracovním systémem.
Je také dobré připomenout, že Scrum Guide žádnou povinnou Definition of Ready nepředepisuje. Pracuje s průběžně zpřesňovaným Product Backlogem a se společným výběrem práce pro Sprint. Definition of Ready je užitečná technika, nikoliv povinný artefakt Scrumu.
Připravenost není absolutní vlastnost
Stejná položka může být pullable pro jeden tým a nepullable pro jiný.
Zkušený produktový tým může bezpečně převzít relativně stručně popsanou změnu, protože dobře zná doménu, zákazníky, technologii i klíčové stakeholdery. Nově sestavený tým nebo externí dodavatel může ke stejné položce potřebovat podstatně více kontextu.
Rozdíl nemusí znamenat, že je jeden tým agilnější než druhý. Liší se jejich znalosti, oprávnění, schopnosti a prostředí.
Jednoduchý test pullability: pět otázek
Před převzetím práce doporučuji společně projít pět otázek. Nemají sloužit jako další dlouhý formulář. Jejich účelem je otevřít krátkou a konkrétní diskusi nad skutečnou položkou.
1. Víme, proč má práce vzniknout?
Tým by měl rozumět problému, příležitosti nebo očekávané změně. Nemusí znát celou obchodní strategii, ale měl by vědět:
- komu má výsledek pomoci,
- co se má změnit,
- proč je změna nyní důležitá,
- podle čeho poznáme, že měla smysl.
Věta „stakeholder to chce“ obvykle nestačí. Bez porozumění účelu tým neumí dobře rozhodovat o rozsahu, alternativách ani přijatelných kompromisech.
Představme si požadavek:
Přidejte do zákaznického portálu nové tlačítko pro změnu doručovací adresy.
Tým může implementovat přesně popsané tlačítko. Neví ale, zda je cílem snížit počet telefonátů na podporu, zrychlit zpracování objednávky nebo splnit regulatorní povinnost. Každý z těchto cílů může vést k jinému řešení.
V článku Requirement, Feature, Story: proč nestačí mít hierarchii v Jira ukazujeme, proč jednotlivé úrovně backlogu nemají pouze obsahovat různě velké kopie stejného zadání. Každá úroveň by měla přidat nové porozumění nebo rozhodnutí.
2. Rozumíme dostatečně tomu, co má být výsledkem?
Pullable položka nemusí být kompletně specifikovaná. Tým ale potřebuje sdílené pochopení očekávaného výsledku.
Typicky by měl znát:
- hranice rozsahu,
- důležité příklady nebo scénáře,
- podmínky přijetí,
- způsob ověření výsledku,
- hlavní předpoklady a známá rizika.
Cílem není odstranit veškerou nejistotu. V komplexní produktové práci to ani není možné.
Pullable neznamená bez nejistoty. Znamená dostatečně jasné, abychom mohli nejistotu vědomě a řízeně zpracovat.
Jestliže například nevíme, která ze dvou technických variant bude fungovat, může být správným krokem krátký experiment. V takové situaci ale tým nepřebírá celou Feature jako závazek. Přebírá experiment s jasnou otázkou, časovým omezením a očekávaným rozhodnutím.
3. Je položka dostatečně malá, aby mohla skutečně protéct?
Velké položky mají tendenci skrývat nejasnosti. Čím déle bude práce trvat, tím více může obsahovat neodhalených závislostí, předání, rozhodnutí a příležitostí ke změně priority.
Při posuzování velikosti se neptejte pouze na počet Story Points. Zajímejte se také o to:
- kolik různých výsledků položka obsahuje,
- kolik specializací a týmů se na ní musí podílet,
- kolik předání pravděpodobně vznikne,
- zda lze část výsledku ověřit dříve,
- jak se velikost srovnává s obvyklým cycle time týmu.
Story s názvem „Implementovat samoobslužnou změnu adresy“ může ve skutečnosti obsahovat frontend, backend, ověření identity, napojení několika systémů, audit, notifikace a změnu procesů podpory. Formálně jde o jednu položku. Prakticky je to malý projekt.
Lepší první inkrement může být například:
Zákazník může změnit doručovací adresu u objednávky, která ještě nebyla předána dopravci.
Tato část stále přináší použitelný výsledek, ale omezuje počet scénářů a vytváří dřívější možnost ověření.
4. Může tým položku dokončit, ne jen začít?
Toto je často nejdůležitější otázka celého testu.
Organizace bývají velmi dobré v zahajování práce. Mají seznam priorit, planningy, roadmapy a lidi, kterým lze úkol přidělit. Výrazně méně pozornosti věnují podmínkám pro dokončení.
Před převzetím práce si ověřte:
- Má tým potřebné schopnosti a kompetence?
- Jsou dostupná prostředí, přístupy a testovací data?
- Je jasné, kdo rychle rozhodne otevřené otázky?
- Jsou spolupracující týmy připravené?
- Je možné výsledek integrovat a ověřit?
- Dokáže tým splnit svou skutečnou Definition of Done?
Samotné zaznamenání závislosti nestačí. Pole „Dependencies“ může být správně vyplněné, ale jestliže druhý tým nemá práci ve svém plánu, závislost není řízená. Je pouze zdokumentovaná.
Stejný princip platí pro rozhodnutí. Poznámka „čeká se na potvrzení businessu“ není plán odstranění překážky. Potřebujeme vědět, kdo rozhodne, do kdy a co se stane, pokud odpověď nepřijde.
5. Má systém kapacitu a dovoluje týmu práci opravdu převzít?
Poslední otázka se už netýká samotného obsahu položky. Týká se pracovního systému.
Story může být jasná, malá a dokončitelná. Přesto by ji tým neměl zahájit, pokud je jeho WIP limit vyčerpaný nebo se předchozí práce hromadí v testování.
Typická situace vypadá takto:
- vývojář dokončil programování a čeká na testování,
- testování má frontu několika položek,
- vývojář proto zahájí další story, aby nebyl „nevytížený“,
- rozpracovanost roste, ale nic se nedokončuje rychleji.
Z pohledu lokálního využití člověka se nové zahájení práce může zdát racionální. Z pohledu celého systému ale pouze přidává další čekající položku.
Ověřte proto:
- Je v systému dostupná kapacita podle dohodnutých WIP pravidel?
- Je položka skutečně další v pořadí?
- Existují jasná pravidla pro urgentní práci?
- Může tým říci „ještě ne“?
- Je priorita dostatečně stabilní pro realistický horizont dokončení?
Pokud se práce pravidelně přidává až po zahájení sprintu nebo jiného závazku, souvisí problém také se sprint overcommitmentem. Tým může původní plán vytvořit realisticky, ale systém ho následně zaplaví dalšími prioritami.
Tři možné výsledky testu
Test pullability nemusí skončit pouze odpovědí ano nebo ne. V praxi se osvědčují tři výsledky.
Pullable
Tým rozumí účelu a výsledku, položka je přiměřeně malá, podmínky dokončení jsou splněné a v systému existuje skutečná kapacita.
Pullable s vědomým rizikem
Existuje významná nejistota, ale tým o ní ví, umí ji řídit a vědomě se rozhodl ji přijmout.
Například externí služba zatím nemá garantované všechny parametry. Tým však může vytvořit adaptér, použít testovací simulaci a má dohodnuté datum ověření. Riziko je viditelné, má vlastníka a existuje plán reakce.
Not pullable
Chybí zásadní rozhodnutí, kapacita, potřebné schopnosti, možnost dokončení nebo minimální společné pochopení výsledku.
Označení „not pullable“ nemá být trestem pro Product Ownera ani důkazem, že analytik odvedl špatnou práci. Je to informace, kam zaměřit další přípravu.
Někdy bude potřeba položku zmenšit. Jindy získat rozhodnutí, připravit prostředí, koordinovat závislost nebo nejprve realizovat experiment.
Pullability na různých úrovních práce
Pullability se netýká jen stories. Podobný test lze použít na různých úrovních řízení práce, kritéria se však musí přizpůsobit typu rozhodnutí.
Story nebo malá týmová položka
Hlavní otázka zní:
Může tuto položku jeden tým v krátkém čase dokončit a ověřit?
Feature nebo větší ucelený výsledek
Zde se ptáme:
Máme dostatečně vyjasněný výsledek, první smysluplné inkrementy a podmínky pro koordinované zahájení dodávky?
Feature není pullable jen proto, že ji týmy rozložily na několik stories. Pokud stále chybí zásadní business rozhodnutí, architektonická kapacita nebo připravenost okolních systémů, vznikl pouze detailnější seznam nepřipravené práce.
Iniciativa nebo investice
Na vyšší úrovni bude otázka znít:
Rozumíme očekávanému dopadu a máme rozhodovací rámec, který dovolí investici bezpečně pustit do delivery systému?
Jednotlivé úrovně proto nemají používat jeden univerzální checklist. Story, Feature a strategická iniciativa představují jiný druh rozhodnutí. Podrobněji tento rozdíl rozebírá článek Tři úrovně řízení práce: investice, doručení, inkrement.
Typické chyby
1. Ready se zamění za pullable
Organizace předpokládá, že vyplněný popis, acceptance criteria a odhad dokazují připravenost. Nekontroluje však kapacitu, závislosti ani možnost dokončení.
2. Vznikne dvacetibodový checklist
Původně užitečná diskuse se promění v administrativní formulář. Lidé postupně najdou způsob, jak všechna kritéria formálně splnit, aniž by se zvýšila kvalita porozumění.
Pět otázek má sloužit jako podpora rozhovoru, ne jako další procesní gate.
3. Tým se snaží odstranit všechnu nejistotu
Snaha udělat práci dokonale připravenou může vést k dlouhé analýze, podrobným specifikacím a mini-waterfallu před vývojem.
Nejistota je v produktové práci normální. Musí však být viditelná a odpovídat typu položky, kterou tým přebírá. Pokud potřebujeme získat znalost, pullneme experiment nebo discovery práci. Nepředstíráme závazek dodat celý výsledek.
4. Závislost se pouze zapíše
Ticket obsahuje odkaz na jiný tým, ale nikdo neověřil jeho prioritu, kapacitu ani termín. Zdokumentovaná závislost se následně začne považovat za vyřešenou závislost.
5. Volný člověk se zamění za volnou kapacitu systému
Vývojář může začít další práci, zatímco předchozí položky čekají na testování, review nebo nasazení. Lokálně se zvýší vytížení, ale celkový čas dokončení se prodlouží.
6. Tým nesmí říci „ještě ne“
Leadership deklaruje pull systém, ale zároveň očekává okamžité zahájení každé nové priority. Tým rozhoduje pouze o tom, kdo práci provede, nikoliv zda ji systém může bezpečně přijmout.
7. Jedna pravidla platí pro všechny typy práce
Stejná Definition of Ready se používá pro produktovou story, produkční incident, technický dluh, experiment i velkou Feature. Kritéria jsou následně buď příliš obecná, nebo zbytečně těžkopádná.
8. Stav Ready se už znovu neověřuje
Položka mohla být připravená před měsícem. Mezitím se změnila priorita, technologie, regulatorní podmínka nebo dostupnost spolupracujícího týmu.
Pullability se má posuzovat co nejblíže okamžiku skutečného převzetí práce.
Jak začít v praxi
Nedoporučuji začínat novou směrnicí, změnou Jira workflow ani vytvořením povinného pole Pullability Status. Začněte malým experimentem nad skutečnou prací.
1. Vyberte pět nejbližších položek
Vezměte položky, které má tým pravděpodobně převzít během několika následujících dnů. Nemá smysl detailně kontrolovat celý backlog na několik měsíců dopředu.
2. Položte pět otázek
- Víme, proč má práce vzniknout?
- Rozumíme dostatečně očekávanému výsledku?
- Je položka dostatečně malá?
- Můžeme ji dokončit, ne jen začít?
- Má systém kapacitu a můžeme práci opravdu převzít?
3. Použijte tři jednoduché výsledky
- Zelená: pullable.
- Oranžová: pullable s vědomým rizikem.
- Červená: not pullable.
U oranžové položky musí být jasné, jaké riziko přijímáte. U červené zapište jednu hlavní příčinu, nikoliv dlouhý seznam všech nedostatků.
4. Sledujte opakující se příčiny
Po dvou až třech týdnech se podívejte, proč položky nejčastěji nejsou pullable.
- Chybí účel nebo priorita: problém produktového rozhodování.
- Položky jsou příliš velké: problém slicingu a refinementu.
- Čeká se na externí týmy: problém závislostí a koordinace.
- Chybějí prostředí nebo data: problém delivery infrastruktury.
- Není kapacita: problém WIP a řízení toku.
- Tým nesmí odmítnout nový start: problém leadershipu a governance.
Tím se z pullability stane diagnostický nástroj. Neřešíte jednotlivé tickety izolovaně, ale začnete vidět systémové příčiny.
5. Ověřte dopad na toku práce
Nesledujte jen počet položek označených jako Ready. Zajímejte se, co se s prací děje po zahájení.
- Kolik času položky tráví v blokovaném stavu?
- Jak často se po zahájení zásadně mění scope?
- Kolik položek se vrací k doplnění?
- Jak dlouho se čeká na rozhodnutí nebo externí tým?
- Klesá rozpracovanost?
- Zkracuje se cycle time?
Metriky vybírejte podle příčiny, kterou se snažíte ovlivnit. Neexistuje jedna univerzální sada pro každý tým. Praktický návod nabízí článek Jak vybrat týmové KPIs: 5 situací a 3 metriky pro každou z nich.
Kdy už problém není jen v připravenosti backlogu
Test pullability někdy odhalí, že týmový refinement funguje poměrně dobře. Skutečná překážka leží mimo tým.
Například:
- stakeholdeři nedokážou rozhodovat o prioritách,
- každý manažer může do systému vložit urgentní práci,
- týmy mají příliš mnoho paralelních závazků,
- závislosti se koordinují až po zahájení,
- specializované role jsou dlouhodobým úzkým místem,
- plánování optimalizuje vytížení lidí místo dokončování výsledků.
V takovém případě další úprava Definition of Ready nepomůže. Potřebujete se podívat na celý tok práce, WIP, pravidla prioritizace a rozhodovací pravomoci.
Právě na tyto situace je zaměřený Flow Accelerator: krátký praktický zásah pro týmy a organizace, kterým dodávka drhne kvůli vysoké rozpracovanosti, nejasným pravidlům toku nebo skrytým bottleneckům. Pokud zatím není jasné, zda je hlavní problém ve flow, prioritách, rolích nebo leadershipu, vhodnějším prvním krokem může být Agile Reality Check.
Další praktické checklisty, mikrokurzy a toolkity k práci s tokem, předvídatelností a kvalitou postupně doplňujeme také v Agile Brothers Academy.
Závěrečné shrnutí
Položka není připravená jen proto, že má vyplněný popis, acceptance criteria, odhad a stav Ready.
Je pullable teprve tehdy, když:
- tým rozumí jejímu účelu,
- má dostatečně jasnou představu o výsledku,
- položka je přiměřeně malá,
- tým ji dokáže dokončit, nejen zahájit,
- systém má skutečnou kapacitu,
- tým může o převzetí práce vědomě rozhodnout.
Definition of Ready může být užitečná. Nestačí ale kontrolovat pouze ticket. Potřebujeme kontrolovat také schopnost týmu a podmínky celého pracovního systému.
Nejlepší otázka při plánování proto není: „Je story Ready?“ Lepší otázka zní: „Můžeme si tuto práci s čistým svědomím vzít a dovést ji k výsledku?“
Odpověď často odhalí víc o kvalitě vašeho delivery systému než další stránka procesních pravidel.