Scrum-tuotehallinta: täydellinen opas ja esimerkit

Scrum ei ole mitään uutta tuotehallinnan alalla. Useimmat meistä käyttävät Scrum-menetelmää yrityksissämme ja pyrkivät navigoimaan tämän viitekehyksen rooleissa ja periaatteissa saavuttaaksemme tavoitteemme.

Valitettavasti yritykset tulkitsevat usein Scrumin periaatteet väärin ja käyttävät niitä virheellisesti, jolloin käyttäjät jäävät paitsi Scrumin monista hyödyistä.

Tämä pieni ja hyödyllinen opas auttaa sinua hyödyntämään tätä viitekehystä paremmin selittämällä, mistä siinä on kyse, miksi Scrumissa on erilaisia rooleja, mitkä ovat tuotehallinnan vastuut ja miten voit menestyä eri toimintojen välisessä yhteistyössä.

Mitä Scrum on tuotehallinnassa?

Monet meistä keskustelevat mielellään tuotepäällikön roolista Scrum-prosessien ja ketterän menetelmän todellisuudessa (toisin sanoen siitä, mitä tuotepäällikkö tekee Scrum-tiimissä). Sen sijaan, että vain selittäisin asian, ajattelen olevan helpompaa näyttää sinulle, missä tuotepäällikkö sijaitsee tiimin organisaatiokaaviossa.

Tässä oppaassa haluan kuitenkin lähestyä aihetta päinvastaisesta suunnasta ja näyttää, miten Scrum sopii todellisuuteesi tuotehallinnan ammattilaisena ja miten se voi auttaa sinua saavuttamaan tuotteellesi asettamasi tavoitteet.

Haluan aloittaa keskustelemalla Scrumin viitekehyksen keskeisten periaatteiden vaikutuksesta työmme tehokkuuteen.

Meille todennäköisesti kaikkein arvokkain Scrumin periaate on arvon jatkuva toimittaminen käyttäjille. Mitä nopeammin ihmiset voivat ratkaista ongelmia, sitä paremmin tuotteesi suoriutuu. Lisäksi saat varhaista palautetta ihmisiltä, jotka ovat käyttäneet ominaisuutta todellisessa tilanteessa.

Toinen Scrumin tarjoama etu on joustavuus. Jos markkinoiden todellisuus muuttuu, voit mukautua siihen nopeasti uudistamalla tuotejonoasi kokonaisuudessaan ja antamalla uudet ominaisuudet tiimillesi seuraavassa sprintissä (tässä tekoäly sprintin suunnittelussa voi auttaa).

Näitä kahta asiaa on erittäin vaikea (tai lähes mahdotonta) toteuttaa perinteisillä viitekehyksillä, kuten vesiputousmallilla, jossa kaikki on määritelty laajuudeltaan etukäteen ja käyttäjät pääsevät käyttämään tuotetta vasta ohjelmistokehityksen elinkaaren lopussa.

Esimerkkejä tuotemenestyksestä Scrumin käyttöönoton ansiosta

Olen työskennellyt Scrum-tiimien kanssa vuosia, joten suhtaudun tähän ketterään viitekehykseen täysin puolueellisesti. Älä siis ota sanaani absoluuttisena totuutena. Tarkastellaan sen sijaan tosielämän tapauksia, joissa Scrum-menetelmään siirtyminen auttoi tuotetiimejä menestymään nopeammin.

Microsoft Visual Studio: Teknologiajätin pääasiallinen koodinmuokkaustyökalu oli pahamaineinen toistuvista tuotannon ongelmakierteistään, virheellisistä julkaisuistaan ja erittäin harvoin tapahtuvista julkaisuistaan. Heti kun sen tuotetiimi alkoi hyödyntää Scrumia, yritys näki tuotteen vakauden kasvavan jyrkästi ja julkaisusyklien tihentyvän huomattavasti, mikä palautti sen kilpailukyvyn markkinoilla.

