Když už se rozhodnete odhadovat, odhadujte včas

Spousta týmů dělá stejnou chybu. Odhaduje UserStory – položky Backlogu až na Sprint Planningu. Ale to je už pozdě. Odhady by měly sloužit Product Ownerovi k rozhodnutí, jestli chce do dané funkcionality investovat, nebo jestli je moc drahá a je třeba se nad ní ještě zamyslet, probrat se zákazníkem, či rovnou rozdělit, aby tzv. poměr cena/výkon tedy očekávaná business value/effort vyšlo lépe.

Kdy je tedy správný čas na odhady? Kdykoli tak, abyste dopředu netrávili čas na věcech hluboko v Backlogu, protože ty se ještě určitě změní, ale také abyste v případě potřeby byli schopni doplňující informace včas zjistit, rozmyslet otázky, které padly při hodnocení, a také měli dostatek času rozmyslet, jak na dané položce Backlogu budete jako tým pracovat.

Jak již jsem říkala v úvodu, na Sprint Planningu je již pozdě, protože jakákoli nejasnost Sprint Planning protahuje donekonečna, nebo vede k nepříliš silnému commitmentu typu ‘no tak uvidíme, kolik toho stihneme, stejně nevíme, co že se to přesně má udělat‘.

Obecně mají být odhady součástí Backlog Refinementu, tedy je můžete dělat kdykoli před Planningem. Prakticky to znamená například jako součást Backlog Groomingu v půlce Sprintu, nebo třeba tři dni před začátkem Sprintu na speciálním Estimation meetingu hned po Standupu. Obě dvě řešení zajišťují dostatek času pro opakování estimace nad nejasnými UserStories a obě dvě možnosti vedou ke kratšímu a kvalitnějšímu Sprint Planningu což je rozhodně dobře.

Jsou odhady zbytečné? #NoEstimates

Poslední dobou začíná být hodně populární neodhadovat User Stories. Proč? No když je umíte dobře definovat, stačí spočítat počet User Stories za Sprint a máte velocity. Bez dlouhých diskusí o bodech. Umožňuje vám to jak plánovat reálné množství práce, tak předvídatelnost v rámci produktu. Ono na tom něco je, když totiž umíte dobře definovat User Stories, tak to opravdu stačí. Ale… Co když neumíte, a teprve začínáte se Scrumem, nebo Agilem experimentovat? Jste zvyklí na mandays a hodiny, místo User Stories máte klasické requirementy? Pak je tato praktika téměř nereálná. Relativní jednotky – body – vám totiž pomáhají se spoustou věcí. A to číslo je překvapivě jen vedlejším produktem. Není samo o sobě důležité. Takže proč odhadujeme v bodech? Pomáhá nám to soustředit se na hodnotu pro zákazníka a ne na technické komponenty. Pomáhá nám to zvolit takové řešení, abychom co nejsnadněji dosáhli business cíle. Pomáhá nám to učit se komunikovat napříč departmenty (development, testing, business), a všechna ta diskuse, kterou okolo funkcionalit vedeme, z nás dělá dobrý tým. Učíme se dobře definovat funkcionality tak, aby tomu tým rozuměl. Diskuse okolo ohodnocení nám také pomáhají prioritizovat jednotlivé funkcionality. Ze začátku jsou nekonečně dlouhé. Tak byste radši vzali zkratku a než se naučíte chodit, jezdit na kole, lyžích, bruslích byste raději začali rovnou řídit auto nebo pilotovat letadlo. Teoreticky to možné je, ale v praxi takové zkratky moc nefungují. Takže jestli už nejen děláte Agile, ale jste opravdu Agilní, rozumíte Agilnímu mindsetu, máte pravý samoorganizující Scrum tým, tak je možná na čase to zkusit.

Jestli chcete vědět víc, ráda vás pozvu na konferenci Agile Prague 2014, 15.-16. září, kde o tom bude mluvit Vasco Duarte ve své přednášce “How to improve software project estimates – The #NoEstimates view“.