You are on page 1of 22

 

February 2009
 

Scrum:  Developed  and  sustained  by  Ken  Schwaber  and  Jeff  Sutherland  

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.

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

Läpinäkyvyyden lisäksi tekijöiden tulee olla yksiselitteisesti tulkittavissa. Onneksi tämä ei näyttäisi olevan ongelma ohjelmistokehityksessä. Tulee kuitenkin ottaa huomioon. kuinka Scrum toimii tuotekehityksessä.Tarkoitus Scrumia on hyödynnetty monimutkaisten tuotteiden kehittämiseen 1990-luvun alusta lähtien. joissa monimutkaisten tuotteiden kehittäminen on mahdollista. kun prosessin tarkastelun tiheys ylittää prosessin sietokyvyn. Empiirisellä prosessinhallinnalla on kolme tukijalkaa. jotka hallinnoivat lopputulosta. jonka sisällä voi käyttää useita erilaisia prosesseja ja tekniikoita. Scrumin teoria Scrum perustuu empiiriseen prosessinhallintateoriaan. että jo prosessin tarkasteleminen voi muuttaa prosessia. Tämä opas kuvaa.  All  Rights  Reserved     Page  |  3   . ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Scrumin roolina on tuoda esille kehitysmenetelmien todelliset vaikutukset. Se käyttää iteratiivis-inkrementaalista (toistavaa-lisäävää) lähestymistapaa ennustettavuuden optimoimiseen ja riskien kontrolloimiseen. että kun tehtävä on valmis. Scrum ei ole tuotekehitysprosessi tai -tekniikka. jotta haitalliset poikkeamat voidaan havaita. Pulmatilanne syntyy. Ensimmäinen tukijalka on läpinäkyvyys Läpinäkyvyys tarkoittaa. Näin menetelmiä voidaan säännöllisesti parantaa ja tarjota samalla puitteet. 21). koska toinen tärkeä tekijä on prosessia tarkastelevien henkilöiden ammattitaito. että prosessin lopputulokseen vaikuttavien tekijöiden tulee olla näkyvissä niille. Toinen tukijalka on tarkastelu Prosessin eri osia tulee tarkastella riittävän usein. se vastaa tarkastelijoiden ymmärtämää valmiin määritelmää (s. vaan paremminkin viitekehys. Tämä tarkoittaa.

joilla on kaikki tarvittava osaaminen muuttaa tuoteomistajan vaatimukset julkaisukelpoiseksi tuoteparannukseksi sprintin loppuun mennessä. jossa tarkastellaan edellistä sprinttiä ja määritetään mitkä sopeutukset tekevät seuraavasta sprintistä tuottavamman ja nautinnollisemman. jotka optimoivat seuraavan sprintin arvon. jotta myöhemmät poikkeamat minimoidaan. Scrum käyttää aikarajoja säännöllisyyden luomiseen. Scrumin sydän on ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Scrumtiimit on suunniteltu optimoimaan työn joustavuus ja tuottavuus. Jokaisessa scrumtiimissä on kolme roolia: 1) Scrummaster vastaa Scrumin ymmärtämisestä ja seuraamisesta. aikarajoista. sprintin katselmointikokous ja sprintin retrospektiivi. sprintti. 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ä.ja katselmointikokouksissa tarkastellaan edistymistä kohti tuotteen julkaisutavoitetta ja tehdään sopeutuksia. joka koostuu scrumtiimeistä rooleineen. jotka optimoivat työpäivän arvon. 3) Viimeisenä on sprintin retrospektiivi –kokous. dokumenteista ja säännöistä. joita kutsutaan sprinteiksi. 2) tuoteomistaja vastaa scrumtiimin työn arvon maksimoimisesta ja 3) kehitystiimi tekee työn. Siksi ne ovat itseorganisoituvia. sisältävät kaiken tarvittavan osaamisen ja työskentelevät iteraatioissa eli kehitysjaksoissa. tulee tarkastelijan säätää prosessia tai käytettäviä materiaaleja. Scrumin aikarajatut elementit ovat julkaisun suunnittelukokous. Kehitystiimi koostuu henkilöistä.Kolmas tukijalka on sopeuttaminen Jos tarkastelija päättelee. 2) Sprintin suunnittelu. Scrumin sisältö Scrum on viitekehys. sprintin suunnittelukokous.  All  Rights  Reserved     Page  |  4   . päivän Scrum. Säätäminen tulee tehdä niin nopeasti kuin mahdollista. Scrumissa on kolme kohtaa tarkasteluun ja sopeuttamiseen: 1) Päivän Scrum –kokouksessa seurataan edistymistä kohti sprintin eli kehitysjakson tavoitetta ja tehdään sopeutuksia.

Kehitystiimi on sprintin tehtävälistan “sika”. Yksi Scrumin kohdalta puuttuu. Scrumissa on neljä pääasiallista dokumenttia. Tuotteen kehitysjono on priorisoitu lista kaikesta. toimiiko se.  All  Rights  Reserved     Page  |  5   . Julkaisun edistymiskäyrä mittaa tuotteen jäljellä olevaa kehitysjonoa suhteessa julkaisusuunnitelman aikaan. Kokeile sen tuoteparannuksen. roolit ja dokumentit. enintään kuukauden mittainen iteraatio eli kehitysjakso. saavat puhua sijaan jotain ja katso. on kuvattu Vinkki - laatikoissa. keksiä täydellistä ratkaisua. Kanojen ei tule kertoa sioille.sprintti. Scrumin roolit Scrumtiimi koostuu scrummasterista. että vain itse. tuoteomistajasta ja kehitystiimistä. Sprintin tehtävälista on lista tehtäviä. jonka pituus pidetään samana koko kehityshankkeen ajan. joiden avulla yhden sprintin tehtävälistasta tuotetaan julkaisukelpoinen tuoteparannus. kuuluva ‘tarkastele ja sopeuta’ –mekanismi ohjaa jotka eivät ole sääntöjä vaan oikeaan suuntaan. kuinka heidän työnsä tulisi tehdä. Kaikki muut ovat “kanoja”. mitä tehdä. ehdotuksia. Scrumin käyttäjien oletetaan keksivän säännöistä on. mitä tuotteessa saatetaan tarvita. Älä yritä kehitystiimin jäsenet eli henkilöt. Vinkki Säännöt kuvataan tässä Mikäli sääntö joltakin dokumentissa. jotka ovat sitoutuneet kehittämään koska ongelma muuttuu usein nopeasti. Jokainen sprintti alkaa välittömästi edellisen sprintin jälkeen. Säännöt sitovat yhteen Scrumin aikarajat. Tuoteomistaja on tuotteen kehitysjonon “sika”. Scrumtiimin jäseniä kutsutaan “sioiksi”. Scrumin empiiriseen luonteeseen Sellaiset Scrumin toteutustavat. Kaikki sprintit käyttävät samaa Scrumin viitekehystä tuottaen julkaisukelpoisen tuoteparannuksen. päivän Scrum –kokouksessa. Scrummaster on Scrum-prosessin “sika”. Kanat ja siat perustuvat seuraavaan tarinaan: ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Sprintin edistymiskäyrä mittaa sprintin jäljellä olevaa tehtävälistaa suhteessa sprintin aikaan.

