Jak nepsat požadavky v Agile

Jak správně psát požadavky v Agile firmě? Psaní požadavků je z pohledu byznys agility klíčová znalost. Agile sice preferuje komunikaci a spolupráci před byrokracií, ale neznamená to, že najednou není třeba nic psát.

Základní dovedností produktového vlastníka je vycítit, jak správně rozdělit požadavek na menší celky, poté najít správnou míru detailu zápisu a zároveň si během celého procesu udržet přehled.

Při spolupráci s agilními týmy naši mentoři pokaždé začínají produktovým backlogem. Právě ten vypovídá o skutečném pochopení agilních principů, jež jsou důležité, bez ohledu na to, jak teologicky / filozoficky / ideologicky nebo neprakticky na první pohled vypadají.

Se zaváděním Agile se firmy často trápí samy bez pomoci. Při tom vzniká množství nepochopení, které končí ve formě „našich“ pravidel aplikovaných slepě nebo na sílu. Toto nepochopení je později příčinou nefunkčního agilního prostředí, což následně vede k frustraci a odchodu lidí.

Týmy mají tendenci tvrdit, že dokumentace a psaní požadavků je proti samotným principům Agile. Spíše to však vnímají z pohledu zvýšené byrokracie.

Porozumění, jak správně psát požadavky v Agile, však výrazně zvyšuje efektivitu a rychlost týmu. Jen je třeba najít správnou míru.

V tomto a následujících článcích vám přineseme pohled z praxe na typické chyby, s nimiž se běžně potkáváme.

Doufáme, že vám tyto články ulehčí váš začátek na cestě ke smysluplné agilitě.

Nechejte procesu, co je procesní

Typickou chybou v backlogu jsou požadavky, které popisují procesní kroky. Není pravda, že vše, co má tým udělat, musí být v backlogu.

Produktový backlog nemá v názvu produktový náhodou. Backlog by měl popisovat funkčnost, nebo ještě lépe výsledek, z pohledu uživatele.

Příklad: Klient vytváří webou aplikaci, která má umožnit řízení zaměstnanců v provozu. Pro správný management provozovky potřebuje přehled o odpracované pracovní době.

Produktový vlastník má v produktovém backlogu ohledně této potřeby následující požadavky:

User Story 1: Report "Časový výkaz"
Jako zákazník potrebuji vidět časový výkaz zaměstnanců, abych dokázal vyhodnotit náklady.


User Story 2: Akceptace nového reportu
Jako stakeholdeři chceme akceptovat nový report Časový výkaz, abychom týmu dali zpětnou vazbu.

Podrobnější analýzou backlogu jsme zjistili, že se tento vzorec v backlogu nachází víckrát. Product owner se naučil nesprávně dělit požadavky. Ve snaze vyhovět procesu a týmu, jehož výstupy musí projít formálním schválením, raději zapsal User Story 2 ve snaze, „aby se na to nezapomnělo“.

Co je na tom špatně

Z dlouhodobého pohledu je špatně několik věcí:

1. Můžeme očekávat minimálně dvakrát více položek v backlogu.
2. Čas na jejich přípravu by produktový vlastník měl raději investovat do komunikace s klientem, výběru dalšího správného požadavku, jeho rozbití na menší, prioritizaci a nakonec i přípravě a zápisu. Hej, produktový vlastníku, nemáš čas?
3. Snížení přehlednosti produktového backlogu právě kvůli počtu požadavků.
4. Menší přehlednost ztěžuje týmu výběr správného požadavku.
5. Závislost požadavků mezi sebou – produktový vlastník musí sledovat, kdy bude co hotové, a nezapomenout na to.
6. Odhadování se stává noční můrou. Jak máme jako tým odhadnout náročnost akceptace byznysem.
7. Obtížné plánování sprintů. Víme, co byznys stihne akceptovat?
8. Znekvalitnění metrik – nedá se například věřit rychlosti, protože akceptaci nedělá tým a nedokáže tedy ovlivnit její dokončení.
9. Zkomplikování organizačních vztahů. Zažili jsme i takovou situaci, která na první pohled nemá velký základ v psaní požadavků. Akceptaci provádí více lidí mimo tým (v user story je zápis „stakeholdeři“). Kdo je bude koordinovat? Máme si o tom jako tým vést evidenci na svojí tabuli jako úkol? Komu ho přiřadit? Kdo má tyto úkoly přiřazovat, zvlášť když je to lidem pod jiným vedoucím?
10. Prodloužení času dodávky. Dodatečné aktivity vedou k prodloužení času, který by se dal investovat lépe.

Jak psát požadavky správně

Pokud akceptaci dělají lidé mimo váš agilní tým, doporučujeme dát akceptaci zvlášť mimo vaši Kanban tabuli.

V tomto případě může například existovat ještě jedna Kanban tabule Program Kanban, kde můžete sledovat stav rozpracovanosti požadavků a přiřadit sloupce odpovědným osobám.

Po této tabuli „plavou“ požadavky. Levé sloupce po Portfolio Backlog obsahují požadavky, které stakeholdeři spolu s produktovým vlastníkem, byznysem, architekty a analytiky připravují na implementaci.

Vybraný, schválený a připravený požadavek přeřadí produktový vlastník do sloupce Backlog, což indikuje, že ho převzal agilní tým.

Produktový vlastník přesune požadavek do stavu Implementing v momentě, kdy je na týmové Scrum tabuli zařazená do některého sprintu a rozdělená na implementační úkoly přiřazené jednotlivým členům týmu.

Pozn. Dobré nástroje na projektový management dovolují automatizaci změny stavů. V ScrumDesk aplikaci jsme se snažili měnit stavy automaticky i bez dodatečné konfigurace.

Stakeholdeři, resp. byznys, čekají na signál od týmu, že dokončil požadavek. V týmové Scrum tabuli jsou v tomto případě všechny podúkoly v DONE a samotný požadavek (user story) se na Program Board posune do stavu Validating on staging / In Progress.

Požadavek ve sloupci Validating on staging / In Progress je pro stakeholdery signálem pro spuštění akceptace.

Díky Program Kanban boardu mají lepší přehled o stavu požadavků jak stakehodleři, tak agilní tým. Každý se soustředí na svoje a má tak detailní informace, jak potřebuje.

Jiné příklady

Tento vzorec nacházíme i v jiných případech, například:

1. Review požadavky
2. Analýza požadavků
3. Nacenění
4. UX design
5. Návrh architektury
6. Feedback dodavatele
7. Nasazení do produkce
8. Testování
9. Customer experience (CX)
10. Zkušební provoz

Jak se naučit psát požadavky v Agile

Chcete se naučit psát požadavky v Agile týmu správně? Napište nám a zapojíme vás do tréninku Perfektní Product Owner nebo do programu ScrumDesk Product Ownership Academy zaměřeného na produkty účastníků, nejen na všeobecné příklady.