Írta: Dvorzsák Alexander, PSM II., PSPO, PMI-DASSM
A Product Backlog egy prioritás szerint rendezett, folyamatosan alakuló lista, mely tartalmazza, hogy mi kell ahhoz, hogy a terméket javítsuk, tökéletesítsük. Ez az egyedüli forrása egy Scrum csapat munkájának. A szerepe, hogy a hátralevő fejlesztéseket transzparenssé tegye a fejlesztésben érintettek számára. De milyen egy jó Product Backlog? Milyen elemei vannak? Hogyan hozzunk létre egyet? Segítünk.
Mi a Product Backlog?
A Product Backlogot leegyszerűsítve úgyis elképzelhetjük, mint egy „Mi mindent szeretnénk, ha a termékünk tudna” elnevezésű kívánságlista, amit a Product Owner állít össze a stakeholderek, felhasználók igényei alapján. Ezt a listát, illetve a listán található igényeket aztán több szempontrendszer mentén a Product Owner részletezi, priorizálja, majd a csapat elé tárja, hogy közösen értelmezzék azokat a legértékesebb elemeket, melyeknek a megvalósításán a csapat a következő időszakban dolgozni fog.
Kicsit specifikusabban, a Product Backlog a Scrum keretrendszerből származó eszköz, produktum. A tartalma rögzíthető, utánkövethető valamilyen erre megalkotott eszköz segítségével, mint pl. a JIRA, de egy egyszerű excel táblázat is alkalmas lehet a Product Backlog kialakítására. A Scrum általánosan fogalmaz a Product Backlogról, a használójára bízza a konkrét megvalósulását, csak alapelveket ír le. A jó Product Backlog használathoz konkrétabb kritériumokat az agilis gyakorlatban kialakult DEEP modell ad.
Eszerint egy jó Product Backlog
- Detailed – Megfelelően részletezett. Komplex, bizonytalan fejlesztéseknél az alacsonyabb prioritással rendelkező Product Backlog item-eket kevésbé szeretnénk részletezni, hiszen a tartalmuk változhat, amíg bele nem kezdünk a fejlesztésükbe, ezért a tervezésük felesleges munkát jelenthet a csapatnak.
- Estimated – A Product Backlog itemekhez becslések tartoznak. A nem becsülhető Product Backlog itemek leszállítását nagyon nehéz betervezni, ezért nem is nagyon jutnak el odáig.
- Emergent – Folyamatosan alakuló, változó. A Product Backlog tartalmát sohasem rögzítjük, a tartalma aszerint változik, ahogy egyre több visszajelzés érkezik a már piacra kiadott inkrementumokból.
- Prioritized – Üzleti érték szerint priorizált. Üzleti érték szerint a legfontosabb elemek kerülnek a Product Backlog tetejére.
Mi a Product Backlog item (PBi)?
A Product Backlog listájában szereplő elemeket nevezzük PBi-nek (Product Backlog item). Az egy Sprint alatt megvalósítható PBi-ket a Sprint tervezésen feldolgozhatónak tekintjük. Ezt az állapotot a PBi-k részletezésével érjük el, mely során a Scrum csapatban növeljük a közös megértést velük kapcsolatban. Ez egy folyamatos tevékenység, mely során olyan részleteket adhatunk a PBi-khez, mint leírás, méret és sorrend. Ezek a részletek a munka típusától függnek, tehát nincs meghatározva, hogy milyen típusú PBi-ket kell használni a fejlesztések során. A cél az lenne, hogy Product Backlog érthetően, transzparensen tartalmazzon mindent, ami a jelenlegi legjobb tudomásunk szerint a termék fejlesztéséhez kell, vagy kellhet.
Milyen fajtái vannak a Product Backlog itemeknek?
Rengeteg, fajtája létezik: felhasználói igények, hibák, nem funkcionális követelmények, minőségi követelmények, tanulmányok stb. nincs megkötés, ahány szervezet, annyiféle PBi.
Vannak olyan PBi-k, amiknek a nevét sok helyen használják, ezek közül vizsgálunk meg három fajtát. Eredeti és pontos definíciót nem lehet adni ezeknek a PBi fajtáknak, hiszen nincs egy szótár, vagy szabályrendszer, ahol össze lennének gyűjtve, sokféleképpen használják őket a világban. Itt most leírjuk az eredetüket és a gyakori tulajdonságaikat. Kritikus szemmel érdemes tekinteni a munka során használt PBi-kre, mindig legyünk tisztában azzal, hogy az adott keretek között milyen PBi-ket használunk és azokat hogyan definiáljuk (azokkal, akikkel együtt dolgozunk).
Az Epic megértéséhez többféle megközelítés lehetséges. Ezek közül a legfontosabbak:
- Jira: Az Epic egy nagyobb méretű feladat, amit kisebb méretű Storykra tudunk lebontani.
- SAFe: Az Epic egy termékfejlesztési kezdeményezés, ami kellően nagy ahhoz, hogy elemzést, Minimum Viable Product (MVP) definiálását és üzleti jóváhagyást igényeljen, mielőtt lefejlesztik.
- Mike Cohn: Ha egy User Story túl nagy, akkor Epic-nek hívjuk. Mi legtöbbször ebben az értelemben szoktuk használni.
A User Story használatához, kritériumaihoz sokan hozzájárultak a történelem során. Elsőként Kent Beck használja a kifejezést a Chrysler C3 projekt során. Alistair Cockburn, Ron Jeffries és a Connextra-nál egy XP csapat is továbbfejleszti a User Story-kat a következő években, majd Bill Wake kitalálja az INVEST kritériumot egy jó User Story leírására.
Leggyakrabban ebben az írásos formában használják: “Én, mint <felhasználó>, azt csinálom, hogy <tevékenység, képesség>, azért, hogy <előny>”
Egy jó User Story az INVEST kritériumoknak felel meg:
- Independent (független): A User Story-kat tetszőleges sorrendben tudom szállítani.
- Negotiable (nyitott): A User Story tartalma addig változhat, amíg le nem zárjuk.
- Valuable (értékes): A felhasználók számára tartalmazzon értéket.
- Estimable (becsülhető): Egy ésszerű, reális becsléssel rendelkezzen.
- Small (kicsi): Rövid időn belül megvalósítható (egy Sprintbe belefér)
- Testable (tesztelhető): Bizonyítani tudjam, hogy jól működik a User Story.
Spike
A Spike egy olyan feladat, mely információgyűjtésre, vagy kérdések megválaszolására irányul, nem pedig arra, hogy valami leszállíthatót állítson elő. Egy gyakori eset, hogy a Spike egy tanulmány egy nem becsülhető PBi kapcsán, melynek a kimenete a becsülhetőség lesz.
Kent Beck, XP: “Egy nagyon egyszerű program, mely nagyobb megoldási lehetőségeket vizsgál.”
Összefoglaló
Rengeteg módon használják a Product Backlog-ot és a PBi-ket a világban, a legfontosabb, hogy legyen célja, értelme, értéke a használatuknak. Nem a Jira a Product Backlog-ok egyetlen megvalósulási lehetősége, nem az számít, hogy milyen platformot használunk, hanem az, hogy hogyan használjuk, és hogy lehetővé tegye a párbeszédet a különböző szereplők között. Sok esetben, ahogy már említettük, egy tábla post-it-ekkel vagy egy excel tábla is elég lehet, hogy transzparenssé tegyük a Product Backlogunkat. Érdemes új csapatok, új fejlesztések esetén átbeszélni, hogy mit értünk PB, PBi alatt, hogyan használjuk őket és milyen célt szolgálnak.
Amennyiben Ön is fontosnak tartja, hogy minél sikeresebben tudja irányítani csapatát és hatékonyan tudja megvalósítani a kitűzött projekt célokat, akkor válasszon aktuális projektvezetőknek ajánlott képzéseink közül!
Designabc