15 tapaa epäonnistua kehitysjonon hallinnassa

Ketterässä kehittämisessä korostuu tehokas kommunikointi ja jatkuvan palautteen avulla tapahtuva oppiminen. Kehitysjonot ovat työkaluja, joiden avulla kehittyvän tuotteen ominaisuuksista käytävää keskustelua hallitaan. Ne ovat muodoltaan yksinkertaisia, mutta sisällöltään vaativia. Ohessa muutama kehitysjonon haaste

1. Liian yksityiskohtainen

Kirjoittamalla perinteisen vaatimusmäärittelyn kaltaisia yksityiskohtaisia kehitysjonoja tuoteomistaja tuhlaa aikaansa ja vie tilan kehitystiimin luovuudelta. Muodoltaan kehitysjonossa olevat asiat ovat verrattavissa perinteisissä projektisuunnitelmissa esitettyihin tuotteen osituksiin. Ne ovat tarkoituksellisesti epätäydellisiä.

Ohjelmistokehittäjä todennäköisesti tietää esimerkiksi, millainen ohjelmalogiikka tarvitaan käyttöliittymässä olevien paluu, OK, lisää, muuta ja poista -painikkeiden toteuttamiseen. Tällöin kehitysjonoon ei tarvita erillisiä käyttäjätarinoita näitä kuvaamaan.

2. Liian iso, ennakoitu liikaa

Useita satoja tai jopa tuhansia kohtia sisältävä kehitysjono ennustaa kehitystiimin työt vuosiksi eteenpäin. On ennenaikaista sisällyttää kehitysjonoon asioita, joiden tekeminen ei ole ajankohtaista. Ei ole edes varmaa tullaanko niitä koskaan tekemään.

3. Liiketoiminnan hyöty, mittarit puuttuvat

Kehitysjonon priorisoinnin kannalta on tärkeää ymmärtää, miksi tuotteessa on juuri nämä ominaisuudet. Kustannus-hyöty-laskelmiin pitää olla mahdollisuus ainakin karkealla tasolla. Esimerkiksi käyttäjätarina:  Markkinoinnin edustajana haluan verkkosivustomme käyttävän evästeitä, jotta voimme hyvin kohdistaa myynti- ja markkinointitoimenpiteemme asiakkaisiimme. Tästä voimme jatkaa keskustelua siitä, onko evästeiden käyttö hyvää liiketoimintaa.

4. Käyttäjätarinan ”miksi” on väärin

Esimerkiksi käyttäjätarina: ”Asiakkaana haluan käyttää digipalvelu X.ää, jotta voin säästää luontoa” kuvaa tarvetta todennäköisesti heikommin kuin ”Yhtiön omistajan haluan asiakkaidemme käyttävän digipalvelu X:ää, jotta voimme säästää kustannuksissamme 10%.  Mittareiden lisääminen paljastaa usein olemmeko tekemässä niitä asioita, joita tuotteen onnistumiselta todellisuudessa vaaditaan.

5. Konkretia puuttuu, liian abstrakti

Pelkkä liiketoiminnan tarve riittää harvoin. Kehitystiimi haluaa tietää, mitä heidän pitää tuottaa. Mitä kehitystiimin pitäisi tehdä esimerkiksi käyttäjätarinan  ”Yhtiön omistajana haluan strategian jotta omistaja-arvon kasvu tulevina vuosina turvataan” toteuttamiseksi? 

6. Koko sivun käyttäjätarina

Käyttäjätarinamuoto ei sovellu kaikkiin tilanteisiin. Sen käyttö ei ole pakollista. Esimerkiksi monimutkaista ohjelmistologiikkaa tai visuaalista ilmettä on vaikea kuvata yhdellä virkkeellä. Kehitysjonoa voi täydentää erilaisilla kaavioilla, luonnoksilla ja laskentasäännöillä.

7. Arkkitehtuuri puuttuu

Kehitysjonon rakenne kuvaa meneillään olevan työn lisäksi myös tuotteen arkkitehtuuria. Hyvässä arkkitehtuurissa ja kehitysjonossa rakenneosat (etenkin teemat ja epicit) ovat itsenäisesti rakennettavissa, julkaistavissa ja korvattavissa. Tikettilistasta syntyy helposti spagettikoodia.

