Backlogit eli työjonot ja niiden hallinta näyttelee keskeistä roolia ohjelmistokehitystyön ohjauksessa. Tällä arkisella tehtävällä voi olla yllättävänkin iso vaikutus siihen, miten tuoteomistajan ydintehtävä eli kehitysinvestoinnin arvontuoton maksimointi onnistuu.

Tämän kirjoituksen taustalla on ilmeinen kaupallinen motiivi. Järjestämme Profession kanssa yhteistyössä Edistynyt Backlogin hallinta -koulutuksen. Jos kirjoitus siis herättää tunteita, niin hae kirstunvartijalta siunaus ja ilmoittaudu koulutukseen (tai ilmoita lempituoteomistajasi)!

Backlogin hallinta voi pintapuolisesti tarkasteltuna vaikuttaa tosiaan hyvin arkiselta perusaherrukselta ja sitä se onkin. Tiimi ja tuoteomistaja työstävät yhdessä tuotteen kehitysjonoa viikottain:

• Listaamalla kehitysjonoon tarpeita, ominaisuuksia, työtä, jne. asioita joiden valmiiksi tekeminen vie tuotetta (tai projektia) liiketoiminnan haluamaan suuntaan.
• Järjestämällä jonoa siten, että lähitulevaisuudessa eniten arvoa tuottava juttu on jonon kärjessä, toiseksi tärkein sen perässä jne. Kaukaisemmat ja vähemmän tärkeät jutut ovat sitten siellä jossain pohjalla.
• Selkeyttämällä jonossa olevien asioiden sisältöä sen verran, että tiimi pystyy tekemään asioita valmiiksi.
• Pilkkomalla isoja asioita useiksi pieniksi asioiksi, jotta ne olisi mahdollista saada valmiiksi yhden iteraation sisällä.
• Sopimalla yhdessä, mitä seuraavaksi tehdään – tuoteomistajan viime kädessä tehdessä siihen liittyvät päätökset.
• 
  

Vaikka edellä kuvattu kuulostaa yksinkertaiselta, liittyy backlog-työskentelyyn lukuisia ongelmia, mistä voi olla vakavaakin haittaa hankkeen onnistumiselle.

Kyselin LinkedInissä ihmisiltä, mitkä asiat menevät usein metsään backlogien kanssa touhutessa ja toisaalta mitkä asiat auttavat menestyksekkäässä backlog-työskentelyssä. Tiivistän seuraavassa keskusteluun osallistuneiden ihmisten havaintoja (kiitokset kaikille osallistujille!).

Backlogin hallinnan sudenkuopat

Seuraavat ongelmat ovat hyvin tyypillisiä backlog-työskentelylle, mutta monia muitakin on helposti löydettävissä varsinkin, kun alkaa porautumaan listattujen ongelmien juurisyihin.

