3 načina kako prioritizirati svoj Product Backlog

Savjeti 22. velj. 2022

Svatko tko je Product Manager ili Product Owner zna da je izgradnja uspješnog digitalnog proizvoda poput izgradnje kuće, sa samo jednom malom razlikom: kuću u jednom trenutku i završiš.

To može biti tvoja najgora noćna mora. Beskonačni niz zadataka, bugova i user storyja unutar Product Backloga u kombinaciji sa svakodnevnim pitanjima kada će feature biti pušten. Srećom, postoje metode koje će ti pomoći da odrediš prioritet taskova unutar svog Product Backloga. U ovom blog postu pokriti ćemo naše 3 najdraže:

  1. Impact effort matrix
  2. Stack ranking
  3. MoSCoW metoda

O čemu se radi?

Svaki Product Manager ili Product Owner nastoji najprije isporučiti funkcionalnosti koje donose najveću vrijednost customeru. Ironično, ono što obično donosi najveću vrijednost, zahtijeva najviše vremena za istraživanje od strane tima kako bi se smanjili potencijalni rizici povezani s isporukom te funkcionalnosti.

Zato, u početku, isporuka ovakvih funcionalnosti oduzima više vremena jer je naše znanje minimalno. Ali zamisli, što da postoji hitan bug fix ili ono malo poboljšanje proizvoda koje stalno provlačiš kroz svaki sprint ili tehnička nadogradnja koja će omogućiti dev timu brži development u budućnosti? Što ćeš prvo učiniti?

Postoji kompromis koji Product Manager mora napraviti u odnosu kratkoročnog i dugoročnog razmišljanja. Trebaju li zadaci biti brzo pušteni iz backloga, ali uz donošenje manje ili nikakve vrijednosti customeru ili se treba fokusirati na dugoročno i isporučiti najvažniju funkcionalnosti za customera, ali nakon uložene značajne količine vremena.

Reklo bi se da nije tako lako odlučiti. Pa, pogodi što? To nije sve. Ako dilemi dodamo vječno pitanje: treba li tim razviti prave funkcionalnosti ili razviti funkcionalnosti ispravno ili konačno, razviti ih brzo? Tek tada čovjek malo poludi. 😊

Idealan slučaj bi bilo imati sve tri opcije, ali to nisu uvijek karte koje ćeš dobiti. Ponekad ćeš biti u poziciji da razviješ prave funkcionalnosti s pravom tehnologijom ili arhitekturom sustava, ali će ti trebati dosta vremena i propustit ćeš tržišnu priliku za lansiranje ove funkcionalnosti. Konkurent bi mogao biti ispred tebe, a customer gubi ekskluzivnost.

S druge strane, možeš biti u poziciji da vrlo brzo razviješ prave stvari, ali preskakanje koraka dugoročno te može koštati značajnog technical debta, napora za refaktoriranje ili čak značiti promjenu korištene tehnologije. Treća opcija, kada stvari možeš razviti ispravno na prilično brz način, čini se kao sjajna opcija, ali što ako napraviš nešto što customeru nikada nije trebalo niti donosi vrijednost. E onda si tek u problemu.

Gledajući iz daleka, očigledno je da trebaš balansirati između tri opcije, ali što je još važnije trebaš balansirati između Scrum uloga, a evo i zašto. Obično će se Product Manager ili Product Owner zauzeti za stvari koje donose najveću vrijednost customeru, dok će razvojni tim nastojati da stvari budu izgrađene na pravi način, a zatim će tvoji stakeholderi sužavati rokove i požurivati da stvari što prije krenu u development.

Vrijeme je važno jer znači novac, prekretnice i go-live datume, itd. Štoviše, brzim developmentom prije ćeš dobiti povratne informacije o razvijenim funkcionalnostima i brže ćeš učiti. Ovo je prednost koja će se umnožiti sa sprintovima i samim time će skratiti tvoj feedback loop. Ali na kraju, što ako "najglasniji" stakeholder traži jednu funkcionalnost, dok ostali traže drugu? Čini se da smo skloni ušutkati najglasnije ljude u prostoriji tako što ćemo ih prve poslušati, ali evo važne lekcije koju trebaš naučiti iz Stakeholder Managementa: u redu je reći ne.

Iako je ovo samo dio mogućih situacija koje ti se događaju na dnevnoj bazi, to nije kraj svijeta jer, srećom, postoje metode koje su dokazano učinkovite pri određivanju prioriteta taskova unutar Product Backloga. Ovo su naše preporučene tehnike:

#1 Impact effort matrica

Ova tehnika ima 2 glavne stvari:

  1. Razina truda potrebna za izvršavanje taska
  2. Razina poslovnog utjecaja kojeg task ima

