Tuotteen työlista vs. sprintin työlista: keskeiset erot

Tuotekannat ovat ketterien työnkulkujen selkäranka, ja ne ohjaavat tiimejä ideoista toteutukseen. Yksi yleinen sudenkuoppa on kuitenkin se, että tuotekantojen ja sprinttikantojen välistä eroa ei tunnisteta – tämä voi johtaa väärin kohdennettuihin prioriteetteihin, tehottomiin sprintteihin ja turhautuneisiin tiimeihin.

Vaikka monilla meistä on kokemusta tuotekantojen hallintaohjelmistoista, näiden kahden toisistaan poikkeavan työkalun väärinkäyttö voi aiheuttaa enemmän hämmennystä kuin selkeyttä.

Miten siis varmistamme, että tuotekannat toimivat meidän hyväksemme eivätkä meitä vastaan? Niiden ainutlaatuisten roolien ymmärtäminen ei liity vain määritelmiin, vaan myös yleisten työnkulkuongelmien ratkaisemiseen ja tiimien yhteistyön optimointiin. Käydään läpi niiden erot ja tarkastellaan, miten niitä voidaan käyttää tehokkaasti.

Mikä on tuotteen kehitysjono?

Lyhyt ja yksinkertaistettu selitys tuotteen kehitysjonosta on tämä: se sisältää kaikki ominaisuudet ja tehtävät, joita sinä ja kehitystiimisi suunnittelette toteuttavanne.

Rakenteellisemman määritelmän saamiseksi tutustutaan Atlassianin määritelmään.

Olet ehkä huomannut, että Atlassianin asiantuntijat korostivat kahta tärkeää käsitettä määritellessään kehitysjonoa.

1. Se on priorisoitu.

Yksinkertaisen rakennettavien asioiden luettelon tekeminen johtaa joko valtavaan sekasotkuun tai tuotteeseen, joka ei pysty ratkaisemaan käyttäjiesi ongelmia kunnolla. Ominaisuusluettelo ei siis oikeastaan ole tuotteen kehitysjono, ellet priorisoi sitä.

2. Se on johdettu tiekartasta.

Olen nähnyt lukuisia kehitysjonoja, jotka olivat yksinkertaisesti seurausta siitä, että kaikki jakoivat ominaisuusideoitaan ja lisäsivät niitä kehitysjonoon. Tämä johtaa sekasotkuun ja tuotteeseen, joka näyttää Frankensteinin hirviöltä. Jos haluat kehitysjonon kohteiden saavuttavan tietyn tuote- tai liiketoimintatavoitteen, sinun on rakennettava kehitysjono tiekartan ja tuotevision pohjalta.

Kehitysjonon olemassaolon keskeinen tarkoitus on luoda kaikille yrityksessä yksi totuuden lähde. Kehitysjonon pitäisi aina olla yksi, ja kaikkien pitäisi käyttää sitä viitteenä päättäessään, mitä seuraavaksi tehdään.

Lisäksi tuotteen kehitysjono on erinomainen työkalu sinun ja sidosryhmiesi priorisoinnin helpottamiseen, koska kaikki tarvittava on koottu yhteen luetteloon.

Mitä kehitysjonon tulisi sisältää?

Jos käytät jotakin ketteristä viitekehyksistä, tuotteen kehitysjono koostuu seuraavista kohteista:

• Laajat kokonaisuudet: Suuria ominaisuuksia, jotka auttavat saavuttamaan tiettyjä tuotetavoitteita, kuten konversion kasvattamisen, tietyn käyttäjäongelman ratkaisemisen tai käyttäjän matkan parantamisen koko tuotteessa. Google Docsin kommentointiominaisuus on tästä esimerkki. Laajat kokonaisuudet koostuvat yleensä pienemmistä ”alisominaisuuksista”, joita kutsutaan käyttäjätarinoiksi.
• Käyttäjätarinat: Pieniä ominaisuuksia tai ominaisuuden osia, joita asiakkaasi voivat käyttää. Edellä mainitussa Google Docsin ominaisuudessa ”jonkun mainitseminen kommentissa” tai ”kommentin ratkaiseminen” olisivat tyypillisiä esimerkkejä tähän laajaan kokonaisuuteen kuuluvista käyttäjätarinoista.
• Tekniset tehtävät: Kehitystiimisi tekemää työtä, joka ei liity kehitysjonon ominaisuuksiin. Tällaisia tehtäviä ovat esimerkiksi varmuuskopiotietokannan määrittäminen, mikropalvelun uudelleenjärjestely tai kyselynopeuksien optimointi.
• Virheet: Kehitysjono ei ole todellinen kehitysjono, jos siinä ei ole virheitä. Riippumatta siitä, kuinka hyvin kehität ja testaat ominaisuuksiasi, nämä pienet loiset ilmaantuvat aina. Siksi niitä on säilytettävä, seurattava ja hallittava jossakin. Paras käytäntö on tallentaa ne kehitysjonoon ja priorisoida ne aivan kuten mikä tahansa muu kehitysjonon kohde.

