Oletko koskaan katsonut työlistaasi ja halunnut poistaa siitä kaiken ja aloittaa alusta? Minulla on ollut sama tunne useammin kuin kerran, sillä tuotebacklogien rakentaminen ja ylläpito ei ole helppo tehtävä. Haluan kuitenkin näyttää, miten työlistat tehdään oikein, ja innostaa sinua siistimään omasi, joten jaan kanssasi neljä erinomaista esimerkkiä tuotebacklogeista.
Mikä on tuotebacklog Agilessa ja Scrumissa?
Tuotebacklog on elävä asiakirja, joka sisältää kaikki kohteet, joiden parissa tuotetiimi, scrum master ja tekninen tiimi suunnittelevat työskentelevänsä tuotteen rakentamiseksi.
Se sisältää kaiken, mitä tuotteen rakentamiseen ja ylläpitoon tarvitaan, kuten uudet ominaisuudet, teknisen velan tehtävät, viimeisimmästä retrospektiivistä saadut teknisten prosessien parannukset, laadunvarmistuksen automaatiotehtävät ja paljon muuta.
Tuotebacklogin keskeinen ominaisuus on se, että kyseessä on priorisoitu luettelo, jossa ylimpänä olevilla kohteilla on korkein prioriteetti ja jotka tiimin tulisi ottaa työn alle ensin sprinttejä suunnitellessaan (tai kun heidän kanban-taulullaan on ylimääräistä tilaa).
Tuotebacklog vs. sprinttibacklog vs. tuotteen tiekartta: mikä niiden ero on?
Agile-projektinhallinnassa ja erityisesti scrum-menetelmässä tuotebacklog ei ole ainoa kohteiden luettelo, jonka tuotteen omistaja laatii kehitystiimille. Lisäksi on sprinttibacklog ja tuotteen tiekartta. Mutta mikä niiden ero on? Selvitetään se.
Sprinttibacklog: Tämä on suuremman työlistan osajoukko, joka sisältää vain ne kohteet, jotka scrum-tiimi on ottanut mukaan seuraavaan sprinttiin tai muunlaiseen iteraatioon sprintin suunnittelukokouksen tuloksena. Täällä olevat kohteet ovat yleensä hyvin viimeisteltyjä ja sisältävät tarinapisteitä.
Tuotteen tiekartta: Tämä on korkean tason kokonaiskuva-asiakirja, joka esittää tuotteen tärkeimmät ominaisuudet ja virstanpylväät. Toisin kuin luonteeltaan taktisemmassa työlistassa, joka sisältää ominaisuuksien kuvauksia, tuotteen tiekartta on strateginen ja sen tarkoituksena on näyttää tiimin jäsenille ja sidosryhmille, mihin suuntaan tuote on menossa ja mitkä ovat tärkeimmät painopistealueet.
Nyt kun sinut ja keskeiset käsitteet on esitelty asianmukaisesti, siirryn suoraan selittämään, miten tuotebacklogia hallitaan (ja miten sitä, hmm, ei pidä hallita).
Näin sitä EI pidä tehdä: tässä on kauhea esimerkki tuotebacklogista
Tuotebacklogien luomiseen ja hallintaan liittyvien vastamallien ymmärtäminen on todennäköisesti yhtä tärkeää kuin parhaiden käytäntöjen oppiminen. Syynä on se, että jos et tiedä jonkin asian olevan vastamalli, saatat päätyä sisällyttämään sen työlistaasi ja ajattelemaan, että se on normaalia ja tavallista.
Tarkastellaan alla olevaa esimerkkiä nähdäksemme joitakin käytäntöjä, jotka voivat heikentää työlistasi laatua merkittävästi.
Palataanpa esimerkkiin. Käytä aikaa sen tarkkaan tutkimiseen.
Näyttää kamalalta, eikö totta? Itse asiassa useimmat meistä kokevat tätä työlistaa katsoessaan kaksi tunnetta:
- Inhoa tämän työlistan kohteiden sekavuuden vuoksi.
- Syyllisyyttä, sillä myönnetään se: meillä kaikilla on ollut tämän näköinen työlista (minullakin, tietenkin).
Puretaan nyt tämän työlistan ongelmat.
Have an account? Log In
Tuotebacklogin kohteiden ylikuormitus
Huomasitko, että tässä työlistassa oli 665 tehtävää? Suurimmassa työlistassa, jota minulla oli “ilo” hallita, oli yli 2 500 kohdetta.
Ylikuormitetun työlistan ongelma on se, ettet lähes varmasti pysty muistamaan, mitä kukin sen kohde tarkoittaa ja miksi olet sijoittanut sen tiettyyn kohtaan tai tietylle prioriteettitasolle työlistallasi. Koska et tiedä, mitä nämä tehtävät koskevat, et todennäköisesti tuo niitä seuraavaan tarkennukseesi, keskustele niiden yksityiskohdista tai sisällytä niitä tulevaan sprinttiin.
Näin päädyt valtavaan, hallitsemattomaan sotkuun, joka kasautuu jatkuvasti.
Jälkilistan virheellinen priorisointi
Toinen ongelma, jonka olet saattanut huomata tässä jälkilistassa, on se, että sen yläosaan – korkeimman prioriteetin kohteiden yläpuolelle – on sijoitettu työtehtäviä, joiden prioriteetti on ”Alhaisin” ja ”Matala”.
Tämä on tyypillinen tilanne silloin, kun jälkilistaasi ei ole priorisoitu asianmukaisesti. Tähän voi olla monia syitä, mutta todennäköisin on se, että olet vähentänyt ”Korkean” prioriteetin kohteen tärkeyttä siirtämällä sitä alemmaksi jälkilistalla, mutta unohtanut muuttaa prioriteettikenttää.
Author's Tip
Riippumatta siitä, miksi prioriteetit päätyivät sekaisin, tämä voi vahingoittaa tuotettasi ja tiimiäsi. Älä unohda, että jälkilistan pitäisi toimia kaikille ”ainoana totuuden lähteenä”. Jos siis jonkin kohteen prioriteetti on asetettu väärin (esimerkiksi sille on annettu korkeampi prioriteetti kuin pitäisi), tiimisi saattaa alkaa työskennellä sen parissa ja jättää huomiotta muut tärkeämmät tehtävät.
Yksityiskohtien puute
Huomasitko kohdan, jossa sanotaan ”Haluan saumattoman integraation kaikkien sosiaalisen median alustojen kanssa”? Hah. Se ei ole edes kunnollinen käyttäjätarina, kun otetaan huomioon sen valtava laajuus. Aihepiiri on niin laaja, että käytännössä sen käsittelyyn pitäisi olla useita laajoja kokonaisuuksia, joista jokainen sisältäisi yhden sosiaalisen median alustan käyttäjätarinat.
Valtavan laajuuden lisäksi tämän kohteen – ja itse asiassa jokaisen tämän jälkilistan kohteen – ongelmana on sen epämääräisyys. Käyttäjätarinoiden pitäisi kuvata tiettyä käyttäjäkokemusta ja toimintoa.
Kuvittele vieväsi tämän tarinan jälkilistan tarkennuskokoukseen yhdessä ketterän tiimisi kanssa. Joutuisit vastaamaan valtavaan määrään kysymyksiä lähes kaikista tarinan osa-alueista.
”Mitä tarkoitat saumattomalla?” ”Miltä integraatio näyttää?” ”Minkä sosiaalisen median alustojen kanssa integroidumme?!”
”Haluan kaiken, ja heti”
Toinen hälytysmerkki, jonka olet saattanut huomata jälkilistassa, oli se, että 70 prosentilla sen kohteista oli ”Korkein” prioriteetti. Tämä on toinen tyypillinen tilanne silloin, kun luotat prioriteetteja määrittäessäsi pelkästään sidosryhmiesi mielipiteisiin – jokainen sidosryhmä pitää omia kohteitaan tärkeinä – etkä yritä arvioida niitä objektiivisesti ja verrata niiden tärkeyttä listan muiden kohteiden tärkeyteen.
Nyt kun olemme määritelleet, miltä huono jälkilista näyttää, korjataan se ja tarkastellaan neljää hyvää jälkilistaesimerkkiä... jotta voit tehdä jälkilistastasi jälleen loistavan.
3 esimerkkiä hyvin toteutetuista jälkilistoista
Ennen kuin esittelen nämä esimerkit, haluan huomauttaa, ettei loistavan jälkilistan luomiseen ole yhtä ainoaa oikeaa tapaa. Jälkilistasi ulkoasu riippuu tuotteesi luonteesta, sen kypsyysasteesta, yrityksesi tai tiimisi koosta ja niin edelleen.
Hyvä jälkilista on käytännössä sellainen, joka pystyy selkeyttämään tuotteesi nykyistä ja tulevaa sisältöä sekä luomaan siitä yhteisen näkemyksen kaikille.
On kuitenkin olemassa yleisiä tapoja hallita jälkilistaa, joiden ansiosta se on järjestelmällisempi ja kaikkien on helpompi käyttää sitä. Jokainen alla oleva esimerkki edustaa tällaista parasta käytäntöä.
Esimerkki nro 1: osioihin jaettu jälkilista
Jälkilistalla ei lähes koskaan ole hyvä olla satoja tai tuhansia kohteita. Noin sadan kohteen jälkilista on kuitenkin yleensä melko yleinen ja normaali. Mutta vaikka jälkilistallasi olisi sata kohdetta, on helppo unohtaa, mitä kukin niistä koskee, tai jättää ne pitkäksi aikaa käsittelemättä lisäämättä niitä tuleviin sprintteihin.
Jotta jälkilistasi olisi järjestelmällisempi, voit harkita sen jakamista osioihin.
Jotkut tuotejohtajat käyttävät osioita ryhmitelläkseen kohteita painopistealueiden tai virstanpylväiden perusteella. Itse käytän tähän mieluummin tehtävien versio-, eepos- ja komponenttitunnisteita ja jaan jälkilistan osioihin tulevien sprinttien sisällön perusteella.
Tämä on erinomainen tapa varata sprintti (tai ainakin suuntaa-antava toteutusaikataulu) suurimmalle osalle jälkilistan kohteista ja varmistaa, ettei yksikään tehtävä jää laiminlyödyksi.
Toinen yleinen tapa hallita työjonoa osioiden avulla on ryhmitellä kohteet niiden tarkennustilan tai työnkulun perusteella (tässä tekoäly työjonon hallinnassa voi auttaa). Tässä tapauksessa virtaviiv estat prosessiasi seuraavilla osioilla:
- Nykyinen sprintti
- Valmis suunniteltavaksi
- Valmis tarkennettavaksi
- Työjono
Tässä tapauksessa työskentelet lisäämällä tuotevaatimuksia ja kuvauksia työjonossa oleville kohteille. Kun vaatimukset ovat valmiit, siirrät ne ”Valmis tarkennettavaksi” -osioon, joka toimii seuraavan tarkennuskokouksesi käsittelyalueena.
Kun kohde on tarkennettu, siirrät sen ”Valmis suunniteltavaksi” -osioon osoittaen, että se on valmis ja tiimi voi sisällyttää sen tulevaan sprinttiinsä.
Esimerkki 2: Työjono, jossa komponentit, epicit ja versiot on sijoitettu asianmukaisesti
Työjonon jakaminen osiin tekee siitä varmasti selkeämmän ja järjestelmällisemmän. Pelkän jaottelun käytön rajoitus on kuitenkin se, että voit järjestää työjonosi vain yhden kriteerin perusteella (esimerkiksi sprinttien, tarkennustilan ja niin edelleen).
Onneksi nykyaikaiset tuotetyöjonotyökalut tarjoavat laajemman valikoiman vaihtoehtoja tuotekehityksen tehtävälistan järjestämiseen useiden kriteerien perusteella. Katso vaikka tätä ihastuttavan selkeää työjonoa.
Eikö se näytäkin hyvin järjestetyltä ja miellyttävältä katsella? Tässä tapauksessa hyödynsimme seuraavia ominaisuuksia tehdäksemme työjonosta helpommin hallittavan:
Komponentit
Tämä kenttä tai ominaisuus kuvaa perinteisesti tuotteen aluetta, johon haluat lisätä kyseisen toiminnallisuuden. Yllä olevassa esimerkissä komponentit ovat erillisiä tuotteita, joista Grammarly koostuu.
Toinen yleinen tapa käyttää komponentteja on järjestää käyttäjätarinat ja tehtävät toiminnallisuuden luomiseen tarvittavan teknologian perusteella. Verkkosovelluksissa voit esimerkiksi käyttää käyttöliittymä- ja taustajärjestelmäkomponentteja apuna työn ja riippuvuuksien järjestämisessä niiden insinöörien välillä, jotka ovat erikoistuneet joko asiakas- tai palvelinpuolen kehitykseen.
Versiot ja julkaisut
Tämän ominaisuuden avulla dokumentoit kaikki toiminnallisuudet ja virheenkorjaukset, jotka scrum-tiimisi julkaisee tuotteesi tietyn version yhteydessä. Versioiden seuranta työjonossa tuo mukanaan kaksi erittäin arvokasta hyötyä.
- Se auttaa sinua suunnittelemaan sprinttisi ja julkaisusi. Jos esimerkiksi suunnittelet julkaisua kahden viikon kuluttua, sinun tulee varmistaa suunnittelukokouksessa, että sprinttiin sisällytetään kaikki kyseiseen julkaisuversioon tarkoitetut tehtävät.
- Voit dokumentoida kaiken, mitä tiimisi on sisällyttänyt tiettyyn versioon ja jäljittää ongelmat helposti, kun tuotannossa tapahtuu jotain.
Kuvitellaan esimerkiksi, että ihmiset alkavat saada CAPTCHA-virheitä rekisteröitymisprosessissasi uusimmassa 1.3.2-versiossa. Kun etsit tehtävää, jonka perusteella tiimisi teki muutoksia CAPTCHA-määrityksiin, huomaat, että se kuuluu versioon 1.3.1. Tämä tarkoittaa, että sinun on joko palautettava versioon 1.3.0 tai tehtävä pikakorjaus.
Epicit
En usko, että minun tarvitsee selittää, mikä epic on ja mitä hyötyä sen käyttämisestä on. Jos kuitenkin haluat perehtyä epicien parhaisiin käytäntöihin ja yksityiskohtiin, voit tutustua sitä käsittelevään epic-oppaaseemme (sanaleikki tarkoitettu).
More Articles
Esimerkki 3: Työjono, jossa kussakin osiossa on oikea määrä yksityiskohtia
Tämä on hyvä käytäntö, johon olet saattanut törmätä monissa ketterää toimintaa ja tuotehallintaa käsittelevissä kirjoissa ja teoreettisissa teksteissä. Vaikka suhtaudumme teoreettisiin käsitteisiin yleensä sitä epäilevämmmin, mitä enemmän kokemusta kartutamme, tämä käytäntö on todellisuudessa hyödyllinen.
Ajatuksena siis on, että ylimpänä olevissa kohteissa tulisi olla paljon yksityiskohtia, ja ihannetapauksessa ne tulisi olla käsitelty tuotetyöjonon tarkennuksessa ainakin kerran. Työjonon alaosassa olevissa kohteissa sen sijaan tulisi olla vain vähän yksityiskohtia, sillä on hyvin mahdollista, että opit jotain uutta tuotteestasi ja loppukäyttäjistäsi ja tämä kohde vanhenee.
Tämä tarkoittaa, että jos työjonosi ylimpänä oleva kohde näyttää tältä (tai on tätäkin yksityiskohtaisempi):
Työjonosi lopussa olevissa tarinoissa pitäisi olla paljon vähemmän yksityiskohtia ja niiden pitäisi näyttää tältä:
Kaikissa työjonosi keskellä olevissa tarinoissa ja aloitteissa on keskitasoinen määrä yksityiskohtia.
Esimerkki 4: Tiedän, että se on ilmeistä, mutta… siisti työjono
Tiedän, ettei työjonosi pitäminen siistinä ole helppoa. Olen ollut samassa tilanteessa monta kertaa ja tiedän, että se tuntuu työläältä. Kaiken työjonossa olevan tarkistamatta jättäminen ja vanhentuneiden kohteiden poistaminen ovat kuitenkin merkittäviä työjonosi laatuun vaikuttavia tekijöitä.
Asioiden poistaminen työjonosta ei ole aina helppoa. Siellä on todella hienoja ominaisuuksia, jotka toivot toteuttavasi jonain päivänä (pääasiassa mukavia lisäominaisuuksia), etkä toisinaan oikeastaan halua luopua niistä. Mutta jossain vaiheessa on myönnettävä, että tiedät, ettet tule koskaan toteuttamaan sitä. Ja vaikka toteuttaisitkin, se tarkoittaisi, että korkean prioriteetin ominaisuudet ovat loppuneet, mikä ei yleensä ole hyvä merkki.
Joskus sidosryhmäsi ovat luoneet nämä vanhentuneet kohteet työjonoosi. Ennen niiden poistamista yrität kysyä heiltä, onko heidän pyyntönsä edelleen voimassa, ja vastaus on lähes aina kyllä. Jos pyyntö on kuitenkin yli 6 kuukautta vanha ja he ovat jo unohtaneet sen, vakuuta heille, ettei kyse ole kiireellisestä asiasta (jos olisi, he olisivat palanneet siihen useita kertoja) ja poista se.
Hyvä työjono on sellainen, joka toimii sinulle parhaiten
Jos otit kaikki tässä esitetyt parhaat käytännöt huomioon, olisiko sinulla hyvä työjono? Ne auttavat, mutta eivät takaa erinomaisuutta.
Älä unohda, että työjonon tarkoituksena on olla kaikille ainoa totuuden lähde . Näiden parhaiden käytäntöjen lisäksi sinun on siis otettava huomioon tiimisi ja sidosryhmiesi tarpeet ja työskentelytavat sekä rakennettava työjonosi tavalla, joka auttaa heitä pysymään samalla sivulla.
Tämä hyviä työjonoja käsittelevä opas on osa suurempaa kaikkea ketterää työskentelyä käsittelevää sarjaa. Tilaa uutiskirjeemme, niin saat lisää tämän kaltaisia oppaita ja näkemyksiä sähköpostiisi joka toinen viikko!
