Tuoteomistajan Scrum-pikaopas

11. toukok.

Tämä pikaopas perustuu 11/2020 päivitettyyn ja 2/2021 suomennettuun uusimpaan Scrum-versioon. Kirjoittaja Karoliina Luoto on osallistunut suomennostyöhön.

Scrum on ketterä viitekehys, joka on tarkoitettu monimutkaisten, liiketoimintakriittisten kokonaisuuksien kehittämiseen. Scrum on parhaimmillaan intensiivisessä kehitysvaiheessa hankkeissa, joissa on paljon tuntemattomia tekijöitä.

Tämä pikaopas summaa Scrumin tärkeimmät elementit erityisesti tuoteomistajan (product owner) näkökulmasta.

Mitä tuoteomistajan kannattaa huomata Scrumista?

Scrum on historialtaan ja lähtökohdiltaan kehittäjäkeskeinen. Niinpä se jättää kuvaamatta tärkeimmän osan tuoteomistajan työtä:

kehitettävän tuotteen tai palvelun vision ohjaamisen
siitä huolehtimisen, että tuotteesta tulee toteutetuksi tarvittu laajuus vaaditussa aikataulussa
käyttäjäpalautteen hankkimisen siitä, mikä kehitettävässä järjestelmässä on käyttäjille arvokkainta
ohjausryhmien ja muiden päätöksentekijöiden osallistamisen päätöksentekoon.

Näihin tehtäviin on etsittävä työkalut Scrum-oppaan ulkopuolelta, ja vakiintuneita työkaluja ja -tapoja onkin onneksi paljon olemassa.

Erityisesti Scrum jättää mainitsematta sen, mitä uusimmat ketterät ja leanit viitekehykset korostavat. Ennen kuin resursseja sidotaan kehittämiseen, suunnitellun ratkaisun osuvuus on syytä verifioida kokeilemalla sitä kevyesti esim. prototyypin ja siitä kerättävän käyttäjäpalautteeen avulla. Näin varmistetaan, että resursseja syövällä Scrum-kehityksellä kehitetään käyttäjän ja liiketoiminnan tarpeiden kannalta oikeaa ratkaisua.

Scrum on kehitetty erityisesti kehityskeskeisten organisaatioiden omaan kehitystyöhön. On kuitenkin paljon myös tilaaja-toimittaja -projekteja, joissa tuoteomistaja on tilaajan organisaatiossa ja kehittäjät sekä Scrummaster ostettuna resursseina. Tällöin yhtenäisen Scrum-tiimin ihannetta haastaa tilaajan ja toimittajan välinen sopimussuhde ja taloudelliset intressit, joita tuoteomistaja joutuu usein käytännössä myös joiltakin osin hoitamaan.

Se puoli kehittämisestä, jonka Scrum kuvaa hyvin, on tuoteomistajan toiminta kehittäjien kanssa. Siinäkään Scrum ei ole kuitenkaan tyhjentävä menetelmä, vaan kevyt viitekehys, jonka sisällä on jatkuvasti etsittävä käytännön toimintatapoja kehitysarjen hallitsemiseen. Ei ole tyhjä sanonta, että Scrum on helppo oppia, mutta haastavaa hallita.

Menestys kiinni Scrumin perustan omaksumisesta

Scrumin menestyksekäs käyttö riippuu pitkälti siitä, miten hyvin tiimi sisäistää Scrumin perustan eli sen keskeiset periaatteet ja arvot. Ilman niitä Scrumin toteutus voi jäädä mekanistiseksi ja siinä voidaan ajautua epäoleellisuuksiin.

Scrum perustuu empirismiin ja lean-ajatteluun. Se käyttää iteratiivista (asteittain tarkentuvaa) ja inkrementaalista (lisäävää) lähestymistapaa ennustettavuuden optimoimiseksi ja riskien hallitsemiseksi.

Empirismi toteutuu Scrum-oppaan mukaan Scrumin tapahtumien avulla, ja siinä on kolme peruspilaria:

Läpinäkyvyys eli Scrumin tuotosten tilan tekeminen havaittavaksi työn tekijöille sekä työn vastaanottajille, jotta tarkastelu ja valistuneet päätökset ovat mahdollisia
Tarkastelu eli sen havainnoiminen, miten työ etenee ja millaisia poikkeamia tässä on. Tässä auttavat erityisesti Scrumin tapahtumat.
Mukauttaminen eli suunnitelman hiominen uuden tiedon perusteella.

Scrum perustaa empirismin pitkälti Scrumin tapahtumien ja lopputulosten läpinäkyvyyden varaan.
Tuoteomistajalle empirismi tarkoittaa kuitenkin korostuneesti myös aivan käytännöllistä työtä.

Menestyäkseen tehtävässään tuoteomistajan on käytettävä paljon energiaa on siihen, että hän hahmottaa sekä tuotteen etenemisen tilanteen että pystyy ennakoimaan suunnitelmiin vaikuttavia tekijöitä kuten uusia havaintoja käyttäjätarpeista tai muutoksia kehittämisen rajoituksissa. Edistymisen seuranta on läpinäkyvyyden kulmakivi.

Scrumin arvot, sitoutuminen, keskittyminen, avoimuus, kunnioitus ja rohkeus, ohjaavat hyvässä Scrum-tiimissä kaikkien mukana olijoiden yhteistyötä sekä tehtäviä päätöksiä.

Scrum-tiimi keskittyy tuotteen tavoitteeseen

Itseohjautuvaan, monialaiseen ja hierarkiattomaan Scrum-tiimiin kuuluvat tuoteomistaja, kehittäjät ja Scrum Master. Scrum-tiimi vastaa yhdessä arvokkaiden ja käyttökelpoisten inkrementtien tuottamisesta jokaisessa sprintissä. Se ottaa vastuun kaikesta tuotteeseen liittyvästä tekemisestä: sidosryhmäviestinnästä, laadun varmistamisesta, ylläpidosta, tuotannosta, kokeiluista, tutkimuksesta ja kehittämisestä sekä mistä tahansa mitä saatetaan tarvita.

Tuoteomistaja varmistaa kehitystyön arvon

Tuoteomistaja vastaa siitä, että tehty kehitystyö tuottaa suurimman mahdollisen arvon käyttäjille ja liiketoiminnalle eli:

Tuotteen tavoitteen luomisesta ja sen viestimisestä täsmällisesti
Tuotteen kehitysjonon sisällön valmistelusta ja sen viestimisestä selkeästi
Tuotteen kehitysjonon sisällön järjestämisestä
Tuotteen kehitysjonon läpinäkyvyyden, saatavuuden ja ymmärrettävyyden varmistamisesta

Scrum-opas korostaa tuoteomistajan olevan henkilö eikä komitea. Käytännössä tätä sääntöä joskus rikotaan jakamalla työt esimerkiksi kahden hengen kesken toisaalta projektin vision varmistamiseen, viestintään ja hallintoon, toisaalta kehitysjonon tarkempaan hallintaan ja kehitystiimin kanssa toimimiseen. Vaarana tässä on rikkinäisen puhelimen ilmiö, jota saa minimoitua erittäin aktiivisella kommunikoinnilla.

Scrum käsittelee tuoteomistajaa itsevaltiaana ja viimeisenä päätöksentekijänä, jonka valtuuksia muu organisaatio kunnioittaa. Vastuun ja vallan näkökulma onkin oleellinen. Käytännössä tuoteomistajan on usein projektin menestys varmistaakseen hyödynnettävä esim. ohjausryhmän päätöksiä, projektiyhteisön huomioita ja erityisesti käyttäjäpalautetta päätöksenteossaan, samalla kun punnitsee niiden merkittävyyttä suhteessa palvelun yleiseen visioon kantaa päätöksistään vastuun kehitystiimin suuntaan.

Tuoteomistajan rooliin liittyy elintärkeä vastuu, josta Scrum-opas ei juurikaan puhu. Käytännössä tuoteomistaja on nimittäin usein sidosryhmien takuumiehenä sen suhteen, että tarvittava tulos saadaan aikaan säädetyssä ajassa. Tärkeä osa tämän vastuun haltuunottoa on varmistaa, että kehittämiselle on varattu mielekäs aikataulu ja että etenemistahtia seurataan ja toteutussuunnitelmaa sopeutetaan suhteessa koko tuotteen kokonaisuuteen.