1. Työtä tehdään backlogin ulkopuolelta. Ei ole näkyvää mistä työ tulee, mitä se on, paljonko sitä on ja mitä odotuksia tai sopimuksia työhön kohdistuu.
2. Backlogin työstämiseen ei ole varattu riittävästi ja säännöllistä aikaa, mikä johtaa moniin muihin ongelmiin.
3. Todelliset prioriteetit eivät näy backlogilla tai eivät ole ajan tasalla, vaikka joillakin henkilöillä saattaa olla jonkinlainen, mutta ei välttämättä yhtenäinen käsitys niistä. Pahimmassa tapauksessa kaikki backlogin tehtävät ovat “prioriteetti 1”, mikä käytännössä tarkoittaa, että tiimi ei ole enää ketterä, koska neuvotteluvara muuttuvien tilanteiden äärellä puuttuu.
4. Backlogi sisältää paljon sekalaista, keskenään hyvin erilaista ja erikokoista työtä, jonka yhteyttä suurempaan kokonaisuuteen (esim. epicit tai muut kehitysteemat) tai tavoitteeseen on vaikea hahmottaa.
5. Backlogi kasvaa niin isoksi, että sen hahmottaminen ja hallinta on vaikeaa. Backlogi sisältää lähitulevaisuuden kannalta epäolennaista työtä (vanhentunutta tai liian kaukana tulevaisuudessa), jota ei kuitenkaan tohdita siivota backlogilta.
6. Käyttäjätarinat herättävät hämmennystä esim. käyttäjäpersoonan ja tavoitteen hyvin kuvaava tarina saattaakin osoittautua liian isoksi, jotta tiimi voisi tehdä sen yhdessä sprintissä. Voi olla yllättävän haastavaa pohtia miten se pilkottaisiin vertikaalisti pienempiin arvoa tuottaviin ja potentiaalisesti julkaistavissa oleviin kakun palasiin ilman, että sorrutaan tekemään horisontaalisen teknisen toteutuksen tehtävälistaa.
7. Työmääräarvioinnista ja tekemisen tahdin ennustamisesta puuttuu vaivan ja hyödyn tasapaino. Aina on tarve hakea vastauksia kysymyksiin kuten koska ollaan valmiita, koska tietty työ backlogilla tulee tehtyä, mitä on valmiina tiettyyn päivään mennessä, mitä saadaan aikaan tietyllä rahalla jne. Toisaalta tiedämme, että työmääräarviointi on usein parhaimmillaankin epäluotettavaa ja arvioinnin hyöty tulee siitä, että ymmärrys tehtävästä työstä kasvaa. Pahimmillaan arviointi tuudittaa meidät valheelliseen turvallisuudentunteeseen ja luo absurdeja odotuksia kehityshankkeen tulevaisuudelle.
8. Tärkeä asiat ja päätökset dokumentoidaan ainoastaan backlogille, jolloin ne katoavat, kun asioita valmistuu tai poistuu backlogilta.
9. Backlogi yksiulotteisena listana ei auta tiimiä kasvattamaan ymmärrystä laajemmasta kokonaisuudesta. Hallintatyökalut usein piilottavat tavoitteet, prioriteetit, riippuvuudet, kenelle tehtävä työ on arvokasta, aikataulut, sopimukset jne. Suuremmissa kuin triviaaleissa hankkeissa kokonaisuuden hahmottamiseen tarvitaan jotain muutakin kuin pelkkä lista tehtäviä.
10. Ihmiset elävät tarinoista ja niiden kerronnasta. Empatia ja tunteet jäävät meille mieleen. Yksiulotteinen lista ei auta meitä kertomaan koko tuotteen tarinaa, vaan harhauttaa meidät kerronnasta tarinoiden kirjoittamiseen (mikä ei alkuunkaan ollut käyttäjätarinoiden idea). Kun tuotteen koko tarinaa ei ymmärretä (ja miksi asioita ollaan tekemässä), on listaa vaikea priorisoida eikä sisällön suhdetta kokonaisuuteen ymmärretä.

Seuraavat ratkaisut auttavat edellä listattuihin ongelmiin ja niiden voidaan ajatella olevan backlog-työskentelyn hyviä käytäntöjä.

Hyviä käytäntöjä backlog-työskentelyyn

Keskustele näistä tiimisi kanssa, kun seuraavan kerran ajatte metsään backlogin kanssa (tai vähän ennen sitä!).

1. Backlog-työskentelylle ja keskustelulle varataan riittävästi ja säännöllistä aikaa. Tuoteomistaja valmistelee asioita sekä työstää niitä yhdessä kehitystiimin kanssa. Onnistunut vuorovaikutus on kaiken ytimessä.
2. Kaikki työ kirjataan matalalla kynnyksellä näkyviin työjonoon ja varmistetaan, että työn kirjaaminen ei henkilöidy kenellekään. Erityisesti isommissa hankkeissa on syytä selkeyttää tiimin rajapinnat, eli sovitaan miten työ kulkee tiimille ja opetetaan ihmiset tähän toimintamalliin.
3. Selkeytetään myös tiimin sisäiset toimintatavat (working agreements) esim. Definition of Ready ja Definition of Done, jotta tiedetään esim. mitä pitää selvittää ja kuvata, jotta työ voidaan aloittaa ja mitä pitää olla tehty, jotta työ voidaan todeta valmiiksi.
4. Selkeytetään miten päätökset kirjataan ja kommunikoidaan. Kehitystyön aikana tehdään paljon päätöksiä liittyen prioriteetteihin, aikatauluihin, scopeen, arkkitehtuuriin, sisältöihin, ominaisuuksiin jne. Mitkä näistä päätöksistä on tarpeen kirjata talteen? Kenelle niistä tulee kommunikoida? Miten päätöksiin voidaan palata myöhemmin?
5. Määritetään isojen päämäärien lisäksi lyhyen aikavälin tavoitteet esim. pohtimalla yhdessä, mitä halutaan nähdä sprintin päätteeksi, julkaisussa, kvartaalin lopuksi jne. Sidotaan tekeminen ja tehtävät näihin tavoitteisiin.
6. Pilkotaan työ siten, että jokainen palanen toteuttaa järjestelmää koko arkkitehtuurin vertikaalisti läpileikaten ja on itsenäisenä julkaistavissa ja siten potentiaalisesti tuottaa arvoa käyttäjilleen. Työn ositus tähtää kokonaisten, mutta ohuiden kakun palasten valmistamiseen eikä kakun horisontaalisten kerrosten tai täytteiden luomiseen.
7. Tuoteomistaja selvittää ja pohtii prioriteettejä, keskustelee niistä tiimin kanssa ja päättää. Tiimi arvio ja priorisoi tekemistään päivittäin kohti seuraavaa tavoitetta. Jos ohituskaistalta tulee kiireellistä tekemistä, muistetaan kysyä mikä jää pois, jos uusi asia tehdään.
8. Opetellaan backlogin hallintatyökalun käyttö kunnolla. Tehdään useita näkymiä eri näkökulmia ja eri asioiden tarkastelua varten. Kehittäjän ja tuoteomistajan lempparinäkymät voivat olla erilaiset, mutta on syytä myös ymmärtää, että ihmiset katsovat työjonoa eri linsseillä.
9. Siivotaan epäolennaiset työt pois aktiiviselta backlogilta, olivat nämä sitten mädäntyneitä, kaukaisen tulevaisuuden roadmappia tai epämääräistä toiveiden tynnyriä. Hallintatyökalun näkymät ja suodattimet auttavat tässä, jotta asioita ei tarvitse varastoida useaan paikkaan.
10. Piirretään backlogin rinnalla ja sen työstämisen sekä kaiken aiheeseen liittyvän vuorovaikutuksen tukena “maailmankarttaa”, joka auttaa hahmottamaan tavoitteet, prioriteetit, riippuvuudet, kenelle tehtävä työ on arvokasta, aikataulut, sopimukset jne. Tämä voi olla esim. mindmap, user journey map, service blueprint tai vaikkapa user story map, joka kaikista tiiviimmin liittyy backlog-työskentelyyn.

Miten parantaa oman kehitystiimin backlogin hallintaa?

Tuntuuko siltä, että tiimilläsi olisi petrattavaa backlogin hallinnassa? Sitten kannattaa ilmoittautua Edistynyt Backlogin hallinta -koulutukseen. Koulutuksessa saat uusia ideoita ja ajattelutapoja backlogien kanssa touhuamiseen. Harjoittelemme mm. käytännössä tuotevision selkeyttämistä Lean UX Canvas -menetelmän avulla ja rakennamme tuotteen koko tarinaa User Story Mapping -menetelmällä.

Menestyksekkään backlog-työskentelyn keskiössä on laadukas vuorovaikutus. Edellä mainitut menetelmät eivät ole hopealuoteja vaan keinoja parantaa tiimin ja muiden asianosaisten vuorovaikutusta ja yhteistyötä. Kirjoittelen näistä aiheista todennäköisesti lisää koulutuksen jälkeen.

Lukutoukille suosittelen lämpimästi seuraavaa ajatusten salaattibuffaa:

• Vertaa miten vuoden 2020 ja 2017 Scrum Guidet eroavat toisistaan backlogien hallinnan osalta ja tsekkaa sen jälkeen miten A Scrum Book syventää näitä ajatuksia.
• The Professional Scrum Product Owner -kirja rakentaa melko kattavan kuvan siitä mitä backlogin omistajan maailmaan sisältyy.
• 50 Quick Ideas To Improve Your User Stories sisältää enemmän kuin viisikymmentä loistavaa ideaa backlog-työskentelyn elävöittämiseksi.
• Yksi noista ideoista on tietysti käyttäjätarinoiden kartoitus eli se maailmankartan luominen. User Story Mapping -kirja kertoo menetelmän käytöstä kaiken tarvittavan.

Olennaisinta on kuitenkin se, että myös backlogin hallinta on sellainen aihe, josta voidaan keskustella – ja myös keskustellaan – tiimin arkisissa usein toistuvissa retrospektiiveissä. Ilman jatkuvaa reflektointia ja käytännön kehitystoimenpiteitä ei ole jatkuvaa parantamista.