Scrum-pikaopas tuoteomistajalle Karoliina Luoto Codento Oy 2017 CC Flickr d26b73
Scrum-pikaopas tuoteomistajalle 2 Karoliina Luoto Codento Oy helmikuu 2017 Tuoteomistajan pikaopas uusimpaan Scrum-versioon Tämä pikaopas perustuu uusimpaan, heinäkuussa 2016 päivitettyyn ja syksyllä suomennettuun Scrum-versioon. Kirjoittaja Karoliina Luoto on osallistunut suomennostyöhön. Scrum on ketterä viitekehys, joka on tarkoitettu monimutkaisten, liiketoimintakriittisten järjestelmien kehittämiseen. Monesti Scrum on parhaimmillaan projektivaiheessa, kun tuntemattomia tekijöitä on paljon. Tämä pikaopas vetää yhteen Scrumin tärkeimmät elementit erityisesti tuoteomistajan (product owner) näkökulmasta. Lähteenä on suomenkielinen Scrum-opas: http://www.scrumguides.org/docs/scrumguide/v2016/2016scrum-guide-finnish.pdf CC Flickr d26b73 Creative Commonsin lisenssi Nimeä-JaaSamoin. Lisenssi on ladattavissa osoitteesta http://creativecommons.org/licenses/by-sa/4.0/legalcode.fi.
Tuoteomistaja ja Scrum Scrum on tehty kehitystiimin lähtökohdista, joten tuoteomistajan rooli kaipaa erityistä huomiota 3 Mitä tuoteomistajan kannattaa huomata Scrumista? Scrum on lähtökohdiltaan kehitystiimikeskeinen. 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 arvokkainta ohjausryhmien ja muiden päätöksentekijöiden osallistamisen päätöksentekoon. Näihin tehtäviin on etsittävä työkalut Scrum-oppaan ulkopuolelta. Scrum kuitenkin kuvaa hyvin, miten tuoteomistaja toimii kehitystiimin kanssa. Scrum on kehitetty erityisesti tuotefirmojen omaan kehitykseen. On kuitenkin paljon myös tilaaja-toimittaja -projekteja, joissa tuoteomistaja on tilaajan organisaatiossa ja kehitystiimi sekä Scrummaster toimittajan puolelta. Tällöin yhtenäisen Scrum-tiimin ihannetta haastaa tilaajan ja toimittajan välinen sopimussuhde ja taloudelliset intressit. Haaste ratkaistaan yleensä erottamalla laskutus ja asiakassuhteen hallinta Scrum-tiimin ulkopuolelle. Käytännössä tuoteomistaja kuitenkin joutuu olemaan myös näiden asioiden kanssa jonkin verran tekemisissä. Kehitystiimin toiminnassakaan Scrum ei ole tyhjentävä menetelmä. Se on 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.
Scrumin arvot (lisätty Scrumiin 07/2016) 4 Onnistuminen Scrumissa perustuu sille, miten hyvin tiimi omaksuu sen keskeiset arvot:! " # $ Karoliina Luoto % Sitoutuminen Yksilöt sitoutuvat henkilökohtaisesti Scrumtiimin tavoitteisiin Rohkeus Scrum-tiimin jäsenillä on rohkeutta toimia oikein ja työstää vaikeita ongelmia Keskittyminen Kaikki keskittyvät sprintin työhön ja Scrumtiimin tavoitteisiin Avoimuus Koko kehitysyhteisö sopii avoimuudesta liittyen kaikkeen työhön ja sen ongelmiin Kunnioitus Scrum-tiimin jäsenet kunnioittavat toisiaan kyvykkäinä ja itsenäisinä ihmisinä
Scrumin periaatteet Tärkeimmät periaatteet ovat: 5 & Läpinäkyvyys eli merkittävien asioiden tekeminen havaittaviksi niille, jotka vastaavat lopputuloksesta. Esimerkiksi yhteinen sanasto tärkeille asioille sekä tiimin ja työn hyväksyjien yhteinen määritelmä sille, millainen valmis ominaisuus on (valmiin määritelmä, definition of done ). ' Tarkastelu eli sen havainnoiminen, miten työ etenee ja millaisia poikkeamia tässä on. ( Sopeuttaminen eli muutoksista päättäminen läpinäkyvyyden ja tarkastelun pohjalta.
1. Scrum-tiimi Itseohjautuvia, monitaitoisia ja omavaraisuuteen pyrkiviä 6 $ Scrum-tiimiin kuuluvat: 1.1 Tuoteomistaja 1.2 Kehitystiimi 1.3 Scrummaster Scrum-tiimit ovat itseohjautuvia ja monitaitoisia. Ne päättävät itse, kuinka työnsä tekevät sekä pyrkivät omavaraisuuteen ja siihen, että mikään tärkeä taito ei ole vain yhden tiimin jäsenen hallussa. Lyhyen tähtäimen tehokkuuden sijaan pyritään joustavuuteen, luovuuteen ja kestävyyteen. CC Flickr University of the Fraser Valley Scrum-tiimi kehittää ja toimittaa järjestelmästä tuoteversioita usein ja edellisten versioiden pohjalle rakentaen. Samalla maksimoidaan mahdollisuus palautteeseen hyväksyjiltä ja käyttäjiltä.
1.1 Tuoteomistaja Tuoteomistajan rooli on Scrumin pullonkaula 7 ) Tuoteomistaja vastaa siitä, että järjestelmälle saadaan isoin mahdollinen arvo. Tuoteomistaja on vastuussa siitä, että kehitettävälle järjestelmälle saadaan isoin mahdollinen arvo liiketoiminnan ja järjestelmän käyttäjien kannalta. Tuoteomistaja vastaa myös tuotteen kehitysjonon hallinnasta. Hän kuvaa mahdollisimman ymmärrettävästi ja läpinäkyvästi, millaisia ominaisuuksia järjestelmään pitää kehittää. Hän pitää nämä potentiaaliset ominaisuudet keskenään tärkeysjärjestyksessä. Selkeän kehitysjonon avulla kehitystiimi tietää aina, minkä tehtävän voi tehdä seuraavaksi. Tuoteomistaja voi tehdä nämä työt itse tai pyytää kehitystiimiä tekemään ne. Joka tapauksessa tuoteomistaja on vastuussa siitä, miten ne tulevat tehdyksi. Scrumin mukaan tuoteomistaja on yksi henkilö, ei komitea. Käytännössä tätä sääntöä joskus rikotaan jakamalla työt esimerkiksi kahden hengen kesken toisaalta projektin viestintään ja hallintoon, toisaalta ja kehitystiimin kanssa toimimiseen. Vaarana on rikkinäisen puhelimen ilmiö, jota saa minimoitua erittäin aktiivisella kommunikoinnilla. Scrum-opas sanoo: 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 henkilöllä ei ole oikeutta käskeä kehitystiimiä työskentelemään muiden kuin tuoteomistajan asettamien vaatimusten parissa, eikä kehitystiimin tule myöskään reagoida tällaisiin pyyntöihin. 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ä ohjausryhmän päätöksiä, projektiyhteisön huomioita ja erityisesti käyttäjäpalautetta päätöksenteossaan, samalla kun kantaa päätöksistään vastuun kehitystiimin suuntaan.
1.1 Tuoteomistaja mistä Scrum-opas ei niinkään puhu? Ajankäytön ja parhaan arvon välillä tasapainoilu 8 ) Tuoteomistaja vastaa myös siitä, että projektissa saadaan aikaan tulosta tarvitussa ajassa. 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 suhteessa koko tuotteen kokonaisuuteen. Tarvitaan siis kokonaiskäsitys tuotteesta jota ollaan työstämässä: Tuotteen kokonaisuuden hahmottaminen esimerkiksi käyttäjätarinakartoituksella tai muulla kattavuuteen pyrkivällä menetelmällä Tuotteen kokoluokan arvioiminen esimerkiksi toimintopisteanalyysillä tai kehittäjien kanssa t-paitakokoluokituksella, ja näiden arvioiden vertaaminen toteutuvaan toteutustahtiin Toiseksi tarvitaan keinoja nopeuttaa arvon tuottamisen tahtia tarvittaessa. Scrumissa ajatellaan, että kestäviä tuloksia ei voi saada aikaan tekemällä töitä näännyttävällä tahdilla tai leikkaamalla laatua. Tiimin kasvattamiseenkin liittyy ongelmia. Sen sijaan ratkaisuja etsitään miettimällä asioita fiksummin: Käyttäjätutkimus: Mikä on se mahdollisimman yksinkertainen ominaisuuksien yhdistelmä, joka jo toisi asiakkaille ilahduttavan paljon arvoa? ( Minimum viable product tai jopa minimum lovable product.) Julkaistaan tämä ensin. Ominaisuuksien painottaminen: Mitä ominaisuuksia käyttää suurin osa käyttäjistä? Minkä parissa he kuluttavat eniten aikaa? Keskitetään hiomistyö näihin ominaisuuksiin ja etsitään muissa yksinkertaisempia ratkaisuja.
Tuoteomistaja tarvitsee käytännön välineitä tuotteen kokonaisuuden hahmottamiseen sekä tuotekokonaisuuden etenemisen arvioimiseen.
1.2 Kehitystiimi Ymmärtää, millaisia vaihtoehtoja tuotteen kehittämiseen on olemassa 10 $ Kehitystiimi vastaa siitä, että jokaisessa sprintissä saadaan julkaisukelpoinen tuoteversio. Kehitystiimi on Scrum-tiimi ilman tuoteomistajaa ja Scrummasteria. Sen muodostavat ohjelmistokehittäjät. Kehitystiimin vastuulla on saada potentiaalisesti julkaisukelpoinen, valmis tuoteversio aikaan jokaisessa sprintissa. Scrum korostaa kehitystiimin kohdalla samaa itseohjautuvuutta ja monitaitoisuutta kuin Scrum-tiimissäkin, mutta lisäksi erityisesti tarkkojen roolien välttämistä sekä yhteistä vastuuta syntyvästä järjestelmästä. Kehitystiimin koko on 3-9 kehittäjää. Koon suhteen tasapainoillaan toisaalta riittävän kommunikoinnin ja monialaisuuden, toisaalta liian koordinoinnin välillä. Tuoteomistaja pääsee hyödyntämään kehitystiimin teknistä tietotaitoa, kun tehdään päätöksiä siitä, millaisilla ratkaisuilla tuoteominaisuuksia kehitetään. Tuoteomistaja voi pyytää kehitystiimiltä ajatuksia muutamasta erilaajuisesta toteutusvaihtoehdosta ja niistä voidaan yhdessä valita se, joka tuoteomistajan ymmärryksen mukaan tällä hetkellä tyydyttää 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. Kehitystiimi kantaa vastuun tuotteen teknisestä visiosta eli siitä, että tuotteesta muodostuu mielekäs ja kestävä kokonaisuus. Tuoteomistajan kannattaa kunnioittaa tätä vastuuta ja toisaalta omalla toiminnallaan auttaa kehitystiimiä sen kantamisessa.
1.3 Scrummaster Vastaa siitä, että kaikki ymmärtävät ja käyttävät Scrumia. 11 * Scrummaster ei ole projektipäällikkö. Scrummaster vastaa siitä, että kaikki ymmärtävät ja käyttävät Scrumia. Scrummaster on Scrum-tiimin palveleva johtaja, joka auttaa Scrumin käytössä yhtä hyvin niin tuoteomistajaa, kehitystiimiä kuin esimerkiksi ohjausryhmääkin. Erityisesti Scrummaster kannustaa projektiyhteisöä oppimaan jatkuvasti eli tarkastelemaan ja sopeuttamaan toimintaansa. Usein Scrummasterin rooli ymmärretään väärin. Tilanteessa, jossa kehitystiimi on toimittajan tarjoama ja tuoteomistaja on tilaajaorganisaatiosta, Scrummaster ajatellaan usein toimittajan projektipäälliköksi ja toimitusvastuulliseksi. Scrumin mukaan siis Scrummasterin vastuulla on kuitenkin ainoastaan auttaa käyttämään Scrumia. Muista mahdollisista rooleista on sovittava erikseen Scrum-viitekehyksen ulkopuolella. Scrumin mukaisenakin Scrummasterin rooli on erittäin tärkeä. Scrummaster auttaa: Tuoteomistajaa tarjoamalla tekniikoita kehitysjonon hallinnointiin ja järjestämiseen sekä tuotesuunnittelun ymmärtämiseen, fasilitoimalla Scrumin tapahtumia tarvittaessa Kehitystiimiä valmentamalla itseohjautuvuuteen, moniosaamiseen ja toimimaan ympäristöissä, joissa Scrum ei ole vielä täysin käytössä, poistamalla esteitä etenemisen tieltä sekä fasilitoimalla Scrumin tapahtumia tarvittaessa Muuta organisaatiota johtamalla ja valmentamalla päätöksentekijöitä Scrumin käyttöönotossa, suunnittelemalla Scrumin toteutusta organisaatiossa, auttamalla työntekijöitä ja sidosryhmiä ymmärtämään Scrumia ja tuotekehitystä, aiheuttamalla muutoksia, jotka kasvattavat Scrumtiimin tuottavuutta ja työskentelemällä yhdessä mahdollisten muiden Scrummastereiden kanssa Scrumin käytön tehokkuuden parantamiseksi Scrummasterin tehtävä on siis vaativa rooli Scrum-työtavan omaksumisessa ja kehittämisessä. Käytännössä Scrummasteria auttamaan tuodaankin usein siksi ketteryysvalmentajia. Heidän rooliinsa Scrum ei ota kantaa.
2. Scrumin tapahtumat Luovat tekemiseen säännöllisyyttä, minimoivat kokousten tarvetta ja mahdollistavat yhdessä oppimisen 12 + Scrum-tapahtumat ovat: 2.1 Sprintti 2.2 Sprintin suunnittelu 2.3 Päiväpalaveri 2.4 Sprintin katselmointi 2.5 Sprintin retrospektiivi Scrumin tapahtumien tärkein tehtävä on mahdollistaa tarkasteleminen ja sopeuttaminen eli yhdessä oppiminen. Jokaisella Scrum-tapahtumalla on oma erityinen rooli, eikä mitään niistä voi jättää pois. Kaikki Scrumin tapahtumat ovat aikarajattuja, eli niillä on maksimipituus, jota ei kuitenkaan ole pakko käyttää kokonaan. CC Flickr Lauris Rubenis Tuoteomistajalle tärkeä tapahtuma on sprintin suunnittelu siksi, että se vaatii työtä kehitysjonon valmistelussa suunnittelukuntoon.
2.1 Sprintti Scrumin kehitystyön perusyksikkö 13 % Sprintin aikana tuotetaan valmis, käyttökelpoinen tuoteversio. Sprintti on enintään kuukauden pituinen tai sitä lyhyempi aika, jossa tuotetaan valmiin määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti julkaisukelpoinen versio tuotteesta. Sprinteillä on aina sama pituus, ja uusi sprintti alkaa heti edellisen päätyttyä. Yleensä sprintti keskeytetään vain silloin, kun maailma ympärillä muuttuu lyhyen sprintin aikana niin paljon, ettei sen tavoitteen saavuttaminen enää kannata. Tällöin asiasta päättää tuoteomistaja. Sprintit koostuvat sprintin suunnittelupalaverista, päiväpalaverista, kehitystyöstä sprintin katselmoinnista ja sprintin retrospektiivista. Jokaisella sprintillä on oma sprinttitavoite. Mitä loogisempi ja helpommin kommunikoitava tavoite sprintille saadaan muodostettua, sitä helpompi tavoitetta kohti on työskennellä. Sprintin sisältöä voidaan sen aikana tarkentaa tuoteomistajan ja kehitystiimin välillä sitä mukaa kun siitä opitaan lisää, tai mikäli kohdataan vaikeuksia, toteuttaa esimerkiksi vain osa sprintin tehtävistä. Tavoitetta ei sprintin aikana kuitenkaan muuteta. Sprintin aikana ei myöskään tingitä laatutasosta esimerkiksi muuttamalla valmiin määritelmää.
2.2 Sprintin suunnittelu Valmistellaan selkeä työkokonaisuus sprinttiä varten 14 % Sprintin suunnittelussa päätetään sprintin tavoite ja suunnitelma sen toteuttamiseksi. Sprintin aikana toteutettava työ suunnitellaan sprintin suunnittelupalaverissa yhdessä koko Scrum-tiimin kesken. Suunnittelu rajataan Scrumin mukaan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille, mutta käytännössä yli puolen päivän sprinttisuunnittelut ovat harvinaisia. Scrummaster varmistaa, että sprintti suunnitellaan, osallistujat ymmärtävät tapahtuman tarkoituksen ja tapahtuma pysyy aikarajan sisällä. Sprintin suunnittelussa käsitellään seuraavat asiat: Mitä on mahdollista toimittaa alkavan sprintin tuoteversiossa? Tuoteomistaja ja kehitystiimi keskustelevat ja käyvät läpi seuraavat kehitysjonon kohdat. Koko tiimi työskentelee yhdessä ymmärtääkseen tehtävät. Sen pohjalta muodostetaan sprintin tavoite, joka ohjaa työtä. Kehitystiimi arvioi ja päättää yksin, miten paljon työtä sprinttiin voidaan ottaa. Miten tuoteversion toimittamiseen liittyvä työ voitaisiin toteuttaa? Kehitystiimi suunnittelee itseohjautuvasti, miten sovittu työ toteutetaan valmiiksi tuoteversioksi. Ainakin sprintin ensimmäisten päivien työt pilkotaan enintään päivän kokoisiin paloihin. Tuoteomistaja tai tarvittaessa muutkin henkilöt voivat olla läsnä antamassa tarvittaessa lisää tietoa. Sprinttiin otetut tuotteen kehitysjonon kohdat sekä niiden toteutussuunnitelma on nimeltään sprintin kehitysjono. Sprintin suunnittelun lopussa kehitystiimillä on sprinttitavoite sekä suunnitelma sen toteuttamiseksi, jonka se voi selittää Scrummasterille ja tuoteomistajalle. Scrum-opas korostaa kehitystiimin 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 kehitystiimille 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 sitä arvostetaan.
Sprinttisuunnittelu työllistää tuoteomistajaa Scrumin tapahtumista eniten.
2.3 Päiväpalaveri Ei raportointia vaan kommunikointia 16, Enintään 15 min päiväpalaverissa suunnitellaan seuraavat 24 tuntia. Päiväpalaveri on enintään 15 minuutin mittainen tapahtuma, jossa kehitystiimi tahdistaa työnsä ja suunnittelee seuraavat 24 tuntiaan. Käytännössä tiimi tarkastelee edellisen päiväpalaverin jälkeen tehtyä työtä ja ennustaa, mitä voidaan toteuttaa ennen seuraavaa päiväpalaveria. Tekemisiä fokusoidaan suhteessa sprinttitavoitteeseen. Päiväpalaveri pidetään yksinkertaisuuden vuoksi samaan aikaan samassa paikassa. Scrummaster varmistaa, että kehitystiimi pitää päiväpalaverin ja että se pysyy aikarajassa. Kehitystiimin vastuulla on itse päiväpalaverin järjestäminen. Scrum siis sulkee tuoteomistajan päiväpalaverin ulkopuolelle. Käytännössä tätä sääntöä usein rikotaan varsinkin projekteissa, joissa tuoteomistaja ei istu samassa tilassa kehitystiimin kanssa, jotta kommunikaatio saadaan toimimaan. Tällöin pitää kuitenkin olla erityisen tarkkana siitä, että päiväpalaveri säilyy kehitystiimin kommunikointina suunnitelmasta tavoitteen saavuttamiseksi eikä muutu raportoinniksi tuoteomistajalle.
2.4 Sprintin katselmointi Katselmoinnissa tarkastellaan kehitettyä tuoteversiota 17 ' Sprintin katselmointi on mahdollisuus visiokeskusteluun Sprintin lopuksi pidetään enintään nelituntinen sprintin katselmointi, jossa tarkastellaan kehitettyä tuoteversiota ja sopeutetaan tarvittaessa jäljellä olevaa tuotteen kehitysjonoa. Sprintin katselmoinnin aikana Scrum-tiimi ja sidosryhmät käyvät läpi yhteistyössä, mitä sprintissä kehitettiin, ja keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi. Keskustelun tavoitteena on ymmärtää, miten tuotteelle ja kehitysponnistukselle saadaan jatkossa paras arvo. Roolitus sprinttikatselmoinnissa menee seuraavasti: 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 tuoteversioon 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 Tarkistetaan tuotteen julkaisun aikataulu, budjetti, markkinatilanne ja potentiaaliset toiminnallisuudet Sidosryhmät kuten ohjausryhmä osallistuu sen pohtimiseen, mitä kannattaa tehdä seuraavaksi. Erityisesti sidosryhmät tuovat mukanaan tietoa markkinatilanteesta, tuotteen käytöstä sekä aikatauluun ja budjettiin vaikuttavista asioista. Sidosryhmien ja tulevaisuuden suunnittelun rooli sprinttikatselmoinnissa on erityisesti korostunut uusimmissa Scrum-versioissa sidosryhmätyössä. Sidosryhmätyöhön tarvitaan kuitenkin muitakin välineitä, ja nämä ovat tuoteomistajan vastuulla.
2.5 Sprintin retrospektiivi Elintärkeä mahdollisuus oppimiseen 18 - Scrum-tiimi tarkastelee sprintin retrospektiivissä toimintaansa ja miten sitä voi parantaa. 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 että tapahtumaan osallistuvat ymmärtävät sen tarkoituksen. Scrummaster opastaa Scrum-tiimiä pitämään tapahtuman enintään sen aikarajan pituisena. 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. Vaikka prosessin parannuksia voidaan toteuttaa milloin tahansa, sprintin retrospektiivi tarjoaa muodollisen tilaisuuden prosessin tarkasteluun ja sopeuttamiseen. Käytännössä retrospektiivi on usein valitettavasti se osa Scrumista, josta ensimmäisenä lipsutaan, koska oppiminen on tukalaa. Se on kuitenkin koko Scrumin ja työn sujumisen ytimessä. Tuoteomistajan kannattaa ehdottomasti olla yhtenä Scrum-tiimin jäsenistä retrospektiiveissä mukana.
3. Scrumin tuotokset Lisäävät läpinäkyvyyttä 19. Scrumin tuotoksia ovat: 3.1 Tuotteen kehitysjono 3.2 Edistymisen seuraaminen kohti tavoitetta 3.3 Sprintin kehitysjono 3.4 Sprintin edistymisen seuraaminen 3.5 Tuoteversio 3.6 Tuotosten läpinäkyvyys 3.7 Valmiin määritelmä CC Flickr Amelia Bueno Timón
3.1 Tuotteen kehitysjono Lista kaikista muutoksista, jotka toteutetaan tuleviin tuoteversioihin 20 / Kehitysjono on tuoteomistajan tärkein työväline. Tuotteen kehitysjono on paitsi järjestetty lista kaikesta mitä tuotteessa saatetaan tarvita, erityisesti lähde tuotteeseen toteutettaville vaatimuksille ja muutoksille. Tuoteomistaja vastaa tuotteen kehitysjonosta mukaan lukien sen sisältö, saatavuus ja järjestäminen. Tuotteen kehitysjono listaa kaikki ominaisuudet, toiminnot, vaatimukset, parannukset ja korjaukset, jotka tullaan toteuttamaan tuleviin tuoteversioihin. Tuotteen kehitysjonon kohdat sisältävät vähintään kuvauksen, järjestyksen ja työmääräarvion. 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. Joskus useampi Scrum-tiimi työskentelee saman tuotteen parissa. Tällöin työtä ohjataan yhdellä tuotteen kehitysjonolla, johon voidaan lisätä vaatimusten ryhmittelyä tukeva tunniste. Tuoteomistajan ei kannata suhtautua kehitysjonoon toiveiden tynnyrinä, vaikka sinne kirjataankin mieleen tulevat toiveet tuotteelle. Mieluummin kannattaa jo alusta alkaen ottaa tavoitteeksi saada mahdollisimman paljon kehitysjonosta käyttäjäpalautteen perusteella ei toteuteta luokkaan. Tämä vapauttaa työaikaa niille ominaisuuksille, jotka ovat aidosti tuotteen menestymisen ja käyttäjille tulevan arvon kannalta tärkeitä.
Tuotteen kehitysjono on tuoteomistajan tärkein työväline.
Tuotteen kehitysjono kehittyy kattavammaksi listaksi, kun tuotetta käytettäessä saadaan palautetta markkinoilta. Vaatimusten muuttuminen ei pääty koskaan.
3.1 Tuotteen kehitysjono Alkupuolelta tarkalla tasolla, lopusta karkeampi 23 / Kehitysjonon työstössä tuoteomistaja ja kehitystiimi lisäävät yksityiskohtia kehitysjonoon. Tuotteen kehitysjonon työstäminen 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. Työstön aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. työstönkäytännön toteutuksesta päätetään Scrum-tiimin sisällä. työstöön 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 työstää 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 valintaan. Kehitystiimi vastaa kaikista työmääräarvioista, mutta tuoteomistaja vastaa siitä, että kehitysjono on kuvattu tarpeelliselle tasolle asti ja että se on hyvässä järjestyksessä.
3.2 Edistymisen seuraaminen kohti tavoitetta Vain sitä, mitä on todella tapahtunut, voidaan käyttää tulevaisuuteen liittyvässä päätöksenteossa 24 0 Tuoteomistaja seuraa ja arvioi työn edistymisnopeutta. Jäljellä oleva työ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.
Edistymisen seuranta on läpinäkyvyyden kulmakivi.
3.3 Sprintin kehitysjono Sprinttiin valittu kehitystehtävien kokonaisuus 26 / Sprintin kehitysjono on näkyvä, reaaliaikainen kuva kehitystiimin työstä. Sprintin kehitysjono koostuu sprinttiin valituista tuotteen kehitysjonon kohdista sekä suunnitelmasta niiden toteuttamiseksi. Sprintin kehitysjono on kehitystiimin antama ennuste siitä, mitä toiminnallisuutta seuraavaan tuoteversioon 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. Sprintin kehitysjonon tulee olla riittävän yksityiskohtainen, jotta työn edistyminen voidaan havaita päiväpalaverissa. 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. Yksi syy siihen, että tuoteomistajan kannattaa pitää kehitysjono kokonaan järjestyksessä ja sen alkupään kuvaukset tarkkoina on, että jos kehitystiimiltä loppuukin sprintin aikana työ kesken, he ottavat sprinttiin uusia kehitystehtäviä kehitysjonon kärjestä toki tuoteomistajan kanssa kommunikoiden.
3.4 Sprintin edistymisen seuraaminen Jäljellä oleva työmäärä on milloin tahansa laskettavissa yhteen 27 1 Kehitystiimin keino hallita omaa edistymistään sprintissä. 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äiväpalaverissa arvioidakseen todennäköisyyttä sprintin tavoitteen saavuttamiselle. Seuraamalla jäljellä olevaa kokonaistyömäärää sprintin läpi kehitystiimi voi hallita omaa edistymistään.
3.5 Tuoteversio Jokaisen sprintin lopussa on olemassa käyttökelpoinen tuoteversio 28 2 Tuoteversio on kehitysjonon kohtien summa. Tuoteversio on summa kaikista tuotteen kehitysjonon kohdista, jotka ovat valmistuneet sprintin ja aiempien sprinttien aikana. Sprintin lopussa siinä valmistuneen tuoteversion tulee olla valmis, joka tarkoittaa, että se täyttää Scrum-tiimin valmiin määritelmän ja on käyttökelpoisessa kunnossa, riippumatta siitä, päättääkö tuoteomistaja julkaista sen. Joka sprintin lopussa valmistuva käyttökelpoinen tuoteversio on tärkein tuoteomistajan riskienhallinnan keino. Mikäli kehitystyön ympäristössä tapahtuisi jotakin odottamatonta, se varmistaa, että kehitystyön tulokset ovat käytettävissä.
3.6 Tuotosten läpinäkyvyys Läpinäkyvyys on Scrumin riskienhallintaa 29 & Heikko läpinäkyvyys kasvattaa riskejä. 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ä. Scrummaster työskentelee 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ä. Vaikka Scrummasterilla on läpinäkyvyyden avustamisessa keskeinen rooli, tuoteomistaja on Scrum-tiimistä se kenelle läpinäkyvyys on kaikkein tärkeintä. Niinpä sen toteuttamisessa kannattaa olla aktiivinen.
Täydellisen läpinäkyvyyden vallitessa päätökset perustuvat todelliseen tietoon.
3.7 Valmiin määritelmä Scrumin tärkein laadunhallinnan väline 31 3 Kaikkien tiimin jäsenten on ymmärrettävä, mitä valmis tarkoittaa. Kun tuotteen kehitysjonon kohdan tai tuoteversion 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 tuoteversioon 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 tuoteversio, joka noudattaa Scrum-tiimin nykyistä valmiin määritelmää. Kehitystiimit toimittavat tuoteversion jokaisessa sprintissä. Jos tuoteversio on käyttökelpoinen, tuoteomistaja voi päättää julkaista sen välittömästi. Jos tuoteversion valmiin määritelmään liittyy kehitysorganisaation standardeja tai määräyksiä, kaikkien Scrum-tiimien tulee noudattaa määritelmää miniminään. Jos taas tuoteversion valmiin määritelmään ei liity kehitysorganisaation standardeja tai määräyksiä, kehitystiimi määrittelee tuoteversiolle sopivan valmiin määritelmän. Mikäli tuoteversiota kehittää useampi Scrum-tiimi, niiden kehitystiimien tulee sopia yhteisestä valmiin määritelmästä. Jokainen tuoteversio rakentuu kaikkien aikaisempien tuoteversioiden päälle ja on läpikotaisin testattu. Näin varmistetaan, että kaikki tuoteversiot toimivat yhdessä. Kun Scrum-tiimit kypsyvät, niiden valmiin määritelmä laajenee sisältämään tiukemmat kriteerit korkealle laadulle. Tiimiltä ei kannata aluksi vaatia liian tiukkaa valmiin määritelmää, sillä silloin vaarana on, että sitä ei noudateta. Kaikilla tuotteilla tai järjestelmillä tulisi olla valmiin määritelmä, joka määrittää standarditason tuotteeseen tehtävälle työlle. Odottamattomien muutoksien varalta tuoteomistajan kannattaa varmistaa, että valmiin määritelmään sisältyy myös koodin tallennus saataville jatkotyöstöä varten sekä välttämätön minimidokumentaatio.
Valmiin määritelmä on Scrumin tärkein laadunvarmistuksen väline.
Scrumin muutokset 2013 ja 2016 tiivistettynä Uusin versio korostaa arvoja, edellisessä viilattiin Scrumia systeeminä 33 + Muutokset 2013 Läpinäkyvyyden korostaminen Päiväpalaverissa on kyse tiimin kommunikoinnista eikä raportoinnista Kehitysjonon kohtien valmistelun merkitys Tapahtumien aikarajaus Sprinttikatselmoinnin merkitys sidosryhmiltä saatavassa palautteessa ja tulevaisuuden suunnittelussa Lisäksi lanseerattiin sprinttitavoitteen käsite sekä muutettiin sprinttisuunnittelu yhdeksi tapahtumaksi Muutokset 2016 Scrumin arvojen korostaminen onnistumisen edellytyksenä Suomennoksessa tarkennuksia joihinkin edellisen käännöksen kohtiin
Kiitos kiinnostuksesta! Codento tarjoaa ketteriä kehitystiimejä ja tuotteenhallinnan sekä Scrum-johtamisen valmennusta.
Ketteryysvalmentajamme Asiantuntijamme auttavat sinua mielellään tuotehallintaan ja Scrumiin liittyvissä kysymyksissä ja haasteissa. 36 Karoliina Luoto Karoliina.luoto@codento.com Otso Kivekäs Otso.kivekas@codento.com Miika Kuha Miika.kuha@codento.com Karoliina Luoto on ketterän tuotehallinnan ja projektijohtamisen valmentajakonkari, joka etsii hankkeisiin maksimiarvoa minimipanostuksella. Otso Kivekäs on pitkän linjan ohjelmistoarkkitehti ja projektikätilö, joka vaikuttamisen ammattilaisena taitaa myös projektien johtamisen politiikan. Miika Kuha on kokenut tuoteomistaja, joka on sittemmin keskittynyt organisaatioiden ja tekemisen leaniyttämiseen oleellinen näkokulma myös Scrumtuoteomistajalle!
CODENTO Liiketoimintaa liiniyttäviä palveluitamme ovat: 37 Lean ohjelmistokehitys Ketterä tiimi käyttöösi, liiketoiminnan arvo fokukseen ja koodi omistukseesi. Kun kehittäjät välittävät, syntyy kestävää laatua. IT-arkkitehtuuri Kun liiketoiminnan ITarkkitehtuuri on taitekohdassa tai edessä on isompi strategia- tai tuotevalinta, ulkopuolisesta näkemyksestä on apua. Ketterät menetelmät Codenton valinta on ketterät menetelmät - lean sekä Scrum tai Kanban. Valmennamme ja konsultoimme niiden käytössä. Meiltä saat tarvittaessa tukea ja valmennusta tuoteomistajana toimimiseen sekä projektia ympäröivän organisaation mukaan ottamiseen. Scrum-projektit menestyvät, kun kaikki osapuolet saadaan mukaan onnistumaan.
38 Yhteystiedot Toimistomme sijaitsee Fennia-korttelissa aivan Helsingin yliopiston metroaseman yläpuolella ja kivenheiton päässä Helsingin päärautatieasemalta. Vuorikatu 14 00100 Helsinki Finland +358 400 438610 petri.aukia@codento.fi CC Flickr Amy West