scrum guide fi

February 2009

Scrum: Developed and sustained by Ken Schwaber and Jeff Sutherland

© 2008-‐2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 2

Alkusanat

Yleistä Scrum perustuu ohjelmistoteollisuuden parhaisiin käytäntöihin, joiden toimivuus on testattu lähes kahden vuosikymmenen aikana tuhansissa kehityshankkeissa. Scrum nojaa empiiriseen prosessiteoriaan. Kuten Jim Coplien on sanonut: “Scrumista on vaikeaa olla pitämättä; käytämme sitä luontaisesti ollessamme selkä seinää vasten.”

Ihmiset

Tuhannet ihmiset ovat avustaneet ja tukeneet Scrumin kehitystä. Suurimman panoksen ovat antaneet ensimmäisten kymmenen vuoden aikana Jeff Sutherland, Jeff McKenna, Ken Schwaber, Mike Smith ja Chris Martin. Scrum esiteltiin ja julkaistiin OOPSLA-seminaarissa 1995. Seuraavien viiden vuoden aikana Mike Beadle ja Martine Devos tekivät merkittäviä lisäyksiä, unohtamatta muita kehitykseen osallistuneita, joiden avulla Scrum on kehittynyt nykyiseen muotoonsa.

Historia Ohjelmistokehityksessä Scrumin historiaa voidaan jo pitää pitkänä. Scrumia kokeiltiin ja kehitettiin ensimmäisen kerran yrityksissä nimeltä Individual Inc., Fidelity Investments ja IDX (GE Medical).

Käännös

Tämä opas on käännetty Ken Schwaberin ja Jeff Sutherlandin alkuperäisestä englanninkielisestä versiosta. Käännöstyön on tehnyt Lare Lekman sekä Arto Eskelinen, Petri Heiramo, Antti Järvinen, Lasse Koskela, Sirkka Lekman, Samuli Ruuskanen, Marko Taipale, Pentti Virtanen, Vesa Vänskä ja Lasse Ziegler.


Tarkoitus

Scrumia on hyödynnetty monimutkaisten tuotteiden kehittämiseen 1990-luvun alusta lähtien. Tämä opas kuvaa, kuinka Scrum toimii tuotekehityksessä. Scrum ei ole tuotekehitysprosessi tai -tekniikka, vaan paremminkin viitekehys, jonka sisällä voi käyttää useita erilaisia prosesseja ja tekniikoita. Scrumin roolina on tuoda esille kehitysmenetelmien todelliset vaikutukset. Näin menetelmiä voidaan säännöllisesti parantaa ja tarjota samalla puitteet, joissa monimutkaisten tuotteiden kehittäminen on mahdollista.

Scrumin teoria

Scrum perustuu empiiriseen prosessinhallintateoriaan. Se käyttää iteratiivis-inkrementaalista (toistavaa-lisäävää) lähestymistapaa ennustettavuuden optimoimiseen ja riskien kontrolloimiseen. Empiirisellä prosessinhallinnalla on kolme tukijalkaa.

Ensimmäinen tukijalka on läpinäkyvyys Läpinäkyvyys tarkoittaa, että prosessin lopputulokseen vaikuttavien tekijöiden tulee olla näkyvissä niille, jotka hallinnoivat lopputulosta. Läpinäkyvyyden lisäksi tekijöiden tulee olla yksiselitteisesti tulkittavissa. Tämä tarkoittaa, että kun tehtävä on valmis, se vastaa tarkastelijoiden ymmärtämää valmiin määritelmää (s. 21).

Toinen tukijalka on tarkastelu Prosessin eri osia tulee tarkastella riittävän usein, jotta haitalliset poikkeamat voidaan havaita. Tulee kuitenkin ottaa huomioon, että jo prosessin tarkasteleminen voi muuttaa prosessia. Pulmatilanne syntyy, kun prosessin tarkastelun tiheys ylittää prosessin sietokyvyn. Onneksi tämä ei näyttäisi olevan ongelma ohjelmistokehityksessä, koska toinen tärkeä tekijä on prosessia tarkastelevien henkilöiden ammattitaito.


Kolmas tukijalka on sopeuttaminen Jos tarkastelija päättelee, että yksi tai useampi prosessin osa on hyväksyttävien raja-arvojen ulkopuolella ja että tämän johdosta syntyvää tuotetta olisi mahdoton hyväksyä, tulee tarkastelijan säätää prosessia tai käytettäviä materiaaleja. Säätäminen tulee tehdä niin nopeasti kuin mahdollista, jotta myöhemmät poikkeamat minimoidaan.

Scrumissa on kolme kohtaa tarkasteluun ja sopeuttamiseen: 1) Päivän Scrum –kokouksessa seurataan edistymistä kohti sprintin eli kehitysjakson tavoitetta ja tehdään sopeutuksia, jotka optimoivat työpäivän arvon. 2) Sprintin suunnittelu- ja katselmointikokouksissa tarkastellaan edistymistä kohti tuotteen julkaisutavoitetta ja tehdään sopeutuksia, jotka optimoivat seuraavan sprintin arvon. 3) Viimeisenä on sprintin retrospektiivi –kokous, jossa tarkastellaan edellistä sprinttiä ja määritetään mitkä sopeutukset tekevät seuraavasta sprintistä tuottavamman ja nautinnollisemman.

Scrumin sisältö

Scrum on viitekehys, joka koostuu scrumtiimeistä rooleineen, aikarajoista, dokumenteista ja säännöistä.

Scrumtiimit on suunniteltu optimoimaan työn joustavuus ja tuottavuus. Siksi ne ovat itseorganisoituvia, sisältävät kaiken tarvittavan osaamisen ja työskentelevät iteraatioissa eli kehitysjaksoissa, joita kutsutaan sprinteiksi. Jokaisessa scrumtiimissä on kolme roolia: 1) Scrummaster vastaa Scrumin ymmärtämisestä ja seuraamisesta, 2) tuoteomistaja vastaa scrumtiimin työn arvon maksimoimisesta ja 3) kehitystiimi tekee työn. Kehitystiimi koostuu henkilöistä, joilla on kaikki tarvittava osaaminen muuttaa tuoteomistajan vaatimukset julkaisukelpoiseksi tuoteparannukseksi sprintin loppuun mennessä.