Tältä tyypillinen tuotteen kehitysjono näyttää:

Jos kaipaat lisäohjeita, lue artikkelimme aiheesta 3 esimerkkiä hyvin toteutetusta tuotteen kehitysjonosta.

Seuraavaksi tarkastellaan tuotepäällikön roolia kehitysjonon parissa työskentelyssä.

Kuka vastaa kehitysjonon hallinnasta?

Lyhyesti sanottuna tuotepäällikkö on backlogin valtias. Hän päättää, mitä rakennetaan, missä järjestyksessä ja miksi. Backlog on hänen aluettaan, ja viime kädessä hän vastaa siitä, että se pysyy linjassa tuotevision, käyttäjien tarpeiden ja liiketoimintatavoitteiden kanssa.

Tämä ei tarkoita, että PM olisi ainoa, joka käsittelee backlogia. Insinöörit, suunnittelijat ja muut tiimin jäsenet voivat ehdottaa tai jopa lisätä kohteita, mutta kaikki muutokset tulisi tehdä PM:n valvonnassa. Kaaottinen backlog johtaa nimittäin kaoottiseen tuotteeseen.

PM:n keskeisiin backlog-vastuisiin kuuluvat:

• Backlogin priorisointi – Varmistetaan, että arvokkain ja vaikuttavin työ tehdään ensin.
• Backlogin tarkentaminen tiimin kanssa – Kohteita tarkastellaan, päivitetään ja pilkotaan säännöllisesti, jotta työ pysyy selkeänä ja toteutuskelpoisena.
• Backlogin prioriteeteista ja muutoksista viestiminen – Sidosryhmät pidetään ajan tasalla, jotta yllätyksiä ei synny.

Koska backlog on elävä dokumentti, se kehittyy jatkuvasti. Uusia ideoita syntyy, prioriteetit muuttuvat ja joitakin ominaisuuksia jätetään kokonaan pois. Tämä joustavuus on ketterän kehityksen keskeinen periaate – backlogin tulisi kuvastaa viimeisimpiä realiteetteja, ei jäykkää ja vanhentunutta suunnitelmaa.

Hyvin hallittu backlog ei ole pelkkä tehtävälista, vaan strateginen työkalu, joka auttaa tiimejä rakentamaan oikean tuotteen oikeaan aikaan. Ja kaiken keskiössä? Tuotepäällikkö, jolla on avaimet hallussaan.

Tuotebacklogin luominen ja hallinta 101

Backlogin ensimmäisen version rakentaminen alkaa heti, kun tuotesuunnitelma on valmis. Yleensä poimit tuotesuunnitelmasta kaikki merkittävät ominaisuudet ja työkokonaisuudet ja muutat ne backlogissa eepoksiksi.

Sen jälkeen alat laatia kutakin varten tuotevaatimusdokumentteja ja luot PRD:ssä kuvatun toiminnallisuuden jaotteluun perustuvia eepoksia.

Tuotekehityksen luonnollisena seurauksena päädyt kuitenkin muuttamaan näitä eepoksia jatkuvasti, lisäämään itsenäisiä käyttäjätarinoita ja korjaamaan virheitä, jolloin backlogista tulee sellainen, jonka parissa useimmat meistä työskentelevät. Toisin sanoen sotkuinen.

Backlogia on kuitenkin melko helppo ylläpitää, jos:

• Järjestät säännöllisiä backlogin tarkennustilaisuuksia.
• Varaat seuraavasta sprintistä aikaa laajamittaisiin virheenkorjauksiin ja puhdistat backlogin niistä.
• Et anna kaikkien lisätä ideoitaan backlogiin keskustelematta ensin kanssasi.
• Priorisoit backlogia jatkuvasti.
• Käytät käyttäjätarinoiden kartoitusta saadaksesi selkeän yleiskuvan siitä, mitä on tehtävä.