Svi taskovi, user stories, bugovi ili sub-taskovi podijeljeni su u 4 kvadranta:

  • Quick wins su taskovi koji imaju najveći utjecaj na poslovanje i generalno, bez puno dodatnog posla. Ovo je kvadrant s najvažnijim funkcionalnostima i tvoj bi se tim prvo trebao usredotočiti na njih.
  • Major Projects su na drugom mjestu. To su oni koji su važni za posao, ali ih nije baš lako napraviti. Oni zahtijevaju puno truda i vjerojatno dulje vrijeme za isporuku. Zato bi tim trebao biti vrlo oprezan pri odlučivanju koji zadaci spadaju u ovu kategoriju jer treba odabrati samo one koji su vrijedni uloženog truda.
  • Fill in Jobs nisu toliko važni i spadaju u kategoriju kasnijeg obavljanja. Neki od ovih poslova su neizbježni, ali to su stvari koje možete raditi kada nemate ništa na gornjim kvadrantima. Oni obično nemaju veliki utjecaj na poslovanje, ali su također vrlo jednostavni za napraviti.
  • Thankless tasks su oni u donjem desnom kutu, s velikim naporom i malim utjecajem. Njih treba izbjegavati, ako je moguće, jer je pametnije koristiti resurse tima radeći na nečem drugom. U najboljem slučaju, ne bi uopće radili na tim taskovima i jednostavno bi se usredotočili na brze pobjede, velike projekte i fill in poslove.

Postoji mnogo predložaka koje možeš koristiti prilikom primjene tehnike High effort matrice. Važno je da ovu vježbu radite timski i tada ćete svi vidjeti na što se prvo treba usredotočiti i svi ćete uskladiti očekivanja.

#2 Stack ranking

Stack ranking je najčešće korištena tehnika, gdje svoje taskove rangirate od najvažnijih (vrh gomile) do najmanje važnih (dno gomile). Dodijelite prioritetne brojeve jedan, dva, zatim tri i nastavite do n, ukupan broj stavki u vašem backlogu.

Prednost ove metode je što može postojati samo jedan prioritetni zadatak. Pritom je to zapravo najteže odlučiti. Ali što je još važnije, sve zadatke iz svog backloga međusobno uspoređujete tako da je način na koji odlučujete o važnosti dosljedan tijekom ove vježbe.

Kao tim, trebali biste preuzimati taskove od vrha prema dnu. Tako ćete uvijek raditi na najvažnijim zadacima.

High impact u kombinaciji sa Stack Rankingom

Neki Product Manageri ili Product Owneri odluče za kombinaciju gore spomenutih tehnika. Nakon što se donese odluka koji će taskovi završiti u kojem kvadrantu na temelju High impact matrice, tada možeš koristiti Stack ranking kako biste poredali zadatke unutar kvadranta.  

Tako dobivate backlog proizvoda s uređenim popisom taskova, koji odgovara poslovnim očekivanjima.

#3 The MoSCoW metoda

MoSCoW model, za koji je zaslužan pionirski data scientist Dai Clegg, korijene ima u Agile software developmentu.

Ova metoda dobila je ime na temelju slova koja čine njezine kriterije: Must Have, Should have, Could have i Won't have. Vrlo je sličan Stack rankingu, ali ima različite kategorije važnosti:

  • Must Have user storyji su oni za koje jamčite da ćete ih isporučiti jer bez njih ne možete isporučiti. Na primjer, ako biste morali otkazati svoj release jer ih niste mogli uključiti, onda je to obavezno Must Have.
  • Should Have funkcionalnosti su važne, ali nisu apsolutno neophodne za uspjeh vašeg releasea. Može biti bolno ako ih se izostavi i mogu utjecati na vaš proizvod, ali ne utječu na minimalnu održivost vašeg proizvoda.
  • Could have funkcionalnosti su one koje su poželjne, ali su manje važne od značajki Should Have. Trebali biste poraditi na ovim user storyjima nakon što one u Must have i Should have budu gotove.
  • Won't have user storyji su oni za koje su se svi složili da ih ovaj put nećete isporučiti. Možete ih zadržati u backlogu za kasnije, ako ili kada to bude potrebno.

Problemi s modelom MoSCoW su u tome što je tako lako reći koji zadaci pripadaju u kategoriju Must have, dok postaje teško za Could have ili Won't have. Skloni smo klasificirati refactoring kao Could have i Won't have i to jednostavno nikada ne dolazi na vrh našeg popisa prioriteta.

Važnost prioritiziranja backloga

Nakon što je backlog prioritiziran, imaš jasan put za fokus tvog tima. Ali nemoj zaboraviti, backlog refinement je iterativni proces i kada ga jednom riješiš, to ne znači da posao tu završava…uvijek bi trebali pročistiti svoj backlog pazeći da su ispoštovani principi određivanja prioriteta koje ste usvojili.

Oznake

Joberty

Joberty je platforma za razmjenu iskustava iz IT zajednice.

Tvoja prijava je uspješno sačuvana!
Odlično! Kako bi imao pristup cijelom sadržaju bloga potrebno je izvršiti proces plaćanja.
Tvoja prijava je uspješna!
Tvoj nalog je aktiviran, sada imaš pristup cijelom sadržaju bloga.