Prioritizácia backlogu: ako vybrať funkcie, ktoré dávajú zmysel

01Backlog usporiadajte podľa jedného zrozumiteľného cieľa

Zoznam požiadaviek môže obsahovať novú funkciu, opravu chyby, technickú zmenu aj obchodný záväzok. Ak ich porovnávate iba podľa hlasitosti zadávateľa, tím nedokáže vysvetliť svoje poradie. Najprv určte výsledok, ktorý má produkt v danom období zlepšiť. Môže to byť úspešné dokončenie prvej úlohy alebo spoľahlivejšie spracovanie objednávok.

Cieľ napíšte tak, aby sa dala preveriť zmena. Počet vydaných funkcií opisuje aktivitu tímu. Lepšie zvládnutie úlohy používateľa opisuje prínos, ktorý chcete dosiahnuť. Vyberte spôsob merania a uveďte obmedzenia. Pri novom produkte môže ísť najprv o overenie potreby, nie okamžité zvyšovanie výnosov.

Pri práci podľa Scrumu zodpovedá Product Owner za usporiadanie Product Backlogu a komunikovanie produktového cieľa. Takto zodpovednosť opisuje Scrum Guide. Konkrétnu prioritizačnú metódu však nepredpisuje. Aj mimo Scrumu potrebujete vedieť, kto po vypočutí podkladov rozhodne a komu svoje rozhodnutie vysvetlí.

Backlog nemusí byť podrobným sľubom na celý rok. Najbližšie položky pripravte tak, aby ich tím vedel pochopiť a odhadnúť. Vzdialenejšie možnosti môžu zostať stručnejšie. Rozdiel medzi nápadom, preverovanou potrebou a pripravenou prácou má byť viditeľný, aby dlhý zoznam nevyvolával falošné očakávania.

02Z požiadavky najprv urobte rozhodovateľnú položku

Názov „pridať export“ ešte nehovorí, pre koho a na čo je potrebný. Spresnite používateľa, situáciu, dnešnú prekážku a očakávaný výsledok. Možno potrebuje odovzdať účtovníctvu mesačné údaje, ale postačí automatické prepojenie. Oddelenie problému od prvého navrhnutého riešenia umožní porovnať viac ciest.

Priložte dôkaz v primeranom rozsahu: opakujúce sa otázky podpory, rozhovor, pozorovaný neúspech alebo údaj z používania. Rozlišujte jednotlivý prípad a opakovaný vzorec. Veľký zákazník môže mať dôležitú potrebu, no jej veľkosť nesmiete automaticky preniesť na všetkých používateľov.

K položke doplňte podmienku úspechu a to, čo do nej nepatrí. Pri exporte môže ísť o vybrané polia a overené použitie konkrétnym tímom. Univerzálny export všetkého do všetkých formátov je podstatne širšia úloha. Rozsah ovplyvňuje poradie rovnako ako samotný prínos.

Overte aj alternatívu bez vývoja. Zrozumiteľnejší návod, úprava nastavenia alebo zmena pracovného postupu môže riešiť časť problému. Ak je riešenie dočasné, zaznamenajte jeho náklady a obmedzenia. Backlog sa má rozhodovať medzi použiteľnými možnosťami, nie iba medzi názvami obrazoviek.

03MoSCoW pomáha udržať rozsah konkrétneho dodania

MoSCoW rozdeľuje požiadavky na Must Have, Should Have, Could Have a Won’t Have this time. Podľa Agile Business Consortium je podstatný konkrétny časový rámec. V praxi si označte nevyhnutné, dôležité, voliteľné a teraz nezahrnuté požiadavky. Skupiny pomenujte aj pri komunikácii termínu, aby zadávatelia vedeli, ktoré časti patria do základného rozsahu a ktoré sú podmienené dostupným časom. Rovnaká vec môže byť nevyhnutná pre celý projekt, ale ešte nepotrebná v prvom overení.

Pri označení Must Have sa spýtajte, čo nastane bez tejto požiadavky. Ak bez nej riešenie nedáva použiteľný alebo prijateľný výsledok, máte silný dôvod. Ak existuje dočasný obchádzkový postup, posúďte jeho cenu a uskutočniteľnosť. Samotná preferencia oddelenia nestačí na zaradenie medzi nevyhnutné veci.

Metóda potrebuje aj položky, ktoré vedome odložíte. Ak je celý zoznam nevyhnutný, pri probléme nemáte priestor upraviť rozsah. Vysvetlite zadávateľom, čo sa v tomto dodaní nezahrnie a prečo. Označenie teraz nie musí byť viditeľné, aby sa požiadavka nevracala do práce neformálnou cestou.

MoSCoW sama neurčuje presné poradie vo vnútri skupiny. Pri viacerých dôležitých položkách potrebujete ďalšie kritériá, závislosti a kapacitu. Použite ju najmä pri dohode o minimálnom rozsahu verzie. Nenúťte kategórie predstierať presnosť, ktorú nemajú.

04RICE umožní porovnať prínos s náročnosťou

RICE, ktorú pôvodne opísal Intercom, pracuje s dosahom, dopadom, istotou a náročnosťou. Dosah sa vzťahuje na rovnaké obdobie a zvolenú jednotku. Dopad opisuje účinok na cieľ, istota kvalitu podkladov a náročnosť prácu tímu. Skóre vzniká násobením prvých troch faktorov a delením náročnosťou.

V pôvodnom RICE má istota obmedziť nadšenie pre slabo podložené nápady. Vo vlastnom rozhodovaní preto pomenujte, čo neviete: veľkosť problému, účinok zmeny alebo technickú náročnosť. Niekedy bude najbližšou prioritou krátke overenie neistoty. Vývoj celej funkcie by zatiaľ stál na príliš veľkom predpoklade.

