Jedna z nestandardních situací, na kterou jako Product Owner narazíte, která ovšem ve finále není až tak mimořádná – vlastně je docela častá, je situace, kdy některý z requestorů na realizaci svého požadavku „prostě trvá“. Škála podob takové vytrvalosti je potom velmi různá. Od prostého připomínání se až po méně či více důrazný a nepříjemný nátlak. Podobně široká je řada možných důvodů, proč daný requestor svůj požadavek potřebuje nejlépe ihned, mimo jakoukoliv prioritizaci.

Úspěšné vypořádání se s takovou situací potom zahrnuje několik aktivit. V první řadě je potřeba se s požadavkem vypořádat, nějakým způsobem jej vyřešit, ať už ke spokojenosti nebo nespokojenosti requestora. Druhou aktivitou, z pohledu vašeho úspěšného fungování v daném prostředí minimálně stejně významnou, je potom řízení vztahu s daným requestorem. Neměl by odcházet s pocitem porážky ve chvíli, kdy jeho požadavek odmítneme na základě objektivních důvodů, ale neměl by zažívat ani silný pocit vítězství ve chvíli, kdy se mu jeho požadavek skrze vás podařilo zařadit do sprint backlogu. Měl by si být vědom, že na vaší straně to bylo za cenu ústupků a že podobné řešení není standardní.

Neexistují výjimky z procesu

Jak tedy zprocesovat požadavek, který na vašem stole přistál a za vašimi zády stojí jeho requestor a výhružně podupává nohou při čekání na odpověď, zda jej zaplánujete do dalšího sprintu backlogu. V první řadě je potřeba si uvědomit, že při správném nastavení procesu řízení požadavků a jejich prioritizace není žádný prostor pro výjimky. Ke zpracování takového požadavku je potřeba přistoupit úplně stejně jako k řešení všech dalších požadavků, které řešíte. Žádné výjimky.

Pokud se jedná o drobnost a máte dostatečnou kapacitu, tak zpravidla prostor pro realizaci takového požadavku najdete a můžete jej zaplánovat (samozřejmě záleží na týmu, prioritách ostatních úkolů, ale pokud řešíte požadavek, jehož realizace reálně zabere 2 MDs a celková kapacita vašeho týmu ve sprintu je třeba 30 MDs, tak si troufám tvrdit, že kapacitu pro jeho odbavení najdete, aniž byste narušili termíny realizace komplexnějších úkolů. Mimochodem, tím jsem ťuknul další dvě zajímavá témata – prioritizace malých úkolů v backlogu a stanovování odhadů pracnosti – v man days vs. story pointech).

Pokud se jedná o větší úkol (již prošel groomingem, je vyjasněný a máte jeho nacenění, to je podmínka pro jakoukoliv další práci), tak dalším krokem je určení jeho priority. To se i v případě netrpělivých requestorů provádí stejným procesem jako prioritizace dalších user stories. Pokud z prioritizace vyjde vysoká priorita požadavku, tak vašemu netrpělivému requestorovi se na tváři může rozlít blažený výraz a odchází. Win-win situace pro všechny. Vy jste dodrželi standardní pravidla a requestor dostal co chtěl.

Mimořádná řešení

V případě, kdy priorita požadavků není tak vysoká, aby mohla být zaplánována do chtěného sprintu, přichází na řadu několik dalších možností řešení. První je reprioritizace požadavků, které jsou v backlogu nad tímto requestem. Reprioritizace je poměrně standardní věc a měla by se dělat pokaždé, když se v backlogu objeví něco jiného. De facto posunutí každého požadavku před jiný je situace, kdy musíte zvážit nejen prioritu požadavku, který posouváte výš, ale i prioritu prvního požadavku v pořadí, který předsunutím jiného požadavku odsunete na horší pozici.

Management stakeholderů, nastavení jejich očekávání a spolupráce s nimi je jedním z hlavních úkolů product ownera. Je to o jasně nastavených pravidlech, transparentním backlogu a komunikaci. Další ze situací kdy vlastník chce realizovat svůj požadavek v nereálných termínech. Tato situace často navazuje na předchozí problém, kdy požadavek který získá nejvyšší prioritu a i tak tlačí na termín, který prostě není reálný. Jak postupovat v takovém případě si povíme v samostatném článku.

Další témata pro budoucí články:

  • kvantifikace přínosu user stories – určení priority
  • prioritizace malých úkolů v backlogu
  • estimace pracnosti – man days vs. story points
  • požadavek na realizaci v nereálných termínech
  • edukace agilního přístupu – agilní hry pro vzdělávání byznysu