Scrum käyttää aikarajoja säännöllisyyden luomiseen. Scrumin aikarajatut elementit ovat julkaisun suunnittelukokous, sprintin suunnittelukokous, sprintti, päivän Scrum, sprintin katselmointikokous ja sprintin retrospektiivi. Scrumin sydän on


sprintti, enintään kuukauden mittainen iteraatio eli kehitysjakso, jonka pituus pidetään samana koko kehityshankkeen ajan. Kaikki sprintit käyttävät samaa Scrumin viitekehystä tuottaen julkaisukelpoisen tuoteparannuksen. Jokainen sprintti alkaa välittömästi edellisen sprintin jälkeen.

Scrumissa on neljä pääasiallista dokumenttia. Tuotteen kehitysjono on priorisoitu lista kaikesta, mitä tuotteessa saatetaan tarvita. Sprintin tehtävälista on lista tehtäviä, joiden avulla yhden sprintin tehtävälistasta tuotetaan julkaisukelpoinen tuoteparannus. Julkaisun edistymiskäyrä mittaa tuotteen jäljellä olevaa kehitysjonoa suhteessa julkaisusuunnitelman aikaan. Sprintin edistymiskäyrä mittaa sprintin jäljellä olevaa tehtävälistaa suhteessa sprintin aikaan.

Säännöt sitovat yhteen Scrumin aikarajat, roolit ja dokumentit. Säännöt kuvataan tässä dokumentissa. Yksi Scrumin säännöistä on, että vain kehitystiimin jäsenet eli henkilöt, jotka ovat sitoutuneet kehittämään tuoteparannuksen, saavat puhua päivän Scrum –kokouksessa.

Sellaiset Scrumin toteutustavat, jotka eivät ole sääntöjä vaan ehdotuksia, on kuvattu Vinkki -laatikoissa.

Scrumin roolit Scrumtiimi koostuu scrummasterista, tuoteomistajasta ja kehitystiimistä. Scrumtiimin jäseniä kutsutaan “sioiksi”. Tuoteomistaja on tuotteen kehitysjonon “sika”. Kehitystiimi on sprintin tehtävälistan “sika”. Scrummaster on Scrum-prosessin “sika”. Kaikki muut ovat “kanoja”. Kanojen ei tule kertoa sioille, kuinka heidän työnsä tulisi tehdä. Kanat ja siat perustuvat seuraavaan tarinaan:

Vinkki

Mikäli sääntö joltakin kohdalta puuttuu, Scrumin käyttäjien oletetaan keksivän itse, mitä tehdä. Älä yritä keksiä täydellistä ratkaisua, koska ongelma muuttuu usein nopeasti. Kokeile sen sijaan jotain ja katso, toimiiko se. Scrumin empiiriseen luonteeseen kuuluva ‘tarkastele ja sopeuta’ –mekanismi ohjaa oikeaan suuntaan.


Kana ja sika tapaavat, kun kana ehdottaa: “Perustetaanko yhdessä ravintola?”

Sika miettii hetken ja kysyy: “Minkä nimen antaisimme uudelle ravintolalle?”

Kana vastaa: “Pekonia ja munia!”

Sika sanoo: ”Ei kiitos. Minä joutuisin sitoutumaan, kun sinä taas olisit vain mukana!”

Scrummaster Scrummasterin vastuulla on varmistaa, että scrumtiimi pitäytyy Scrumin arvoissa, käytännöissä ja säännöissä. Scrummaster auttaa organisaatiota omaksumaan Scrumin. Scrummaster opastaa ja valmentaa scrumtiimiä työskentelemään tuottavammin ja kehittämään laadukkaampia tuotteita. Scrummaster auttaa scrumtiimiä ymmärtämään ja käyttämään itseorganisoitumista sekä moniosaamista. Scrummaster myös auttaa scrumtiimiä tekemään parhaansa ympäristössä, joka ei välttämättä ole vielä optimoitu monimutkaisten tuotteiden kehittämiseen. Kun scrummaster auttaa toteuttamaan nämä muutokset, kutsutaan sitä “esteiden poistamiseksi”. Scrummasterin rooli on palvella ja edustaa itseohjautuvaa scrumtiimiä.

Vinkki

Scrummaster työskentelee asiakkaan ja johdon kanssa valitakseen tuoteomistajan. Scrummaster opastaa ja tukee tuoteomistajaa hänen työnsä hoitamisessa. Tuoteomistajan odotetaan pystyvän optimoimaan tuotteen arvon Scrumia hyödyntämällä. Jos hän ei pysty tähän, pidetään scrummasteria edesvastuussa.

Vinkki

Scrummaster voi tehdä kehitystyötä kehitystiimin jäsenenä. Tämä saattaa kuitenkin johtaa konflikteihin, kun scrummasterin tulee valita kehitystehtävien toteutuksen ja tiimin esteiden poistamisen välillä. Scrummasterin ei koskaan tulisi olla tuoteomistaja.


Tuoteomistaja Tuoteomistaja on yksi ja ainoa henkilö, joka vastaa tuotteen kehitysjonosta ja kehitystiimin työn arvon maksimoimisesta. Tämä henkilö ylläpitää tuotteen kehitysjonoa ja varmistaa, että se on kaikkien nähtävissä. Kaikki näkevät, millä töillä on korkein prioriteetti, joten kaikki tietävät, mitä tullaan tekemään. Tuoteomistaja on yksi henkilö, ei komitea. Tuoteomistajalla voi olla tukenaan komiteoita, mutta tuotteen kehitysjonon prioriteettien muuttamiseksi näiden henkilöiden tulee vakuuttaa tuoteomistaja. Yritykset, jotka siirtyvät Scrumiin, saattavat huomata, että tämä vaikuttaa pikkuhiljaa tapoihin priorisoida ja määritellä vaatimuksia.

Tuoteomistajan työn onnistumiseksi organisaation kaikkien henkilöiden tulee kunnioittaa hänen päätöksiään. Kenenkään ei sallita pyytää kehitystiimiä työskentelemään muilla prioriteeteilla, eikä kehitystiimien sallita kuunnella ketään, joka väittää toisin. Tuoteomistajan päätökset näkyvät tuotteen kehitysjonon prioriteeteissa ja sisällössä. Tämä näkyvyys vaatii tuoteomistajaa tekemään parhaansa, mikä tekee tuoteomistajan roolista vaativan ja palkitsevan.