Scrummaster auttaa Scrummaster opastaa ja organisaatiota omaksumaan tukee tuoteomistajaa hänen työnsä hoitamisessa. säännöissä. joka ei Scrummaster voi tehdä välttämättä ole vielä optimoitu kehitystyötä kehitystiimin monimutkaisten tuotteiden jäsenenä. Kana ja sika tapaavat. kutsutaan sitä “esteiden kehitystehtävien toteutuksen ja tiimin poistamiseksi”.  All  Rights  Reserved     Page  |  6   . Scrumin. Scrummasterin rooli esteiden poistamisen on palvella ja edustaa välillä. Scrummaster opastaa ja Tuoteomistajan odotetaan valmentaa scrumtiimiä pystyvän optimoimaan työskentelemään tuottavammin ja tuotteen arvon Scrumia hyödyntämällä. Minä joutuisin sitoutumaan. Jos hän ei kehittämään laadukkaampia pysty tähän. käytännöissä ja valitakseen tuoteomistajan. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Kun scrummaster konflikteihin. Scrummaster auttaa scrummasteria scrumtiimiä ymmärtämään ja edesvastuussa. 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. että scrumtiimi pitäytyy Scrummaster työskentelee asiakkaan ja johdon kanssa Scrumin arvoissa. kun auttaa toteuttamaan nämä scrummasterin tulee valita muutokset. käyttämään itseorganisoitumista sekä moniosaamista. Tämä saattaa kuitenkin johtaa kehittämiseen. pidetään tuotteita. Scrummasterin ei itseohjautuvaa scrumtiimiä. Scrummaster myös auttaa scrumtiimiä tekemään Vinkki parhaansa ympäristössä. kun sinä taas olisit vain mukana!” Scrummaster Scrummasterin vastuulla on Vinkki varmistaa. koskaan tulisi olla tuoteomistaja.

eikä kehitystiimien sallita kuunnella ketään. jotka siirtyvät työskennellä projektin Scrumiin. tuoteomistajana voi toimia Tämä henkilö ylläpitää tuotteen tuotepäällikkö. Tuoteomistajalla voi olla tukenaan komiteoita. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. tapoihin priorisoida ja määritellä vaatimuksia. Kenenkään ei sallita pyytää kehitystiimiä työskentelemään muilla prioriteeteilla. Tuoteomistajan päätökset näkyvät tuotteen kehitysjonon prioriteeteissa ja sisällössä.Tuoteomistaja Tuoteomistaja on yksi ja ainoa henkilö. joka väittää toisin. että tuoteomistajana voi toimia se on kaikkien nähtävissä. prioriteetti. ei komitea. mikä tekee tuoteomistajan roolista vaativan ja palkitsevan. Tuoteomistajan työn onnistumiseksi organisaation kaikkien henkilöiden tulee kunnioittaa hänen päätöksiään. Tuoteomistaja on yksi henkilö. Tämä lisävastuu saattaa kuitenkin heikentää vakuuttaa tuoteomistaja. Tämä näkyvyys vaatii tuoteomistajaa tekemään parhaansa. Organisaation sisäisessä kehityksessä kehitysjonoa ja varmistaa. millä töillä on korkein päällikkö. Tuoteomistaja ei voi koskaan että tämä vaikuttaa pikkuhiljaa toimia scrummasterina. joten kaikki tietävät. tuoteomistajan kykyä Yritykset. Kaikki automatisoitavan toimialan näkevät. mutta Vinkki tuotteen kehitysjonon Tuoteomistaja voi osallistua prioriteettien muuttamiseksi kehitystyöhön kehitystiimin näiden henkilöiden tulee jäsenenä. mitä tullaan tekemään. joka vastaa tuotteen Vinkki kehitysjonosta ja kehitystiimin Kaupallisessa kehityksessä työn arvon maksimoimisesta.  All  Rights  Reserved     Page  |  7   . sidosryhmien kanssa. saattavat huomata.