Spotify: Rakkaan musiikin suoratoistopalvelumme Scrumin käyttöönotto on yksi alan tunnetuimmista tapauksista. Spotifylla oli vaikeuksia mukautua ja skaalautua riittävän nopeasti ratkaistakseen prosessihaasteensa... kunnes organisaatio otti Scrumin käyttöön. Spotifyn erottaa muista kuitenkin sen oman Scrum-projektinhallintamallin kehittäminen. Malli perustui itsenäisten ketterien tiimien ryhmään, joilla oli käytettävissään kaikki tarvittava asiantuntemus nopeaan kokeiluun ja käyttäjäpalautteen hyödyntämiseen.

ING: Alankomaalainen pankkijätti kuului ensimmäisiin rahoituslaitoksiin, jotka ymmärsivät pankkitoiminnan tulevaisuuden olevan digitaalinen. Se ymmärsi myös, etteivät sen erittäin perinteiset projektinhallintaprosessit soveltuneet ohjelmistokehitykseen. Niinpä se otti nopeasti käyttöön lean- ja Scrum-menetelmät ja nousi, ei yllättäen, sähköisen pankkitoiminnan johtajaksi.

Scrum-tuotehallinnan keskeiset roolit

Jos sinä tuotepäällikkönä päätät, että Scrum on oikea tapa edetä, tässä on nopea katsaus tämän viitekehyksen keskeisiin rooleihin. Sen avulla voit erottaa toisistaan roolisi tuotepäällikkönä ja Scrumin tuoteomistajana.

Aloitetaan rooleista. Tyypilliseen Scrum-tiimiin kuuluu seuraavia henkilöitä:

• Scrum-mestari: Tämä henkilö auttaa tiimiä noudattamaan Scrumin sääntöjä ja optimoimaan prosessejaan.
• Tuoteomistaja: Hän edustaa liiketoimintaa ja käyttäjiä Scrum-tiimissä. Tuoteomistajat vastaavat työjonosta sekä asettavat sprinttitavoitteet ja käyttäjätarinoiden prioriteetit.
• Scrum-tiimi: Tuotetta rakentavat kehittäjäsi, suunnittelijasi, laadunvarmistuksen asiantuntijasi ja muut erikoisosaajat.

Scrum-tiimissä voi olla myös monenlaisia muita asiantuntijoita. Monialaiset tiimit perustuvat ajatukseen, että tiimi on ammattiosaamisen saatavuuden osalta itsenäinen. Jos tuotteesi on esimerkiksi vahvasti analytiikkaan painottuva, tiimiisi voi kuulua myös data-analyytikko.

Tuotepäällikkö vs. tuoteomistaja: mikä ero on?

Antamani tuoteomistajan määritelmä saattaa hämmentää sinua hieman, sillä se kuulostaa hyvin samanlaiselta kuin se, mitä tuotepäällikkö yleensä tekee.

Mikä siis tässä tapauksessa on ero tuotepäällikön ja tuoteomistajan välillä?

Ymmärtääksemme eron tarkastellaan ensin kummankin keskeisiä vastuualueita.

Tuotepäälliköt

• Tehdä tuotekehityksen alkuvaiheen selvitystyötä sekä ymmärtää asiakkaiden tarpeita ja ongelmia.
• Määritellä tuotteen visio ja suunta, jota tiimi noudattaa.
• Kehittää tuoteratkaisuja, jotka voivat vastata asiakkaiden tarpeisiin.
• Johtaa tuotteen toimitusprosessia.
• Kehittää tuotetta pienin askelin asiakaspalautteen ja tietoon perustuvan päätöksenteon pohjalta.
• Hallita tuotteen visiota ja toteutusta koko yrityksessä ja sen eri tasoilla.

Tuoteomistajat