Vinkki

Kaupallisessa kehityksessä tuoteomistajana voi toimia tuotepäällikkö. Organisaation sisäisessä kehityksessä tuoteomistajana voi toimia automatisoitavan toimialan päällikkö.

Vinkki

Tuoteomistaja voi osallistua kehitystyöhön kehitystiimin jäsenenä. Tämä lisävastuu saattaa kuitenkin heikentää tuoteomistajan kykyä työskennellä projektin sidosryhmien kanssa. Tuoteomistaja ei voi koskaan toimia scrummasterina.


Kehitystiimi Kehitystiimin jäsenet muuttavat tuotteen kehitysjonon sisällön julkaisukelpoikseksi tuoteparannukseksi jokaisessa sprintissä. Kehitystiimit ovat monitaitoisia; kehitystiimin jäsenillä tulee olla kaikki vaadittava tieto, taito ja asenne tuotteen parantamiseen. Kehitystiimin jäsenillä on usein erityistaitoja, kuten ohjelmointi, laadunvarmistus, liiketoiminta-analyysi, arkkitehtuuri, käytettävyyssuunnittelu tai tietokantasuunnittelu. Lopputuloksen kannalta tärkeimmät taidot ovat ne, joita kaikilla kehitystiimin jäsenillä on, eivät ne mitä heiltä puuttuu. Nämä yhteiset taidot muuttavat vaatimukset julkaistavaksi tuotteeksi. Henkilöt, jotka kieltäytyvät ohjelmoimasta, koska ovat arkkitehteja tai suunnittelijoita, eivät sovi kehitystiimiin. Kaikkien tiimin jäsenten tulee sitoutua sprintin yhteiseen tavoitteeseen, vaikka se vaatisi uusien taitojen oppimista tai vanhojen taitojen palauttamista mieleen. Kehitystiimeissä ei käytetä titteleitä eikä kehitystiimejä myöskään pilkota alatiimeihin, kuten testaamiseen tai liiketoiminta-analyysiin.

Kehitystiimit ovat itseorganisoituvia. Ei kukaan – ei edes scrummaster – kerro kehitystiimille kuinka tuotteen kehitysjono tulisi muuttaa julkaisukelpoiseksi tuoteparannukseksi. Kehitystiimi ratkaisee asian itsenäisesti. Jokainen kehitystiimin jäsen soveltaa omaa osaamistaan kaikkiin haasteisiin. Tästä muodostuva synergia parantaa koko kehitystiimin suorituskykyä ja tuottavuutta.

Kehitystiimin optimaalinen koko on seitsemän henkilöä, plus tai miinus kaksi. Alle viiden hengen kehitystiimissä on vähemmän yhteistyötä ja sen tuloksena vähemmän tuottavuushyötyjä. Lisäksi pieni kehitystiimi saattaa törmätä osaamispulaan jossain sprintin osassa, eikä välttämättä pysty tuottamaan julkaisukelpoista tuoteparannusta. Jos taas kehitystiimissä on yli yhdeksän henkilöä, tarvitaan yksinkertaisesti liikaa koordinointia. Suuret tiimit aiheuttavat empiirisen prosessin toiminnalle liikaa sekavuutta. On kuitenkin olemassa näyttöä menestyneistä kehitystiimeistä, jotka ovat rikkoneet näitä tiimikoon ala- ja ylärajoja. Tuoteomistajan ja scrummasterin


roolit eivät sisälly näihin lukuihin, elleivät he työskentele kehitystiimissä “sikoina” sprintin tehtävälistan tehtävien toteutuksessa.

Kehitystiimin kokoonpano saattaa muuttua sprintin lopussa. Aina kun kokoonpanoa vaihdetaan, kehitystiimin itseorganisoinnilla saavutettu tuottavuushyöty pienenee. Tämän vuoksi kehitystiimin kokoonpanoa ei tulisi muuttaa ilman harkintaa.

Aikarajat Scrumin aikarajatut elementit ovat julkaisun suunnittelukokous, sprintti, sprintin suunnittelukokous, sprintin katselmointikokous, sprintin retrospektiivi ja päivän Scrum.

Julkaisun suunnittelukokous Julkaisun suunnittelun tavoitteena on asettaa tavoitteet ja suunnitelma, jotka scrumtiimit ja koko organisaatio ymmärtävät ja osaavat kommunikoida toisilleen. Julkaisusuunnittelu vastaa kysymykseen “kuinka voimme kehittää visiostamme menestyvän tuotteen parhaalla mahdollisella tavalla? Kuinka voimme saavuttaa tai ylittää tavoitellun asiakastyytyväisyyden ja sijoitetun pääoman tuoton?” Julkaisusuunnitelma määrittelee julkaisun tavoitteen, tuotteen kehitysjonon korkeimmat prioriteetit, suurimmat riskit sekä julkaisun ominaisuudet ja toiminnallisuuden. Se asettaa myös todennäköisen toimituspäivän sekä kustannusarvion, jonka tulisi pitää mikäli suunnitelma ei muutu. Organisaatio voi julkaisusuunnitelman perusteella seurata julkaisun edistymistä sprintti kerrallaan ja tehdä suunnitelmaan tarvittaessa muutoksia.

Julkaisun suunnittelu on täysin valinnaista. Mikäli scrumtiimi aloittaa työn ilman julkaisun suunnittelukokousta, muodostuu puuttuvasta suunnittelutiedosta työskentelyn este, joka tulee poistaa. Esteen poistamiseksi tarvittavat tehtävät merkitään tuotteen kehitysjonoon.

Scrumissa tuotteita kehitetään iteratiivisesti siten, että jokainen sprintti kehittää tuotteelle parannuksen, alkaen kaikkein arvokkaimmasta ja riskipitoisimmasta ominaisuudesta. Peräjälkeen


toistuvat sprintit kehittävät lisää tuotteen parannuksia. Jokainen parannus on julkaistavissa oleva siivu koko tuotteesta. Kun on toteutettu riittävästi julkaisukelpoisia parannuksia, joista on arvoa tuotteen käyttäjille ja sidosryhmille, tuote julkaistaan.