Tarvitaan siis kokonaiskäsitys toteutussuunnitelmasta ja sen toteutumisesta.

Kokonaiskäsityksen rakentaa karkea arvio koko tuotteen koosta, kuukausien yli ulottuva julkaisusuunnitelma, aktiivinen havainnointi näiden toteutumisesta ja jatkuva suunnitelmien sopeuttaminen havaintojen perusteella.

Kehittäjät ovat sitoutuneet tuottamaan laatua

Kehittäjät ovat Scrum-tiimissä ne ihmiset, jotka ovat sitoutuneet luomaan käyttökelpoisen inkrementin jokaisessa sprintissä. He vastaavat sprintin suunnitelman tekemisestä eli sprintin kehitysjonosta, laadun iskostamisesta tuotteeseen noudattamalla valmiin määritelmää, suunnitelmansa mukauttamisesta päivittäin sprintin tavoitteen saavuttamiseksi ja toistensa kohtelemisesta vastuullisina ammattilaisina.

Scrum-opas on alkanut ajan kuluessa korostaa enemmän kehittäjien vastuuta syntyvän tuotteen laadusta. Kehityksen menestyksen takaamiseksi onkin oleellista, että tämä vastuu toteutuu ja kehittäjiä rohkaistaan kantamaan vastuunsa tuotteen toteutusvisiosta ja sen vastaavuudesta valmiin määritelmään sekä muihin toteutuksen vaatimuksiin kuten ohjelmistokehityksen maailmassa tekniseen ympäristöön ja elinkaarivaatimuksiin.

Samalla kun tuoteomistaja ei puutu kehitystyön toteutustapaan, hän pääsee kuitenkin hyödyntämään kehitystiimin teknistä tietotaitoa, kun tehdään päätöksiä siitä, millaisilla ratkaisuilla käyttäjien tarpeet täytetään. Tuoteomistaja voi esim. pyytää kehitystiimiltä ajatuksia muutamasta erilaajuisesta toteutusvaihtoehdosta ja niistä voidaan yhdessä valita se, jokatuoteomistajan ymmärryksen mukaan tällä hetkellä tyydyttävät käyttäjien minimitarpeen. Usein jokaisen ominaisuuden kohdalla kannattaa aloittaa yksinkertaisimmasta mahdollisesta ratkaisusta ja mahdollisesti jatkaa kehittämistä myöhemmin käyttäjäpalautteen pohjalta.

Käytännössä tuoteomistajalla on hyvä olla nimettynä vastinparina toteutusympäristön asiantuntija.

Tämän kanssa voidaan esimerkiksi ennen varsinaisen toteutuksen alkamista miettiä toteutuksen tärkeimpiä reunaehtoja.

Scrum Master auttaa muita käyttämään scrumia

Scrum Master auttaa kaikkia kehitystyössä mukana olevia ymmärtämään Scrumin periaatteet ja käytännöt. Scrum Master vastaa tiimin tehokkuudesta tarjoamalla kaikille puitteet toimintatapojen jatkuvaan parantamiseen.

Scrum Master palvelee tiimiä mm. valmentamalla sen jäseniä itseohjautuvuuteen ja monialaisuuteen, auttamalla sitä keskittymään käyttäjille arvokkaiden ja valmiin määritelmää noudattavien inkrementtien toteutukseen, varmistamalla, että esteet Scrum-tiimin etenemiseltä poistetaan ja varmistamalla, että kaikki Scrumin tapahtumat pidetään, ne toteutuvat positiivisessa hengessä, ovat tuottavia ja pysyvät annetun ajan puitteissa.

Tuoteomistajan kannalta vieläkin oleellisempia ovat tavat, joilla Scrum Master palvelee tuoteomistajaa ja muuta organisaatiota.

Tuoteomistajaa Scrum Master auttaa mm. seuraavilla tavoilla:

Auttamalla löytämään tehokkaita tapoja tuotteen tavoitteen määrittelyyn sekä tuotteen kehitysjonon hallintaan
Auttamalla Scrum-tiimiä ymmärtämään tarpeen selkeälle ja johdonmukaiselle tuotteen kehitysjonon sisällölle
Auttamalla luomaan kokeiluihin perustuvia tapoja tuotteen suunnitteluun kompleksisessa ympäristössä
Fasilitoimalla tarvittaessa tai pyydettäessä sidosryhmien välistä yhteistyötä

Muuta organisaatiota Scrum Master auttaa mm. seuraaville tavoilla:

Johtamalla, kouluttamalla ja valmentamalla organisaatiota Scrumin käyttöönotossa
Suunnittelemalla ja neuvomalla organisaatiota Scrumin toteutuksessa
Auttamalla työntekijöitä ja sidosryhmiä ymmärtämään ja hyödyntämään havaintoihin perustuvaa lähestymistapaa työhön, joka on kompleksista
Poistamalla esteitä sidosryhmien ja Scrum-tiimien välillä

Mikäli Scrum Master ei jostakin syystä pysty tarjoamaan yllä lueteltuja palveluita tuoteomistajalle ja muulle organisaatiolle, kehittämisen onnistumisen varmistamiseksi on hyvä huolehtia että nämäkin palvelut ovat tiimin saatavilla jossakin muodossa. Toisinaan niihin käytetään esim. ketteryysvalmentajaa.

Scrumin tapahtumat varmistavat empirismin

Scrumin tapahtumat ovat tärkein mahdollisuus tarkastella ja mukauttaa toimintaa tai tuotetta. Jos niitä ei järjestetä Scrumin mukaisesti, menetetään samalla tilaisuus empirismiin. Scrumin tapahtumilla saadaan lisäksi tuotua kehittämisen arkeen säännöllisyyttä ja vähennettyä Scrumin ulkopuolisten palaverien tarvetta. Kompleksisuuden vähentämiseksi ne suositellaan pidettäväksi aina samaan aikaan ja samassa paikassa.

Sprintti mahdollistaa ennustettavuuden

Sprintti on Scrumin pulssi. Sprinteissä ideoista tuotetaan arvoa. Sprintin pituus pidetään vakiona (vähemmän kuin kuukausi), ja uusi sprintti alkaa välittömästi edellisen päätyttyä.

Sprintin aikana ei tehdä muutoksia, jotka vaarantavat sprintin tavoitteen, ei heikennetä laatua, jalostetaan tuotteen kehitysjonoa tarpeen mukaan ja tarkennetaan sprintin sisältöä ymmärryksen karttuessa kehittäjien ja tuoteomistajan vuoropuheluna.

Sprintti sisältää kaiken tarpeellisen työn tuotteen tavoitteen saavuttamiseksi, ja työhön kuuluuvat sprintin suunnittelu, päivittäispalaverit, sprintin katselmointi ja sprintin retrospektiivi.

Sprintit mahdollistavat paremman ennustettavuuden, koska etenemistä kohti tuotteen tavoitetta tarkastellaan ja mukautetaan vähintään kerran kuukaudessa. Etenemisen ennustamiseen on useita käytäntöjä, kuten edistymiskäyrät tai kertymäkuvaajat. Vaikka nämä ovat hyödyllisiä, ne eivät korvaa empirismin merkitystä.

Sprintin suunnittelussa syntyy sprintin tavoite

Sprintti käynnistyy sprintin suunnittelulla. Koko Scrum-tiimi tekee suunnitelman yhdessä, ja tuoteomistaja varmistaa, että osallistujat ovat valmiita keskustelemaan tuotteen kehitysjonon tärkeimmistä kohdista ja siitä, miten ne liittyvät tuotteen tavoitteeseen. Tämä on voinut vaatia esim. kehitysjonon jalostamista yhdessä edellisen sprintin aikana.

Tuoteomistajalle sprintin suunnittelu on työllistävin Scrumin tapahtuma.

Sprintin suunnittelun enimmäispituus on 8 h, kun sprintti on kuukauden mittainen.