joita kaikilla kehitystiimin jäsenillä on. vaikka se vaatisi uusien taitojen oppimista tai vanhojen taitojen palauttamista mieleen. taito ja asenne tuotteen parantamiseen. plus tai miinus kaksi. tarvitaan yksinkertaisesti liikaa koordinointia. kuten testaamiseen tai liiketoiminta-analyysiin. Kehitystiimi ratkaisee asian itsenäisesti. Kehitystiimit ovat itseorganisoituvia.  All  Rights  Reserved     Page  |  8   . eikä välttämättä pysty tuottamaan julkaisukelpoista tuoteparannusta. arkkitehtuuri.ja ylärajoja. laadunvarmistus. jotka ovat rikkoneet näitä tiimikoon ala. Kaikkien tiimin jäsenten tulee sitoutua sprintin yhteiseen tavoitteeseen. On kuitenkin olemassa näyttöä menestyneistä kehitystiimeistä. Lisäksi pieni kehitystiimi saattaa törmätä osaamispulaan jossain sprintin osassa. Tästä muodostuva synergia parantaa koko kehitystiimin suorituskykyä ja tuottavuutta. Tuoteomistajan ja scrummasterin ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Lopputuloksen kannalta tärkeimmät taidot ovat ne. Suuret tiimit aiheuttavat empiirisen prosessin toiminnalle liikaa sekavuutta. Kehitystiimin jäsenillä on usein erityistaitoja. Jos taas kehitystiimissä on yli yhdeksän henkilöä.Kehitystiimi Kehitystiimin jäsenet muuttavat tuotteen kehitysjonon sisällön julkaisukelpoikseksi tuoteparannukseksi jokaisessa sprintissä. Alle viiden hengen kehitystiimissä on vähemmän yhteistyötä ja sen tuloksena vähemmän tuottavuushyötyjä. käytettävyyssuunnittelu tai tietokantasuunnittelu. jotka kieltäytyvät ohjelmoimasta. eivät ne mitä heiltä puuttuu. eivät sovi kehitystiimiin. kehitystiimin jäsenillä tulee olla kaikki vaadittava tieto. Kehitystiimin optimaalinen koko on seitsemän henkilöä. Nämä yhteiset taidot muuttavat vaatimukset julkaistavaksi tuotteeksi. Henkilöt. kuten ohjelmointi. liiketoiminta-analyysi. Kehitystiimit ovat monitaitoisia. Kehitystiimeissä ei käytetä titteleitä eikä kehitystiimejä myöskään pilkota alatiimeihin. Jokainen kehitystiimin jäsen soveltaa omaa osaamistaan kaikkiin haasteisiin. Ei kukaan – ei edes scrummaster – kerro kehitystiimille kuinka tuotteen kehitysjono tulisi muuttaa julkaisukelpoiseksi tuoteparannukseksi. koska ovat arkkitehteja tai suunnittelijoita.

sprintin retrospektiivi ja päivän Scrum. Se asettaa myös todennäköisen toimituspäivän sekä kustannusarvion.  All  Rights  Reserved     Page  |  9   . Scrumissa tuotteita kehitetään iteratiivisesti siten. sprintti. Esteen poistamiseksi tarvittavat tehtävät merkitään tuotteen kehitysjonoon. suurimmat riskit sekä julkaisun ominaisuudet ja toiminnallisuuden. elleivät he työskentele kehitystiimissä “sikoina” sprintin tehtävälistan tehtävien toteutuksessa. muodostuu puuttuvasta suunnittelutiedosta työskentelyn este. että jokainen sprintti kehittää tuotteelle parannuksen. jonka tulisi pitää mikäli suunnitelma ei muutu. Julkaisun suunnittelu on täysin valinnaista. jotka scrumtiimit ja koko organisaatio ymmärtävät ja osaavat kommunikoida toisilleen. kehitystiimin itseorganisoinnilla saavutettu tuottavuushyöty pienenee. Organisaatio voi julkaisusuunnitelman perusteella seurata julkaisun edistymistä sprintti kerrallaan ja tehdä suunnitelmaan tarvittaessa muutoksia. joka tulee poistaa. Aina kun kokoonpanoa vaihdetaan.roolit eivät sisälly näihin lukuihin. Tämän vuoksi kehitystiimin kokoonpanoa ei tulisi muuttaa ilman harkintaa. sprintin katselmointikokous. tuotteen kehitysjonon korkeimmat prioriteetit. Julkaisun suunnittelukokous Julkaisun suunnittelun tavoitteena on asettaa tavoitteet ja suunnitelma. Kehitystiimin kokoonpano saattaa muuttua sprintin lopussa. Mikäli scrumtiimi aloittaa työn ilman julkaisun suunnittelukokousta. Aikarajat Scrumin aikarajatut elementit ovat julkaisun suunnittelukokous. sprintin suunnittelukokous. alkaen kaikkein arvokkaimmasta ja riskipitoisimmasta ominaisuudesta. 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. Peräjälkeen ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland.

Kokonaisuudessaan Scrumin julkaisusuunnittelu todennäköisesti vaatii hieman enemmän aikaa kuin perinteinen suunnittelu. Kun on toteutettu riittävästi julkaisukelpoisia parannuksia. valittuja vaatimuksia. sprintien välillä. tuote julkaistaan. ettei Mikäli kehitystiimi Sprintin tavoitteesta poikkeavia havaitsee sitoutuneensa toimittamaan liian paljon.  All  Rights  Reserved     Page  |  10   . mutta eivät varsinaisesti kuulu Scrumiin. Julkaisusuunnittelu vaatii tuotteen kehitysjonon töiden priorisointia ja aika-arviointia. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Sprintti poistaakseen tai keventääkseen sprinttiin muodostuu sprintin suunnittelusta. Sprintit seuraavat kanssa tuotteen toisiaan peräjälkeen ilman taukoja kehitysjonosta lisää toteutettavaa. Kehitystiimin se keskustelee koostumus ja laatutavoitteet pysyvät tuoteomistajan kanssa samoina koko Sprintin ajan. Tähän on olemassa useita tekniikoita. muutoksia toteuteta. joista on arvoa tuotteen käyttäjille ja sidosryhmille. se valitsee tuoteomistajan retrospektiivista. Niissä suurin osa suunnittelusta tehdään yleensä julkaisuprojektin alussa eikä suunnitelmia muuteta ajan kuluessa. Tähän kuluu yleensä vain 15-20% ajasta. Scrumin julkaisusuunnittelussa taas määritellään vain yleinen tavoite ja todennäköiset seuraukset. Lisäksi Scrumissa hyödynnetään oikea-aikaista Just-In- Time -suunnittelua jokaisessa sprintin katselmointi. jotka ovat hyödyllisiä. sprintin taas kehitystiimillä on katselmoinnista ja sprintin ylimääräistä aikaa. Monilla organisaatioilla on jo käytössä julkaisun suunnitteluprosessi. ja suunnittelukokouksessa sekä päivän Scrum -kokouksissa. Jos varsinaisesta kehitystyöstä.toistuvat sprintit kehittävät lisää tuotteen parannuksia. Jokainen parannus on julkaistavissa oleva siivu koko tuotteesta. jonka organisaatio tarvitsee perinteisen julkaisusuunnitelman luomiseen. Sen Vinkki aikana Scrummaster varmistaa. Sprintti Sprintti tarkoittaa aikarajattua iteraatiota eli kehitysjaksoa.