Monilla organisaatioilla on jo käytössä julkaisun suunnitteluprosessi. Niissä suurin osa suunnittelusta tehdään yleensä julkaisuprojektin alussa eikä suunnitelmia muuteta ajan kuluessa. Scrumin julkaisusuunnittelussa taas määritellään vain yleinen tavoite ja todennäköiset seuraukset. Tähän kuluu yleensä vain 15-20% ajasta, jonka organisaatio tarvitsee perinteisen julkaisusuunnitelman luomiseen. Lisäksi Scrumissa hyödynnetään oikea-aikaista Just-In-Time -suunnittelua jokaisessa sprintin katselmointi- ja suunnittelukokouksessa sekä päivän Scrum -kokouksissa. Kokonaisuudessaan Scrumin julkaisusuunnittelu todennäköisesti vaatii hieman enemmän aikaa kuin perinteinen suunnittelu.

Julkaisusuunnittelu vaatii tuotteen kehitysjonon töiden priorisointia ja aika-arviointia. Tähän on olemassa useita tekniikoita, jotka ovat hyödyllisiä, mutta eivät varsinaisesti kuulu Scrumiin.

Sprintti Sprintti tarkoittaa aikarajattua iteraatiota eli kehitysjaksoa. Sen aikana Scrummaster varmistaa, ettei Sprintin tavoitteesta poikkeavia muutoksia toteuteta. Kehitystiimin koostumus ja laatutavoitteet pysyvät samoina koko Sprintin ajan. Sprintti muodostuu sprintin suunnittelusta, varsinaisesta kehitystyöstä, sprintin katselmoinnista ja sprintin retrospektiivista. Sprintit seuraavat toisiaan peräjälkeen ilman taukoja sprintien välillä.

Vinkki

Mikäli kehitystiimi havaitsee sitoutuneensa toimittamaan liian paljon, se keskustelee tuoteomistajan kanssa poistaakseen tai keventääkseen sprinttiin valittuja vaatimuksia. Jos taas kehitystiimillä on ylimääräistä aikaa, se valitsee tuoteomistajan kanssa tuotteen kehitysjonosta lisää toteutettavaa.


Projektia käytetään jonkin saavuttamiseen. Ohjelmistokehityksessä sitä käytetään tuotteen tai järjestelmän kehittämiseen. Jokainen projekti koostuu määritelmästä mitä kehitetään, suunnitelmasta kuinka se kehitetään, suunnitelman mukaisesta toteutustyöstä sekä näiden seurauksena syntyvästä tuotteesta. Jokaisella projektilla on horisontti, näkymä eteenpäin, jonka aikana suunnitelma on realistinen. Jos horisontti on liian kaukana, määritelmä voi muuttua, voi ilmestyä uusia muuttujia ja riski saattaa kasvaa liian suureksi.

Scrum on viitekehys projekteille, joiden horisontti on enintään kuukauden mittainen, koska pidempi aika sisältäisi liikaa riskejä. Projektin ennustettavuutta tulee tarkastella vähintään kuukauden välein sekä arvioida projektin ennustettavuuden tai kontrollin kadottamisen riskiä.

Sprintti voidaan keskeyttää ennen kuin sprintin aikaraja täyttyy. Vain tuoteomistajalla on valta keskeyttää sprintti, mutta hän voi halutessaan tehdä niin sidosryhmien, kehitystiimin tai scrummasterin toivomuksesta. Missä tilanteessa sprintti sitten tulisi keskeyttää? Johto voi pyytää keskeyttämään sprintin mikäli sen tavoite vanhenee. Tällainen tilanne voi syntyä, jos yrityksen suunta, markkinat tai teknologinen ympäristö muuttuu. Yleisesti ottaen sprintti tulee keskeyttää jos sen jatkaminen ei ole enää mielekästä nykyisessä tilanteessa. Sprintin lyhyestä kestosta johtuen keskeyttäminen on kuitenkin harvoin hyödyllistä.

Mikäli sprintti keskeytetään, kaikki siinä toteutetut “valmiit” tuotteen kehitysjonon kohdat katselmoidaan ja hyväksytään, mikäli niistä voidaan muodostaa julkaisukelpoinen tuoteparannus. Kaikki muut kehitysjonon kohdat siirretään takaisin tuotteen kehitysjonoon alkuperäisine aika-arvioineen ja niihin mahdollisesti tehty työ oletetaan menetetyksi. Sprintin keskeytys kuluttaa resursseja, koska kaikkien

Vinkki

Kun kehitystiimi aloittaa Scrumin, kahden viikon sprintit mahdollistavat työskentelyn ja oppimisen ilman liikaa epätietoisuutta. Tämän pituiset sprintit voidaan synkroinoida muiden kehitystiimien kanssa yhdistämällä kaksi julkaisukelpoista tuoteparannusta.


tulee kokoontua suunnittelukokoukseen uuden Sprintin aloittamiseksi. Sprintin keskeytykset ovat kehitystiimille yleensä raskaita ja myös siksi hyvin harvinaisia.

Sprintin suunnittelukokous Sprintin suunnittelukokouksessa suunnitellaan alkava kehitysjakso. Kokous rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa (esimerkiksi kahden viikon sprintille enintään neljä tuntia eli noin 5% koko sprintille varatusta ajasta).

Sprintin suunnittelukokous koostuu kahdesta osasta. Ensimmäisessä osassa päätetään, mitä sprintissä tullaan tekemään. Toisessa osassa (neljän tunnin aikaraja kuukauden Sprintille) kehitystiimi ratkaisee kuinka se kehittää tarvitun tuoteparannuksen sprintin aikana.

Sprintin suunnittelukokous koostuu siis “mitä?” -osasta ja “miten?” -osasta. Jotkut scrumtiimit yhdistävät nämä kaksi osaa. Ensimmäisessä puoliskossa scrumtiimi selvittää tuoteomistajan johdolla vastauksen kysymykseen “mitä?”. Tuoteomistaja esittelee kehitystiimille tuotteen kehitysjonon korkeimmat prioriteetit, jonka jälkeen kehitystiimi ja tuoteomistaja miettivät yhdessä mitä toiminnallisuutta tuotteen kehitysjonosta valitaan kehitettäväksi seuraavassa Sprintissä. Sprintin suunnittelukokouksen lähtökohtana on priorisoitu tuotteen kehitysjono, viimeisin tuoteparannus, kehitystiimin kapasiteetti ja kehitystiimin aiempi suorituskyky. Päätös sopivasta työmäärästä on täysin kehitystiimin, koska vain kehitystiimi voi arvioida paljonko vaatimuksia se pystyy toteuttamaan alkavassa sprintissä.