Číslo s desatinnými miestami nepovažujte za presnú hodnotu budúceho výsledku. Skúste, či sa poradie zmení pri rozumnom zhoršení odhadu náročnosti alebo prínosu. Ak malá zmena predpokladu obráti poradie, možnosti sú skôr podobné než jednoznačne zoradené. Pomôže doplniť podklad alebo zvoliť menší overiteľný rozsah.

Pri väčšej funkcii rozlišujte viac častí. Prvá môže vyriešiť hlavný problém, ďalšie zlepšujú pohodlie pre menšiu skupinu. Ak hodnotíte len celý balík, ľahko prehliadnete jednoduchšiu cestu. Odhadujte preto použiteľný menší výsledok spolu s prácou potrebnou na jeho bezpečné nasadenie.

05Povinnosti, riziká a závislosti posúďte výslovne

Dôležitý záväzok alebo kritická chyba nemusí dosiahnuť vysoké skóre podľa počtu používateľov. Určte, ktoré požiadavky vyplývajú zo zmluvy, prevádzkovej hranice alebo overeného rizika. Zaznamenajte konkrétny dôvod a termín. Všeobecné označenie bezpečnosť alebo urgentné nemá samo uzavrieť diskusiu o rozsahu.

Závislosť môže zmeniť poradie aj pri nižšom priamom prínose. Nová integrácia môže potrebovať úpravu oprávnení a dátového modelu. Náročnosť posudzujte spolu s nevyhnutným predchádzajúcim krokom. Zároveň preverujte, či je závislosť naozaj potrebná, alebo len vychádza zo zvyku realizovať veľké zmeny naraz.

Technický dlh pomenujte cez dôsledok. Opakované chyby, pomalé nasadenie alebo neudržateľná podpora vysvetlia jeho význam lepšie než neurčitá potreba prepísať systém. Určte, aká úprava obmedzí konkrétny problém. Časť dlhu môžete riešiť priebežne, väčšia zmena potrebuje samostatnú dohodu o nákladoch a očakávanom prínose.

Pri obchodnej výnimke zaznamenajte, čo pre jej prijatie odsúvate. Sľub jednej funkcie znamená menej kapacity na inú prácu. Rozhodujúca osoba má vidieť obidve strany a potvrdiť zmenu. Táto jednoduchá stopa zabraňuje situácii, v ktorej nový záväzok pribudne, no pôvodné termíny zostanú bez vysvetlenia.

06Výber práce preveďte cez skutočnú kapacitu

Prioritný zoznam nemusí presne zodpovedať tomu, čo tím dokončí v najbližšom období. Overte dostupnosť ľudí, potrebné zručnosti a práce v rozpracovaní. Návrh, vývoj, skúška, migrácia dát a príprava podpory patria do jedného rozsahu. Položka s malým kódom môže mať zložité prevádzkové odovzdanie.

Náročnosť odhadujú ľudia, ktorí budú prácu vykonávať. Zadávateľ vysvetlí cieľ a dôsledky, tím zasa neznáme technické okolnosti. Pri väčšej neistote nepýtajte presný termín ako náhradu za chýbajúce poznanie. Dohodnite krátke preverenie s konkrétnou otázkou a výstupom, podľa ktorého následne upravíte odhad.

Rozpracovanú prácu neprerušujte pri každej novej požiadavke bez posúdenia dôsledkov. Zmena môže byť potrebná, no vyžaduje vedomé rozhodnutie o strate sústredenia a o stave pôvodnej úlohy. Určte cestu pre skutočne naliehavé prípady a odlišujte ju od bežného pridania nápadu do backlogu.

Vybrané položky nech podporujú súvislý výsledok. Niekoľko nesúvisiacich malých úloh môže vytvoriť veľa dokončených kartičiek, ale žiadnu použiteľnú zmenu pre zákazníka. Pri dohode o najbližšej práci si preto predstavte, čo konkrétne budete vedieť ukázať a čo používateľ následne dokáže urobiť.

07Po dodaní opravte predpoklady aj ďalšie poradie

Po nasadení sa vráťte k pôvodnému problému a podmienke úspechu. Overte používanie, kvalitu výsledku a vzniknuté náklady podpory. Ak očakávaný prínos nenastal, rozlíšte slabý predpoklad, nedostatočné vysvetlenie funkcie a chybu realizácie. Každá príčina mení ďalšie rozhodovanie iným spôsobom.

Pri novom produkte sa prioritizácia prirodzene spája s overením záujmu a návrhom MVP. Pri rozvíjaní služby nadväzuje na plánovanie vývoja SaaS. V obidvoch prípadoch má poradie vyjadrovať aktuálne poznanie a dostupnú kapacitu.

Staršie nápady pravidelne prehodnoťte. Zmenený trh, odstránený problém alebo nová alternatíva môže zrušiť ich význam. Položku možno archivovať s dôvodom a podmienkou návratu. Čistenie backlogu dáva tímu priestor na relevantné možnosti a znižuje dojem, že každý zapísaný nápad je budúcim sľubom.

Na pravidelnej kontrole poradia prejdite nové dôkazy, termíny a závislosti. Nemusíte prepočítavať všetko od začiatku. Vyberte položky, pri ktorých sa zmenil podstatný predpoklad, a zaznamenajte dôvod zmeny. Tím aj zadávatelia tak uvidia, že poradie sa mení podľa poznania, nie podľa poslednej naliehavej správy.

08Časté otázky o prioritizácii backlogu