Projektia käytetään jonkin saavuttamiseen. Jokainen projekti koostuu määritelmästä mitä kehitetään. voi ilmestyä uusia muuttujia ja riski saattaa kasvaa liian suureksi. kehitystiimin tai scrummasterin toivomuksesta. Kaikki muut kehitysjonon kohdat siirretään takaisin tuotteen kehitysjonoon alkuperäisine aika-arvioineen ja niihin mahdollisesti tehty työ oletetaan menetetyksi. kuin sprintin aikaraja täyttyy. mutta hän voi halutessaan tehdä niin sidosryhmien. Ohjelmistokehityksessä sitä käytetään tuotteen tai järjestelmän kehittämiseen. Tällainen tilanne voi syntyä. kaikki siinä toteutetut “valmiit” tuotteen kehitysjonon kohdat katselmoidaan ja hyväksytään. koska pidempi Kun kehitystiimi aloittaa Scrumin. Vain tuoteomistajalla on valta keskeyttää sprintti. Jos horisontti on liian kaukana. markkinat tai teknologinen ympäristö muuttuu. jonka aikana suunnitelma on realistinen. Vinkki joiden horisontti on enintään kuukauden mittainen. Missä tilanteessa sprintti sitten tulisi keskeyttää? Johto voi pyytää keskeyttämään sprintin mikäli sen tavoite vanhenee. muiden kehitystiimien kanssa yhdistämällä kaksi julkaisukelpoista Sprintti voidaan keskeyttää ennen tuoteparannusta. Sprintin keskeytys kuluttaa resursseja. koska kaikkien ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland.  All  Rights  Reserved     Page  |  11   . näkymä eteenpäin. suunnitelmasta kuinka se kehitetään. Jokaisella projektilla on horisontti. vähintään kuukauden välein sekä Tämän pituiset sprintit arvioida projektin ennustettavuuden voidaan synkroinoida tai kontrollin kadottamisen riskiä. Yleisesti ottaen sprintti tulee keskeyttää jos sen jatkaminen ei ole enää mielekästä nykyisessä tilanteessa. Scrum on viitekehys projekteille. jos yrityksen suunta. mikäli niistä voidaan muodostaa julkaisukelpoinen tuoteparannus. määritelmä voi muuttua. kahden viikon aika sisältäisi liikaa riskejä. Mikäli sprintti keskeytetään. Sprintin lyhyestä kestosta johtuen keskeyttäminen on kuitenkin harvoin hyödyllistä. suunnitelman mukaisesta toteutustyöstä sekä näiden seurauksena syntyvästä tuotteesta. Projektin sprintit mahdollistavat ennustettavuutta tulee tarkastella työskentelyn ja oppimisen ilman liikaa epätietoisuutta.

Ensimmäisessä osassa päätetään. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Sprintin tavoite antaa kehitystiimille konkreettisen näkökulman ja perustelun. kehitystiimin kapasiteetti ja kehitystiimin aiempi suorituskyky. Jotkut scrumtiimit yhdistävät nämä kaksi osaa. miksi se on kehittämässä tuotteelle parannusta. koska vain kehitystiimi voi arvioida paljonko vaatimuksia se pystyy toteuttamaan alkavassa sprintissä. Tuoteomistaja esittelee kehitystiimille tuotteen kehitysjonon korkeimmat prioriteetit. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa (esimerkiksi kahden viikon sprintille enintään neljä tuntia eli noin 5% koko sprintille varatusta ajasta). Päätös sopivasta työmäärästä on täysin kehitystiimin. Sprintin suunnittelukokous koostuu kahdesta osasta. jonka jälkeen kehitystiimi ja tuoteomistaja miettivät yhdessä mitä toiminnallisuutta tuotteen kehitysjonosta valitaan kehitettäväksi seuraavassa Sprintissä. Sprintin suunnittelukokous koostuu siis “mitä?” -osasta ja “miten?” - osasta.tulee kokoontua suunnittelukokoukseen uuden Sprintin aloittamiseksi. Sprintin suunnittelukokous Sprintin suunnittelukokouksessa suunnitellaan alkava kehitysjakso. Toisessa osassa (neljän tunnin aikaraja kuukauden Sprintille) kehitystiimi ratkaisee kuinka se kehittää tarvitun tuoteparannuksen sprintin aikana.  All  Rights  Reserved     Page  |  12   . Sprintin tavoite on osa koko julkaisun tavoitteesta. Sprintin keskeytykset ovat kehitystiimille yleensä raskaita ja myös siksi hyvin harvinaisia. Kokous rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille. viimeisin tuoteparannus. Kehitysjonon kohtien valinnan jälkeen valitaan sprintin tavoite. Se toteutuu sprinttiin valittujen kehitysjonon kohtien toteutuksen kautta. Ensimmäisessä puoliskossa scrumtiimi selvittää tuoteomistajan johdolla vastauksen kysymykseen “mitä?”. mitä sprintissä tullaan tekemään. Sprintin suunnittelukokouksen lähtökohtana on priorisoitu tuotteen kehitysjono.