• Luoda ja ylläpitää tuotteen työjonoa.
• Toimia Scrum-tiimin strategian, suunnittelun ja liiketoimintalogiikan ainoana totuuden lähteenä.
• Priorisoida tuotteen työjonon kohteet ja selkeyttää tiimille, mikä on tärkeää.
• Määritellä ominaisuuksien hyväksymiskriteerit ja hyväksyä sprintin tulokset niiden perusteella.
• Poistaa tiimin jäsenten esteitä selkeyttämällä vaatimuksia ja korjaamalla niihin liittyviä ongelmia.
• Osallistua Scrum-tapahtumiin ja toimia liiketoiminnan ja asiakkaiden äänenä tiimissä.

Kuten voimme nähdä, useimmat meistä tekevät asioita, joita löytyy kummastakin luettelosta. Se on täysin normaalia ja yleistä, sillä monet meistä toimivat samanaikaisesti sekä tuotepäällikköinä että tuoteomistajina.

Keskeinen ero näiden kahden välillä on se, että tuotepäällikkyys on ammatti ja osaamiskokonaisuus, kun taas tuoteomistajuus on rooli Scrum-tiimissä.

Mutta mitä tämä tarkoittaa?

Se tarkoittaa, että tuoteomistajan ei tarvitse olla tuotepäällikkö. Pienessä startup-yrityksessä, jossa on toimitusjohtaja ja kolme kehittäjää, toimitusjohtaja ottaa tuoteomistajan roolin toimittamalla kehittäjille priorisoidun työjonon.

Myös päinvastainen tilanne on mahdollinen. Voit olla tuotepäällikkö olematta tuoteomistaja. Olen tästä hyvä esimerkki, sillä yksi aiemmista tiimeistäni ei käyttänyt Scrumia. Ei Scrumia, ei myöskään tuoteomistajaa tiimissä. Noudatimme kuitenkin lean- ja ketterän kehityksen periaatteita.

Jotta saisit paremman käsityksen näiden kahden roolin erosta, tässä on rinnakkainen vertailu niiden tehtävistä.

Mutta mikä oli erityisen roolin tarkoitus Scrum-tiimissä? Eivätkö he olisi voineet vain tehdä yhteistyötä tiimiin kuulumattomien tuotepäälliköiden kanssa? Pidän todella paljon siitä, miten Teresa Torres vastaa tähän.

Siksi tärkein syy erityiselle tuoteroolille Scrum-tiimissä on tuoda tiimiin sisäistä tuotetietoa ja asiantuntemusta sekä vahvistaa entisestään sen monialaisuutta. 

Miten tuotepäällikkö toimii yhteistyössä Scrum-tiimien kanssa?

Jos olet päättänyt valita Scrumin, sinun on tiedettävä, miten toimia tiimin jäsenenä ja miten tehdä yhteistyötä muiden kanssa. Käyn lyhyesti läpi, miten tämä tapahtuu kunkin Scrum-tapahtuman ja artefaktin yhteydessä.

• Päivittäinen Scrum (eli päivittäiset tilannepalaverit): Tärkein työ, jonka teet näissä aikarajatuissa kokouksissa, on vastata kehitystiimisi tuotteeseen liittyviin kysymyksiin ja poistaa esteet.
• Sprintin suunnittelupalaveri: Tässä olet henkilö, joka asettaa sprintin tavoitteen määrittelemällä selkeästi odotuksesi niiden ominaisuuksien osalta, jotka odotat toimitettavan.
• Sprintin retrospektiivi: Prosessit, joita käytät prioriteettien ja vaatimusten toimittamiseen tiimille, voivat ratkaista sen tehokkuuden tai romuttaa sen. Siksi voit käyttää tätä kokousta kerätäksesi tiimiltä palautetta ja parantaaksesi prosessejasi.
• Sprintin katselmointi: Tehtäväsi on hyväksyä sprintin valmiit ominaisuudet ja antaa tiimille palautetta heidän työstään.
• Tuotteen tarkennus (eli työlistan tarkennus): Omistat tämän kokouksen, ja sinun tulee käyttää sinulle varattu aika keskustellaksesi tiimille tarkoitettujen käyttäjätarinoiden prioriteeteista ja yksityiskohdista. Kannusta aina tiimiä haastamaan vaatimuksesi ja löytämään sinne jääneet ”tuotebugit”.
• Tuotteen työlista: Sinun vastuullasi on hallita tuotteen työlistaa ja pitää se siistinä ja priorisoituna, sillä tiimi rakentaa sprinttinsä sen perusteella.
• Sprintin työlista: Tämä ei ole sinun omistuksessasi. Keskeinen yhteistyötehtäväsi on ohjata tiimiä ottamaan oikeat käyttäjätarinat sprintin työlistalle varmistaaksesi, että he voivat saavuttaa sprintin tavoitteesi.