8. Ei synny inkrementtejä

Perinteisessä vaatimusmäärittelyssä kuvataan usein suuri joukko komponentteja, jotka integroidaan vasta lopussa yhteen. Ketterän toimintatavan inkrementaalinen ja iteratiivinen malli jossa meillä on koko ajan toimiva ja kehittyvä tuote vaatii tätä tukevaa kehitysjonoa. Esimerkiksi, koska käyttöliittymää ja taustajärjestelmää ei rakenneta erillään toisistaan, niitä ei eroteta myöskään kehitysjonossa omiksi kokonaisuuksikseen.

9. Ei keskustelua tiimin ja käyttäjien kanssa

Koska kehitysjono on tarkoituksellisesti epätäydellinen tulee tuoteomistajan, käyttäjien ja kehittäjien aktiivisesti keskustella keskenään. Ymmärrys tuotteesta ei välity dokumentteja ja sähköposteja lähettämällä vaan yksilöiden välisessä vuorovaikutuksessa.

10. Ei palautetta: POC, alfa, beta, MVP

Kehitysjonoa kirjoitettaessa pitää huomioida se, että tuote kehittyy pala kerrallaan. Tuote annetaan käyttäjien ja asiakkaiden arvioitavaksi mahdollisimman varhaisessa vaiheessa. On parempi epäonnistua proof-of-concept:in kanssa kuin kalliin tuotekehitysputken lopuksi. Kehitysjono arvioi julkaistaanko piirre POC:ssa, alfa-versiossa, betassa vai myöhemmin.

11. Ei muutoksia, ei katselmuksia

Kehitysjono kuvaa kullakin hetkellä rakenteilla olevan osan tuotteesta. Se poikkeaa projektisuunnitelmasta siinä, että sitä ei jäädytetä projektin alkaessa. Sen sijaan tuotetta pyritään tarkoituksellisesti parantamaan asiakas- ja käyttäjäpalautteen avulla. Katselmus on tapahtuma, jossa Scrum Tiimi keskustelee sidosryhmien kanssa tuotteen tulevaisuudesta.

12. Yleismääritykset valmiin määritelmään

Yleismääritykset kuten ei-toiminnalliset vaatimukset, tietoturvapolitiikka ja käyttöliittymästandardit kuvataan valmiin määritelmässä. Tällöin niitä ei toisteta tarpeettomasti kehitysjonossa.

13. Työn ositus tiimeille ei kommunikoidu

Kehitysorganisaation, tuotteen ja kehitysjonon rakenteet vastaavat yleensä toisiaan, jotta riippuvuudet voidaan hallita kunkin tiimin sisällä. Vahva ennakkosuunnittelu tai isot tiimien väliset kokoukset eivät ole osoittautuneet tarpeeksi nopeaksi ja vuorovaikutteiseksi tavaksi kommunikoida.

14. Alustaspesifiset tiimit

Tuoteomistajan on vaikea optimoida kehitysorganisaation työn arvoa, jos tämä koostuu osaamissaarekkeista. Kehitysjonossa alustat kuten Android, IOS ja Windows otetaan huomioon vasta alatasolla, joka kuuluu yhdelle tiimille.

15. Kaksinkertainen työ, puuttuvia osia

Kaikille avoin kehitysjono levittää kokonaiskuvaa tuotteesta niin, että kukin piirre rakennetaan tasan yhden kerran. Komponenttien uudelleenkäytön suhteen ketterä maailma on opportunisti.

Perinteet ja töiden organisointi ovat juurisyitä ylläoleviin. Seuraukset avautuvat kun huomioi ymmärryksen kehittymisen ja tarpeiden muuttumisen kehitystyön edetessä.

Tieturin ket­te­ryys­kou­lu­tuk­sia

• Kehitysjonojen (Backlog) hallinta -koulutus antaa käytännönläheiset opit haasteiden voittamiseen.
• Product owner I (PO I)
• SAFe Product Owner/Product Manager with POPM Certification
• Scrum Master I (SM I)
• Scrum perusteet
• Ketterä projekti – agile projektijohtaminen

Meiltä löydät lähes 30 koulutusta ketteryyteen, katso kaikki ketteryyskoulutukset.

Ketteryys Product Owner Agile Scrum