Sprintin suunnittelu vastaa kolmeen kysymykseen:

Miksi tämä sprintti on arvokas? Tuoteomistaja ehdottaa miten tuotteen arvoa ja hyödyllisyyttä voisi kasvattaa sprintin aikana, ja koko Scrum-tiimi määrittelee yhdessä sprintille tavoitteen, joka kertoo miksi tämä sprintti on arvokas sidosryhmille. Sprintin tavoite viimeistellään ennen sprintin suunnittelun päättymistä.
Mitä tässä sprintissä voidaan saada valmiiksi? Kehittäjät valitsevat tuotteen kehitysjonon kohtia alkavaan sprinttiin tuoteomistajan kanssa käytävän keskustelun pohjalta. Samalla Scrum-tiimi voi jalostaa kehitysjonon kohtia, mikä lisää ymmärrystä ja ennustettavuutta. Voi olla haastavaa arvioida, paljonko sprintin aikana saadaan valmiiksi. Mitä paremmin kehittäjät tuntevat aiemman suorituskykynsä, tulevan kapasiteettinsa ja valmiin määritelmän, sitä varmempia he ovat sprinttien ennusteissa.
Miten valittu työ saadaan valmiiksi? Kehittäjät suunnittelevat jokaiselle sprinttiin valitulle tuotteen kehitysjonon kohdalle tarvittavan työn, jolla tuotteen inkrementti saadaan vastaamaan valmiin määritelmää. Usein tämä tehdään pilkkomalla tuotteen kehitysjonon kohtia työpäivän mittaisiksi tai sitä pienemmiksi tehtäviksi. Työn suunnittelu- ja toteutustapa on täysin kehittäjien valittavissa.

Scrum-opas korostaa kehittäjien itsenäistä otetta sprintin sisällön päättämisessä ja toteutustavan suunnittelussa. Keskustelu toteutusvaihtoehdoista on kuitenkin tärkeä myös tuoteomistajalle, mikäli hän ei ole aiemmin kuullut kehittäjien näkemyksiä niistä. Myös kehittäjille on oleellista kuulla, minkä verran tuoteomistaja näkee että kuhunkin ominaisuuteen kannattaa panostaa. Oleellista kuitenkin on, että tämä keskustelu ei käänny tuoteomistajan saneluksi tai puuttumiseksi kehittäjien työhön, vaan että kehittäjien tekninen asiantuntemus tunnustetaan keskustelussa ja ominaisuuksien varsinainen toteutustyö ja siihen kuluva aika on kehittäjien itsensä hallussa.

Sprintin tavoite, sprinttiin valitut tuotteen kehitysjonon kohdat ja suunnitelma näiden toteuttamiseksi muodostavat yhdessä sprintin kehitysjonon.

Päivittäispalaveri tarkastelee ja mukauttaa etenemistä

Päivittäispalaverin tarkoitus on tarkastella etenemistä kohti sprintin tavoitetta ja tarvittaessa mukauttaa sprintin kehitysjonoa ja tulevaa työtä. Päivittäispalaveri on 15 minuutin mittainen tapahtuma Scrum-tiimin kehittäjille. Kompleksisuuden vähentämiseksi se pidetään samaan aikaan ja samassa paikassa jokaisena sprintin työpäivänä. Päivittäispalaverit parantavat vuorovaikutusta, nostavat esiin työn esteitä ja kannustavat nopeaan päätöksentekoon. Näin muiden kokousten tarve vähenee.

Nykyisessä versiossaan Scrum toteaa tuoteomistajan roolista päivittäispalaverissa, että hän osallistuu siihen mikäli hän myös itse toteuttaa kehitysjonon kohtia muiden kehittäjien ohella.

Sprintin katselmoinnissa tarkastellaan tuotetta kokonaisuutena