Kehitysjonon kohtien valinnan jälkeen valitaan sprintin tavoite. Se toteutuu sprinttiin valittujen kehitysjonon kohtien toteutuksen kautta. Sprintin tavoite antaa kehitystiimille konkreettisen näkökulman ja perustelun, miksi se on kehittämässä tuotteelle parannusta. Sprintin tavoite on osa koko julkaisun tavoitteesta.


Sprintin tavoite antaa kehitystiimille hieman liikkumavaraa toteutuksen suhteen. Sprintin tavoitteena voi esimerkiksi olla “automatisoi asiakastilin muokkaaminen turvallisen transaktio-pohjaisen väliohjelmiston kautta.” Työskennellessään kehitysryhmä pitää tavoitteen mielessä. Päästäkseen tavoitteeseen se toteuttaa toiminnallisuuden ja vaaditun teknologisen ratkaisun. Jos työ paljastuu kehitystiimille ennakoitua vaikeammaksi, se kommunikoi tuoteomistajan kanssa ja toteuttaa toiminnallisuuden vain osittain.

Sprintin suunnittelukokouksen toisessa puoliskossa kehitystiimi selvittää vastauksen kysymykseen “miten?”. Kehitystiimi aloittaa toisen puoliskon (neljän tunnin aikaraja kuukauden sprintille) yleensä tunnistamalla tehtävät, joilla se kehittää sprinttiin valituista tuotteen kehitysjonon kohdista julkaisukelpoisen tuoteparannuksen. Tehtävien tulee olla riittävän pienikokoisia, jotta kukin niistä voidaan toteuttaa enintään yhdessä työpäivässä. Tämä lista on nimeltään sprintin tehtävälista. Kehitystiimi itseorganisoituu jakaakseen tehtävälistassa olevat tehtävät keskenään joko sprintin suunnittelukokouksessa tai oikea-aikaisesti sprintin kuluessa (Just-In-Time).

Tuoteomistaja on läsnä myös sprintin suunnittelun toisella puoliskolla tarkentaakseen tuotteen kehitysjonon sisältöä ja auttaakseen löytämään kompromisseja. Jos kehitystiimi huomaa, että sprintissä onkin liikaa tai liian vähän tehtäviä, se voi neuvotella uudestaan tuoteomistajan kanssa. Kehitystiimi voi kutsua mukaan muitakin henkilöitä saadakseen teknisiä tai liiketoiminnallisia neuvoja. Uusi kehitystiimi havaitsee yleensä tässä kokouksessa, että se joko uppoaa tai oppii uimaan tiiminä, ei yksilöinä. Kehitystiimi myös havaitsee, että sen täytyy luottaa itseensä. Havaittuaan tämän

Vinkki

Yleensä vain noin 60-70% sprintin tehtävälistasta suunnitellaan sprintin suunnittelukokouksessa. Loput tehtävät jätetään suunniteltaviksi myöhemmin tai niille annetaan suuremmat aika-arviot ja ne pilkotaan pienempiin tehtäviin myöhemmin sprintin aikana.


kehitystiimi alkaa itseorganisoitua omaksuakseen ammattimaisesti toimivan kehitystiimin toimintatavat ja tunnusmerkit.

Sprintin katselmointi Jokaisen sprintin lopuksi pidetään sprintin katselmointikokous, joka rajataan enintään neljään tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa (esimerkiksi kahden viikon sprintille enintään kaksi tuntia eli noin 2,5% koko sprintille varatusta ajasta). Sprintin katselmoinnissa scrumtiimi ja muut asianosaiset henkilöt käyvät yhdessä läpi sprintin saavutukset. Katselmoinnin ja tuoteomistajan päivittämän tuotteen kehitysjonon perusteella selvitetään, mitä seuraavaksi kannattaa tehdä. Sprintin katselmointi on sisällöltään vapaamuotoinen kokous, jossa toteutetun toiminnallisuuden demonstraation tarkoituksena on edistää keskustelua siitä mitä tehdään seuraavaksi. Kokous sisältää vähintään seuraavat elementit: Tuoteomistaja selvittää kehitystiimin kanssa mitkä sprintiin valitut kehitysjonon kohdat on saatu valmiiksi ja mitkä ovat vielä kesken. Kehitystiimi keskustelee mikä sujui hyvin, mitä ongelmia ilmeni ja kuinka ongelmat ratkaistiin. Kehitystiimi myös esittelee tekemänsä työn ja vastaa kysymyksiin. Seuraavaksi tuoteomistaja käy läpi tuotteen kehitysjonon nykytilan sisältäen arvion tulevien sprintien kehitysnopeudesta ja tuotteen julkaisuajasta. Tämän jälkeen koko scrumtiimi keskustelee uusien tietojen vaikutuksesta seuraaviin sprintteihin. Sprintin katselmointi tarjoaa arvokasta pohjatietoa seuraavan sprintin suunnittelukokoukselle.

Sprintin retrospektiivi Sprintin katselmointikokouksen jälkeen ja ennen seuraavan sprintin suunnittelukokousta scrumtiimi pitää retrospektiivin. Kokous rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa (esimerkiksi kahden viikon sprintille enintään 90 minuuttia). Kokouksessa scrummaster kannustaa scrumtiimiä tarkastelemaan ja sopeuttamaan Scrum-kehykseen liittyvää kehitysprosessia ja käytäntöjä, jotta seuraavista sprinteistä


saadaan tuottavampia ja miellyttävämpiä. Retrospektiivin pitämiseen on tarjolla hyödyllisiä tekniikoita, joita on kuvattu monissa kirjoissa.

Retrospektiivin tarkoituksena on tarkastella viimeisimmän sprintin onnistumista ihmisten, muodostuneiden ihmissuhteiden, prosessien ja työkalujen näkökulmasta. Tarkastelussa tulisi tunnistaa ja priorisoida tärkeimmät asiat, jotka menivät hyvin sekä asiat, joita muuttamalla työ sujuisi jatkossa vieläkin paremmin.

