Super User Story, User Story a Epics

Jak už jsem psala v minulém příspěvku, User Story musí vytvářet obrázek, být nezávislá, popsatelná, přinášet hodnotu, ohodnotitelná, malá a testovatelná – tedy v originále: Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (zkráceně “INVEST”). Tedy něco, do čeho chcete investovat úsilí a potažmo peníze. Po té co se pokusíte User Story takto definovat, často zjistíte, že potřebujete ještě něco co je širší, co vám drží globální kontext a jednotlivé User Story pohromadě.

K dispozici jsou dva koncepty. První se na User Story dívá jako na entitu, která jde v podstatě donekonečna škálovat a zavádí tak pojem Super User Story – např. Jedu na výlet do Evropy – nebo jen do Německa – nebo jen do Berlína – nebo chci navštívit Berlínské Egyptské museum. Je to takový strom vnořených User Story. Samozřejmě že když to takto rozdrobíme, budou se nám jednotlivé User Story (listy toho stromu) samostatně jen velice špatně prodávat jako super zájezd. Ale na druhou stranu, asi si umíte představit zájezd jen s památkami bez jídla a zájezd all inclusive. A s vaším produktem je to podobné. Také obvykle existuje funkcionalita, kterou můžete oželet a která vlastně není tak prioritní.

Druhý koncept zavádí pojem Epics, kde Epics je něco co jednotlivé User Story zastřešuje – tedy taková souhrnná Super User Story. Epics se ovšem již nepíše ve formátu ‘jako uživatel, chci funkcionalitu, abych dostal business value‘, ale zároveň se jako takový nedá naplánovat do sprintu a ani nechat reálně týmem ohodnotit. Na to je v něm skrytá moc velká dávka nejistoty.

Obě varianty jsou v podstatě podobné, a pomáhají vám udělat si představu o backlogu, ujasnit si co má jakou prioritu a kde je jaká přidaná hodnota.

Burndown grafy

Sice už jsem tu párkrát o burndown grafech psala, ale nedávno jsem rozšířila a opravila původní template, a nakonec, opakování je matka moudrosti, tak ho tu popíšu ještě jednou.

Microsoft Excel Scrum Burndown template najdete zde.

A teď k popisu jednotlivých záložek. Na prvním obrázku je reprezentace product backlogu. V levé části jsou definovány jednotlivé Super User Story a User Story, spolu s ohodnocením. V pravé části je zaznamenán progress na konkrétní User Story v daném Sprintu.

backlog-representation

V další záložce se vlastně všechna data počítají. Jediné co musíte udělat je každý Sprint vyplnit aktuální hodnoty do sloupce C a D – Data from Backlog (Points Remaining Velocity a Actual Points Complete). Zároveň před začátkem projektu nastavit očekávanou rychlost týmu a buffer / očekávaný přírůstek bodů za sprint – sloupce K a L (Plan: Planned Velocity a Planned New Points (Buffer)). Chcete-li sledovat i jak se Vám posouvá datum konce projektu, vyplňte si na začátku projektu i v Planned Date sekci sloupec F (Target Date) a každý Sprint aktuální predikci v Planned Date sekci sloupec E (Projected Completion Date). Všechno ostatní se počítá a kreslí za Vás.

burndown-data

A následují grafy. První z nich sleduje plánovanou rychlost týmu a porovnává ji s aktuálními hodnotami, kterých tým byl schopen dosáhnout.

burndown-velocity-rychlost-graf

Další graf zobrazuje klasický burndown graf rozšířený o predikce kdy očekáváme, že bude projekt hotový. V jednoduchosti řečeno, pokud se pohybujete mezi tečkovanými čárami, běží vše podle očekávání.

burndown-graf

Poslední graf který v souboru najdete Vám ukazuje jak se v čase měnilo předpokládané ukončení projektu.

burndown-project-completion-date

Kdo je to Scrum Master? A kdo Product Owner?

Chcete vědět co je podstatou role ScrumMaster a ProductOwner v rámci Scrum procesu? Tady je stručné shrnutí těchto rolí.

SCRUM MASTER role

ScrumMaster především:

  • pomáhá týmu dosáhnout jeho cílů
  • odstraňuje problémy
  • motivuje tým k lepším výsledkům
  • chrání tým před vnějšími vlivy, které by ho mohly odvádět od soustředěné práce na definovaném cíli

Není to teamleader v klasickém slova smyslu, ale pracuje jako mezičlánek mezi týmem a jakýmkoli rušivým elementem zvenku.

Stará se o to aby Scrum proces byl efektivní a fungoval, má na starosti jeho dodržování, ale zároveň i možnost ho změnit je-li to třeba.

