Jedním z možných způsobů odhadování náročnosti práce v agilním světě jsou Story points. A přesto, že jejich zavedení v týmu přináší spoustu výhod, v některých týmech se jejich zavedení nemusí podařit. V takovém případě, mohou Story points bohužel skončit jen jako jinak pojmenovaná náhrada odhadování v časových jednotkách. Podle čeho se ale rozhodnout? Kde můžeme Story points bez problémů zavést, kde je potřeba se Story points počkat na správný čas a kde to třeba nemusí dávat smysl vůbec? V dnešním článku vám chci nasdílet pár zkušeností, které používám.
Proč se zabývat Story points?
Ikdyž jsou dnes i jiné způsoby, jak se vypořádat s odhady v agilních týmech, podle mého názoru se Story points u řady týmů vyplatí používat. U týmů, se kterými jsem pracoval vedly Story points nejčastěji k těmto přínosům:
- Přesnější odhady než v man days
- Podporují týmovou spolupráci a budování lepší zastupitelnosti v týmu
- Napomáhají lepšímu pochopení zadání napříč celým vaším týmem. Proto je zde i potenciál pro menší chybovost požadavků a méně nečekaných překvapení během vývoje.
T-shape a specializace rolí v týmu
Než budeme pokračovat dál, pojďme se spolu podívat na to, jaká je v začínajících týmech specializace rolí. V řadě týmů, které s agilními přístupy teprve začínají existuje velká specializace rolí. Tým s velkou specializací obsahuje například experta na vývoj backendu, experta na vývoj frontendu, experta na databáze, experta na testování a experta na analýzu požadavků. Členové tohoto týmu jsou skvělí ve svém oboru, ale často nejsou zastupitelní. A tak pokud chcete s vaším týmem plánovat dodávky, musíte plánovat vždy požadavky pro každého specialistu zvlášť.
Jiná situace je většinou ve startupech. V začínajících firmách je celkem běžné, že si jeden člověk musí poradit s úkoly spadajících hned do několika různých specializací najednou. Lidé tak mají například jednu hlavní specializaci, ve které jsou nejlepší a k tomu několik dalších, ve kterých si umí v jednodušších situacích poradit. Tomuto rozložení zkušeností lidí se říká T-shape. Naopak počátečnímu stavu s úplnou specializací se říká I-shape.
Proč se do T-shape v týmu pouštět? Pomůže vám snížit externí závislosti vašeho týmu a zjednoduší vám plánování práce pro váš tým. Váš tým je tak efektivnější a vlastně se i zlevní jeho provoz. Váš tým bude soběstačnější a nebude muset čekat na odbavení svých požadavků v jiných týmech. Bonbónkem navíc je, že vám T-shape usnadní i zavedení Story pointů.
Jiný název pro Man Days?
No a jsme u toho. Pokud je ve vašem týmu pořád silná specializace rolí a vůbec žádný T-shape, pravděpodobně budete muset i nadále každý sprint plánovat každého specialistu zvlášť, aby měli všichni ve sprintu dost práce.
Pokud v tuto chvíli zavedete používání Story points, lidé si pravděpodobně v hlavě převedou Story points zpátky na jednotky času, jak na to byli zvyklí. Tím si vlastně ověří, že má frontendista v týmu dost práce na celý sprint a stejně tak další role. Implementace Story points v tomto případě nepřináší žádnou hodnotu a Story points jsou pak v podstatě jen jinak pojmenované man days.
Jeden odhad za celý tým
Aby nedošlo k omylu, přestože je T-shape ideální předpoklad pro používání Story points, stačí vám pro práci se Story points naprosté minimum. Story points dávají smysl používat ve chvíli, když váš celý tým dokáže odhadnout složitost každého požadavku pomocí jediného čísla za celý tým. Aby to dokázali, musí alespoň rámcově rozumět tomu jak se každý požadavek bude testovat, jak náročná bude úprava frontendu, backendu, jestli bude u požadavku potřeba nějaká integrace s okolními systémy. Také si musí uvědomovat, jaký je rozdíl, mezi relativním a absolutním odhadem.
Neznamená to tedy, že musí všichni detailně rozumět tomu, jaké změny se přesně udělají v kódu. Specializace v týmu pořád existuje, ale není tak striktní, jako byla v minulosti. Stačí když členové týmu pozorně poslouchají kolegy, kteří při refinementu nebo plánování požadavku říkají, co je potřeba v rámci požadavku udělat. Členové týmu tak mohou na základě informací od kolegů porovnat požadavek s nějakým jiným, který už v minulosti řešili. Také budou moci odhadnout, zda jsou zhruba stejně složité, nebo je některý z nich náročnější. Pokud se tým napoprvé na odhadu neshodne, diskuse nad tím, proč se odhady od jednotlivých členů týmu liší je dovede k tomu, že ještě lépe pochopí zadání a nebude je během sprintu čekat nějaké nepříjemné překvapení.
Jsme připraveni na Story points?
Pravděpodobně budete úspěšní se zavedením Story points, pokud:
- existuje ve vašem týmu alespoň částečná zastupitelnost . Například pokud tým nestíhá, tak dokáže vývojář nebo analytik pomoci s testováním, nebo s jinou činností, která jinak není v náplni práce jeho role
- leckdy stačí i to, že členy vašeho týmu zajímá, co je vše potřeba dodat k tomu, aby mohli jako tým úspěšně dodat kompletní požadavek zákazníkovi. Věnují tedy pozornost i tomu, když mluví o práci na požadavku ostatní kolegové. Nepůsobí tedy jen jako subdodavatel v týmu, který neřeší co se s jeho výtvorem stane dál. Naopak, považují cíle týmu za svoje vlastní.
- Tým rozumí tomu, jak fungují relativní odhady (tým umí porovnat, který požadavek je složitější dokončit napříč všemi řemesly).
- V neposlední řadě je potřeba, aby tým rozuměl přínosům. Musí vědět proč se chcete do odhadování pomocí Story points pustit a dávalo jim to smysl.
Pokud není splněn ani jeden z výše uvedených bodů, možná ještě nepřišla ta správná chvíle Story points začít používat. Pokud se o to přesto pokusíte, je zde značné riziko, že si váš tým převede v hlavě hodnotu Story points zpátky na čas. Tento způsob odhadování vám pak nepřinese výsledky.
Jak tedy začít?
Ověřili jste si připravenost vašeho týmu na zavedení Story points? Následujících pár tipů vám může pomoci zlepšit efektivitu týmu i týmovou spolupráci jeho členů. Navíc vám také usnadní zavedení Story points, pokud se pro ně rozhodnete:
1. Některý z jednodušších požadavků si vezme jiný vývojář než kolega, který tyto požadavky řeší obvykle. Zkušený vývojář představí funkčnost a kód kolegovi a před dokončením požadavku mu udělá code review.
2. Vysvětlete v týmu, že jde jen o částečnou zastupitelnost a nejde vám o to, vybudovat armádu univerzálních vojáků. 😊
3. Pokud v některém sprintu váš tým nestíhá testovat, zeptejte se v týmu, zda někdo z analytiků nebo vývojářů pomůže s otestováním požadavku. Vaše zákazníky zajímá hotový požadavek a ne to, který jednotlivec stihl v týmu dodat svůj příspěvek včas.
4. Také můžete zkusit do týmu dočasně zapojit vývojáře (nebo jinou roli), který bere T-shape a zastupitelnost jako běžnou součást svojí práce a inspiruje ostatní.
S motivací týmu vyzkoušet Story points mi často pomohlo dohodnout jejich zavedení nejprve na zkoušku. Dohodli jsme se, že jejich používání za nějaký čas vyhodnotíme a případně uděláme změny. Vrátit se s odhady nazpět na mandays se nakonec rozhodl jen jediný.
Pokud se tedy rozhodnete využít odhadování pomocí Story points ve svých týmech, přeju vám ať vám jejich zavedení splní očekávání. A pokud máte zajímavé zkušenosti, které pomáhají při zavádění Story points vám, neváhejte nám o nich napsat!
Zajímá vás o úspěšné implementaci Story points víc? Můžete využít například našeho kurzu Scrum prakticky – reálné využití a osvědčené postupy.