jotta kukin niistä voidaan toteuttaa enintään yhdessä työpäivässä.Sprintin tavoite antaa kehitystiimille hieman liikkumavaraa toteutuksen suhteen. Sprintin suunnittelukokouksen toisessa puoliskossa kehitystiimi selvittää vastauksen kysymykseen “miten?”. Sprintin tavoitteena voi esimerkiksi olla “automatisoi asiakastilin muokkaaminen turvallisen transaktio- pohjaisen väliohjelmiston kautta. Päästäkseen tavoitteeseen se toteuttaa toiminnallisuuden ja vaaditun teknologisen ratkaisun. joilla se kehittää sprinttiin valituista tuotteen kehitysjonon kohdista julkaisukelpoisen tuoteparannuksen. Havaittuaan tämän ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Jos kehitystiimi tehtävät jätetään huomaa.” Työskennellessään kehitysryhmä pitää tavoitteen mielessä. Loput kompromisseja. Kehitystiimi voi kutsua mukaan muitakin henkilöitä saadakseen teknisiä tai liiketoiminnallisia neuvoja. Kehitystiimi aloittaa toisen puoliskon (neljän tunnin aikaraja kuukauden sprintille) yleensä tunnistamalla tehtävät. Kehitystiimi itseorganisoituu jakaakseen tehtävälistassa olevat tehtävät keskenään joko sprintin suunnittelukokouksessa tai oikea-aikaisesti sprintin kuluessa (Just-In-Time).  All  Rights  Reserved     Page  |  13   . Uusi kehitystiimi havaitsee yleensä tässä kokouksessa. tuoteomistajan kanssa. ei yksilöinä. että sen täytyy luottaa itseensä. se aika-arviot ja ne pilkotaan voi neuvotella uudestaan pienempiin tehtäviin myöhemmin sprintin aikana. että sprintissä onkin suunniteltaviksi myöhemmin tai niille annetaan suuremmat liikaa tai liian vähän tehtäviä. Tuoteomistaja on läsnä myös sprintin suunnittelun toisella Vinkki puoliskolla tarkentaakseen Yleensä vain noin 60-70% tuotteen kehitysjonon sisältöä ja sprintin tehtävälistasta suunnitellaan sprintin auttaakseen löytämään suunnittelukokouksessa. se kommunikoi tuoteomistajan kanssa ja toteuttaa toiminnallisuuden vain osittain. että se joko uppoaa tai oppii uimaan tiiminä. Tehtävien tulee olla riittävän pienikokoisia. Jos työ paljastuu kehitystiimille ennakoitua vaikeammaksi. Kehitystiimi myös havaitsee. Tämä lista on nimeltään sprintin tehtävälista.

Sprintin retrospektiivi Sprintin katselmointikokouksen jälkeen ja ennen seuraavan sprintin suunnittelukokousta scrumtiimi pitää retrospektiivin. Tämän jälkeen koko scrumtiimi keskustelee uusien tietojen vaikutuksesta seuraaviin sprintteihin. Kehitystiimi myös esittelee tekemänsä työn ja vastaa kysymyksiin. Sprintin katselmointi Jokaisen sprintin lopuksi pidetään sprintin katselmointikokous. Seuraavaksi tuoteomistaja käy läpi tuotteen kehitysjonon nykytilan sisältäen arvion tulevien sprintien kehitysnopeudesta ja tuotteen julkaisuajasta. Kehitystiimi keskustelee mikä sujui hyvin. 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. 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. Sprintin katselmoinnissa scrumtiimi ja muut asianosaiset henkilöt käyvät yhdessä läpi sprintin saavutukset. Sprintin katselmointi on sisällöltään vapaamuotoinen kokous. Kokous rajataan enintään kolmeen tuntiin kuukauden sprintille. mitä seuraavaksi kannattaa tehdä. Katselmoinnin ja tuoteomistajan päivittämän tuotteen kehitysjonon perusteella selvitetään. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa (esimerkiksi kahden viikon sprintille enintään 90 minuuttia). jossa toteutetun toiminnallisuuden demonstraation tarkoituksena on edistää keskustelua siitä mitä tehdään seuraavaksi.5% koko sprintille varatusta ajasta).  All  Rights  Reserved     Page  |  14   . mitä ongelmia ilmeni ja kuinka ongelmat ratkaistiin.kehitystiimi alkaa itseorganisoitua omaksuakseen ammattimaisesti toimivan kehitystiimin toimintatavat ja tunnusmerkit. Sprintin katselmointi tarjoaa arvokasta pohjatietoa seuraavan sprintin suunnittelukokoukselle. jotta seuraavista sprinteistä ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Kokouksessa scrummaster kannustaa scrumtiimiä tarkastelemaan ja sopeuttamaan Scrum-kehykseen liittyvää kehitysprosessia ja käytäntöjä.