Tarkasteltavia asioita ovat scrumtiimin kokoonpano, kokousjärjestelyt, työkalut, valmiin määritelmä (s. 21), kommunikointimenetelmät ja prosessit, joilla tuotteen kehitysjonosta tuotetaan jotain “valmista”. Sprintin retrospektiivin loppuun mennessä scrumtiimin tulisi tunnistaa ja valita seuraavan sprintin aikana toteutettavat parannukset. Näillä muutoksilla nykytilaa sopeutetaan empiirisen tarkastelun mukaiseksi.

Päivän Scrum Kukin kehitystiimi pitää päivittäin 15 minuuttia kestävän tarkastelu- ja sopeutuskokouksen, jota kutsutaan päivän Scrumiksi. Päivän Scrum pidetään aina samaan aikaan samassa paikassa. Tapaamisessa jokainen kehitystiimin jäsen kertoo vuorollaan:

1. Mitä olen saanut aikaan viime tapaamisen jälkeen,

2. Mitä aion tehdä ennen seuraavaa tapaamista, ja

3. Mitä esteitä etenemiselläni on.

Päivän Scrum –kokoukset kehittävät kommunikointia, vähentävät muita kokouksia, tunnistavat ja poistavat esteitä, korostavat nopeaa päätöksentekoa ja parantavat kaikkien ymmärrystä projektista.

Scrummasterin tehtävänä on varmistaa, että kehitystiimi todella pitää kokouksen. Kehitystiimin vastuulla taas on järjestää päivän Scrum. Scrummaster valmentaa kehitystiimiä pitämään kokous lyhyenä valvomalla kokouksen käytäntöjä ja pitämällä puheenvuorot lyhyinä. Scrummaster valvoo myös tarvittaessa käytäntöä, joka kieltää


mahdollisesti kuuntelemaan tulleita “kanoja“ puhumasta tai muulla tavoin häiritsemästä Päivän Scrumia.

Päivän Scrum ei ole raportointikokous. Se on tarkoitettu ainoastaan henkilöille (kehitystiimille), jotka osallistuvat tuoteparannuksen kehittämiseen. Kehitystiimi on sitoutunut sprintin tavoitteeseen ja siihen liittyviin tuotteen kehitysjonon vaatimuksiin. Päivän Scrumissa tarkastellaan kehityksen etenemistä suhteessa sprintin tavoitteeseen (yllä mainitut kolme kysymystä). Päivän Scrumissa sovitaan tarvittaessa erillisistä kokouksista, joissa käsitellään työn toteutusta. Tarkoituksena on maksimoida todennäköisyys sille, että kehitystiimi pääsee sprintille asettamaansa tavoitteeseen. Päivän Scrum -kokouksella on Scrumin empiirisessä prosessissa tärkeä rooli työn tarkastelussa ja sopeuttamisessa.

Scrumin dokumentit Scrumin neljä dokumenttia ovat tuotteen kehitysjono (Product Backlog), sprintin tehtävälista (Sprint Backlog), julkaisun edistymiskäyrä (Release Burndown) ja sprintin edistymiskäyrä (Sprint Burndown).

Tuotteen kehitysjono ja julkaisun edistymiskäyrä Tuotteen kehitysjonossa listataan kaikki vaatimukset tuotteelle, jota kehitystyhmä(t) kehittävät. Tuoteomistaja vastaa tuotteen kehitysjonosta, sen sisällöstä, saatavuudesta ja priorisoinnista. Tuotteen kehitysjono ei ole koskaan valmis ja sen ensiversio sisältää ainoastaan tunnetut ja parhaiten ymmärretyt vaatimukset. Tuotteen kehitysjono kehittyy yhdessä itse tuotteen ja sen käyttöympäristön kanssa. Tuotteen kehitysjono on dynaaminen ja se muuttuu jatkuvasti sisältämään vaatimukset, jotka tuote tarvitsee ollakseen tarkoituksenmukainen, kilpailukykyinen ja hyödyllinen. Tuotteen kehitysjono on olemassa yhtä kauan kuin tuote.


Tuotteen kehitysjono sisältää kaiken tarpeellisen menestyvän tuotteen kehittämiseksi ja julkaisemiseksi. Tuotteen kehitysjono on lista kaikista ominaisuuksista, toiminnoista, teknologioista, parannuksista ja korjattavista virheistä, jotka tullaan toteuttamaan tuleviin tuotejulkaisuihin. Jokaisella kehitysjonon kohdalla on kuvaus, prioriteetti ja aika-arvio. Prioriteetti määritellään riskin, lisäarvon ja tarpeellisuuden perusteella. Näiden muuttujien arviointiin ja siten kehitysjonon priorisointiin on olemassa useita erilaisia tekniikoita.

Tuotteen kehitysjono järjestetetään sen kohtien prioriteettien mukaan. Korkeimman prioriteetin kohdat ohjaavat seuraavaksi aloitettavaa kehitystä. Korkeampi prioriteetti tarkoittaa, että kehitysjonon kohta on kiireellisempi, sitä on ehditty suunnitella enemmän ja sen arvosta vallitsee suurempi yksimielisyys. Korkeamman prioriteetin kohdat ovat selkeämpiä ja sisältävät tarkempaa tietoa kuin matalamman prioriteetin kohdat. Korkeamman prioriteetin kohtien suurempi selkeys kasvattaa myös aika-arvioiden tarkkuutta. Mitä matalampi prioriteetti, sitä vähemmän kehitysjonon kohdasta tiedetään ja sitä vaikeampaa kohtaa on ymmärtää.

Vinkki

Tuotteen kehitysjonon kohdat kirjataan usein käyttäjätarinoina (User Story). Myös käyttötapauksia (Use Case) voidaan käyttää, mutta ne sopivat paremmin liiketoiminnalle tai terveydelle kriittisten sovellusten kehittämiseen.

Vinkki

Scrumtiimi käyttää yleensä 10% sprintin ajasta tuotteen kehitysjonon päivittämiseen, jotta kehitysjono täyttää edellä määritellyn tarkoituksensa. Päivityksen yhteydessä tuotteen kehitysjonossa ylimpänä olevat kohdat (korkein prioriteetti ja suurin arvo) harjoitetaan pienemmiksi siten, että ne kattavat ainakin seuraavan sprintin. Päivitysten aikana kehitysjonon kohtia analysoidaan ja tarkennetaan. Sprintin suunnittelukokoukseen mennessä korkeimman prioriteetin kohdat on hyvin ymmärretty ja helposti valittavissa toteutukseen.


Kun tuotetta aletaan käyttää, sen arvo kasvaa ja markkinoilta saadaan palautetta, minkä seurauksena tuotteen kehitysjono muuttuu laajemmaksi ja perusteellisemmaksi. Vaatimusten muuttuminen ei pääty koskaan. Tuotteen kehitysjono on elävä dokumentti. Muutokset liiketoiminnan vaatimuksissa, markkinassa, teknologiassa ja henkilöstössä aiheuttavat jatkuvasti muutoksia tuotteen kehitysjonoon. Moninkertaisen työn minimoimiseksi vain korkeimman prioriteetin kohdat tulee määritellä yksityiskohtaisesti. Tuotteen kehitysjonon kohdat, joita kehitystiimi toteuttaa seuraavissa sprinteissä, tulee hajottaa riittävän pieniksi ja tarkoiksi, jotta mikä tahansa kohdista ehditään täysin toteuttaa yhden sprintin aikana.

Useampi scrumtiimi työskentelee usein saman tuotteen parissa. Tällöin työtä ohjataan yhdellä tuotteen kehitysjonolla, johon lisätään vaatimusten ryhmittelyä tukeva tunniste. Ryhmittely voi perustua toiminnallisuuteen, teknologiaan tai arkkitehtuuriin, ja ryhmittelyä käytetään usein työn jakamiseen useamman scrumtiimin kesken.

Julkaisun edistymiskäyrä on diagrammi, joka esittää tuotteen kehitysjonossa jäljellä olevan työmäärän suhteessa aikaan. Arvioitu työmäärä on missä tahansa yksikössä, jonka

Vinkki

Tuotteen kehitysjonoon lisätään usein oma sarakkeensa hyväksymistesteille. Hyväksymistestin avulla pitkät määrittelytekstit voidaan useimmiten korvata nopeasti todennettavalla testillä, joka määrittää kuinka vaatimuksen tulee toimia ollakseen valmis.

Vinkki

Joissakin organisaatioissa tuotteen työjonoon lisätään enemmän työtä kuin sitä ehditään sprinteissä toteuttaa. Tämä voi muodostaa julkaisun edistymiskäyrään trendiviivan, joka on tasainen tai jopa ylöspäin nouseva. Jotta työn lisäämisen vaikutusta voidaan tasata läpinäkyvyys säilyttäen, voidaan määrittää uusi nollataso, kun työtä lisätään tai vähennetään. Uusi nollataso tulisi määritellä vain silloin, kun lisätään tai poistetaan suurempia kokonaisuuksia. Uusi nollataso tulee dokumentoida hyvin.


scrumtiimi ja organisaatio on valinnut. Julkaisun edistymiskäyrässa ajan yksikkönä ovat yleensä sprintit.

Tuotteen kehitysjonon vaatimuksille annetaan alustavat aika-arviot julkaisun suunnittelun yhteydessä sekä sitä mukaa, kun uusia vaatimuksia lisätään tuotteen kehitysjonoon. Aika-arviot tarkentuvat tuotteen kehitysjonon säännöllisissä tarkasteluissa. Aika-arvioita voi muuttaa milloin tahansa muulloinkin. Aika-arvioden antamisesta vastaa kehitystiimi. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään ja valitsemaan kompromisseja, mutta lopullisen aika-arvion antaa aina kehitystiimi. Tuoteomistaja pitää ajantasaisen julkaisun edistymiskäyrän jatkuvasti näkyvillä. Jäljelläolevan työmäärän muutoksista voidaan myös piirtää trendiviiva.

Sprintin tehtävälista ja edistymiskäyrä Sprintin tehtävälista koostuu tehtävistä, jotka kehitystiimin tulee toteuttaa muuttaakseen tuotteen kehitysjonosta valitut kohdat julkaisukelpoiseksi tuoteparannukseksi. Tehtävät määritellään useimmiten sprintin suunnittelukokouksessa. Ne kuvaavat työtä, jonka kehitystiimi tunnistaa tarpeelliseksi sprintin tavoitteeseen pääsemiseksi. Sprintin tehtävälistaan valitut kohdat tulee hajottaa niin pieniksi, että sprintin edistyminen voidaan havaita päivän Scrum -kokouksessa. Sprintin tehtävälistan kohdan tyypillinen koko on yksi miestyöpäivä tai vähemmän.

Kehitystiimi ylläpitää ja päivittää sprintin tehtävälistaa koko sprintin ajan. Aloittaessaan sprintin toteutustyön kehitystiimi voi havaita, että tarvitaankin vähemmän tai enemmän tehtäviä kuin suunniteltiin, tai että jokin tehtävä tulee viemään enemmän tai vähemmän aikaa kuin

Vinkki

Julkaisun edistymiskäyrän trendiviiva saattaa olla epäluotettava muutaman ensimmäisen sprintin ajan, ellei kehitystiimi ole työskennellyt yhdessä aikaisemmin ja tunne hyvin tuotetta sekä käytettyjä teknologioita.


arvioitiin. Kehitystiimi lisää tarvittavat uudet tehtävät sprintin tehtävälistaan.

Kun tehtäviä työstetään tai ne valmistuvat, kunkin tehtävän arvioitu jäljelläoleva työmäärä päivitetään. Mikäli tehtävä havaitaan tarpeettomaksi, se poistetaan. Ainoastaan kehitystiimi voi muuttaa sprintin tehtävälistaa, sen sisältöä tai aika-arvioita sprintin aikana. Sprintin tehtävälista on selkeästi näkyvä, reaaliaikainen kuva työstä, jonka kehitystiimi suunnittelee saavansa valmiiksi sprintin aikana. Tämän vuoksi sprintin tehtävälista on täysin kehitystiimin omistuksessa ja hallinnassa.

Sprintin edistymiskäyrä on diagrammi, joka esittää sprintin tehtävälistassa jäljellä olevan työmäärän suhteessa aikaan. Sprintin edistymiskäyrä piirretään laskemalla yhteen kaikki sprintin tehtävälistassa olevat aika-arviot ja päivittämällä tätä lukua kerran päivässä. Luku kuvaa sprintin koko jäljellä olevaa työmäärää päivän tarkkuudella. Piirtämällä viiva sprintin kokonaistyömäärää päivän tarkkuudella kuvaavien pisteiden läpi kehitystiimi näkee konkreettisesti etenemisensä kohti sprintin tehtävien valmistumista. Tehtäviin käytetyn työajan pituudella ei ole Scrumissa merkitystä. Ainoastaan jäljellä oleva työmäärä ja päivämäärä ovat kiinnostavia muuttujia.

Yksi Scrumin säännöistä on sprintin tarkoitus tuottaa julkaisukelpoinen tuoteparannus, joka on scrumtiimin sopiman “valmiin” määritelmän mukainen.

Vinkki

Aina kun mahdollista, piirrä edistymiskäyrä käsin suurelle paperille tai valkotaululle, joka on esillä kehitystiimin työskentelytilassa. Kehitystiimi seuraa suurta näkyvää edistymiskäyrää todennäköisemmin kuin Excelissä tai verkkopohjaisessa työkalussa olevaa edistymiskäyrää.


Valmis Scrum vaatii kehitystiimejä kehittämään tuoteparannuksen jokaisessa sprintissä. Parannuksen tulee olla julkaistavissa välittömästi, jos tuoteomistaja niin päättää. Tämän vuoksi parannuksen tulee olla “valmis” siivu tuotteesta. Jokaisen parannuksen tulee olla lisäys kaikkiin edellisiin parannuksiin ja se tulee testata huolellisesti, jotta varmistetaan kaikkien parannusten keskinäinen toimivuus.

Tuotekehityksessä sana “valmis” saattaa johtaa oletukseen, että toiminnallisuus on vähintään siististi ohjelmoitu, refaktoroitu, yksikkötestattu, käännetty ja hyväksymistestattu. Joku toinen taas voi olettaa, että “valmis” toiminnallisuus on ainoastaan käännetty. Mikäli kaikki eivät tunne “valmiin” määritelmää, empiirisen prosessihallinnan kaksi muuta tukijalkaa eivät toimi. Kun joku kommunikoi jonkin olevan valmis, kaikkien tulee ymmärtää, mitä valmis tarkoittaa.

Valmis määrittelee, mitä kehitystiimi tarkoittaa sitoutuessaan toteuttamaan tuotteen kehitysjonon kohdan. Jotkut tuotteet eivät sisällä dokumentaatiota, joten valmiin määritelmä ei myöskään sisällä dokumentaatiota. Täysin valmis tuoteparannus taas sisältää kaiken analyysin, suunnittelun, refaktoroinnin, ohjelmoinnin, dokumentoinnin ja testaamisen kaikille tuotteen kehitysjonon vaatimuksille, jotka liittyvät tuoteparannukseen. Testaaminen sisältää yksikkö-, systeemi-, käyttäjä- ja regressiotestauksen sekä ei-toiminnalliset testit suorituskyvylle, vakaudelle, turvallisuudelle ja integroinnille. Valmis sisältää myös mahdollisen kansainvälistämisen. Joidenkin kehitystiimien ei ole heti mahdollista sisällyttää kaikkea tarvittavaa valmiin määritelmäänsä. Tämän tulee olla tuoteomistajan tiedossa. Jäljellä oleva tekemätön työ tulee tehdä valmiiksi ennen kuin tuotetta voidaan toimittaa ja käyttää.

Vinkki

“Keskeneräinen” työ kerätään usein tuotteen kehitysjonoon kohdan “keskeneräinen työ” alle. Kun keskeneräisen työn summaa näin ylläpidetään, tuotteen edistymiskäyrä säilyy tarkempana.


LOPPUSANAT Jotkut organisaatiot eivät kykene kehittämään julkaisukelpoista tuoteparannusta yhden sprintin aikana. Näillä ei välttämättä vielä ole tarvittavaa automaattista testausympäristöä kaikkien edelläkuvattujen testien toteutukseen. Tällaisessa tilanteessa kullekin tuoteparannukselle luodaan kaksi kategoriaa: “Valmis” työ ja “keskeneräinen” työ. Keskeneräinen työ on osa tuoteparannusta, joka päätetään tehdä valmiiksi myöhemmin. Tuoteomistaja tunnistaa töiden tilanteen Sprintin katselmointipalaverissa, koska tuoteparannuksen tulee vastata sovittua valmiin määritelmää. Keskeneräiset työt lisätään tuotteen kehitysjonoon uudeksi kohdaksi “keskeneräiset työt”, johon kumuloituu tekemättömien töiden aika-arviot, jotka näkyvät julkaisun edistymiskäyrässä tekemättömänä työnä. Näin läpinäkyvyys kasvaa kohti tuotteen julkaisua. Sprintin katselmointipalaverissa tehtävä tarkastelu ja sopeuttaminen on yhtä tarkkaa kuin tämä läpinäkyvyys.

Jos kehitystiimi ei esimerkiksi pysty toteuttamaan suorituskyky-, regressio-, vakaus-, turvallisuus- ja integrointitestausta jokaiselle sprinttiin suunnitellulle kehitysjonon kohdalle, lasketaan tämän keskeneräisen työmäärän suhde työhön, joka voidaan toteuttaa (analyysi, suunnittelu, refaktorointi, ohjelmointi, dokumentointi, yksikkö- ja käyttäjätestaaminen). Oletetaan esimerkiksi, että tämä suhdeluku on kuusi yksikköä “valmiita töitä” ja neljä yksikköä “keskeneräisiä töitä”. Kun kehitystiimi saa valmiiksi vaatimuksen, jonka aika-arvio on kuusi yksikköä työtä (huomioiden kehitystiimin “valmiin” määritelmä, joka sisältää vain sen hallitsemat työvaiheet), lisätään neljä yksikköä työtä “keskeneräiset työt” –vaatimukseen.

“Keskeneräinen” työ kumuloituu sprintti kerrallaan ja työ tulee tehdä valmiiksi ennen tuotteen julkaisua. Keskeneräinen työ kumuloituu lineaarisesti, mutta siinä on eksponentiaalisia piirteitä, jotka riippuvat organisaatiosta. Keskeneräisen työn toteuttamiseksi julkaisuprojektin loppuun lisätään julkaisu-sprinttejä. Tarvittavien julkaisu-sprintten määrän arviointi on sitä vaikeampaa mitä enemmän eksponentiaalisia piirteitä keskeneräisellä työllä on.

scrum guide fi

Documents