Sprintin katselmoinnin tarkoitus on tarkastella sprintin tuloksia ja selvittää tulevat muutostarpeet. Siinä Scrum-tiimi esittelee tärkeimmille sidosryhmille työnsä tulokset, ja tämän perusteella keskustellaan yhdessä edistymisestä kohti tuotteen tavoitetta. Scrum-tiimi ja sidosryhmien edustajat katselmoivat yhdessä, mitä sprintissä saavutettiin ja mitä muutoksia tuotteen toimintaympäristössä on tapahtunut. Tämän perusteella osallistujat keskustelevat siitä, mitä kannattaisi tehdä seuraavaksi. Tuotteen kehitysjonoa voidaan myös muokata huomioimaan uusia mahdollisuuksia.

Sprintin katselmointi on siis sidosryhmille avoin työpajamainen kokous ja Scrum-tiimin tulisi välttää sen latistamista pelkäksi “demoksi”.

Tuoteomistajalle katselmointi on tärkeä työkalu. se on ainoa Scrumin tapahtuma, johon sidosryhmiä voi tuoda mukaan ilman erillisten järjestelyiden tekemistä.

Sprintin katselmoinnin enimmäispituus on 4 h, jos sprintin pituus on kuukausi.

Sprintin retrospektiivi varmistaa jatkuvan parantamisen

Sprintin retrospektiivissä suunnitellaan keinoja laadun ja tehokkuuden parantamiseksi.

Scrum-tiimi tarkastelee miten kulunut sprintti sujui liittyen ihmisiin, yhteistyöhön, prosesseihin ja työkaluihin sekä valmiin määritelmään. Tarkastelun kohteena olevat asiat vaihtelevat usein työn sisällön mukaan. Scrum-tiimi keskustelee siitä, mikä meni sprintin aikana hyvin, mitä ongelmia kohdattiin ja kuinka nämä ongelmat ratkaistiin tai jätettiin ratkaisematta. Scrum-tiimi tunnistaa hyödyllisimmät muutokset parantaakseen tehokkuutta. Vaikuttavimmat parannukset toteutetaan mahdollisimman pian. Ne voidaan jopa lisätä seuraavan sprintin kehitysjonoon.

Sprintin retrospektiivi päättää sprintin. Sprintin retrospektiivin enimmäispituus on 3 h, kun sprintin pituus on kuukausi.

Scrumin tuotokset huolehtivat läpinäkyvyydestä

Scrumin tuotokset on suunniteltu viemään tärkeimmän tiedon läpinäkyvyys huippuunsa, jotta kaikilla tuotoksia tarkastelevilla on samat lähtökohdat niiden mukauttamiseen.

Uusimmassa Scrum-versiossa jokainen tuotos sisältää sidoksen, jolla varmistetaan, että tuotos on läpinäkyvä ja sen edistyminen sen suhteen voidaan hahmottaa mitattavasti:

Tuotteen kehitysjono on sidottu tuotteen tavoitteeseen (kehitysjonon kohdat edistävät tuotteen tavoitetta)
Sprintin kehitysjono on sidottu sprintin tavoitteeseen (kehitysjonon kohdat edistävät sprintin tavoitetta)
Inkrementti on sidottu valmiin määritelmään (tuotteen inkrementti toteuttaa sovittua valmiin määritelmää)

Tuotteen kehitysjono ja tuotteen tavoite

Tuotteen kehitysjono on vähitellen syntyvä, järjestetty lista siitä, mikä on tarpeen tuotteen parantamiseksi. Se on ainoa lähde Scrum-tiimissä tehtävälle työlle. Se on Scrumin tuotoksista se, joka työllistää tuoteomistajaa eniten ja jonka ympärille tuoteomistajan työ pitkälti keskittyy.

Tuotteen kehitysjonon kohdat, jotka Scrum-tiimi voi saada valmiin määritelmän mukaisesti valmiiksi yhden sprintin aikana, katsotaan valmistelluiksi. Valmisteltuja kohtia voidaan valita sprintin suunnittelussa sprinttiin toteutettaviksi. Usein Scrum-tiimi saavuttaa tavoitellun läpinäkyvyyden tason jalostamalla tuotteen kehitysjonon kohtia.

Kehitysjonon jalostaminen on toimenpide, jossa kehitysjonon kohtia pilkotaan ja tarkennetaan luomalla pienempiä ja täsmällisempiä tuotteen kehitysjonon kohtia. Jalostaminen on jatkuvaa toimintaa, jolla tarkennetaan yksityiskohtia kuten kuvausta, järjestystä ja kokoa. Usein nämä ja muut tuotteen kehitysjonon kohtien piirteet vaihtelevat toimialan mukaan.