ScrumMaster by měl upřednostňovat koučovací principy, podporovat tým a jednotlivce v jejich rozvoji, být komunikativní, vnímavý a utlumovat případné konflikty v rámci týmu.
ScrumMaster role
ScrumMaster je ten, kdo se stará aby se “kola týmu točila” a který “zametá cestičku”, aby se týmu dobře šlo a pracovalo. ScrumMaster je součástí týmu a měl by být týmu kdykoli k dispozici. Sedí proto v jedné místnosti s týmem.

Funguje-li ScrumMaster dobře, nedá se jeho pozice chápat jako vícenáklad. To že rozpohybuje tým a zajistí tak vyšší efektivitu, kvalitu a motivaci v celkovém rozsahu ušetří vice peněz než ScrumMaster teoreticky stojí.

PRODUCT OWNER role

ProductOwner je vlastníkem produktu. Má na starosti definování vize projektu a její transparentní komunikaci týmu, zákazníkům, firmě. ProductOwner definuje priority, rozhoduje, na které funkcionalitě se bude pracovat dříve, na které později a na které vůbec. Má na starosti Business Value, a také ROI produktu.

ProductOwner je týmu pravidelně a podle potřeby k dispozici, ale na rozdíl od ScrumMastera už s týmem nesedí v jedné místnosti. Tráví dostatek času se zákazníky, aby vstřebal jejich prostředí a dokázal se vždy správně rozhodnout kde je pravá hodnota pro zákazníka.
Product Owner role
ProductOwner neřídí jednotlivé členy týmu ani tým, nemá možnost jim přikazovat, co musí dokončit, jen stanovuje, co se má dělat a v jakém pořadí (priority).

Primárním cílem ProductOwnera je tedy porozumění produktu, zákazníkovi a definice, komunikace, a jasné vysvětlení cíle, kam jdeme, proč a jak. A to jak týmu, tak managementu a zákazníkům. Cíl musí být pro všechny stejný, jazyk, kterým ho komunikuje, bude však odlišný.

Role by neměla být kombinována s rolí ScrumMastera.

Přijďte si zkusit Scrum proces

První akce nově vzniklé Agilní Asociace je workshop: Přijďte si zkusit Scrum.

Vyzkoušejte si Scrum proces formou hry. Seznamte se s lidmi z firem co agilní medody a Scrum proces používají nebo o něm uvažují.

Kdy: Čtvrtek 10.2.2011, 16:00 – 18:00

Kde: CA Technologies CZ, s.r.o.
V Parku 2343/24,
148 00 Praha 4 – Chodov.

Vhodné jak pro ty, co už Scrum znají, tak pro ty, co se s ním teprve chtějí seznámit.

Vstup volný.

Workshop - přijďte si zkusit Scrum proces

Uvažujete-li že přijdete, přihlašte se emailem na info@agilniasociace.cz, na Facebooku, nebo na LinkedIn.

Agilní Asociace je sdružení příznivců agilních metod. Cílem Agilní Asociace je zvýšit povědomí o Agilních metodách řízení, a vytvořit platformu pro sdílení informací a zkušeností z oblasti Agilních metod.

Přijďte se na naše akce podívat, staňte se našimi členy 🙂

Ne – certifikační kurz na Scrum proces?

Krize je pomalu za námi, firmy začínají zase investovat do vývoje nových funkcionalit a produktů a přemýšlí jak být rychlejší, flexibilnější, efektivnější. Jak být lepší než konkurence. A najdou agilní metody a Scrum proces. Ty organizovanější přijdou na to, že potřebují certifikaci, aby jim to opravdu šlo. Co je tedy certifikace v podání Scrum Aliance? Ty, co by čekali nějakou zkoušku či test, musím zklamat. Nic takového certifikace neobsahuje.

Na trhu jsou obecně k dispozici dva kurzy – Certified Scrum Master kurz CSM a Certified Scrum Product Owner kurz CSPO. Oba jsou velmi drahé. Důvodem je to, že takový kurz smí školit jen Certifikovaný trenér, a těch je vzhledem k procesu definovanému Scrum Aliancí relativně málo, a to i v celosvětovém měřítku. Důvodem je starost Scrum Aliance o kvalitu trenérů. Neříkám, že tito trenéři nejsou dobří, jen říkám, že i skvělého (necertifikovaného) trenéra z USA/EU seženete za polovic.

