Scrum Útmutató | 40. Termék Hátralék ápolása

A termék backlog ápolása a terméktulajdonos egyik fő feladata. Az ápolási folyamat magában foglalja az új felhasználói történetek megfogalmazását, részletezését és hozzáadását a termék backloghoz. Az ápolási feladatok közül azonban a legfontosabb az, hogy biztosítsuk, hogy a backlogba helyezett bejegyzések a megfelelő sorrendben legyenek, azaz prioritást kapjanak.

A termék backlog ápolása – tartalomjegyzék:

1. Bevezetés
2. A termék backlog ápolásának célja
3. Hibák a termék backlog karbantartásában
4. Backlog karbantartás vs. a Scrum-ban használt mutatók
5. Összefoglalás

Bevezetés

A termék backlog a Scrum egyik artefaktuma. Ez tartalmazza a termék létrehozásához szükséges munkák prioritásos listáját. Más szavakkal, ez egy lista a felhasználói történetekről, amelyek szükségesek a termék céljának eléréséhez. Részletes leírást talál arról, hogy mik a felhasználói történetek ebben a cikkben. És itt találhatók a termék backlog jellemzőiről és karbantartásáról szóló részletek.

A termék backlog ápolása a következő neveken is ismert:

• Backlog priorizálás,
• Backlog finomítás,
• Backlog skálázás.

A termék backlog ápolásának célja

A terméktulajdonos kezeli a termék backlogot. A kulcsfontosságú készségek közé tartozik a feladatok priorizálása a határidő közeledtével. Ennek az az oka, hogy a termék backlog ápolásának célja, hogy biztosítsa, hogy a termék funkciói a legmagasabb üzleti értékkel bírjanak, azaz azok, amelyek a legfontosabbak az ügyfél szempontjából, a teendők listájának élén álljanak. És a leírásuk világos és részletes legyen, hogy a megvalósítás a következő sprintben azonnal elkezdődhessen.

A termék backlogot szükség esetén naponta frissíteni lehet. A terméktulajdonos új felhasználói történeteket adhat hozzá a termék backloghoz, miután beszélt az érdekelt felekkel és a fejlesztőcsapattal, vagy következtetéseket vonhat le és átfogalmazhatja a már a termék backlogban írt felhasználói történeteket.

A backlog kötelező frissítése az egyik feladat, amelyet a sprint áttekintése során végeznek. Ezt a folyamatot részletesen leírtuk ebben a cikkben. Általában ezen a találkozón a Scrum csapat nemcsak a következő sprintben elvégzendő feladatokat vitatja meg. Előzetesen meghatározza a felhasználói történeteket és azok megvalósítását a következő két vagy három sprintben. Ez a megközelítés lehetővé teszi a Scrum csapat számára, hogy szélesebb perspektívát vegyen a hosszú távú irányról. Lehetővé teszi, hogy a jelenleg végzett feladatokat a következő sprintekben történő fejlesztésük szempontjából gondolják át.

Hibák a termék backlog karbantartásában

A termék backlog ápolásával kapcsolatos leggyakoribb problémák egyike az, hogy megengedjük, hogy kontrollálatlanul bővüljön. Ennek az az oka, hogy a termék fejlesztése során különböző további funkciók és feladatok, amelyeket mind az érdekelt felek, mind a Scrum csapat tagjai javasolnak, spontán módon merülnek fel. Ezért a termék backlog terjedésének korlátozása (scope creep) az egyik legfontosabb feladat, amelyet a terméktulajdonos végez. A leggyakoribb hibák, amelyeket a terméktulajdonosok elkövetnek, a következőkre vonatkoznak:

1. Eltérés a termék céljától – túl sok ötlet hozzáadása a termék backloghoz az alapvető termék célján túl nem jó gyakorlat, mivel ez nagymértékben csökkenti az olvashatóságát. Jobb, ha az extra funkciók ötleteit egy külön dokumentumban gyűjtjük össze.
2. Tartalom duplikálása – ismételt vagy nagyon hasonló ötletek beírása a backlogba különböző érdekelt felektől – mielőtt új bejegyzést adna a backloghoz, a terméktulajdonosnak meg kell győződnie arról, hogy az új bejegyzés nem duplikálja a meglévőket.
3. Szélesebb perspektíva hiánya – a termék backlog bejegyzéseit a termék céljával kapcsolatos értékük szerint kell rendezni. Mindazonáltal tartsuk szem előtt, hogy a priorizálásnak figyelembe kell vennie a következő néhány sprintet, hogy a megvalósított feladatok zökkenőmentesen kapcsolódjanak a megelőző sprinthez és a közvetlenül utána következő sprinthez.

Az ilyen típusú hibák elkerülhetetlenek. Azonban a megjelenésük tudatában a terméktulajdonos óvatosabb lehet az új felhasználói történetek hozzáadásában a termék backloghoz, hogy megtalálja a megfelelő egyensúlyt. Ennek az az oka, hogy túlzottan megvágni a backlogot és eltávolítani azokat a bejegyzéseket, amelyek hasonló, de eltérő feladatokat tartalmaznak, szintén hiba. Például hasonló termékfunkciók leírása, amelyek jelentősen eltérnek a megvalósításban.

Backlog karbantartás vs. a Scrum-ban használt mutatók

A termék backlog tartalmaz egy leírást a projekt során hátralévő munkáról. Azonban csak egy naprakész és rendszeresen ápolt backlog képes pontosan megbecsülni a befejezett munka mennyiségének arányát a teljeshez képest. A befejezett munka mennyiségének ábrázolásához a Burndown Chartot kell alkalmazni, amelyről ebben a cikkben írtunk.

Az egyik népszerű mutató, amely a Scrum csapat munkáját leírja, a Sebesség. Ezt úgy mérhetjük, hogy összehasonlítjuk a termék backlog bejegyzéseinek számát, amelyeket egyetlen sprint alatt átalakítottak incrementté. A sebességet részletesebben írtuk le ebben a cikkben.

Összefoglalás

A terméktulajdonos végzi a termék backlog ápolását. Amikor a termék backlog jól karbantartott, a Scrum csapatnak világos képe van a hátralévő munkáról. Szélesebb, előretekintő perspektívát is kaphat arról, hogy milyen az út a termék céljához. Ezért a terméktulajdonosnak biztosítania kell, hogy a termék backlogban szereplő felhasználói történetek a befejezés prioritásának megfelelően legyenek rendezve. És azt is, hogy a következő sprintekben elvégzendő feladatok a lehető legnagyobb részletességgel legyenek leírva.

Ha tetszik a tartalmunk, csatlakozz a mi szorgos méheink közösségéhez a Facebookon, Twitteren, LinkedIn-en, Instagramon, YouTube-on, Pinterest-en.