Kehittäjät, jotka tekevät työn, ovat vastuussa työmäärän arvioinnista. Tuoteomistaja voi vaikuttaa kehittäjiin kirkastamalla eri vaihtoehtoja ja auttamalla heitä valitsemaan niiden väliltä.

Tuotteen kehitysjono kehittyy koko ajan kattavammaksi ja tarkemmaksi listaksi, kun tuotetta testattaessa tai käytettäessä saadaan palautetta käyttäjiltä. Vaatimusten muuttuminen ja lisääntyminen ei pääty koskaan.

Sidos tuotteen tavoitteeseen. Tuotteen tavoite kuvaa tuotteen tulevaa tilaa, jonka saavuttamista Scrum-tiimi suunnittelee. Tuotteen tavoite sisältyy tuotteen kehitysjonoon. Tuotteen kehitysjonon muut kohdat syntyvät vähitellen määrittelemään, mitä pitää tehdä, jotta tuotteen tavoite saavutetaan.

Tuote on väline arvon tuottamiseksi. Sillä on selkeät rajat, tunnetut sidosryhmät sekä hyvin määritellyt käyttäjät tai asiakkaat. Tuote voi olla palvelu, fyysinen tuote tai jotain abstraktimpaa.

Tuotteen tavoite on pitkän aikavälin tavoite Scrum-tiimille. Sen on saavutettava (tai hylättävä) kukin tavoite ennen siirtymistä seuraavaan.

Sprintin kehitysjono ja sprintin tavoite

Sprintin kehitysjono koostuu sprintin tavoitteesta (miksi), sprinttiin valituista tuotteen kehitysjonon kohdista (mitä) sekä käytännön suunnitelmasta inkrementin toteuttamiseksi (miten). Sprintin kehitysjono on kehittäjien itselleen tekemä suunnitelma. Se on erittäin näkyvä, reaaliaikainen kuva työstä, jonka kehittäjät suunnittelevat tekevänsä sprintin aikana saavuttaakseen sprintin tavoitteen. Tämän vuoksi sprintin kehitysjonoa tarkennetaan koko sprintin ajan sitä mukaa, kun opitaan lisää. Sen tulisi olla riittävän yksityiskohtainen, jotta kehittäjät voivat tarkastella edistymistään päivittäispalaverissa.

Sidos sprintin tavoitteeseen. Sprintin tavoitteen saavuttaminen on sprintin ainoa päämäärä. Vaikka kehittäjät ovat sitoutuneet sprintin tavoitteeseen, tavoite on silti joustava sen suhteen, kuinka paljon toteutustyötä se sisältää. Sprintin tavoite lisää johdonmukaisuutta ja keskittymistä ja kannustaa Scrum-tiimiä työskentelemään yhdessä erillisten tavoitteiden sijaan.

Sprintin tavoite luodaan sprintin suunnittelussa ja lisätään sitten sprintin kehitysjonoon. Kehittäjät pitävät sprintin tavoitteen mielessään sprintin aikana työskennellessään. Jos työ osoittautuu erilaiseksi kuin kehittäjät odottivat, he sopivat yhteistyössä tuoteomistajan kanssa sprintin kehitysjonon laajuudesta siten, ettei se vaikuta sprintin tavoitteeseen.

Tuoteomistajalle sprintin kehitysjono tarjoaa läpinäkyvyyttä sprintin aikana. Sen tilasta näkee, miten työ etenee ja mistä kehittäjät mahdollisesti kaipaavat palautetta ja lisätietoa.

tuoteen Inkrementti ja valmiin määritelmä

Inkrementti on konkreettinen askel kohti tuotteen tavoitetta ja lisäys aikaisempiin inkrementteihin. Sen toimivuus tulee olla kattavasti varmistettu ja sen tulee olla käyttökelpoinen.