Absolvovala jsem CSPO, a určitě jsem se hodně dozvěděla. A určitě to mělo nějaký přínos. Očekávat ale, že tím že necháte přecertifikovat Scrum Mastera a Product Ownera zajistíte, že budou schopni zavést Scrum, je poněkud přehnané. Oba certifikační kurzy jsou jen dvoudenní kurzy, kde se účastníci něco dozvědí. O certifikaci jejich opravdových znalostí a schopností však nemůže být ani zmínka.

Máte-li pocit, že nevíte na koho z necertifikovaných trenérů a koučů se obrátit, a chtěli byste raději někoho z USA/EU, ráda vám někoho doporučím. Za stejný budget dostanete víc, než certifikací. A nakonec trváte-li na certifikaci, i mezi těmito trenéry jsou velké rozdíly.

No a pro ty, co nesměřují ani k certifikaci, ani nemíří do ciziny, můžu nabídnout své zcela obyčejné české kurzy Scrum procesu a agilních metod, na kterých se dozvíte vše, co potřebujete vědět o agilních metodách a Scrum procesu 🙂

Scrum proces není všemocný

Scrum proces se zdá být jednoduchou náplastí na všechny problémy. Nefunguje Vám tým? Začněte používat Scrum. Jste zahlceni byrokracií, Scrum Vás jí zbaví. Máte málo kvalitní kód, a pořád něco předěláváte? Netestujete? Zákazník není spokojen s tím, co dostal? Scrum má řešení. Tak se pojďme podívat, jak modelové firmy Scrum proces nasazují.

1. Technokrat s.r.o

Ředitel pověří někoho ze zkušenějších teamleaderů či vývojářů v týmu aby zjistili, o co jde. Ten si udělá research. Možná si koupí knihu, ale internet většinou stačí. Všechno umíme a víme, tak začneme. Scrum meeting (daily standup) je zdánlivě jednoduchý a chcete-li dělat Scrum, tak ho prostě musíte mít. Zároveň je ale třeba hledat tool, protože kartičky se používaly maximálně před sto lety. Čím složitější tool je, tím více možností má, ty všechny by se nám mohly hodit. A výsledek je, že tým brblá, že je to všechno k ničemu, proč tráví denně hodinu na meetingu který nic nepřináší, že své práce má dost. Toolu nikdo nerozumí, a Scrum metodě také ne. Navíc produktivita výrazně klesla a zákazník se také netváří nadšeně. Zeptáte-li se na Scrum metodu, dozvíte se, že Scrum my známe a děláme, ale my jsme v tom a tom jiní a pro nás se Scrum proces nehodí a nejde vlastně použít.

2. Developper s.r.o

Vývojáři o Agilních metodách nebo Scrumu nebo XP zaslechli někde od jiných týmů. A líbí se jim to. Nikdo by jim přeci nerozkazoval, nikdo by jim neříkal, co mají dělat a jak. Plánuje přeci tým, a to jsou oni. Cool. Tak začnou jednotlivé praktiky dělat. Většinou to selže v napojení na management. Někdy už na úrovni teamleadera, někdy až u top managementu. Spousta managerů v Čechách je ze staré školy. Bojí se dát své pseudozodpovědnosti na ostatní. Bojí se, že by někdo mohl vědět, co a jak dělají. A co se chystají dělat. A že by vše neměli pevně v rukou. A tak je lepší praktiky Scrumu omezit, okleštit nebo zakázat. Ale ne přímo, oni dělají Scrum, ale vidíte, dali jsme jim šanci, a ono to mělo takové problémy…

3. Korporát a.s.

Scrum proces a agilní metody používají velké firmy okolo nás. Měli bychom ho zkusit. Pošleme týmy na kurzy, project managery na certifikaci Scrum Mastera, a změníme procesy. Týmy tedy začnou, a až do prvního většího problému vše funguje. Pak ovšem project manager zapomene, že má jinou roli, a že jako Scrum Master nesmí měnit plán, nesmí rozhodovat za tým, a rychle se vrátí k osvědčeným metodám řízení projektů, na které byl zvyklý. A celá firma prochází deziluzí. Dalo by se říci, že devět z deseti project managerů se na Scrum Mastery nikdy nepodaří přeučit.

Existují i úspěšné firmy. Velké i malé. Ty většinou pochopili, že Agilní metody a Scrum představují změnu myšlení a přináší změnu kultury firmy. Investovali do kurzů, našli si interního či externího kouče aby jim s transformací pomohl. Vědí, proč změnu chtějí a co od ní očekávají. A vědí, že změna je náročná a vyžaduje hodně každodenní práce na každé úrovni. Taková změna nejde nařídit zhora, ani partyzánsky vybudovat odspodu. Musí propojit celou firmu. Stojí hodně energie. Ale výsledek pak stojí za to.

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

  • Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
  • Lepítka na jednotlivé user story v backlogu.
  • Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
  • Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:
    • Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10
    • Odbory prosadily kratší pracovní týden – 5b
    • Je Den Železničářů, v poledne se jde do hospody – 4b
    • Včera pršelo, vypili jsme moc rumu – 3b

    Ale také třeba takto:

    • Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b
    • Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b
    • V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

  • Větší hodiny měřící délku Sprintu, my jsme zvolili:
    • 5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint
    • 5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

    Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

  • Zákazníka – toho budete pravděpodobně hrát Vy – který může:
    • Chtít vidět další města
    • Změnit svá přání

    Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.

Retrospektiva – kolečko

Jednou z nejdůležitějších agilních praktik je retrospektiva. Cílem je zapojit tým do rozhodování o procesu, nechat je vyjádřit svůj názor, ale hlavně poslouchat se navzájem a pochopit, že ne každý se dívá na věc stejně. Retrospektivou se učíme a uvědomujeme si, co jsme dělali dobře a co ne. Ideální frekvence je po každém sprintu, aby se problémy zbytečně neprohlubovaly a tým měl pravidelnou a častou možnost zhodnotit, jak sprint probíhal z pohledu každého člena.

Jak retrospektiva vypadá? Možností je několik, ale začneme tou nejjednodušší. Tou je takzvané kolečko kdy všichni členové týmu odpoví na dvě základní otázky:

  • Co se mi líbilo, co co jsme dělali dobře a chtěli bychom v tom pokračovat
  • Co se mi nelíbilo a chtěli bychom to změnit

Nezapomeňte, že retrospektiva je o pocitech, jak jsem to viděl já, co jsem si myslel, jak jsem se cítil. Pocit je osobní, neklade si nároky na to být universální pravdou.

V dobře fungujícím týmu se vám může lehce stát, že nikdo v týmu nemá pocit žádných problémů a že tým subjektivně funguje dobře. Potom se popsaný framework rozšiřuje o další oblast:

  • Co by se mohlo vylepšit nebo zefektivnit

Ideální tým ani proces neexistuje, vždy se dá něco najít, jen je to občas těžké si uvědomit.

Začnete-li s retrospektivou, tým začne přemýšlet o věcech jinak, jednotlivý členové budou mít pocit, že má smysl promluvit a zapojit se. Přestanou být pasivními členy čekajícími na úkoly. A jste zase o krůček blíže k vysněnému ‘self-organized‘ týmu.

Extreme Scrum přednáška na Agileee

První ročník konference Agile Eastern Europe 2009 v Kievě je za námi. Agileee měla dobrou atmosféru a spoustu velmi zajímavých lidí. Mám-li vybrat top 2 přednášející, určitě by to byli J.B.Rainsberger se svojí přednáškou “An Introduction to Agile Through the Theory of Constraints” a David Hussman s přednáškou “Agile Journeys: How Did We Get Here and Where are We Going?”. Budete-li mít někde možnost si je poslechnout, určitě to stojí za to.

Moje přednáška je ke shlédnutí níže. Pojednává o speciální case study kdy byl použit Scrum v extrámním prostředí kde se projekty počítají na hodiny. Řešením specifické situace bylo nasazení Scrum metody a půldenního sprintu. Výsledky byly velmi pozitivní.

Část case study byla také publikována na konferenci SoMeT, 8th International Conference on Software Methodologies, Tools and Techniques.

Workshop agilního řízení a metodiky SCRUM

Ráda bych Vás pozvala na workshop agilního řízení a metodiky SCRUM. Workshop pořádáme spolu s Petrem Olmerem, pod záštitou Sun Microsystems a Agilního konsorcia. Kurz je plánován pro začátečníky a mírně pokročilé projektové manažery, produktové manažery, technické ředitele, analytiky, informační architekty a další.

Program kurzu

  • 9:00 – 10:00 Úvod, co jsou agilní metody, proč zavádět Scrum proces, základní terminologie
  • 10:00 – 10:15 Coffee break
  • 10:15 – 11:30 Sprint cyklus, plánování, odhady, ohodnocení úloh, burndowns
  • 11 :30 – 11:45 Vysvětlení Scrum hry
  • 11:45 – 12:45 Přestávka na oběd
  • 12:45 – 13:45 Scrum hra
  • 13:45 – 14:45 Retrospektiva
  • 14:45 – 15:00 Coffee break
  • 15:00 – 16:00 Agilita a psychologie

Více informací na stránkách Agilního konsorcia.