Tämän lisäksi teet muunlaista tuotetyötä, kuten sidosryhmien hallintaa tai tuotteen löytämistä. Scrum-tiimin jäsenenä tehtäväsi on pitää tiimi tietoisena sekä sidosryhmien että käyttäjien tarpeista sen jälkeen, kun olet selkeyttänyt ne.

Jos esimerkiksi haastattelet käyttäjää ja huomaat, että kirjautumisprosessisi käyttökokemus on yleisesti ottaen hämmentävä, on tärkeää jakaa tämä tieto tiimin kanssa, jotta he kiinnittävät huomiota kyseiseen osaan seuraavissa sprinteissä.

Scrum-tuotehallinnan parhaat käytännöt

Vaikka tuotehallinta vaikuttaa helpolta Scrum-kehyksen (ja ketterän kehityksen yleisesti) näkökulmasta tarkasteltuna, teemme usein monia virheitä työskennellessämme itseohjautuvissa tiimeissämme.

Tässä siis muutama Scrumin paras käytäntö, joiden avulla voit välttää nämä virheet:

• Aseta selkeät odotukset: Suurin virhe, jonka voit tehdä, on antaa tiimillesi epämääräisiä prioriteetteja ja vaatimuksia. Selkeyden puute on yksi kehityksen viivästymisen ja sinun ja tiimin välisten jännitteiden johtavista syistä. Perehdymme pian perusteellisesti siihen, miten tämä saavutetaan.
• Älä käytä mukautuvuutta väärin: Mahdollisuus muuttaa suuntaa on hieno asia, mutta voit tehdä sen vain tuotteen työlistalla, et sprintin työlistalla. Heti sprintin alettua älä lisää siihen käyttäjätarinoita tai poista niitä. Tämä sotkee tiimisi suunnitelmat ja etenemisen ja johtaa keskeneräisiin sprintteihin.
• Luo psykologisesti turvallinen ympäristö: Olet tiimin jäsen, et sen johtaja. Älä siis painosta tiimiäsi ottamaan suurempia sitoumuksia tai saattamaan työtä valmiiksi etuajassa. Kaikissa Scrum-oppaissa, myös Scrum.orgin oppaassa, painotetaan vahvasti terveiden suhteiden ylläpitämistä tiimikavereihin, sillä se on tehokkaan tiimityön kulmakiviä.

Nämä kolme parasta käytäntöä ovat kokemukseni perusteella tärkeimmät. Jos kuitenkin kaipaat lisää vinkkejä ketteristä työnkuluista ja tuotejohtajien Scrum-käytännöistä, tutustu erilliseen oppaaseemme aiheesta ketterä tuotehallinta.

Tuotteen työlistan tehokas hallinta

Kuten aiemmin mainitsin, selkeyden tarjoaminen tiimillesi on yksi tuotepäällikön tärkeimmistä tehtävistä. Hyvä uutinen on, että tuotteen työlista on todennäköisesti paras yksittäinen työkalu tämän saavuttamiseen. Tässä siis muutama tuotteen työlistan hallinnan vinkki avuksesi:

Tarkennukset: Riippumatta siitä, kuinka hyvin kirjoitat käyttäjätarinasi, niihin jää ”bugeja”, ja haluat kehitystiimisi tarkistavan ne ja osoittavan ne sinulle. Lisäksi et ole kehittäjä, joten saatat kirjoittaa vaatimuksia, joita on vaikea toteuttaa. Tiimisi kertoo tästä jälleen tarkennusprosessin aikana.

Priorisointitekniikat: Hyödynnä lukuisia priorisointikehyksiä ymmärtääksesi, mitkä ominaisuudet ovat toisia tärkeämpiä. Oma suosikkini on MoScoW sen yksinkertaisuuden vuoksi.

Yhdenmukaisuus tiekartan ja vision kanssa: Työlistasi laajojen toiminnallisuuskokonaisuuksien ja käyttäjätarinoiden tulisi kuvastaa yleisiä tuotetavoitteita ja mittareita, jotka haluat saavuttaa. Muista siis tarkistaa tiekarttasi jatkuvasti, kun lisäät jotain työlistalle.

Sidosryhmien yhteensovittaminen Scrumissa

Tuotepäällikön roolin ydin Scrumissa on se, että olet käytännössä itseohjautuvan tiimin ja ulkomaailman välinen yhdistävä linkki – olipa kyse käyttäjistä, sidosryhmistä tai muista tiimeistä.

Sen lisäksi, että hoidat tuotepäällikkönä tavanomaisia sidosryhmien hallintaan liittyviä tehtäviä, sinun on myös välitettävä nämä tiedot takaisin tiimillesi ja päinvastoin. On myös tilanteita, joissa sinun on välitettävä tietoa tiimiltä takaisin sidosryhmille.

Hyvä esimerkki tästä ovat tekniset haasteet, kuten jatkuvan integraation ongelmat, jotka voivat vaikuttaa tietyn ominaisuuden aikatauluun tai laajuuteen. Tästä sinun on keskusteltava sidosryhmien kanssa, minkä jälkeen joko hyväksytte uuden aikataulun tai laajuuden tai keksitte toisen ratkaisun (esimerkiksi vahvistatte tiimiä kyseiseen aiheeseen liittyvällä lisäasiantuntemuksella).

On myös tilanteita, joissa tiimisi on saattanut keksiä kiinnostavan idean ominaisuudeksi tai ratkaisuksi, joka kannattaa lisätä etenemissuunnitelmaan. Jälleen välität tämän tiedon sidosryhmille ja päätätte, lisätäänkö se suunnitelmaasi vai ei.

Ketterän etenemissuunnittelun merkitys Scrumissa

Vaikka ketterät etenemissuunnitelmat eivät kuulu suoraan Scrumiin, ne ovat yksi Scrumin mahdollistavista työkaluista. Mitä järkeä iteratiivisessa suunnittelussa nimittäin olisi, jos käyttäisit tuotteesi kehittämiseen vesiputousmallia ketterän etenemissuunnitelman sijaan?

Siinä tapauksessa se, mitä kutsut Scrumin mukaiseksi tuotestrategiaksi, olisi yksinkertaisesti ennalta määritellyn ja kiinteän, perinteiseen SDLC-malliin perustuvan suunnitelman jakamista kahden viikon (tai sprinttiesi pituuden mukaisten) jaksoihin. Jotta Scrum olisi tiimillesi mielekäs, sinun on siis tehtävä ketterää ja vuorovaikutteista suunnittelua sekä rakennettava etenemissuunnitelma, joka pystyy muuttumaan ajan myötä.

Jotta yhdistäisit ketterän etenemissuunnitelmasi asianmukaisesti tiimisi Scrum-prosesseihin, ehdotan seuraavaa:

• Yhdistä etenemissuunnitelman kohteet (yleensä epicit) tuotteen työlistan käyttäjätarinoihin. Näin taktisen työsi (tarinat) ja strategiasi (etenemissuunnitelma) välillä on suora yhteys.
• Esittele etenemissuunnitelmasi Scrum-tiimillesi. Näin he tietävät, mihin suuntaan tuote kehittyy, ja ottavat tulevat ominaisuudet huomioon käyttöliittymän tai taustajärjestelmän arkkitehtuuria suunnitellessaan.
• Hyödynnä erikoistuneita työkaluja, kuten Jiraa, Monday.comia ja Clickupia, tehostaaksesi etenemissuunnittelun ja työlistan hallinnan prosessia.

Viimeisen kohdan osalta nämä kolme työkalua ovat niitä, joita olen käyttänyt käytännössä. Voit kuitenkin harkita myös monien muiden tuotehallintatyökalujen käyttöä.

Scrumin mukaisen tuotehallinnan haasteet

Vaikka Scrum on erinomainen viitekehys tuotetavoitteidesi saavuttamiseen, tämän viitekehyksen käyttöön liittyy omat haasteensa, kuten:

• Tiimisi tai sidosryhmäsi eivät välttämättä ymmärrä, mistä Scrumissa on kyse. Tämä voi tietenkin johtaa merkittäviin Scrumin käyttöönotto-ongelmiin, kuten kieltäytymiseen tiettyjen artefaktien käytöstä. Suosittelen varautumaan tähän havainnollistamalla halutun "lopputilanteen" eli sen, miltä tiimi ja työnkulku näyttävät, kun viitekehys on otettu kokonaisuudessaan käyttöön.
• Ihmiset (ja sinä) saattavat hämmentyä roolistasi tiimissä ja tiimin ulkopuolella. Jokaisella urani aikana työskentelemälläni yrityksellä on ollut oma käsityksensä siitä, mikä Scrum-tuoteomistajan rooli on. Tiimillesi on parasta määritellä, mitä rooli tarkoittaa — ja mitä se ei tarkoita.
• Työstämiesi ominaisuuksien laajuus pyrkii kasvamaan loputtomasti. Ei ole yllättävää, että tästä on erittäin helppo päätyä laajuuden hallitsemattoman kasvun tilanteeseen. Scrum-tiimien on oltava tinkimättömiä sen suhteen, mitä ne ottavat tehtäväkseen ja mille ne sanovat "ei".
• Tiekartta voi helposti suistua raiteiltaan. Kun tiimi on suhteellisen itsenäinen ja voi valita, mitä se työstää, saatat päätyä tilanteeseen, jossa tiimi rakentaa tiekarttasi ulkopuolelle jääviä asioita. Lopullisen tavoitteen pitäminen selkeästi fokuksessa on ensiarvoisen tärkeää tämän sudenkuopan välttämiseksi.

Vaikka nämä haasteet ovat melko yleisiä, hyvä uutinen on se, että tuotepäälliköltä kuluu yleensä vain pari sprinttiä Scrum-prosessin ymmärtämiseen ja valtaosan näistä haasteista voittamiseen. Jos haluat muodollistaa osaamisesi, opettelemalla kuinka Scrum-mestariksi tullaan voit saada uskottavaa etua tiimiesi ohjaamisessa viitekehyksen avulla.

Johtopäätös

Scrum on yksi parhaista lahjoista, joita tuotepäälliköt voivat saada. Sen ansiosta, että se yhdistää pitkän aikavälin ketteryyden ja lyhyiden iteraatioiden aikaisen kurinalaisuuden, voit välttää viitekehyksettömän ketterän kehitysprosessin kaaoksen ja säilyttää samalla mahdollisuuden muuttaa tuotteesi suuntaa markkinoiden reaktion perusteella.

Toivottavasti pidit oppaastamme. Jos pidit, älä unohda tilata uutiskirjettämme saadaksesi lisää tuotehallinnan resursseja ja oppaita sekä uusimmat podcastit, haastattelut ja muut alan johtajien ja asiantuntijoiden näkemykset.