Viimeiseen kohtaan liittyen tässä on kaksi keskeistä priorisointitekniikkaa, joiden käyttöä suosittelen laajan kokemukseni perusteella kokeiltuani tusinaa eri menetelmää.

MoSCoW

Tämä on melko yksinkertainen tekniikka, jossa backlogin kohteet jaetaan näihin neljään luokkaan:

• Pakollinen: Ominaisuus kuuluu käyttäjän keskeiseen palvelupolkuun, eikä käyttäjän ongelmia voida ratkaista ilman sitä. Esimerkiksi Spotifyn soittolistat ovat pakollinen ominaisuus.
• Tärkeä: Merkittävä parannus käyttäjän palvelupolkuun. Spotifyn tapauksessa se voisi olla mahdollisuus etsiä valmiita soittolistoja mielialan tai tekemisen perusteella.
• Hyödyllinen: Jotain, mikä ilahduttaa käyttäjää, mutta jonka puuttuminen ei ratkaise tuotteen onnistumista tai epäonnistumista. Spotify voisi käyttää eleitä kappaleen vaihtamiseen painikkeiden sijaan.
• Ei toteuteta: Ominaisuudet tai hankkeet, jotka sinä, sidosryhmäsi tai tiimisi totesitte hyödyttömiksi tarkennus- tai priorisointikokouksissa.

Kuten huomaat, MoSCoW on melko yksinkertainen tekniikka. Se on yksi syy, miksi pidän sen käyttämisestä: se on erittäin helppo selittää kaikille huoneessa oleville, ja heidät on helppo saada käyttämään sitä myös valitessaan matalan tai korkean prioriteetin tehtäviä käsiteltävien kohteiden luettelosta.

Kano

Se on toinen yksinkertainen tekniikka, jonka avulla voit tarkastella kyseisiä ominaisuuksia käyttäjien tarpeiden näkökulmasta. Tässä ominaisuudet jaetaan seuraaviin luokkiin:

• Perustarpeet: Käyttäjä ei hyväksy niiden puuttumista. Hotellihuoneessa kyse olisi puhtaiden lakanoiden olemassaolosta sängyllä.
• Suorituskykytarpeet: Ominaisuudet, joiden määrä tai olemassaolo lisää suoraan käyttäjän tyytyväisyyttä. Hotellihuoneessa kyse olisi sisustuksesta tai pesula- ja aamiaispalveluiden saatavuudesta.
• Ilahduttavat tarpeet: Näiden puuttuminen ei vähennä tyytyväisyyttä. Niiden olemassaolo kuitenkin lisää sitä varmasti. Hotellihuoneessa kyse olisi sängylle tehdystä suloisesta pyyhejoutsenesta.

Tässä on kaavio, joka havainnollistaa näiden ominaisuustyyppien suhdetta käyttäjän tyytyväisyyteen Kanon mallissa.

Yhteenvetona voidaan todeta, että tuotteen työlista on tiimin tehtävälista, jonka tuotepäällikkö (tai tuotetiimi) luo ja jota se ylläpitää käyttämällä monenlaisia työlistan hallintatyökaluja ja tekniikoita.

Mikä on sprintin työlista?

Nyt kun tuotteen työlistan luonne on meille selvä, ymmärretään seuraavaksi, mistä sprintin työlistassa on kyse (vihje: siihen ei liity liikuntaa).

Scrum.org määrittelee sprintin työlistan tuotteen työlistan osajoukoksi, jonka Scrum-tiimi on valinnut saatettavaksi valmiiksi tulevan sprintin aikana. Scrum-viitekehyksessä se on yksi keskeisistä Scrum-artefakteista, joiden parissa koko tiimi työskentelee.

Kuten määritelmä osoittaa, sprintin työlistan keskeinen tarkoitus on määritellä selkeästi sen työn laajuus, johon tiimin on keskityttävä sprintin aikana.

Sprintin työlista laaditaan yleensä sprintin suunnittelukokouksessa. Siellä nähdään tyypillisesti seuraavat toimet:

