Miksi Scrum Master tarvitsee tilastoja ja mittareita? Ensinnäkin tarkistaakseen, ovatko hänen työskentelymenetelmänsä tulosten ennustettavuuden ja tiimin tehokkuuden parantamiseksi tehokkaita. Mutta myös seuratakseen, miten heidän toimintansa vaikuttaa Kehitystiimiin. Eli miten ne muokkaavat työntekijöiden käyttäjäkokemusta (UX). Joten tässä artikkelissa esittelemme tilastoja ja mittareita, joita Scrum Masterin tulisi seurata.
Scrum Masterille tärkeät tilastot ja mittarit – sisällysluettelo:
- Kehitystiimin työn tulosten mittaaminen
- Työntekijöiden käyttäjäkokemuksen seuraaminen Kehittäjät
- Yhteenveto
Kehitystiimin työn tulosten mittaaminen
Yleisimmät tilastot ja mittarit, joita Scrum Masterin tulisi seurata, ovat ne, jotka kuvaavat tehtävien suorittamisen vauhtia ja virtausta. Näitä ovat Burnup Chart, Burnup Chart ja Cumulative Flow Chart. Nämä mittarit arvioivat sekä tuotekehitystä että tiimin tehokkuutta. Kukin mahdollistaa näiden asioiden tarkastelun eri näkökulmista, joten on hyvä idea esittää ne yhdessä. Ne ovat käteviä työkaluja edistymisen arvioimiseen eri mittakaavoissa, Sprintin aikana sekä koko tuotekehitysprosessin aikana.

Burndown Chart
Burndown chart näyttää Scrum Masterille ja Kehitystiimille, kuinka paljon työtä on tehty ja kuinka paljon on vielä jäljellä. X-akseli näyttää jäljellä olevan ajan työn loppuunsaattamiseen. Y-akseli näyttää jäljellä olevan työn määrän, joka oli suunniteltu Sprint Backlogissa tai Product Backlogissa.
Tämä kaavio myös auttaa määrittämään Kehitystiimin nopeuden, jolle omistamme myös erillisen artikkelin. Tässä mainitsemme vain, että se on keskimääräinen määrä työtä, joka on tehty yhden Sprintin aikana.
Tämä yksinkertainen työkalu mahdollistaa Scrum Masterille nähdä kuinka tehokkaasti tiimi työskentelee. Se auttaa myös vastaamaan kysymyksiin:
- Mikä osa työstä on jo suoritettu?
- Kuinka monta tehtävää on vielä jäljellä?
- Kuinka kauan tuotteen kehittäminen vie?
Burndown Chartia käytettäessä Scrum Masterin on pidettävä mielessä, että se ei ole ainoa työkalu tiimin edistymisen tilastolliseen arvioimiseen. Se toimii parhaiten projekteissa, joissa työn laajuus on kiinteä ja tunnettu. Se ei toimi hyvin erittäin innovatiivisten ratkaisujen luomisessa uuden asiakkaan kanssa. Silloin koko projektin aikana tehtävän työn määrä – eli Product Backlogin sisältö – voi muuttua merkittävästi projektin aikana, mikä tekee Burndown Chartin käytöstä vaikeaa.
Burnup chart
Burnup Chart on Burndown chartin käänteinen versio, jota käsiteltiin edellä. Tässäkin Y-akseli näyttää jäljellä olevan työn määrän. X-akseli puolestaan näyttää valmistumisen ajan, joka on ilmaistu joko Sprinttien määränä tai päivämäärinä.
Kuitenkin Scrum Master käyttää Burnup Chartia hieman eri tarkoitukseen. Tämä johtuu siitä, että se ei ainoastaan auta mittaamaan tuotteen edistymistä ja tiimin edistymistä. Tämä mittari arvioi myös, miten työn laajuus projektissa muuttuu ajan myötä. Siksi se toimii hyvin projekteissa, joissa laajuus vaihtelee.
Burnup Chart on myös suunnittelutyökalu, joka tehostuu ajan myötä. Se antaa vastauksia kysymykseen, kuinka paljon työtä Kehitystiimin arvioidaan tekevän seuraavassa Sprintissä.
Cumulative Flow Diagram
Kolmas kaaviotyyppi, joka on erittäin hedelmällinen Scrum Masterin työssä Kehitystiimin kanssa, on Cumulative Flow Diagram. Se analysoi kuinka vakaa Kehitystiimin vauhti ja tuottavuus ovat. Sen akselien asettelu on sama kuin Burnup Chartissa, joten sitä kutsutaan usein sen monimutkaisemmaksi versioksi.
Kuitenkin Cumulative Flow Diagram ei ole vain tarkoitettu määrittämään tietyn ajanjakson aikana suoritetut tehtävien määrä. Se ottaa myös huomioon tehtävien määrän, jotka odottavat vuorossa suorittamista. Tämän ansiosta se mahdollistaa niin sanottujen “pullonkaulojen” diagnosoinnin – prosessin hetket, jotka hidastavat tuotteen luomista.
Tämä erittäin diagnostinen ominaisuus tekee siitä yksi hyödyllisimmistä mittareista Scrum Masterin käsissä. Tämä johtuu siitä, että se mahdollistaa työn uudelleenjärjestämisen siten, että Kehitystiimin voimaa jaetaan eri tavalla ja vältetään seisokit.

