Scrum Guide | 11. Statistika a metriky, které by měl Scrum Master sledovat

Proč Scrum Master potřebuje statistiky a metriky? Za prvé, aby zkontroloval, zda jsou jeho metody práce na předvídatelnosti výsledků a zlepšování efektivity týmu účinné. Ale také, aby sledoval, jak jejich činnosti ovlivňují Vývojový tým. To znamená, jak formují uživatelskou zkušenost zaměstnanců (UX). V tomto článku představujeme statistiky a metriky, které by měl Scrum Master sledovat.

Statistiky a metriky důležité pro Scrum Mastera – obsah:

1. Měření výsledků práce Vývojového týmu
2. Sledování uživatelské zkušenosti zaměstnanců vývojářů
3. Shrnutí

Měření výsledků práce Vývojového týmu

Nejčastěji používané statistiky a metriky, které by měl Scrum Master sledovat, jsou ty, které popisují tempo a tok vykonávání úkolů. Patří sem Burnup Chart, Burndown Chart a Cumulative Flow Chart. Tyto měření hodnotí jak vývoj produktu, tak efektivitu týmu. Každé z nich umožňuje přistupovat k těmto otázkám z jiného úhlu, takže je dobré je ukazovat společně. Jsou to užitečné nástroje pro hodnocení pokroku na různých měřítkách, během Sprintu i celého procesu vývoje produktu.

Burndown Chart

Burndown chart ukazuje Scrum Masterovi a Vývojovému týmu, kolik práce bylo vykonáno a kolik zbývá udělat. Osa X ukazuje čas zbývající do dokončení práce. Osa Y ukazuje množství práce, které zbývá udělat a které bylo naplánováno v Sprint Backlogu nebo Product Backlogu.

Tento graf také pomáhá určit rychlost Vývojového týmu, které se také budeme věnovat v samostatném článku. Zde jen zmíníme, že se jedná o průměrné množství práce vykonané během jednoho Sprintu.

Tento jednoduchý nástroj umožňuje Scrum Masterovi nejen vidět jak efektivně tým pracuje. Pomáhá také odpovědět na otázky:

• Jaká část práce byla již dokončena?
• Kolik úkolů zbývá dokončit?
• Jak dlouho potrvá vývoj produktu?

Při používání Burndown Chart musí Scrum Master mít na paměti, že to není jediný nástroj pro statistické hodnocení pokroku týmu. Nejlépe funguje u projektů, kde je rozsah práce pevný a známý. Nehodí se dobře pro vytváření velmi inovativních řešení s novým klientem. Poté se množství práce, které je třeba udělat v celém projektu – tedy obsah Product Backlogu – může během projektu výrazně měnit, což ztěžuje použití Burndown Chart.

Burnup chart

Burnup Chart je opakem Burndown chartu, o kterém jsme hovořili výše. I zde osa Y ukazuje množství práce, které zbývá udělat. Osa X naopak ukazuje čas dokončení vyjádřený buď v počtu Sprintů, nebo v datech.

Scrum Master však používá Burnup Chart pro mírně jiný účel. To je proto, že nejen pomáhá měřit pokrok produktu a pokrok týmu. Tato metrika také hodnotí, jak se rozsah práce v projektu mění v průběhu času. Proto dobře funguje u projektů s proměnlivým rozsahem.

Burnup Chart je také plánovací nástroj, který se v průběhu času stává efektivnějším. Poskytuje odpovědi na otázku, kolik práce se odhaduje, že Vývojový tým vykoná v dalším Sprintu.

Cumulative Flow Diagram

Třetí typ diagramu, který je velmi plodný v práci Scrum Mastera s Vývojovým týmem, je Cumulative Flow Diagram. Analyzuje jak stabilní je tempo a produktivita Vývojového týmu. Rozložení jeho os je stejné jako u Burnup Chart, takže je často označován jako jeho složitější verze.

Nicméně, Cumulative Flow Diagram není určen pouze k určení počtu úkolů dokončených v daném časovém období. Zohledňuje také počet úkolů, které čekají v řadě na vykonání. Díky tomu umožňuje diagnostikovat takzvané “úzké hrdla” – momenty procesu, které zpomalují vytváření produktu.

Tato velmi diagnostická funkce z něj činí jeden z nejužitečnějších metrik v rukou Scrum Mastera. To je proto, že umožňuje reorganizovat práci tak, aby se síla Vývojového týmu rozložila jinak a vyhnula se prostojům.

Sledování uživatelské zkušenosti zaměstnanců vývojářů

Pravidelná a pečlivá údržba a analýza statistik je nezbytnou součástí efektivní práce Scrum Mastera. Musí však mít na paměti především uživatelskou zkušenost zaměstnanců vývojářů, tj. způsob, jakým vnímají práci v Scrum týmu. Rozhodující není kvalita metrik, ale způsob, jakým je Scrum Master používá.

Pokud jsou statistiky vedeny v souladu s principy Scrumu – jsou transparentní, veřejné a srozumitelné pro zapojené vývojáře – mohou být způsobem, jak motivovat tým k efektivnější práci nebo je odměnit za skvělé výsledky. Statistiky však mohou fungovat také jako nástroj k vyvíjení tlaku na Vývojový tým. Poté se jejich indikace stávají generátorem obvinění a resentimentů. Mohou přispět k zhoršení morálky týmu a zhoršení týmové spolupráce.

Druhým důležitým faktorem uživatelské zkušenosti zaměstnanců vývojářů, o který se musí Scrum Master pracující s statistickými nástroji postarat, je způsob řízení jejich času. To je proto, že Scrum Master potřebuje mít dostatek času na péči o Vývojový tým. Z tohoto důvodu, v případě velkého projektu, stojí za to zvážit zahrnutí další osoby do Scrum týmu. Ta bude fungovat jako projektový manažer a postará se o metriky. Díky tomu uvolní Scrum Mastera – a do určité míry Product Ownera – od úkolů, které ho odvádějí od práce s Vývojovým týmem.

Statistiky a metriky – shrnutí

Scrum Master by měl sledovat základní statistiky popisující práci Vývojového týmu. Jejich zručná interpretace zvyšuje šanci rychle odhalit problémy v práci týmu a reagovat na ně. Nicméně, důležitější než udržování grafů je to, co Scrum Master s nimi dělá. Neměli by metriky považovat za nástroj k hodnocení týmu, ale spíše je brát jako užitečnou pomůcku při motivaci týmu a diagnostice jejich vlastního způsobu práce. To je proto, že metriky budou užitečné nástroje pouze tehdy, pokud pomohou usnadnit procesy zlepšování týmu a produktu.

Pokud se vám náš obsah líbí, připojte se k naší komunitě pilných včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube.