Scrum-opas™ - scrumwell.files.wordpress.com · Scrum-opas™ Scrumin määritelmä ja pelisäännöt Lokakuu 2017 Kirjoittajat ovat Scrumin kehittäjät Ken Schwaber ja Jeff Sutherland

Scrum-opas™

Scrumin määritelmä ja pelisäännöt

Lokakuu 2017

Kirjoittajat ovat Scrumin kehittäjät Ken Schwaber ja Jeff Sutherland

SUOMI

©2017 Scrum.Org, Scrum, Inc. Scrum-opas on julkaistu Creative Commonsin lisenssillä “Nimeä-JaaSamoin”. Lisenssi on ladattavissa osoitteesta http://creativecommons.org/licenses/by-sa/4.0/legalcode.fi sekä tiivistelmänä http://creativecommons.org/licenses/by-sa/4.0/deed.fi. Käyttämällä tätä teosta osoitat lukeneesi ja hyväksyneesi edellämainitut Creative Commonsin lisenssiehdot. Sivu | 2

SisällysluetteloScrum-oppaan tarkoitus .............................................................................................................. 4

Scrumin määritelmä .................................................................................................................... 4

Scrumin käyttötarkoitukset ......................................................................................................... 4

Scrumin taustateoria ................................................................................................................... 5

Scrumin arvot ............................................................................................................................. 6

Scrum-tiimi ................................................................................................................................. 6

Tuoteomistaja ......................................................................................................................... 7

Kehitystiimi ............................................................................................................................. 7

Scrummaster ........................................................................................................................... 8

Scrumin tapahtumat ................................................................................................................... 9

Sprintti .................................................................................................................................... 9

Sprintin suunnittelu............................................................................................................... 10

Päivittäispalaveri ................................................................................................................... 12

Sprintin katselmointi ............................................................................................................. 13

Sprintin retrospektiivi ............................................................................................................ 14

Scrumin tuotokset ..................................................................................................................... 14

Tuotteen kehitysjono ............................................................................................................ 15

Sprintin kehitysjono .............................................................................................................. 16

Inkrementti ........................................................................................................................... 17

Tuotosten läpinäkyvyys ............................................................................................................. 17

“Valmiin” määritelmä ............................................................................................................ 17

Loppuviite ................................................................................................................................. 19

Huomionosoitukset ................................................................................................................... 19

Ihmiset .................................................................................................................................. 19

Historia ................................................................................................................................. 19

Käännös ................................................................................................................................ 19

Muutokset versioiden 2016 ja 2017 välillä................................................................................. 20

1. Lisätty kappale Scrumin käyttötarkoituksista ..................................................................... 20

3. Lisätty kohta scrummasterin palveluista tuoteomistajalle .................................................. 21

4. Päivitetty päivittäispalaverin ensimmäinen kappale muotoon: .......................................... 21


5. Päivitetty päivittäispalaveri –kappale tuomaan lisää selkeyttä päivittäispalaverin tavoitteisiin: .......................................................................................................................... 21

6. Lisätty selkeyttä aikarajoihin.............................................................................................. 21

7. Lisätty tarkennus sprintin kehitysjono –kappaleeseen: ...................................................... 21

8. Lisätty tarkennus inkrementti –kappaleeseen: ................................................................... 21


Scrum-oppaan tarkoitus Scrum on monimutkaisten tuotteiden kehittämiseen, toimitukseen ja ylläpitoon tarkoitettu viitekehys. Tämä opas sisältää Scrumin määritelmän. Määritelmä koostuu rooleista, tapahtumista, tuotoksista ja säännöistä, jotka sitovat Scrumin elementit yhteen. Ken Schwaber ja Jeff Sutherland kehittivät Scrumin, ovat kirjoittaneet Scrum-oppaan ja vastaavat siitä.

Scrumin määritelmä Scrum (subst.): Viitekehys, jonka avulla ihmiset voivat ratkaista monimutkaisia ongelmia kehittäessään mahdollisimman suurta lisäarvoa tarjoavia tuotteita tuottavasti ja luovasti. Scrum on:

• Kevyt • Yksinkertainen ymmärtää • Vaikea taitaa

Scrumia on käytetty työn hallintaan monimutkaisten tuotteiden parissa 1990-luvun alusta lähtien. Scrum ei ole prosessi, tekniikka eikä yksityiskohtia ohjaava menetelmä. Se on paremminkin viitekehys, jonka sisällä voi hyödyntää useita erilaisia prosesseja ja tekniikoita. Scrum tekee tuotehallinnan ja työmenetelmien suorituskyvyn näkyväksi, jotta voidaan jatkuvasti parantaa tuotetta, tiimiä ja työskentely-ympäristöä.

Scrum-viitekehys koostuu Scrum-tiimeistä rooleineen, tapahtumista, tuotoksista ja säännöistä. Jokainen elementti palvelee tiettyä tarkoitusta ja on oleellinen osa Scrumin onnistumista.

Scrumin säännöt sitovat yhteen tapahtumat, roolit ja tuotokset ja ohjaavat niiden välistä vuorovaikutusta. Säännöt on kuvattu tässä dokumentissa.

Scrumin käyttöön liittyvät taktiikat vaihtelevat ja niitä on kuvattu toisaalla.

Scrumin käyttötarkoitukset Scrum kehitettiin alun perin tuotehallintaan ja tuotteiden kehittämiseen. 1990-luvun alkupuolelta lähtien Scrumia on käytetty ympäri maailman laajalti:

1. Soveltuvien markkinoiden, teknologioiden ja tuotteen toimintojen tutkimiseen ja tunnistamiseen

2. Tuotteiden kehittämiseen ja jalostamiseen 3. Tuotteiden ja päivitysten julkaisemiseen jopa useita kertoja päivässä 4. (Saavutettavien, turvallisten, nopeasti pystytettävien) pilvi- ja muiden

tuotantoympäristöjen kehittämiseen ja ylläpitoon, ja 5. Tuotteiden uudistamiseen ja ylläpitoon.

Scrumia on käytetty kehittämään ohjelmistoja, laitteistoja, sulautettuja järjestelmiä, yhteistoimintaverkostoja, itseohjautuvia ajoneuvoja, kouluja, hallintoa ja markkinointia, sekä


hallitsemaan organisaatioiden toimintaa, ja lähes kaikkeen, mitä käytämme päivittäin elämässämme yksilöinä ja yhteisöinä.

Kun teknologia, markkinat, ympäristön monimutkaisuus ja niiden vuorovaikutukset ovat nopeasti kasvaneet, Scrumin hyödyllisyys kompleksisuuden käsittelyssä tulee todistetuksi päivittäin.

Scrum on osoittautunut erityisen tehokkaaksi iteratiivisessa ja inkrementaalisessa tiedon jakamisessa. Scrum on nyt laajasti käytössä tuotteiden, palveluiden ja organisaatioiden hallinnassa.

Scrumin ytimessä on pieni, tiivis tiimi. Yksittäinen tiimi on erittäin joustava ja sopeutumiskykyinen. Nämä vahvuudet toimivat yksittäisen, useamman ja monen tiimin sekä tiimien verkoston tapauksessa, kun nämä kehittävät, julkaisevat, hallinnoivat ja ylläpitävät tuhansien ihmisten työtä ja työn tuloksia. Nämä tiimit työskentelevät yhdessä ja rinnakkain kehittyneiden sovellusarkkitehtuurien ja julkaisuympäristöjen avulla.

Tässä Scrum-oppaassa sanoilla ”kehittää” ja ”kehittäminen” viitataan ylläolevan kaltaiseen kompleksiseen työhön.

Scrumin taustateoria Scrum perustuu empiriiseen prosessinhallintateoriaan, tai empirismiin. Empirismin mukaan tieto perustuu kokemukseen ja päätösten tekemiseen tunnettujen tosiasioiden pohjalta. Scrum hyödyntää iteratiivis-inkrementaalista (toistavaa ja lisäävää) lähestymistapaa ennustettavuuden optimoimiseen ja riskien kontrolloimiseen. Empiirisellä prosessinhallinnalla on kolme tukijalkaa: Läpinäkyvyys, tarkastelu ja sopeuttaminen.

Läpinäkyvyys Prosessin merkittävien tekijöiden tulee olla helposti havaittavissa niille, jotka vastaavat lopputuloksesta. Läpinäkyvyys vaatii, että prosessin merkittävät tekijät määritellään ja sovitaan yhdessä, jotta tarkastelijoilla on yhteinen näkemys siitä, mitä tarkastellaan.

Esimerkiksi:

• Kaikilla osallisilla on yhteinen prosessiin viittaava sanasto, ja • Työn tekijöillä on yhteinen ”valmiin” määritelmä (kts. sivu 17).

Tarkastelu Scrumin käyttäjien tulee säännöllisesti tarkastella Scrumin tuotoksia ja työn edistymistä kohti sprintin tavoitetta, jotta haitalliset poikkeamat voidaan havaita. Tarkastelu ei kuitenkaan saa tapahtua niin tiheästi, että se alkaa häiritä varsinaista työtä. Tarkastelu on hyödyllisintä, kun sen suorittavat ammattitaitoiset tarkastelijat sopivin väliajoin.


Sopeuttaminen Jos tarkastelija päättelee, että yksi tai useampi prosessin osa on hyväksyttävien raja-arvojen ulkopuolella, ja tämän johdosta syntyvää tuotetta olisi mahdoton hyväksyä, tulee tarkastelijan säätää prosessia tai työstettävää ainesta. Säätäminen tulee tehdä niin nopeasti kuin mahdollista, jotta myöhemmät poikkeamat saadaan minimoiduksi.

Scrumissa on neljä muodollista tapahtumaa tarkasteluun ja sopeuttamiseen. Nämä on kuvattu tarkemmin Scrumin tapahtumat -kappaleessa:

• Sprintin suunnittelu • Päivittäispalaveri • Sprintin katselmointi • Retrospektiivi

Scrumin arvot Scrumin arvot ovat sitoutuminen, rohkeus, keskittyminen, avoimuus ja kunnioitus.

Arvojen mukaan toimiessaan Scrum-tiimi vahvistaa Scrumin kolmea tukijalkaa: läpinäkyvyyttä, tarkastelua ja sopeuttamista. Tämä puolestaan kasvattaa luottamusta. Scrum-tiimin jäsenet omaksuvat arvoja työskennellessään Scrumin tapahtumien, roolien ja tuotosten parissa.

Scrumilla onnistuminen riippuu siitä, kuinka hyvin ihmiset pystyvät omaksumaan Scrumin viisi arvoa. Yksilöt sitoutuvat henkilökohtaisesti Scrum-tiimin tavoitteisiin. Scrum-tiimin jäsenillä on rohkeutta toimia oikein ja työstää vaikeita ongelmia. Kaikki keskittyvät sprintin työhön ja Scrum-tiimin tavoitteisiin. Scrum-tiimi sidosryhmineen sopii avoimuudesta liittyen kaikkeen työhön ja sen toteutuksen ongelmiin. Scrum-tiimin jäsenet kunnioittavat toisiaan kyvykkäinä ja itsenäisinä ihmisinä.

Scrum-tiimi Scrum-tiimi koostuu tuoteomistajasta, kehitystiimistä ja scrummasterista. Scrum-tiimit ovat itseohjautuvia ja monitaitoisia. Itseohjautuvat tiimit päättävät itse, kuinka parhaiten tekevät työnsä ulkoisen ohjauksen sijaan. Monitaitoisilla tiimeillä on lisäksi kaikki työn tekemiseen vaadittava osaaminen ilman riippuvuuksia tiimin ulkopuolisiin henkilöihin. Scrumin tiimimalli on suunniteltu joustavuuden, luovuuden ja tuottavuuden optimoimiseksi. Scrum-tiimi on osoittautunut yhä tehokkaammaksi kaikelle edellä mainitulle ja muulle kompleksiselle työlle.

Scrum-tiimit toimittavat tuotteita toistavasti ja lisäävästi, maksimoiden tilaisuudet palautteen saamiseen. Inkrementaaliset “valmiin” tuotteen toimitukset varmistavat, että tuotteesta on aina saatavilla toimiva ja potentiaalisesti hyödyllinen versio.


Tuoteomistaja Tuoteomistaja on vastuussa kehitystiimin työn tuloksena saatavan tuotteen arvon maksimoinnista. Tämän toteutus voi vaihdella suuresti organisaatioiden, Scrum-tiimien ja yksilöiden välillä.

Tuoteomistaja on vastuussa myös tuotteen kehitysjonon hallinnasta. Tämä sisältää:

• Tuotteen kehitysjonon kohtien selkeän ilmaisun • Tuotteen kehitysjonon kohtien järjestämisen siten, että tavoitteet saavutetaan parhaalla

tavalla • Kehitystiimin työn arvon varmistamisen ja maksimoimisen • Tuotteen kehitysjonon avoimuuden, läpinäkyvyyden ja ymmärrettävyyden

varmistamisen siten, että tuotteen kehitysjonosta selviää, mitä Scrum-tiimi tulee tekemään seuraavaksi, ja

• Varmistamisen, että kehitystiimi ymmärtää tuotteen kehitysjonon riittävällä tarkkuudella.

Tuoteomistaja voi itse tehdä yllä kuvatut työt tai pyytää kehitystiimiä tekemään ne. Joka tapauksessa tuoteomistaja on vastuussa niistä.

Tuoteomistaja on yksi henkilö, ei komitea. Tuoteomistaja voi hyödyntää komiteoita tai edustaa sellaisen toiveita tuotteen kehitysjonon kautta, mutta tuotteen kehitysjonon järjestyksen muuttamiseksi tulee aina ensin vakuuttaa tuoteomistaja.

Tuoteomistajan työn onnistumiseksi koko organisaation tulee kunnioittaa hänen päätöksiään. Tuoteomistajan päätökset ovat nähtävillä tuotteen kehitysjonon sisällössä ja järjestyksessä.

Kenelläkään muulla ei ole oikeutta pakottaa kehitystiimiä työskentelemään muiden kuin tuoteomistajan asettamien vaatimusten parissa.

Kehitystiimi Kehitystiimi koostuu ammattilaisista, jotka muuttavat tuotteen kehitysjonon sisällön potentiaalisesti julkaisukelpoikseksi “valmiiksi” inkrementiksi jokaisessa sprintissä. Sprintin aikana tehtävien julkaisujen määrällä ei ole ylärajaa, kunhan tuotetaan vähintään yksi potentiaalisesti julkaisukelpoinen inkrementti. Ainoastaan kehitystiimin jäsenet luovat inkrementtejä.

Organisaatiot muodostavat ja valtuuttavat kehitystiimit organisoimaan ja hoitamaan omaa työtään. Tästä muodostuva synergia parantaa kehitystiimin tehokkuutta ja tuottavuutta. Kehitystiimeillä on seuraavat piirteet:

• Kehitystiimit ovat itseohjautuvia. Ei kukaan – ei edes scrummaster – kerro kehitystiimille, kuinka tuotteen kehitysjono tulisi muuttaa julkaisukelpoiseksi inkrementiksi

• Kehitystiimit ovat monitaitoisia sisältäen kaiken tarvittavan osaamisen potentiaalisesti julkaisukelpoisen inkrementin kehittämiseksi


• Scrum ei tunnusta kehitystiimin jäsenten titteleitä riippumatta henkilön työn sisällöstä. • Scrum ei tunnusta kehitystiimissä alitiimejä, jotka vastaisivat erityisistä osa-alueista kuten

testaamisesta, arkkitehtuurista, kayttöpalveluista tai liiketoiminta-analyysistä, ja • Kehitystiimin jäsenillä voi olla erityistä osaamista tai erilaisia työn painopisteitä, mutta

vastuu kehityksestä kuuluu koko kehitystiimille yhdessä.

Kehitystiimin koko Kehitystiimin optimaalinen koko on riittävän pieni, jotta se pysyy ketteränä ja riittävän suuri, jotta se saa sprintin aikana valmiiksi merkittävän määrän työtä. Vähemmän kuin kolme kehitystiimin jäsentä vähentää vuorovaikutusta ja johtaa pienempiin tuottavuushyötyihin. Liian pieni kehitystiimi saattaa sprintin aikana törmätä osaamispulaan jollakin osa-alueella, eikä välttämättä pysty tuottamaan julkaisukelpoista inkrementtiä. Jos taas kehitystiimissä on yli yhdeksän henkilöä, tarvitaan liikaa koordinointia. Suuret tiimit aiheuttavat liian paljon kompleksisuutta, jotta empiirinen prosessi olisi käyttökelpoinen. Tuoteomistajan ja scrummasterin roolit eivät sisälly näihin lukuihin, elleivät he lisäksi työskentele kehitystiimissä sprintin kehitysjonon tehtävien toteutuksessa

Scrummaster Scrummaster vastaa Scrumin edistämisestä ja tukemisesta sellaisena kuin se on kuvattu tässä Scrum-oppaassa. Scrummasterit tekevät tämän auttamalla kaikkia ymmärtämään Scrumin teorian, käytännöt ja säännöt.

Scrummaster on Scrum-tiimin palveleva johtaja. Scrummaster auttaa Scrum-tiimin ulkopuolisia ymmärtämään mitkä heidän tavoistaan toimia Scrum-tiimin kanssa ovat hyödyllisiä ja mitkä taas eivät. Scrummaster auttaa muuttamaan näitä toimintatapoja maksimoidakseen Scrum-tiimin työn arvon.

Scrummasterin palvelut tuoteomistajalle Scrummaster palvelee tuoteomistajaa useilla eri tavoilla, kuten:

• Varmistamalla, että jokainen Scrum-tiimissä ymmärtää mahdollisimman hyvin tavoitteet, julkaisujen laajuuden ja tuotteen liiketoiminta-alueen

• Ehdottamalla tekniikoita tuotteen kehitysjonon tehokkaaseen hallintaan • Auttamalla Scrum-tiimiä ymmärtämään tarpeen selkeille tuotteen kehitysjonon kohdille • Ymmärtämällä tuotesuunnittelua empiirisessä ympäristössä • Varmistamalla, että tuoteomistaja tietää kuinka tuotteen kehitysjono järjestetään arvon

maksimoimiseksi • Ymmärtämällä ja harjoittamalla ketteryyttä, ja • Fasilitoimalla Scrumin tapahtumia pyydettäessä tai tarpeen mukaan.


Scrummasterin palvelut kehitystiimille Scrummaster palvelee kehitystiimiä useilla eri tavoilla, kuten:

• Valmentamalla kehitystiimiä itseohjautuvuuteen ja moniosaamiseen • Auttamalla kehitystiimiä luomaan korkean lisäarvon tuotteita • Poistamalla esteet kehitystiimin etenemisen tieltä • Fasilitoimalla Scrumin tapahtumia pyydettäessä tai tarpeen mukaan, ja • Valmentamalla kehitystiimiä ympäristöissä, joissa Scrumia ei vielä ole täysin otettu käyttöön

ja ymmärretty.

Scrummasterin palvelut organisaatiolle Scrummaster palvelee organisaatiota useilla eri tavoilla, kuten:

• Johtamalla ja valmentamalla organisaatiota Scrumin käyttöönotossa • Suunnittelemalla Scrumin toteutusta organisaation sisällä • Auttamalla työntekijöitä ja sidosryhmiä ymmärtämään sekä käyttämään Scrumia ja

empiiristä tuotekehitystä • Aiheuttamalla muutoksia, jotka kasvattavat Scrum-tiimin tuottavuutta, ja • Työskentelemällä muiden scrummastereiden kanssa Scrumin käytön tehokkuuden

parantamiseksi organisaatiossa.

Scrumin tapahtumat Scrumissa käytetään ennalta sovittuja tapahtumia luomaan säännöllisyyttä ja minimoimaan muiden kuin Scrum-palavereiden tarve. Kaikki Scrumin tapahtumat ovat aikarajattuja eli jokaisella niistä on maksimipituus. Tapahtumat voidaan päättää ennen niiden maksimipituuden täyttymistä, kunhan aikaa on käytetty riittävästi, eikä prosessissa pääse syntymään hukkaa. Ainoa poikkeus tästä on itse sprintti, joka sisältää muut tapahtumat.

Kaikki Scrumin tapahtumat tarjoavat muodollisen mahdollisuuden tarkastella ja sopeuttaa jotain. Tapahtumat on tarkasti suunniteltu lisäämään tuotekehitykselle kriittisen tärkeää läpinäkyvyyttä ja mahdollistamaan tarkastelu. Yhdenkin tapahtuman jättäminen pois vähentää läpinäkyvyyttä ja johtaa menetettyyn tilaisuuteen tarkastelussa ja sopeuttamisessa.

Sprintti Scrumin ytimenä on sprintti, enintään kuukauden pituinen tai sitä lyhyempi aikaraja, jonka sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti julkaisukelpoinen inkrementti. Sprintin aikana voidaan tehdä yksi tai useampi julkaisu, joista inkrementti koostuu. Sprinteillä on sama pituus koko kehityksen ajan. Uusi sprintti alkaa välittömästi edellisen päätyttyä.

Sprintit koostuvat sprintin suunnittelupalaverista, päivittäispalaverista, kehitystyöstä, sprintin katselmoinnista ja sprintin retrospektiivista.


Sprintin aikana:

• Ei tehdä muutoksia, jotka vaarantaisivat sprintin tavoitteen • Laatutavoitteesta ei tingitä, ja • Sprintin sisältöä voidaan tarkentaa ja siitä voidaan neuvotella tuoteomistajan ja

kehitystiimin välillä, kun opitaan lisää ratkaistavasta ongelmasta.

Kukin sprintti voidaan ajatella enintään kuukauden mittaisena tai lyhyempänä projektina. Kuten projekteja, sprinttejä käytetään tietyn tavoitteen saavuttamiseen. Jokainen sprintti sisältää määritelmän, mitä tullaan toteuttamaan, toteutuksen designin, joustavan suunnitelman, joka ohjaa toteutusta sekä varsinaisen työn ja työn tuloksena syntyvän inkrementin.

Sprintin pituus on rajattu enintään yhteen kalenterikuukauteen. Jos sprintti on liian pitkä, toteutettavan sisällön määritelmä saattaa muuttua, työn kompleksisuus kasvaa ja riski suurentua. Sprintit lisäävät ennustettavuutta mahdollistamalla työn edistymisen tarkastelun ja sopeuttamisen kohti sprintin tavoitetta vähintään kerran kuukaudessa. Sprintit myös rajoittavat riskin enintään yhden kalenterikuukauden kustannukseen.

Sprintin keskeyttäminen Sprintti voidaan keskeyttää ennen sen aikarajan päättymistä. Vain tuoteomistajalla on valta keskeyttää sprintti, mutta hänen päätökseensä voi vaikuttaa sidosryhmien, kehitystiimin tai scrummasterin näkemys.

Sprintti keskeytetään, jos sprintin tavoite muuttuu tarpeettomaksi. Tämä saattaa tapahtua jos yritys vaihtaa suuntaa tai jos markkinat tai teknologiset edellytykset muuttuvat. Yleisesti ottaen sprintti kannattaa keskeyttää, kun sen toteuttaminen ei ole enää kannattavaa. Sprinttien lyhyydestä johtuen keskeyttäminen kuitenkin kannattaa harvoin.

Kun sprintti keskeytetään, mahdolliset “valmiin” määritelmän täyttävät tuotteen kehitysjonon kohdat katselmoidaan. Jos osa niistä on potentiaalisesti julkaistavissa, tuoteomistaja tyypillisesti hyväksyy ne. Keskeneräisiksi jääneet tuotteen kehitysjonon kohdat arvioidaan uudestaan ja siirretään takaisin tuotteen kehitysjonoon. Keskeneräinen työ vanhenee nopeasti ja tulee siksi arvioida säännöllisesti uudelleen.

Sprintin keskeyttäminen kuluttaa resursseja, koska kaikkien tulee järjestäytyä uuteen sprintin suunnittelupalaveriin aloittaakseen uuden sprintin. Sprintin keskeyttämiset ovat usein traumaattisia Scrum-tiimille ja siksi hyvin harvinaisia.

Sprintin suunnittelu Sprintin aikana tehtävä työ suunnitellaan sprintin suunnittelupalaverissa. Tämä suunnitelma luodaan yhteistyössä koko Scrum-tiimin kesken.


Sprintin suunnittelu rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille. Lyhyemmille sprinteille varataan yleensä vähemmän aikaa. Scrummaster varmistaa, että sprintti suunnitellaan ja että osallistujat ymmärtävät tapahtuman tarkoituksen. Scrummaster valmentaa osallistujia pitämään tapahtuman aikarajan sisällä.

Sprintin suunnittelu vastaa seuraaviin kysymyksiin:

• Mitä on mahdollista toimittaa alkavan sprintin inkrementissä? • Miten inkrementin toimittamiseen liittyvä työ voitaisiin toteuttaa?

Ensimmäinen kysymys: Mitä sprintissä tehdään? Kehitystiimi antaa ennusteen toiminnallisuudesta, joka ehditään toteuttaa sprintin aikana. Tuoteomistaja keskustelee kehitystiimin kanssa sprintin tavoitteesta ja tuotteen kehitysjonon kohdista, jotka toteuttamalla päästään sprintin tavoitteeseen. Koko Scrum-tiimi työskentelee yhdessä ymmärtääkseen sprinttiin sisältyvän työn.

Sprintin suunnittelupalaverin lähtökohtana on tuotteen järjestetty kehitysjono, viimeisin inkrementti, kehitystiimin kapasiteetti ja aiempi suorituskyky. Päätös sopivasta työmäärästä on täysin kehitystiimin, koska vain kehitystiimi voi arvioida, mitä se pystyy toteuttamaan alkavassa sprintissä.

Sprintin suunnittelupalaverissa Scrum-tiimi määrittelee yhdessä sprintin tavoitteen. Sprintin tavoitteeseen päästään toteuttamalla valitut tuotteen kehitysjonon kohdat. Sprintin tavoite ohjaa ja muistuttaa kehitystiimiä siitä, miksi se on kehittämässä inkrementtiä.

Toinen kysymys: Miten valittu työ toteutetaan? Määriteltyään sprintin tavoitteen ja sprintissä tehtävän työn kehitystiimi suunnittelee, miten työ toteutetaan “valmiiksi” inkrementiksi. Sprinttiin valitut tuotteen kehitysjonon kohdat sekä suunnitelma niiden toteuttamiseksi on nimeltään sprintin kehitysjono.

Kehitystiimi aloittaa yleensä suunnittelemalla toiminnallisuuden sekä työt, jotka tarvitaan toimivan inkrementin kehittämiseen. Töiden koot voivat vaihdella, mutta kehitystiimi suunnittelee sprintin suunnittelupalaverissa riittävän määrän työtä, jonka se uskoo voivansa toteuttaa alkavassa sprintissä. Sprintin ensimmäisille päiville suunnitellut työt pilkotaan enintään päivän kokoisiin yksiköihin palaverin loppuun mennessä. Kehitystiimi itseohjautuu sekä sprintin suunnittelupalaverissa että sprintin aikana toteuttaakseen sprintin kehitysjonossa olevan työn.

Tuoteomistaja voi olla läsnä myös toteutuksen suunnitteluosassa tarkentaakseen tuotteen kehitysjonon sisältöä ja auttaakseen löytämään kompromisseja. Jos kehitystiimi huomaa, että sprintissä onkin liikaa tai liian vähän työtä, se voi neuvotella uudestaan tuoteomistajan kanssa.


Kehitystiimi voi kutsua mukaan muitakin henkilöitä saadakseen teknisiä tai liiketoiminnallisia neuvoja.

Sprintin suunnittelun loppuun mennessä kehitystiimin tulee osata selittää tuoteomistajalle ja scrummasterille, kuinka se aikoo työskennellä itseohjautuvana tiiminä saavuttaakseen sprintin tavoitteen ja luodakseen ennustamansa inkrementin.

Sprintin tavoite Sprintin tavoite toteutuu tuotteen kehitysjonon valittujen kohtien toteutuksella. Sprintin tavoite ohjaa ja muistuttaa kehitystiimiä siitä, miksi se on kehittämässä inkrementtiä. Sprintin tavoite luodaan sprintin suunnittelupalaverissa.

Sprintin tavoite antaa kehitystiimille hieman liikkumavaraa toteutuksen suhteen. Sprintissä kehitettävät asiat liittyvät usein yhtenäiseen kokonaisuuteen, joka voi olla sprintin tavoite. Sprintin tavoite voi olla mikä tahansa muukin yhteinen tekijä, joka saa kehitystiimin jäsenet työskentelemään yhdessä erillisten tavoitteiden sijaan.

Työskennellessään kehitystiimi pitää tavoitteen mielessä. Päästäkseen tavoitteeseen se toteuttaa sprintin kehitysjonon ja vaaditun teknologisen ratkaisun. Jos työ paljastuu erilaiseksi kuin kehitystiimi oletti, se neuvottelee uudelleen tuoteomistajan kanssa sprintin kehitysjonon sisällöstä.

Päivittäispalaveri Päivittäispalaveri on enintään 15 minuutin mittainen aikarajattu tapahtuma. Päivittäispalaveri pidetään sprintin jokaisena päivänä. Palaverissa tiimi suunnittelee seuraavan 24 tunnin työt. Tarkastelemalla edellisen päivittäispalaverin jälkeen tehtyä työtä ja ennustamalla sprintissä jäljellä olevaa työtä tiimi parantaa yhteistyötään ja suorituskykyään. Yksinkertaisuuden vuoksi päivittäispalaveri pidetään joka päivä samaan aikaan ja samassa paikassa.

Kehitystiimi hyödyntää päivittäispalaveria tarkastellakseen työnsä edistymistä kohti sprintin tavoitetta ja sprintin kehitysjonon toteutumista. Päivittäispalaveri optimoi työpäivän arvon ja todennäköisyyden sille, että kehitystiimi pääsee sprintin tavoitteeseen. Kehitystiimin tulisi päivittäin ymmärtää, kuinka se aikoo työskennellä itseohjautuvana tiiminä saavuttaakseen sprintin tavoitteen ja odotetun inkrementin sprintin loppuun mennessä.

Kehitystiimi päättää päivittäispalaverin ohjelmasta. Palaveri voidaan käydä monella eri tavalla, kunhan fokus säilyy edistymisessä kohti sprintin tavoitetta. Jotkut tiimit käyttävät kysymyksiä, toisilla palaveri pohjautuu enemmän keskusteluun. Esimerkiksi näin:

• Mitä tein eilen auttaakseni kehitystiimiä saavuttamaan sprintin tavoitteen? • Mitä aion tehdä tänään auttaakseni kehitystiimiä saavuttamaan sprintin tavoitteen? • Havaitsenko mitään estettä, joka estää minua tai kehitystiimiä saavuttamasta sprintin

tavoitteen?


Kehitystiimi tai osa kehittäjistä tapaavat usein heti päivittäispalaverin jälkeen esimerkiksi yksityiskohtaisempaa keskustelua tai sprintin jäljellä olevan työn uudelleen suunnittelua tai mukauttamista varten.

Scrummasterin tehtävänä on varmistaa, että kehitystiimillä on päivittäispalaveri. Kehitystiimin vastuulla taas on pitää päivittäispalaveri. Scrummaster valmentaa kehitystiimiä pitämään tapahtuman enintään 15 minuutin mittaisena.

Päivittäispalaveri on kehitystiimin sisäinen. Jos muita on läsnä, scrummaster huolehtii etteivät he vaikuta häiritsevästi kokoukseen.

Päivittäispalaveri parantaa kommunikointia korostaakseen ja edistääkseen nopeaa päätöksentekoa, poistaakseen muita palavereita, tunnistaakseen poistettavia kehittämisen esteitä ja parantaakseen kehitystiimin ymmärrystä. Päivittäispalaveri on tärkeä tilaisuus työn tarkasteluun ja sopeuttamiseen.

Sprintin katselmointi Sprintin lopussa pidetään sprintin katselmointi, jossa tarkastellaan kehitetty inkrementti ja sopeutetaan tarvittaessa tuotteen kehitysjonoa. Sprintin katselmoinnin aikana Scrum-tiimi ja sidosryhmät selvittävät yhteistyössä, mitä sprintissä kehitettiin. Perustuen tähän tietoon ja mahdollisiin sprintin aikana tuotteen kehitysjonoon tehtyihin muutoksiin osallistujat keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi arvon optimoimiseksi. Kyseessä on epämuodollinen palaveri, ei statuskatsaus, jossa inkrementin esittelyn tavoitteena on saada palautetta ja edistää vuoropuhelua.

Sprintin katselmointi rajataan enintään neljään tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan yleensä vähemmän. Scrummaster varmistaa, että tapahtuma pidetään ja osallistujat ymmärtävät sen tarkoituksen. Scrummaster valmentaa osallistujia pitämään tapahtuman aikarajan sisällä.

Sprintin katselmointi sisältää seuraavat elementit:

• Tilaisuuteen osallistuu Scrum-tiimi sekä tuoteomistajan mahdollisesti kutsumat sidosryhmien tärkeimmät edustajat

• Tuoteomistaja selittää mikä osa työstä on “valmista” ja mikä ei ole “valmista” • Kehitystiimi keskustelee, mikä toteutuksessa meni hyvin, mitä ongelmia se kohtasi ja kuinka

ongelmat ratkaistiin • Kehitystiimi esittelee “valmiin” työn ja vastaa inkrementtiin liittyviin kysymyksiin • Tuoteomistaja kertoo tuotteen kehitysjonon tilanteen ja arvioi todennäköistä

valmistumisajankohtaa perustuen tähänastiseen edistymiseen • Koko ryhmä pohtii, mitä voidaan ja kannattaa tehdä seuraavaksi, jotta sprintin katselmointi

antaa hyvän pohjan seuraaville sprintin suunnittelupalavereille


• Tarkistetaan, kuinka markkinatilanne tai tuotteen mahdolliset käyttötavat ovat vaikuttaneet siihen mikä olisi arvokkainta toteuttaa seuraavaksi, ja

• Tarkistetaan tuotteen julkaisun aikataulu, budjetti, markkinatilanne ja potentiaaliset toiminnallisuudet.

Sprintin katselmoinnin tuloksena on tarkistettu tuotteen kehitysjono, joka sisältää todennäköiset tuotteen kehitysjonon kohdat seuraavalle sprintille. Tuotteen kehitysjonoa voidaan myös yleisesti muokata sisältämään uusia kehitysmahdollisuuksia.

Sprintin retrospektiivi Sprintin retrospektiivi antaa Scrum-tiimille tilaisuuden tarkastella toimintaansa ja tehdä suunnitelman kehitysprosessin parannuksille, jotka toteutetaan seuraavassa sprintissä.

Sprintin retrospektiivi pidetään sprintin katselmoinnin jälkeen ja ennen seuraavan sprintin suunnittelupalaveria. Palaveri rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan yleensä vähemmän aikaa. Scrummaster varmistaa, että sprintin retrospektiivi pidetään ja osallistujat ymmärtävät sen tarkoituksen. Scrummaster valmentaa osallistujia pitämään tapahtuman aikarajan sisällä. Scrummaster osallistuu retrospektiiviin Scrum-prosessin omistajana.

Sprintin retrospektiivin tarkoituksena on:

• Tarkastella, kuinka edellinen sprintti sujui liittyen ihmisiin, yhteistyöhön, prosessiin ja työkaluihin

