Tag: sprint goal

Sprint Goal – příklad

Jedna z častých otázek je, jak má správně vypadat Sprint Goal. Pojďme se ale nejdřív podívat, co to je. Sprint Goal dává Sprintu smysl. Definuje, čeho chceme dosáhnout. Dává dostatečně silný důvod jeho existence. Proč by měl Product Owner do Sprintu investovat (čas i peníze). Vyplatí se to? Sprint Goal je nedílnou součástí prioritizace Backlogu. Sprint totiž není o dodání jednotlivých položek Backlogu, ale o dosáhnutí cíle Sprintu, tedy Sprint Goalu.

Sprint GoalJak by mohl takový Sprint Goal vypadat? Když o něm slyšíte úplně poprvé, můžete začít třeba Sprint Goalem, který je implementací větší položky Backlogu. Jako je třeba:

Ve Sprint Backlogu potom budou různé položky Backlogu, které tvoří jednotlivé části Dashboardu.

Sprint Goal: “Dashboard“ 

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, seznam nezaplacených faktur.“

Když budete chtít v pochopení Sprint Goalu pokračovat, tak o trochu lepším cílem sprintu je podívat se na to z pohledu business hodnoty a zákazníka a identifikovat tak potřebu, například:

Jednotlivými položkami Backlogu, které pak tým následně vybere z Backlogu budou nejen položky tvořící Dashboard, ale například notifikace, které užitečnosti přehledu o financích můžou přispět i více než samotný dashboard.

Spring Goal: “Zvýšit přehled o financích“

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, notifikace o překročených limitech, notifikace o fakturách po splatnosti“.

Na závěr už zbývá jen přidat příklad, jak by takový Sprint Goal nikdy vypadat neměl. “Dokončit PBI1, PBI2, PBI4 a PBI6 podle definice“. Takový Sprint Goal je příkladem tradičního mindsetu a naprostého nepochopení toho o čem Scrum je. Tedy zaměňuje Sprint Goal za konkrétní specifikaci, a Backlog za ToDo list. Ale ani jedno není Scrum. Scrum je takzvaně ‘purpose driven‘. Tedy řízený nějakým vyšším smyslem, něčím, co přináší hodnotu pro zákazníka. Něčím, do čeho byste byli ochotni investovat svoje peníze, abyste další Sprint zaplatili. A pak další, a další. Něco, čemu věříte natolik, že byste do toho šli.

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