Sprintissä voidaan luoda useampia inkrementtejä. Inkrementtien muodostama kokonaisuus esitellään sprintin katselmoinnissa. Tämä tukee havaintoihin perustuvaa empirismiä. Tästä huolimatta inkrementti voidaan toimittaa sidosryhmille jo ennen sprintin päättymistä.

Kaiken inkrementtiin sisältyvän työn tulee täyttää valmiin määritelmä.

Sidos valmiin määritelmään. Valmiin määritelmä on kuvaus tilasta, jossa inkrementti täyttää tuotteelle asetetut laatuvaatimukset. Toisin sanoen kaikkien tuotteen kehitysjonon kohtien toteutuksen täytyy täyttää valmiin määritelmä.

Valmiin määritelmä luo läpinäkyvyyttä ja tarjoaa yhteisen ymmärryksen siitä, mitkä työt on saatu valmiiksi. Jos tuotteen kehitysjonon kohta ei täytä valmiin määritelmää, sitä ei voi julkaista eikä edes esitellä sprintin katselmoinnissa. Sen sijaan se palaa takaisin tuotteen kehitysjonoon tulevaisuudessa harkittavaksi.

Jos valmiin määritelmä kuuluu organisaation standardeihin, täytyy kaikkien Scrum-tiimien noudattaa vähintään sitä. Jos se ei ole organisaation standardi, Scrum-tiimin on luotava tuotteelle sopiva valmiin määritelmä. Kehittäjien on noudettava valmiin määritelmää.

Linkit Scrum-oppaaseen

Ajantasainen Scrum-opas suomeksi

Scrumin uusimman version muutokset

Ajantasainen Scrum englanniksi

Karoliina Luoto

Tuoteomistajan Scrum-pikaopas

Mitä tuoteomistajan kannattaa huomata Scrumista?

Menestys kiinni Scrumin perustan omaksumisesta

Scrum-tiimi keskittyy tuotteen tavoitteeseen

Tuoteomistaja varmistaa kehitystyön arvon

Kehittäjät ovat sitoutuneet tuottamaan laatua

Scrum Master auttaa muita käyttämään scrumia

Scrumin tapahtumat varmistavat empirismin

Sprintti mahdollistaa ennustettavuuden

Sprintin suunnittelussa syntyy sprintin tavoite

Päivittäispalaveri tarkastelee ja mukauttaa etenemistä

Sprintin katselmoinnissa tarkastellaan tuotetta kokonaisuutena

Sprintin retrospektiivi varmistaa jatkuvan parantamisen

Scrumin tuotokset huolehtivat läpinäkyvyydestä

Tuotteen kehitysjono ja tuotteen tavoite

Sprintin kehitysjono ja sprintin tavoite

tuoteen Inkrementti ja valmiin määritelmä

Linkit Scrum-oppaaseen

Withmore

Yhteystiedot

Tuoteomistajan Scrum-pikaopas

Mitä tuoteomistajan kannattaa huomata Scrumista?

Menestys kiinni Scrumin perustan omaksumisesta

Scrum-tiimi keskittyy tuotteen tavoitteeseen

Tuoteomistaja varmistaa kehitystyön arvon

Kehittäjät ovat sitoutuneet tuottamaan laatua

Scrum Master auttaa muita käyttämään scrumia

Scrumin tapahtumat varmistavat empirismin

Sprintti mahdollistaa ennustettavuuden

Sprintin suunnittelussa syntyy sprintin tavoite

Päivittäispalaveri tarkastelee ja mukauttaa etenemistä

Sprintin katselmoinnissa tarkastellaan tuotetta kokonaisuutena

Sprintin retrospektiivi varmistaa jatkuvan parantamisen

Scrumin tuotokset huolehtivat läpinäkyvyydestä

Tuotteen kehitysjono ja tuotteen tavoite

Sprintin kehitysjono ja sprintin tavoite

tuoteen Inkrementti ja valmiin määritelmä

Linkit Scrum-oppaaseen

SAFe, Scrum@Scale, tailored scaled framework or something else? - Comparison of scaled agile methods

Leanin kulttuurin kasvattaminen - ohjeet Toyota Kataan

Withmore

Yhteystiedot