• Tunnistaa asiat, jotka sujuivat hyvin sekä määritellä tärkeimmät parannukset • Luoda suunnitelma Scrum-tiimin työskentelytapojen parantamiseksi.

Scrummaster kannustaa Scrum-tiimiä parantamaan kehitysprosessiaan ja käytäntöjään Scrum-viitekehyksen puitteissa, jotta seuraavista sprinteistä saadaan tuottavampia ja miellyttävämpiä. Retrospektiivissä Scrum-tiimi myös tarkastelee ja tarvittaessa sopeuttaa ”valmiin” määritelmäänsä kasvattaakseen tuotteen laatua.

Sprintin retrospektiivin loppuun mennessä Scrum-tiimi tunnistaa ne prosessin parannukset, jotka se aikoo toteuttaa seuraavan sprintin aikana. Valittujen parannusten toteuttaminen seuraavan sprintin aikana sopeuttaa Scrum-tiimiä sen itseensä kohdistamaan tarkasteluun. Vaikka prosessin parannuksia voidaan toteuttaa milloin tahansa, sprintin retrospektiivi tarjoaa muodollisen tilaisuuden prosessin tarkasteluun ja sopeuttamiseen.

Scrumin tuotokset Scrumin tuotokset kuvaavat työmäärää tai lisäarvoa lisäten siten läpinäkyvyyttä sekä tilaisuuksia tarkastelulle ja sopeuttamiselle. Scrumin tuotokset on suunniteltu erityisesti maksimoimaan läpinäkyvyyden, jotta kaikilla on yhdenmukainen käsitys tuotoksesta.


Tuotteen kehitysjono Tuotteen kehitysjono on järjestetty lista kaikesta mitä tuotteessa tiedetään tarvittavan sekä ainoa lähde tuotteeseen toteutettaville vaatimuksille ja muutoksille. Tuoteomistaja vastaa tuotteen kehitysjonosta mukaan lukien sen sisältö, saatavuus ja järjestäminen.

Tuotteen kehitysjono ei ole koskaan valmis. Sen ensimmäinen versio esittää ainoastaan alustavasti parhaiten tunnetut vaatimukset. Tuotteen kehitysjono kehittyy, kun tuote sekä ympäristö, jossa sitä tullaan käyttämään, kehittyy. Tuotteen kehitysjono on myös dynaaminen; se muuttuu jatkuvasti kuvatakseen, mitä tuote tarvitsee ollakseen tarkoituksenmukainen, kilpailukykyinen ja käyttökelpoinen. Tuotteen kehitysjono on olemassa yhtä kauan kuin tuote.

Tuotteen kehitysjono listaa kaikki ominaisuudet, toiminnot, vaatimukset, parannukset ja korjaukset, jotka tullaan toteuttamaan tuleviin inkrementteihin. Tuotteen kehitysjonon kohdat sisältävät kuvauksen, järjestyksen, työmääräarvion ja arvon. Tuotteen kehitysjonon kohdilla on usein myös testikuvaukset, joiden toteutuminen todistaa kohdan ”valmiiksi”.

Tuotteen kehitysjono kehittyy kattavammaksi listaksi, kun tuotetta käytettäessä sen arvo kasvaa ja saadaan palautetta markkinoilta. Vaatimusten muuttuminen ei pääty koskaan. Tuotteen kehitysjono on elävä dokumentti. Muutokset liiketoiminnan vaatimuksissa, markkinoissa ja teknologiassa aiheuttavat muutoksia myös tuotteen kehitysjonoon.

Useampi Scrum-tiimi työskentelee usein saman tuotteen parissa. Tällöin työtä ohjataan yhdellä tuotteen kehitysjonolla, johon voidaan lisätä vaatimusten ryhmittelyä tukeva tunniste.

Tuotteen kehitysjonon jalostaminen tarkoittaa yksityiskohtien, työmääräarvioiden ja kehitysjonon kohtien keskinäisen järjestyksen lisäämistä. Kyseessä on toistuva prosessi, jossa tuoteomistaja ja kehitystiimi lisäävät yhteistyössä yksityiskohtia tuotteen kehitysjonoon. Jalostamisen aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. Jalostamisen käytännön toteutuksesta päätetään Scrum-tiimin sisällä. Jalostamiseen käytetään yleensä enintään 10% kehitystiimin kapasiteetista. Tuotteen kehitysjonon kohtia voidaan kuitenkin päivittää milloin tahansa muulloinkin tuoteomistajan päätöksellä.

Tuotteen kehitysjonossa korkealle järjestetyt kohdat ovat yleensä selkeämpiä ja yksityiskohtaisempia kuin matalammalle järjestetyt kohdat. Tarkemmat työmääräarviot perustuvat suurempaan selkeyteen ja yksityiskohtien määrään. Mitä matalammalla kehitysjonon kohta on, sitä vähemmän siinä yleensä on yksityiskohtia. Seuraavaan sprinttiin valittavat tuotekehitysjonon kohdat tulee jalostaa niin pieniksi, että kukin yksittäinen kohta voidaan tehdä “valmiiksi” sprintin loppuun mennessä. Tuotteen kehitysjonon kohtia, jotka kehitystiimi voi saada “valmiiksi” yhden sprintin aikana, kutsutaan sprintin suunnittelupalaverissa ”valmistelluksi” sprinttiin valintaa varten.

Kehitystiimi vastaa kaikista työmääräarvioista. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään vaatimuksia ja tekemään kompromisseja, mutta ihmiset, jotka tekevät työn, antavat lopullisen työmääräarvion.


Edistymisen seuraaminen kohti tavoitteita Jäljellä oleva kokonaistyömäärä seuraavan tavoitteen saavuttamiseksi on milloin tahansa laskettavissa yhteen. Tuoteomistaja tarkistaa jäljellä olevan kokonaistyömäärän vähintään jokaisessa sprintin katselmoinnissa. Lisäksi tuoteomistaja vertaa lukua edellisten sprinttien katselmointien vastaaviin lukuihin arvioidakseen työn edistymisnopeutta kohti tavoitetta sekä toivotun aikarajan toteutumista. Tämä tieto tallennetaan läpinäkyvästi kaikkien sidosryhmien edustajien saataville.

Scrumissa on käytetty erilaisia käyriä ennustamaan tuotekehityksen edistymistä. Tällaiset edistymiskäyrät on havaittu hyödyllisiksi, mutta ne eivät korvaa empiirisyyttä. Monimutkaisissa ympäristöissä tulevaa ei voida täysin ennustaa. Vain sitä, mitä on todella tapahtunut, voidaan käyttää tulevaisuuteen liittyvässä päätöksenteossa.

Sprintin kehitysjono Sprintin kehitysjono koostuu sprinttiin valituista tuotteen kehitysjonon kohdista sekä suunnitelmasta toimittaa inkrementti ja saavuttaa sprintin tavoite. Sprintin kehitysjono on kehitystiimin antama ennuste siitä, mitä toiminnallisuutta seuraavaan inkrementtiin tulee sisältymään sekä tarvittavasta työstä toiminnallisuuden toteuttamiseksi.

Sprintin kehitysjono tekee näkyväksi kaiken työn, jonka kehitystiimi tunnistaa tarpeelliseksi saavuttaakseen sprintin tavoitteen. Jatkuvan kehityksen varmistamiseksi sprintin kehitysjono sisältää vähintään yhden korkean prioriteetin parannuksen, joka tunnistettiin edellisen sprintin retrospektiivissa.