Työntekijöiden käyttäjäkokemuksen seuraaminen Kehittäjät
Säännöllinen ja huolellinen tilastojen ylläpito ja analysointi on olennainen osa tehokasta Scrum Masterin työtä. Hänen on kuitenkin pidettävä mielessä ensin kehittäjien työntekijöiden käyttäjäkokemus, eli se, miten he kokevat työn Scrum-tiimissä. Kuitenkin ei ole mittareiden laatu, joka ratkaisee, vaan se, miten Scrum Master käyttää niitä.
Jos tilastot pidetään Scrum-periaatteiden mukaisesti – ne ovat läpinäkyviä, julkisia ja ymmärrettäviä mukana oleville Kehittäjille – ne voivat olla tapa motivoida tiimiä työskentelemään tehokkaammin tai palkita heitä erinomaisista tuloksista. Kuitenkin tilastot voivat toimia myös työkaluna painostaa Kehitystiimiä. Silloin niiden indikaatiot muuttuvat syytösten ja kaunojen generaattoriksi. Ne voivat vaikuttaa tiimin moraalin heikkenemiseen ja tiimityöskentelykäytäntöjen pilaamiseen.
Toinen tärkeä tekijä Kehittäjien työntekijäkokemuksessa, josta Scrum Master, joka työskentelee tilastollisten työkalujen kanssa, on huolehdittava, on ajan hallintatapa. Tämä johtuu siitä, että Scrum Masterin on oltava riittävästi aikaa huolehtia Kehitystiimistä. Tämän vuoksi suurissa projekteissa on syytä harkita lisähenkilön sisällyttämistä Scrum-tiimiin. Hän toimii projektipäällikkönä ja huolehtii mittareista. Tämän ansiosta se helpottaa Scrum Masteria – ja jossain määrin Product Owneria – tehtävistä, jotka häiritsevät häntä työskentelemästä Kehitystiimin kanssa.
Tilastot ja mittarit – yhteenveto
Scrum Master tulisi seurata Kehitystiimin työn kuvaamiseen liittyviä perustilastoja. Niiden taitava tulkinta lisää mahdollisuuksia havaita nopeasti ongelmat tiimin työssä ja reagoida niihin. Kuitenkin tärkeämpää kuin kaavioiden pitäminen on se, mitä Scrum Master tekee niiden kanssa. Heidän ei tulisi käsitellä mittareita työkaluna tiimin arvioimiseen, vaan pikemminkin käyttää niitä hyödyllisinä apuvälineinä tiimin motivoimisessa ja oman toimintatavan diagnosoinnissa. Tämä johtuu siitä, että mittarit ovat vain hyödyllisiä työkaluja, jos ne auttavat helpottamaan tiimin ja tuotteen parantamisprosesseja.
Jos pidät sisällöstämme, liity vilkkaaseen mehiläisyhteisöömme Facebookissa, Twitterissä, LinkedInissä, Instagramissa, YouTubessa.
Caroline Becker
Projektipäällikkönä Caroline on asiantuntija uusien menetelmien löytämisessä parhaiden työnkulkujen suunnittelemiseksi ja prosessien optimoinniksi. Hänen organisatoriset taitonsa ja kyky työskennellä aikarajoitteiden alla tekevät hänestä parhaan henkilön monimutkaisten projektien toteuttamiseen.
Scrum Guide:
- Perustermien, roolien ja käsitteiden sanasto
- Mikä on Scrum?
- Scrum-arvot
- Miten toteuttaa Scrum yrityksessäsi?
- Scrum-tiimi - mitä se on ja miten se toimii?
- Mikä on tuoteomistaja?
- Tuotteen omistajan yleisimmät virheet
- Kuka on Scrum Master?
- Scrum Masterin yleisimmät virheet
- Mitä tilastoja ja mittareita Scrum Masterin tulisi seurata?
- Scrum-kehitystiimi
- Kehittäjien yleisimmät virheet
- Scrum-artifaktit
- Skalointi Scrum
- Sprint Backlog
- Mikä on tuotejonos?
- Mitä ovat käyttäjätarinat?
- Luodaan paras käyttäjätarina INVEST-periaatteella
- Yleisimmät käyttäjätarina-virheet
- Käyttäjätarinan hyväksymiskriteerit
- Arviointi ja tarinapisteet Scrumissa
- Suunnittelupokeri
- Tiimin arviointipeli
- Inkrementin määrittäminen
- Scrum-tapahtumat
- Mikä on burndown-kaavio?
- Burndown-kaavion edut ja haitat
- Kanban-taulut Scrumissa ja Scrumbanissa
- Nopeus Scrumissa - Kehitystiimin nopeus
- Päivittäinen Scrum
- Sprintin suunnittelu
- Sprintin tarkistus
- Mikä on sprintin retrospektiivi?
- Yleisimmät virheet Sprintin retrospektiivissä
- Tuotteen backlogin hoitaminen
- Kuinka luoda ja tulkita burndown-kaaviota?
- Mikä on Sprintti Scrumissa?
- Yhteistyö tuoteomistajan ja Scrum Masterin välillä
- Scrum-tiimin sitoumukset - Tuotetavoite, sprinttitavoite ja valmiuden määritelmä
- Hyvän Scrum Masterin ominaisuudet