21).ja sopeutuskokouksen. Tarkastelussa tulisi tunnistaa ja priorisoida tärkeimmät asiat.  All  Rights  Reserved     Page  |  15   . jotka menivät hyvin sekä asiat. Scrummaster valmentaa kehitystiimiä pitämään kokous lyhyenä valvomalla kokouksen käytäntöjä ja pitämällä puheenvuorot lyhyinä. Sprintin retrospektiivin loppuun mennessä scrumtiimin tulisi tunnistaa ja valita seuraavan sprintin aikana toteutettavat parannukset. ja 3. Scrummasterin tehtävänä on varmistaa. Mitä esteitä etenemiselläni on. kokousjärjestelyt. Näillä muutoksilla nykytilaa sopeutetaan empiirisen tarkastelun mukaiseksi. korostavat nopeaa päätöksentekoa ja parantavat kaikkien ymmärrystä projektista. Mitä aion tehdä ennen seuraavaa tapaamista. tunnistavat ja poistavat esteitä. Tarkasteltavia asioita ovat scrumtiimin kokoonpano. että kehitystiimi todella pitää kokouksen. Päivän Scrum Kukin kehitystiimi pitää päivittäin 15 minuuttia kestävän tarkastelu. kommunikointimenetelmät ja prosessit. Mitä olen saanut aikaan viime tapaamisen jälkeen. muodostuneiden ihmissuhteiden. Kehitystiimin vastuulla taas on järjestää päivän Scrum. jota kutsutaan päivän Scrumiksi. työkalut. joka kieltää ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. joita on kuvattu monissa kirjoissa. Retrospektiivin pitämiseen on tarjolla hyödyllisiä tekniikoita. valmiin määritelmä (s. Päivän Scrum pidetään aina samaan aikaan samassa paikassa. Tapaamisessa jokainen kehitystiimin jäsen kertoo vuorollaan: 1. Retrospektiivin tarkoituksena on tarkastella viimeisimmän sprintin onnistumista ihmisten. vähentävät muita kokouksia.saadaan tuottavampia ja miellyttävämpiä. prosessien ja työkalujen näkökulmasta. Scrummaster valvoo myös tarvittaessa käytäntöä. joita muuttamalla työ sujuisi jatkossa vieläkin paremmin. joilla tuotteen kehitysjonosta tuotetaan jotain “valmista”. Päivän Scrum –kokoukset kehittävät kommunikointia. 2.

Kehitystiimi on sitoutunut sprintin tavoitteeseen ja siihen liittyviin tuotteen kehitysjonon vaatimuksiin. Se on tarkoitettu ainoastaan henkilöille (kehitystiimille). jotka tuote tarvitsee ollakseen tarkoituksenmukainen. Päivän Scrum - kokouksella on Scrumin empiirisessä prosessissa tärkeä rooli työn tarkastelussa ja sopeuttamisessa. julkaisun edistymiskäyrä (Release Burndown) ja sprintin edistymiskäyrä (Sprint Burndown). joissa käsitellään työn toteutusta. Päivän Scrum ei ole raportointikokous. Päivän Scrumissa sovitaan tarvittaessa erillisistä kokouksista. sen sisällöstä.mahdollisesti kuuntelemaan tulleita “kanoja“ puhumasta tai muulla tavoin häiritsemästä Päivän Scrumia. 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. Tuotteen kehitysjono ja julkaisun edistymiskäyrä Tuotteen kehitysjonossa listataan kaikki vaatimukset tuotteelle. saatavuudesta ja priorisoinnista. että kehitystiimi pääsee sprintille asettamaansa tavoitteeseen. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. jota kehitystyhmä(t) kehittävät. Tuotteen kehitysjono on olemassa yhtä kauan kuin tuote. sprintin tehtävälista (Sprint Backlog).  All  Rights  Reserved     Page  |  16   . Tuoteomistaja vastaa tuotteen kehitysjonosta. jotka osallistuvat tuoteparannuksen kehittämiseen. Tarkoituksena on maksimoida todennäköisyys sille. kilpailukykyinen ja hyödyllinen. Päivän Scrumissa tarkastellaan kehityksen etenemistä suhteessa sprintin tavoitteeseen (yllä mainitut kolme kysymystä). Tuotteen kehitysjono ei ole koskaan valmis ja sen ensiversio sisältää ainoastaan tunnetut ja parhaiten ymmärretyt vaatimukset. Scrumin dokumentit Scrumin neljä dokumenttia ovat tuotteen kehitysjono (Product Backlog).

Korkeampi prioriteetti jotta kehitysjono täyttää edellä määritellyn tarkoittaa. sitä ymmärretty ja helposti vähemmän kehitysjonon kohdasta valittavissa toteutukseen. käyttötapauksia (Use Case) parannuksista ja korjattavista voidaan käyttää. Korkeamman kehitysjonon kohtia prioriteetin kohtien suurempi analysoidaan ja tarkennetaan. mutta ne sopivat paremmin virheistä. Korkeimman prioriteetin kohdat Scrumtiimi käyttää yleensä 10% sprintin ajasta tuotteen ohjaavat seuraavaksi aloitettavaa kehitysjonon päivittämiseen. on kiireellisempi. Näiden muuttujien arviointiin ja siten kehitysjonon priorisointiin on olemassa useita erilaisia tekniikoita. lisäarvon ja tarpeellisuuden perusteella. Prioriteetti määritellään riskin.  All  Rights  Reserved     Page  |  17   . Päivitysten aikana prioriteetin kohdat.Tuotteen kehitysjono sisältää kaiken tarpeellisen menestyvän tuotteen Vinkki kehittämiseksi ja julkaisemiseksi. jotka tullaan toteuttamaan liiketoiminnalle tai tuleviin tuotejulkaisuihin. Sprintin selkeys kasvattaa myös aika. Story). Jokaisella terveydelle kriittisten sovellusten kehittämiseen. prioriteetti ja aika-arvio. Myös toiminnoista. Tuotteen kehitysjonon Tuotteen kehitysjono on lista kohdat kirjataan usein käyttäjätarinoina (User kaikista ominaisuuksista. että kehitysjonon kohta tarkoituksensa. sitä on ehditty Päivityksen yhteydessä suunnitella enemmän ja sen arvosta tuotteen kehitysjonossa ylimpänä olevat kohdat vallitsee suurempi yksimielisyys. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. (korkein prioriteetti ja Korkeamman prioriteetin kohdat suurin arvo) harjoitetaan ovat selkeämpiä ja sisältävät pienemmiksi siten. kehitystä. Mitä mennessä korkeimman prioriteetin kohdat on hyvin matalampi prioriteetti. Tuotteen kehitysjono järjestetetään Vinkki sen kohtien prioriteettien mukaan. kehitysjonon kohdalla on kuvaus. tiedetään ja sitä vaikeampaa kohtaa on ymmärtää. suunnittelukokoukseen arvioiden tarkkuutta. että ne kattavat ainakin seuraavan tarkempaa tietoa kuin matalamman sprintin. teknologioista.

ja joka on tasainen tai jopa ylöspäin nouseva. Uusi nollataso työmäärän suhteessa aikaan. minkä Tuotteen kehitysjonoon seurauksena tuotteen kehitysjono lisätään usein oma sarakkeensa muuttuu laajemmaksi ja hyväksymistesteille. joka dokumentti. liiketoiminnan vaatimuksissa. kun lisätään tai kehitysjonossa jäljellä olevan poistetaan suurempia kokonaisuuksia. Muutokset määrittää kuinka vaatimuksen tulee toimia ollakseen valmis.  All  Rights  Reserved     Page  |  18   . edistymiskäyrään trendiviivan. tulee dokumentoida hyvin. sen arvo kasvaa ja markkinoilta Vinkki saadaan palautetta. johon tuotteen työjonoon lisätään lisätään vaatimusten ryhmittelyä enemmän työtä kuin sitä ehditään sprinteissä toteuttaa. joka esittää tuotteen silloin. määrittelytekstit voidaan useimmiten korvata nopeasti Tuotteen kehitysjono on elävä todennettavalla testillä. Arvioitu työmäärä on missä tahansa yksikössä. Moninkertaisen työn minimoimiseksi vain korkeimman prioriteetin kohdat tulee määritellä yksityiskohtaisesti. Ryhmittely voi Tämä voi muodostaa julkaisun perustua toiminnallisuuteen. Jotta työn ryhmittelyä käytetään usein työn lisäämisen vaikutusta voidaan jakamiseen useamman tasata läpinäkyvyys säilyttäen. tukeva tunniste. jonka ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. scrumtiimin kesken. kun työtä lisätään tai vähennetään. Vinkki Tällöin työtä ohjataan yhdellä Joissakin organisaatioissa tuotteen kehitysjonolla. perusteellisemmaksi. markkinassa. teknologiassa ja henkilöstössä aiheuttavat jatkuvasti muutoksia tuotteen kehitysjonoon. joita kehitystiimi toteuttaa seuraavissa sprinteissä.Kun tuotetta aletaan käyttää. Tuotteen kehitysjonon kohdat. tulee hajottaa riittävän pieniksi ja tarkoiksi. Uusi Julkaisun edistymiskäyrä on nollataso tulisi määritellä vain diagrammi. teknologiaan tai arkkitehtuuriin. voidaan määrittää uusi nollataso. jotta mikä tahansa kohdista ehditään täysin toteuttaa yhden sprintin aikana. Vaatimusten Hyväksymistestin avulla pitkät muuttuminen ei pääty koskaan. Useampi scrumtiimi työskentelee usein saman tuotteen parissa.

Aika. mutta lopullisen aika- arvion antaa aina kehitystiimi. tuotteen kehitysjonoon. Sprintin tehtävälista ja edistymiskäyrä Sprintin tehtävälista koostuu tehtävistä. että sprintin edistyminen voidaan havaita päivän Scrum - kokouksessa.scrumtiimi ja organisaatio on valinnut. jotka kehitystiimin tulee toteuttaa muuttaakseen tuotteen kehitysjonosta valitut kohdat julkaisukelpoiseksi tuoteparannukseksi. Aika-arvioita voi teknologioita. 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. Ne kuvaavat työtä. Tehtävät määritellään useimmiten sprintin suunnittelukokouksessa. Aloittaessaan sprintin toteutustyön kehitystiimi voi havaita. Tuotteen kehitysjonon vaatimuksille annetaan alustavat Vinkki aika-arviot julkaisun suunnittelun Julkaisun edistymiskäyrän yhteydessä sekä sitä mukaa. ellei kehitystiimi ole työskennellyt yhdessä arviot tarkentuvat tuotteen aikaisemmin ja tunne hyvin kehitysjonon säännöllisissä tuotetta sekä käytettyjä tarkasteluissa. tai että jokin tehtävä tulee viemään enemmän tai vähemmän aikaa kuin ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Julkaisun edistymiskäyrässa ajan yksikkönä ovat yleensä sprintit. Aika-arvioden antamisesta vastaa kehitystiimi. Jäljelläolevan työmäärän muutoksista voidaan myös piirtää trendiviiva. Sprintin tehtävälistaan valitut kohdat tulee hajottaa niin pieniksi. muuttaa milloin tahansa muulloinkin. että tarvitaankin vähemmän tai enemmän tehtäviä kuin suunniteltiin. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään ja valitsemaan kompromisseja. Tuoteomistaja pitää ajantasaisen julkaisun edistymiskäyrän jatkuvasti näkyvillä. kun trendiviiva saattaa olla epäluotettava muutaman uusia vaatimuksia lisätään ensimmäisen sprintin ajan.  All  Rights  Reserved     Page  |  19   . jonka kehitystiimi tunnistaa tarpeelliseksi sprintin tavoitteeseen pääsemiseksi.

joka Sprintin edistymiskäyrä on esillä kehitystiimin piirretään laskemalla yhteen työskentelytilassa. sen sisältöä tai aika-arvioita sprintin aikana. jonka kehitystiimi suunnittelee saavansa valmiiksi sprintin aikana. 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. Mikäli tehtävä havaitaan tarpeettomaksi. joka on scrumtiimin sopiman “valmiin” määritelmän mukainen. kunkin tehtävän arvioitu jäljelläoleva työmäärä päivitetään. Kun tehtäviä työstetään tai ne valmistuvat. Tämän vuoksi sprintin tehtävälista on täysin kehitystiimin omistuksessa ja hallinnassa. reaaliaikainen kuva työstä. Luku Excelissä tai verkkopohjaisessa työkalussa olevaa kuvaa sprintin koko jäljellä edistymiskäyrää.arvioitiin. Sprintin edistymiskäyrä on diagrammi. se poistetaan. Yksi Scrumin säännöistä on sprintin tarkoitus tuottaa julkaisukelpoinen tuoteparannus. piirrä työmäärän suhteessa aikaan. olevaa työmäärää päivän tarkkuudella. Kehitystiimi kaikki sprintin tehtävälistassa seuraa suurta näkyvää edistymiskäyrää olevat aika-arviot ja päivittämällä todennäköisemmin kuin tätä lukua kerran päivässä. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. edistymiskäyrä käsin suurelle paperille tai valkotaululle. Sprintin tehtävälista on selkeästi näkyvä.  All  Rights  Reserved     Page  |  20   . joka esittää sprintin Vinkki tehtävälistassa jäljellä olevan Aina kun mahdollista. Ainoastaan jäljellä oleva työmäärä ja päivämäärä ovat kiinnostavia muuttujia. Kehitystiimi lisää tarvittavat uudet tehtävät sprintin tehtävälistaan. Ainoastaan kehitystiimi voi muuttaa sprintin tehtävälistaa. Tehtäviin käytetyn työajan pituudella ei ole Scrumissa merkitystä.

Kun keskeneräisen työn dokumentaatiota. turvallisuudelle ja integroinnille. refaktoroitu. määritelmä ei myöskään sisällä tuotteen edistymiskäyrä säilyy tarkempana.  All  Rights  Reserved     Page  |  21   . että toiminnallisuus on vähintään siististi ohjelmoitu. yksikkötestattu. Mikäli kaikki eivät tunne “valmiin” määritelmää. mitä kehitystiimi tarkoittaa Vinkki sitoutuessaan toteuttamaan “Keskeneräinen” työ kerätään tuotteen kehitysjonon kohdan. ohjelmoinnin. Parannuksen tulee olla julkaistavissa välittömästi. Valmis sisältää myös mahdollisen kansainvälistämisen. empiirisen prosessihallinnan kaksi muuta tukijalkaa eivät toimi. jos tuoteomistaja niin päättää. Tämän tulee olla tuoteomistajan tiedossa. Joidenkin kehitystiimien ei ole heti mahdollista sisällyttää kaikkea tarvittavaa valmiin määritelmäänsä. käännetty ja hyväksymistestattu. Valmis määrittelee. dokumentaatiota.Valmis Scrum vaatii kehitystiimejä kehittämään tuoteparannuksen jokaisessa sprintissä. suunnittelun. käyttäjä. refaktoroinnin. Joku toinen taas voi olettaa. jotta varmistetaan kaikkien parannusten keskinäinen toimivuus. Tuotekehityksessä sana “valmis” saattaa johtaa oletukseen. jotka liittyvät tuoteparannukseen. Tämän vuoksi parannuksen tulee olla “valmis” siivu tuotteesta. vakaudelle. Testaaminen sisältää yksikkö-. Kun joku kommunikoi jonkin olevan valmis. Jäljellä oleva tekemätön työ tulee tehdä valmiiksi ennen kuin tuotetta voidaan toimittaa ja käyttää. ©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. systeemi-. joten valmiin summaa näin ylläpidetään. ja regressiotestauksen sekä ei- toiminnalliset testit suorituskyvylle. mitä valmis tarkoittaa. usein tuotteen kehitysjonoon kohdan “keskeneräinen työ” Jotkut tuotteet eivät sisällä alle. kaikkien tulee ymmärtää. Jokaisen parannuksen tulee olla lisäys kaikkiin edellisiin parannuksiin ja se tulee testata huolellisesti. dokumentoinnin ja testaamisen kaikille tuotteen kehitysjonon vaatimuksille. että “valmis” toiminnallisuus on ainoastaan käännetty. Täysin valmis tuoteparannus taas sisältää kaiken analyysin.

©  2008-­‐2010  Ken  Schwaber  and  Jeff  Sutherland. Oletetaan esimerkiksi. suunnittelu. jonka aika-arvio on kuusi yksikköä työtä (huomioiden kehitystiimin “valmiin” määritelmä. lasketaan tämän keskeneräisen työmäärän suhde työhön.  All  Rights  Reserved     Page  |  22   . joka sisältää vain sen hallitsemat työvaiheet).ja integrointitestausta jokaiselle sprinttiin suunnitellulle kehitysjonon kohdalle. Tarvittavien julkaisu-sprintten määrän arviointi on sitä vaikeampaa mitä enemmän eksponentiaalisia piirteitä keskeneräisellä työllä on. dokumentointi. Kun kehitystiimi saa valmiiksi vaatimuksen.ja käyttäjätestaaminen). yksikkö. vakaus-. jotka riippuvat organisaatiosta. refaktorointi. Sprintin katselmointipalaverissa tehtävä tarkastelu ja sopeuttaminen on yhtä tarkkaa kuin tämä läpinäkyvyys.LOPPUSANAT Jotkut organisaatiot eivät kykene kehittämään julkaisukelpoista tuoteparannusta yhden sprintin aikana. joka voidaan toteuttaa (analyysi. “Keskeneräinen” työ kumuloituu sprintti kerrallaan ja työ tulee tehdä valmiiksi ennen tuotteen julkaisua. Jos kehitystiimi ei esimerkiksi pysty toteuttamaan suorituskyky-. johon kumuloituu tekemättömien töiden aika-arviot. joka päätetään tehdä valmiiksi myöhemmin. Keskeneräinen työ kumuloituu lineaarisesti. jotka näkyvät julkaisun edistymiskäyrässä tekemättömänä työnä. Näillä ei välttämättä vielä ole tarvittavaa automaattista testausympäristöä kaikkien edelläkuvattujen testien toteutukseen. mutta siinä on eksponentiaalisia piirteitä. lisätään neljä yksikköä työtä “keskeneräiset työt” –vaatimukseen. Tuoteomistaja tunnistaa töiden tilanteen Sprintin katselmointipalaverissa. turvallisuus. ohjelmointi. regressio-. Keskeneräisen työn toteuttamiseksi julkaisuprojektin loppuun lisätään julkaisu-sprinttejä. Keskeneräinen työ on osa tuoteparannusta. Näin läpinäkyvyys kasvaa kohti tuotteen julkaisua. Tällaisessa tilanteessa kullekin tuoteparannukselle luodaan kaksi kategoriaa: “Valmis” työ ja “keskeneräinen” työ. että tämä suhdeluku on kuusi yksikköä “valmiita töitä” ja neljä yksikköä “keskeneräisiä töitä”. koska tuoteparannuksen tulee vastata sovittua valmiin määritelmää. Keskeneräiset työt lisätään tuotteen kehitysjonoon uudeksi kohdaksi “keskeneräiset työt”.