Sprintin kehitysjonon tulee olla riittävän yksityiskohtainen, jotta työn edistyminen voidaan havaita päivittäispalaverissa. Kehitystiimi muokkaa sprintin kehitysjonoa koko sprintin ajan oppiessaan lisää siitä, mitä tarvitaan sprintin tavoitteen saavuttamiseksi. Tämän vuoksi sprintin kehitysjono muodostuu sprintin aikana.

Mikäli uutta työtä tarvitaan sprintin kehitysjonon toteuttamiseksi, kehitystiimi lisää sen sprintin kehitysjonoon. Kun työtä tehdään tai sitä valmistuu, arvioitua jäljelläolevaa työmäärää päivitetään. Jos suunnitelman osa havaitaan tarpeettomaksi, se poistetaan. Ainoastaan kehitystiimi voi muuttaa sprintin kehitysjonoa sprintin aikana. Sprintin kehitysjono on näkyvä, reaaliaikainen kuva työstä, jonka kehitystiimi aikoo saada valmiiksi sprintin aikana, ja se kuuluu yksinomaan kehitystiimille.

Sprintin edistymisen seuraaminen Sprintin kehitysjonon jäljellä oleva kokonaistyömäärä on milloin tahansa laskettavissa yhteen. Kehitystiimi päivittää tätä kokonaistyömäärää vähintään jokaisessa päivittäispalaverissa arvioidakseen todennäköisyyttä sprintin tavoitteen saavuttamiselle. Seuraamalla jäljellä olevaa kokonaistyömäärää sprintin läpi kehitystiimi voi hallita omaa edistymistään.


Inkrementti Inkrementti on summa kaikista tuotteen kehitysjonon kohdista, jotka ovat valmistuneet sprintin ja aiempien sprinttien aikana. Sprintin lopussa siinä valmistuneen inkrementin tulee olla “valmis”, joka tarkoittaa, että se täyttää Scrum-tiimin “valmiin” määritelmän ja on käyttökelpoisessa kunnossa. Inkrementti on tarkasteltavissa oleva valmis kokonaisuus, joka tukee empiirisyyttä. Inkrementti on ensimmäinen askel kohti visiota tai tavoitetta. Inkrementin tulee olla käyttökelpoisessa kunnossa riippumatta siitä, päättääkö tuoteomistaja julkaista sen.

Tuotosten läpinäkyvyys Scrum perustuu läpinäkyvyyteen. Päätökset, joiden perusteella optimoidaan arvoa ja kontrolloidaan riskejä, perustuvat tarkastelussa havaittuun tuotosten tilaan. Täydellisen läpinäkyvyyden vallitessa päätökset perustuvat todelliseen tietoon. Heikon läpinäkyvyyden vallitessa päätökset voivat olla virheellisiä, ne voivat vähentää tuotosten arvoa ja kasvattaa riskejä.

Scrummasterin tulee työskennellä tuoteomistajan, kehitystiimin ja mahdollisesti muiden tahojen kanssa varmistaakseen, että tuotokset ovat täysin läpinäkyviä. Tarvittaessa scrummaster auttaa soveltamaan erilaisia parhaita käytäntöjä heikon läpinäkyvyyden korjaamiseen. Scrummaster voi havaita heikon läpinäkyvyyden tarkastelemalla tuotoksia, tunnistamalla tapahtumasarjoja, kuuntelemalla tarkasti keskusteluja ja havaitsemalla eroja odotettujen ja todellisten tulosten välillä.

Scrummasterin tehtävänä on työskennellä yhdessä Scrum-tiimin ja organisaation kanssa lisätäkseen tuotosten läpinäkyvyyttä. Työ sisältää yleensä oppimista, ihmisten vakuuttamista ja muutosta. Läpinäkyvyys ei toteudu hetkessä, vaan se on polku.

“Valmiin” määritelmä Kun tuotteen kehitysjonon kohdan tai inkrementin sanotaan olevan “valmis”, kaikkien tulee ymmärtää mitä “valmis” tarkoittaa. Vaikka määritelmä vaihtelee suuresti eri Scrum-tiimien välillä, tiimin jäsenillä tulee olla yhteinen ymmärrys siitä, mitä valmis työ tarkoittaa, jotta läpinäkyvyys turvataan. Tämä on Scrum-tiimin “valmiin” määritelmä ja sitä käytetään arvioimaan, milloin inkrementtiin liittyvä työ on valmis.

Valmiin määritelmä auttaa kehitystiimiä arvioimaan, montako tuotteen kehitysjonon kohtaa se voi valita sprintin suunnittelussa. Jokaisen sprintin tavoitteena on toimittaa potentiaalisesti julkaistavissa oleva inkrementti, joka noudattaa Scrum-tiimin nykyistä “valmiin” määritelmää.

Kehitystiimit toimittavat inkrementin jokaisessa sprintissä. Inkrementin ollessa käyttökelpoinen tuoteomistaja voi päättää julkaista sen välittömästi. Jos inkrementin ”valmiin” määritelmään liittyy kehitysorganisaation standardeja tai määräyksiä, kaikkien Scrum-tiimien tulee noudattaa määritelmää miniminään. Jos taas inkrementin ”valmiin” määritelmään ei liity kehitysorganisaation standardeja tai määräyksiä, kehitystiimi määrittelee inkrementille sopivan


valmiin määritelmän. Mikäli inkrementtiä kehittää useampi Scrum-tiimi, niiden kehitystiimien tulee sopia yhteisestä valmiin määritelmästä.

Jokainen inkrementti rakentuu kaikkien aikaisempien inkrementtien päälle ja on läpikotaisin testattu. Näin varmistetaan, että kaikki inkrementit toimivat yhdessä.

Kun Scrum-tiimit kypsyvät, niiden “valmiin” määritelmä laajenee sisältämään tiukemmat kriteerit korkealle laadulle. Kaikilla tuotteilla tai järjestelmillä tulisi olla ”valmiin” määritelmä, joka määrittää standarditason tuotteeseen tehtävälle työlle.


Loppuviite Scrumin voi opiskella tästä oppaasta ja sen käyttäminen on maksutonta. Scrumin roolit, tuotokset, tapahtumat ja säännöt ovat muuttumattomia, ja vaikka Scrumin toteuttaminen vain osittain on mahdollista, siitä syntyvää lopputulosta ei voi kutsua Scrumiksi. Scrum on olemassa vain kokonaisuudessaan ja soveltuu hyvin kehykseksi muille tekniikoille, menetelmille ja käytännöille.

Huomionosoitukset Ihmiset Tuhannet ihmiset ovat avustaneet ja tukeneet Scrumin kehitystä. Suurimman panoksen ovat antaneet ensimmäisten kymmenen vuoden aikana Jeff Sutherland työskennellessään Jeff McKennan ja John Scumniotalesin kanssa sekä Ken Schwaber työskennellessään Mike Smithin ja Chris Martinin kanssa, sekä kaikki edellämainitut yhdessä. Monet muut osallistuivat Scrumin kehittämiseen seuraavina vuosina ja ilman heidän apuaan Scrum ei olisi yhtä jalostunut kuin se on nykyisin.