1. Tuotepäällikkö määrittelee sprintin tavoitteen.
2. Tiimi alkaa valita saavutettavissa olevaa luetteloa toimitettavista tuotoksista, jotka voivat auttaa sitä saavuttamaan tämän tavoitteen.
3. Tiimi jakaa tarinat teknisiksi tehtäviksi ja arvioi ne.
4. Tiimi tarkastelee aiempien sprinttien kapasiteettia ja nopeutta varmistaakseen, että sprintin työlista on toteutettavissa.

Toisin kuin tuotteen työlistassa, jonka ainoa omistaja on tuotepäällikkö, sprintin työlistan luomisesta ja ylläpitämisestä vastaa Scrum-tiimi. Koska tiimin jäsenet suorittavat ominaisuuksien rakentamiseen tarvittavat tehtävät, he ovat parhaita päättämään sprintin työlistan koosta ja laajuudesta.

Toisin kuin monet muut Scrum-artefaktit, jotka jotkin tiimit saattavat päättää jättää huomiotta (mikä on täysin hyväksyttävää – Scrum mukautetaan omaan tiimiin eikä päinvastoin), sprintin työlista vaikuttaa olevan se, jota lähes kaikki käyttävät. Tähän on hyviä syitä. Sprintin työlista tarjoaa erityisesti seuraavat hyödyt:

• Laajuuden selkeys: Tiimillä on kunnollinen käsitys työstä, joka sen odotetaan tekevän seuraavan iteraation aikana.
• Keskittymisen paraneminen: Kun työn laajuus on selkeä ja Scrum-master estää kaikkien yritykset lisätä sprinttiin uusia tehtäviä, tiimin ei tarvitse keskittyä mihinkään muuhun kuin sprintin työlistalla oleviin kohtiin.
• Edistymisen parempi seuranta: Koska sprintin työlistalle ei tule uusia kohtia eikä siitä poistu kohtia, on melko helppoa nähdä, kuinka hyvin tiimi etenee kohti sprintin tavoitetta.

Kolmannen kohdan osalta useimmissa Agile-työkaluissa on sisäänrakennetut sprinttiraportointityökalut, jotka seuraavat tiimin edistymistä automaattisesti. Yksi suosituimmista raporteista tähän tarkoitukseen on jäljellä olevan työn kaavio.

Tämä kaavio koostuu kahdesta alaspäin suuntautuvasta viivasta. Harmaa viiva kuvaa tiimin hypoteettista ihanteellista edistymistä. Punainen viiva puolestaan kuvaa todellista edistymistä. Jira (kuvakaappauksessa näkyvä työkalu) mittaa näitä viivoja tiimin jäljellä olevien tarinapisteiden kokonaismäärän perusteella. Kun joku siis sulkee tehtävän, punainen viiva laskee kyseisen tehtävän arvioitujen tarinapisteiden määrää vastaavasti.

Sprintin työlistan luominen ja hallinta

Sprintin tehtävälistan luominen alkaa tuotteen tehtävälistasta, jota ei ole vielä jalostettu. Tuoteomistajat järjestävät säännöllisesti tehtävälistan jalostamiskokouksia (eli grooming-istuntoja), joissa tiimi:

• Esittää PM:lle kysymyksiä suunnittelusta ja vaatimuksista ymmärtääkseen selkeästi, mitä tuotetiimi odottaa heidän rakentavan.
• Haastaa joitakin vaatimusten kohtia, jos niiden toteuttaminen vie paljon aikaa tai aiheuttaa teknisiä vaikeuksia.
• Jakaa kunkin tehtävälistan kohdan omistajuuden sille tiimin jäsenelle, jonka he katsovat parhaiten sopivan kyseiseen tehtävään.
• Arvioi tehtävän tai tarinan koon käyttämällä jotakin suosittua tekniikkaa, kuten Fibonacci-lukuja yhdessä suunnittelupokerin kanssa.

Kun oletetaan, että tiimi on jalostanut riittävästi tehtäviä seuraavaa iteraatiota varten, se pitää sprintin suunnittelukokouksen, jossa se sitoutuu tiettyyn määrään tuotteen tehtävälistan tehtäviä. Kun tiimi on sitoutunut tehtäviin ja aloittaa sprintin, tästä tehtäväryhmästä tulee sprintin tehtävälista.

Ketteryysmenetelmä tarjoaa sprintin tehtävälistan hallintaan useita työkaluja, kuten:

• Päivittäiset tilannepalaverit, joissa jokainen tiimin jäsen esittelee edistymisensä tiimille ja raportoi kaikista etenemistä hidastavista esteistä.
• Edistymistä ja jäljellä olevaa työtä kuvaavat kaaviot, jotka havainnollistavat tiimin kokonaisedistymistä.
• Sprintin lopussa järjestettävät esittelykokoukset, joissa tiimi esittelee työnsä tulokset tuotetiimille ja saa käyttökelpoista palautetta rakentamiensa ominaisuuksien suunnittelusta ja toiminnallisuudesta.

Lopuksi ovat retrospektiivikokoukset. Ne eivät suoraan auta sinua hallitsemaan sprintin tehtävälistaa, mutta niiden avulla voit keskustella prosesseista, jotka parantavat sen hallinnan laatua ja tehokkuutta.

Tuotteen tehtävälistan ja sprintin tehtävälistan keskeiset erot

Jotta ymmärtäisit paremmin näiden näennäisesti samankaltaisten käsitteiden erot, esitän ensin rinnakkaisen katsauksen niiden eroihin ja selitän sen jälkeen jokaisen kohdan tarkemmin.

Vaikka yleiskatsaus itsessään voi helposti selittää, miten ne eroavat toisistaan, sinulla saattaa silti olla kysymyksiä tietyistä näkökohdista. Käyn siis ne läpi yksi kerrallaan.

Aikaväli: Tuotteen tehtävälistat edustavat keskipitkän ja pitkän aikavälin suunnitelmaasi, sillä ne heijastavat tuotteesi tiekarttaa ja visiota. Siksi niiden suunnitteluhorisontti voi vaihdella useista sprinteistä pariin vuoteen.

Sprintin tehtävälistoilla puolestaan on hyvin lyhyt aikaväli, sillä ne sisältävät kohteet, jotka tiimisi aikoo toimittaa seuraavassa sprintissä (joka kestää yleensä 1–4 viikkoa).

Omistajuus: Kuten jo mainitsimme, tuotteen tehtävälistasta viime kädessä vastuussa oleva henkilö on joku tuotetiimistä (yleensä kyseiseen tiimiin nimetty tuoteomistaja). Scrum-tiimi voi osallistua tehtävälistan laatimiseen, mutta se voi tehdä sen vain PM:n kautta.

Sprintin tehtävälistan kohdalla tilanne on erilainen. Ainoa tapa, jolla PM voi vaikuttaa siihen, on sprintin tavoitteen asettaminen. Sen lisäksi scrum-tiimillä on valta luoda ja hallita sitä.

Yksityiskohtien taso: Koska tuotteen tehtävälistan kohteet voivat edustaa useiden vuosineljännesten tai jopa vuosien aikana tehtävää työtä, ei ole realistista, että PM kuvaisi jokaisen kohteen yksityiskohtaisesti. Itse asiassa en suosittele sitä lainkaan, sillä on aina mahdollista, että päädyt poistamaan siitä monia ominaisuuksia, jolloin niiden yksityiskohtainen kuvaaminen olisi ollut ajanhukkaa.

Yleensä tärkeimmillä kohteilla on paljon yksityiskohtia, kun taas kaikesta muusta on vain karkea kuvaus.

Kun tarinat siirretään sprintin tehtävälistalle, niiden on kuitenkin sisällettävä kaikki tarvittavat yksityiskohdat. Muuten scrum-tiimi kieltäytyy toteuttamasta tarinoita, jos sillä ei ole selkeää käsitystä siitä, mitä siltä odotetaan.

Tarkoitus: Tuotteen tehtävälista toimii ”välikätenä” epämääräisten strategisten suunnitelmien ja erittäin täsmällisten teknisten toteutustietojen välillä. Se on työkalusi, jonka avulla voit ilmaista strategiset suunnitelmasi tehtävälistan muodossa.

Sprintin tehtävälistat puolestaan ovat luonteeltaan erittäin taktisia, ja niiden tavoitteena on tarjota tiimille selkeä lyhyen aikavälin toimintasuunnitelma ja laajuus.

Joustavuus: Tuotteen tehtävälistat ovat eläviä asiakirjoja, jotka muuttuvat jatkuvasti. Pitkän aikavälin luonteensa vuoksi niiden on muututtava uusien prioriteettien, käyttäjäpalautteen ja markkinaolosuhteiden perusteella, jotta tuotteesi pysyy elinkelpoisena.