Historia Ken Schwaber ja Jeff Sutherland esittelivät ja julkaisivat Scrumin OOPSLA-seminaarissa 1995. Esitys dokumentoi ne opit, jotka Ken ja Jeff olivat hankkineet käyttäessään Scrumia muutaman vuoden ajan.

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).

Scrum-opas sisältää Jeff Sutherlandin ja Ken Schwaberin yli 20-vuotisen Scrum-kehityksen tulokset. Muut lähteet tarjoavat malleja, prosesseja ja oivalluksia, jotka täydentävät Scrum-viitekehystä ja optimoivat tuottavuuden, arvon, luovuuden ja ylpeyden omasta työstä.

Käännös Tämä opas on käännetty Ken Schwaberin ja Jeff Sutherlandin englanninkielisestä alkuperäisteoksesta. Käännöksen on tehnyt Lare Lekman apunaan kotimaiset Scrum-ammattilaiset Arto Eskelinen, Tommi Kemppi, Maarit Laanti, Jukka Lindström, Karoliina Luoto, Towo Toivola, Pentti Virtanen ja Martin von Weissenberg maaliskuussa 2018.

Lähetä muutos- ja korjauspyynnöt tarvittaessa Lare Lekmanille: [email protected]


Muutokset versioiden 2016 ja 2017 välillä

1. Lisätty kappale Scrumin käyttötarkoituksista Scrum kehitettiin alun perin tuotehallintaan ja tuotteiden kehittämiseen. 1990-luvun alkupuolelta lähtien Scrumia on käytetty ympäri maailman laajalti:

1. Soveltuvien markkinoiden, teknologioiden ja tuotteen toimintojen tutkimiseen ja tunnistamiseen

2. Tuotteiden kehittämiseen ja jalostamiseen 3. Tuotteiden ja päivitysten julkaisemiseen jopa useita kertoja päivässä 4. (Saavutettavien, turvallisten, nopeasti pystytettävien) pilvi- ja muiden

tuotantoympäristöjen kehittämiseen ja ylläpitoon, ja 5. Tuotteiden uudistamiseen ja ylläpitoon.

Scrumia on käytetty kehittämään ohjelmistoja, laitteistoja, sulautettuja järjestelmiä, yhteistoimintaverkostoja, itseohjautuvia ajoneuvoja, kouluja, hallintoa ja markkinointia, sekä hallitsemaan organisaatioiden toimintaa, ja lähes kaikkeen, mitä käytämme päivittäin elämässämme yksilöinä ja yhteisöinä.

Kun teknologia, markkinat, ympäristön monimutkaisuus ja niiden vuorovaikutukset ovat nopeasti kasvaneet, Scrumin hyödyllisyys kompleksisuuden käsittelyssä tulee todistetuksi päivittäin.

Scrum on osoittautunut erityisen tehokkaaksi iteratiivisessa ja inkrementaalisessa tiedon jakamisessa. Scrum on nyt laajasti käytössä tuotteiden, palveluiden ja organisaatioiden hallinnassa.

Scrumin ytimessä on pieni, tiivis tiimi. Yksittäinen tiimi on erittäin joustava ja sopeutumiskykyinen. Nämä vahvuudet toimivat yksittäisen, useamman ja monen tiimin sekä tiimien verkoston tapauksessa, kun nämä kehittävät, julkaisevat, hallinnoivat ja ylläpitävät tuhansien ihmisten työtä ja työn tuloksia. Nämä tiimit työskentelevät yhdessä ja rinnakkain kehittyneiden sovellusarkkitehtuurien ja julkaisuympäristöjen avulla.

Tässä Scrum-oppaassa sanoilla ”kehittää” ja ”kehittäminen” viitataan ylläolevan kaltaiseen kompleksiseen työhön.

2. Muutettu Scrum Master –kappaletta tuomaan rooliin lisää selkeyttä:

Scrummaster vastaa Scrumin edistämisestä ja tukemisesta sellaisena kuin se on kuvattu tässä Scrum-oppaassa. Scrummasterit tekevät tämän auttamalla kaikkia ymmärtämään Scrumin teorian, käytännöt ja säännöt.

Scrummaster on Scrum-tiimin palveleva johtaja. Scrummaster auttaa Scrum-tiimin ulkopuolisia ymmärtämään mitkä heidän tavoistaan toimia Scrum-tiimin kanssa ovat hyödyllisiä ja mitkä taas eivät. Scrummaster auttaa muuttamaan näitä toimintatapoja maksimoidakseen Scrum-tiimin työn arvon.


3. Lisätty kohta scrummasterin palveluista tuoteomistajalle Varmistamalla, että jokainen Scrum-tiimissä ymmärtää mahdollisimman hyvin tavoitteet, julkaisujen laajuuden ja tuotteen liiketoiminta-alueen 4. Päivitetty päivittäispalaverin ensimmäinen kappale muotoon: Päivittäispalaveri on enintään 15 minuutin mittainen aikarajattu tapahtuma. Päivittäispalaveri pidetään sprintin jokaisena päivänä. Palaverissa tiimi suunnittelee seuraavan 24 tunnin työt. Tarkastelemalla edellisen päivittäispalaverin jälkeen tehtyä työtä ja ennustamalla sprintissä jäljellä olevaa työtä tiimi parantaa yhteistyötään ja suorituskykyään. Yksinkertaisuuden vuoksi päivittäispalaveri pidetään joka päivä samaan aikaan ja samassa paikassa. 5. Muutettu päivittäispalaveri –kappaletta tuomaan lisää selkeyttä päivittäispalaverin tavoitteisiin: Kehitystiimi asettaa itse palaverin agendan. Palaveri voidaan käydä monella eri tavalla, kunhan fokus säilyy edistymisessä kohti sprintin tavoitetta. Jotkut tiimit käyttävät kysymyksiä, toisilla palaveri pohjautuu enemmän keskusteluun. Esimerkiksi näin:

• Mitä tein eilen auttaakseni kehitystiimiä saavuttamaan sprintin tavoitteen? • Mitä aion tehdä tänään auttaakseni kehitystiimiä saavuttamaan sprintin tavoitteen? • Havaitsenko mitään estettä, joka estää minua tai kehitystiimiä saavuttamasta sprintin

tavoitteen?

6. Lisätty selkeyttä aikarajoihin

Käyttämällä sanaa “enintään” on pyritty selkeyttämään, että tapahtuman ei tarvitse olla koko aikarajan mittainen, vaan enintään aikarajan mittainen.

7. Lisätty tarkennus sprintin kehitysjono –kappaleeseen: Jatkuvan kehityksen varmistamiseksi sprintin kehitysjono sisältää vähintään yhden korkean prioriteetin parannuksen, joka tunnistettiin edellisen sprintin retrospektiivissä.

8. Lisätty tarkennus inkrementti –kappaleeseen: Inkrementti on tarkasteltavissa oleva valmis kokonaisuus, joka tukee empiirisyyttä. Inkrementti on ensimmäinen askel kohti visiota tai tavoitetta.

Documents

Scrum-opas™ - scrumwell.files.wordpress.com · Scrum-opas™ Scrumin määritelmä ja pelisäännöt Lokakuu 2017 Kirjoittajat ovat Scrumin kehittäjät Ken Schwaber ja Jeff Sutherland