Sprintin tehtävälistat ovat tämän täydellinen vastakohta. Vaikka suosittelenkin vahvasti tuotteen tehtävälistan jatkuvaa kehittämistä, sprintin tehtävälistan kohteiden muuttaminen on ehdottomasti kiellettyä, sillä muuten rikot kaikki tiimisi sitoumukset ja suunnitelmat.

Miten tuotteen tehtävälista ja sprintin tehtävälista toimivat yhdessä

Kuten mainittua, sprintin tehtävälista on tuotetehtävälistan täsmällisempi ja selkiytetty osajoukko. Sitä pidetään edelleen osana tehtävälistaa siihen asti, kunnes nykyinen sprinttisi päättyy. Sen jälkeen valmiit käyttäjätarinat poistuvat tehtävälistalta ja keskeneräiset palaavat sen alkuun prioriteettilistalle.

Kun tarkastellaan ominaisuuksien kulkua näiden kahden tehtävälistan välillä, et ehkä ainoastaan täydennä sprintin tehtävälistaa tuotetehtävälistan kohteilla, vaan saatat tehdä myös päinvastoin.

Riippumatta siitä, mihin suuntaan käyttäjätarinat kulkevat, sujuvan siirron varmistaminen on ratkaisevan tärkeää. Tässä asioita, joihin ehdotan sinun kiinnittävän huomiota:

• Kaikkien sprintin tehtävälistalle tulevien kohteiden tulisi sisältää scrum-tiimille avoimia kysymyksiä. Muuten sinusta tulee sprintin etenemisen este. Paras tapa hallita tätä on laatia tiimisi kanssa valmiin työn määritelmän (DoR) lista ja noudattaa sitä.
• Kaikilla sprintin tehtävälistalle tulevilla kohteilla tulisi olla arviot. Muuten tiimisi sitoumukset ja suunnitelmat ovat virheellisiä. Myös työmäärän vähenemiskaavioiden käyttäminen edistymisen seuraamiseen olisi vaikeaa.
• Kun rakennat sprintin tehtävälistaa, kysy aina selkeästi tiimiltä, kokevatko he työmäärän sopivaksi. Ihmisillä on taipumus kuormittaa itseään liikaa, minkä seurauksena sprintit jäävät puolivalmiiksi.
• Kun poistat keskeneräisiä kohteita sprintistä sen päättyessä, käsittele asia aina retrospektiivikokouksessa. Näin voit löytää prosessin tehottomuuden ja poistaa sen.

Kaiken kaikkiaan koko prosessi näyttää tältä.

Sen lisäksi, että annan vinkkejä näiden kahden yhdistämiseen, autan sinua hallitsemaan molempia asianmukaisesti muutaman kokemukseni perusteella laatimani hyvän käytännön avulla.

Tuotetehtävälistan hallinnan hyvät käytännöt

Tuotetehtävälistan omistaminen voi olla joko miellyttävää tai kamalaa sen mukaan, kuinka hyvin hallitset sitä. Näin toimin vuosien kokemukseni perusteella:

• Jatkuva siivoaminen: Kerää rohkeutta poistaa tehtävälistalta kohteet, jotka tuskin koskaan päätyvät kehitykseen.
• Sidosryhmäviestintä: Järjestä säännöllisiä korkean tason priorisointikokouksia sidosryhmiesi kanssa. Näin heidän mielessään oleva suunnitelma vastaa tehtävälistalla olevaa sisältöä.
• Erillinen lista kohteille, joiden tulevaisuus on epävarma: Joskus sinä tai sidosryhmäsi keksitte ideoita, jotka saatetaan toteuttaa tai sitten ei. Jotta ne eivät sotkisi tehtävälistaasi, säilytä niitä jossain erillisellä listalla. Lisää ne tehtävälistalle vasta, kun tiedät, että aiot toteuttaa ne.

Lopuksi suosittelen hyödyntämään lukuisia saatavilla olevia työkaluja ja malleja tuotetehtävälistaa varten luomisprosessin nopeuttamiseksi. Tässä on ClickUpin kokoelma, jota voit käyttää.

Jos haluat lukea lisää tuotteen hyviin käytäntöihin liittyen, suosittelen tutustumaan aihetta käsittelevään oppaaseemme.

Sprintin tehtävälistan hallinnan hyvät käytännöt

Sprintin tehtävälista edustaa tietyn inkrementin laajuutta. Siksi sen asianmukaiseen hallintaan liittyvät vinkit ovat hieman erilaisia:

• Vältä liiallista suunnittelua: Ihmiset ovat huonoja arvioimaan kykyjään. Jos tiimisi sitoutuu huomattavasti suurempaan sprintin tehtävälistaan kuin aiemmin, sinun kannattaa auttaa heitä poistamaan siitä muutama kohde.
• Käsittele esteet päivittäin: En ole urani aikana nähnyt yhtäkään sujuvaa sprinttiä, vaikka niitä on ollut satoja. Esteitä ilmenee aina. Jos et käsittele niitä välittömästi, sprintin valmistumisen todennäköisyys romahtaa. Kiinnitä siis tarkkaa huomiota siihen, mitä tiimisi raportoi päivittäisissä tilannepalavereissa.
• Käytä erikoistuneita työkaluja: Internet on täynnä ohjelmistoja, jotka on suunniteltu parantamaan ketterien prosessiesi tehokkuutta ja vaikuttavuutta. Hyödynnä niitä.

Viimeiseen kohtaan liittyen tässä on muutama työkalu, joissa on kaikki välttämättömät ominaisuudet ja joita voit harkita käyttäväsi.

Atlassian Jira: Monipuolinen ketterän kehityksen työkalu monimutkaisiin työnkulkuihin ja suurille tiimeille.

Trello: Kevyt tehtävienhallintatyökalu, jossa on ketterän kehityksen lisäosia (Kanban ja Scrum) ja joka sopii parhaiten pienille startup-tiimeille.

Monday.com: Se sijoittuu Jiran ja Trellon väliin. Se on monipuolinen, mutta tukee helposti kevyitä prosesseja ja pieniä tiimejä.

Lisätietoja varten tutustu parhaiden tuotteenhallintatyökalujen luetteloomme.

Yleiset sudenkuopat ja haasteet backlogien hallinnassa

Olen menettänyt laskuissa olevien surkeiden epäonnistumisten määrän, joita olen urani aikana kokenut hallitessani backlogejani. Vaikka virheiden tekeminen on väistämätöntä (sillä tavalla oppii), haluan silti tuoda esiin muutaman merkittävän virheen siinä toivossa, että vältät ne (toisin kuin minä).

Kaikkitietävä esittäminen: Tämä pitää erityisesti paikkansa silloin, kun olet juniori (terveisiä Dunning–Kruger-efektille). Luet pari artikkelia backlogien hallinnasta ja kuvittelet osaavasi tehdä sen paremmin kuin kukaan muu. Tämä johtaa lähes aina suureen mokaan. Jos siis ympärilläsi on kokeneempia tuotejohtajia, älä epäröi pyytää heiltä apua. Vaihtoehtoisesti voit tutustua myös esimerkkeihin hyvin toteutetuista tuotebacklogeista.

Oppimisen lopettaminen: Ketterän kehityksen maailma kehittyy nopeasti. Jos lopetat uusien käytäntöjen ja työkalujen opiskelun, päädyt kohtaamaan ongelmia, joihin on jo olemassa uusia ratkaisuja. Ilmoittaudu siis ketterää kehitystä käsitteleville kursseille tai webinaareihin ja tilaa uutiskirjeemme saadaksesi runsaasti tuotejohtamisen materiaaleja ja oppaita.

Ajatteleminen, etteivät tuotejohtajat kuulu ketterään tiimiin: Jos ajattelet, ettei tuotejohtajilla ole mitään tekemistä sprintin sisältämien työtehtävien kanssa, epäonnistut todennäköisesti useimmissa sprinteissäsi. Tarinoiden toteutuksen aikana herää aina tuotteeseen liittyviä kysymyksiä ja tarkennuksia. Mitä nopeammin ratkaiset ne, sitä laadukkaamman lopputuloksen saat sprinttikatselmuksessa.

Kaikki on prioriteetti ja määräaika oli eilen: Tämä tunnetaan myös ”toimitusjohtajan tautina”, ja se on merkki siitä, että backlogistasi puuttuu priorisointi. Helppo tapa lieventää tilannetta on rohkaistua ja sanoa toimitusjohtajallesi: ”Ei, meillä ei ole kapasiteettia. Kerro minulle, kumpi on tärkeämpi.” Usko pois, useimmat toimitusjohtajat kuuntelevat sinua ja antavat selkeän prioriteetin.