A product backlog, ahogy mi szoktuk (Scrum-sorozat 2.

rész)
infokukac.com/2009/12/a-product-backlog-ahogy-mi-szoktuk-scrum-sorozat-2-resz

By Marhefka István 2009. 12. 11.

A Scrum-ról szóló cikksorozatom első részében egy rövid összefoglalást adtam arról, hogy
mik a Scrum alapszabályai. Ígéretemhez híven folytatom azzal, hogy mi hogyan
alkalmazzuk a Scrum-ot.

Ez a post a product backlog-ról szól.

Mi a product backlog?
Az összes hátralévő funkció listája. Semmi “cicó”, egy sima lista. Semmi hierarchikus
fastruktúra vagy az elemek között ide-oda mutató hivatkozások, függőségek. (Mint
ahogyan egyesek szeretik a követelménykezelést emígyen túlbonyolítani.)

A product backlog célja, hogy priorizálva tartalmazza, hogy mik azok a funkciók,

amelyek a szoftver fejlesztéséből még hátra vannak. A Scrum nem is a funkció, hanem
igazából a sztori kifejezést használja. Ennek a célja az, hogy rámutasson, hogy a product
backlog-nak üzleti szempontból kell tartalmaznia a hátralévő feladatokat, funkciókat.
(Story = mese, történet.) Tehát a product backlog nem tartalmaz olyan sort, hogy “admin
felület szerveroldala”, lehetőség szerint olyat sem, hogy “admin felület” (helyette inkább
pl. felhasználók és jogosultságaik adminisztrálása). Olyan sor sincs benne, hogy
“telepítés” vagy “XY funkció tesztelése”. A product backlog egy banki webes rendszernél
például ilyen sorokból (sztorikból) állhat:

Átutalás,
Számlatörténet lekérdezése,
…

Jó kérdés, hogy a szoftverben talált hibák bekerüljenek-e a product backlog-ba. Valakik

szerint igen, valakik szerint nem. Én azok táborába tartozom, akik azt mondják, hogy
általában ne kerüljenek be a hibák a product backlog-ba, kivéve akkor, amikor
új sztoriról van szó. (Erről külön blogbejegyzés fog szólni.)

A product backlog a Scrum stratégiai mozgatórugója. Ez jelöli ki, hogy a

következő sprintben milyen sztorikat kell megvalósítani, ill. az azt követő sprintekben
várhatóan milyen sztorik következnek. Ha a csapat már rutinos, és az adott projekt is
zökkenőmentesen halad, akár pár hónappal előre is tervezhetünk a segítségével. (Mi meg
tudjuk mondani, hogy a product backlog-ból milyen sztorikkal leszünk kész fél évvel
később.)

1/7
Mi Excelt használunk. Sok programozó utálja (én szeretem). Soha nem akartam
célszoftvert a product backlog szerkesztéséhez. Meggyőződésem, hogy nem lehet semmi
sem olyan rugalmas erre a feladatra, mint maga az Excel.

Mi van pontosan a product backlog-ban?

A product backlog nálunk a következő oszlopokat tartalmazza:

(A) azonosító: S-001-től indultunk (“S”, mint sztori). A következő felmerülő sztori
a következő sorszámot kapja.
(B) sztori megnevezése: a sztori rövid megnevezése (pl. “számlatörténet
lekérdezése”),
(C) prioritás: egy szám (súly), ami minél nagyobb, annál fontosabb a sztori, (OK-t
írunk be, ha elkészültünk vele)
(D) sprint: melyik sprintben készült el a sztori (ha már kész van),
(E) becsült sztoripont: egy becslés, hogy az adott sztori mennyi ráfordítással
készül el,
(F) megjegyzés: bármilyen szabad szöveges információ.

(A) Az azonosító

Minden sztorinak van egy egyedi azonosítója. Ez igen hasznos:

mert könnyen megtalálhatunk bármit, ha később újrapriorizáljuk a táblázatot;

a sprint során is hasznos a sztorik azonosítására;
amikor commit-álunk, feltüntetjük a sztori azonosítóját is a logban, hogy szükség
esetén könnyebben összegyűjthetőek legyenek az egy sztorihoz tartozó commit-ok;
az ügyfél is megkapja a product backlog-ot, a sztorik azonosítói segítik a nagy
táblázatban történő eligazodást.

2/7
A sztorik azonosításához az első felmerülő sztorihoz az S-001-et, a következőhöz az S-
002-et s.í.t. használjuk. A sorszám nem utal a prioritásra, csak egy “buta” egyedi
azonosító minden egyes sztorihoz.

(B) A sztori megnevezése

Teljesen nyilvánvaló, hogy szükséges egy rövid megnevezés minden sztorihoz. Az
elnevezéskor vegyük figyelembe, hogy úgy adjunk nevet a sztorinak, hogy – lehetőség
szerint – az ügyfél külön magyarázat nélkül is megérthesse.

(C) A prioritás

Valakik azt mondják, hogy úgy priorizáljuk a sztorikat, hogy ne legyen két olyan sztori,
amely ugyanazt a prioritást kapja. A szándékuk érthető, mert azt szeretnék hangsúlyozni,
hogy adott helyzetben mindig el lehessen dönteni két sztori közül, hogy melyik a
fontosabb. Az én tapasztalatom viszont az, hogy ha sok elemű a product backlog (több
tucatnyi sztori van benne), igencsak macerás egyedi prioritást adni minden sztorinak,
mert a product backlog folyamatosan változik.

Hogyan kezdjük a priorizálást, amikor épp egy nagy számosságú sztorihalmaz előtt ülünk?
Az első sztori, ami szembe jön, legyen – mondjuk – 1000 prioritású. Jöjjön a következő.
Hát, ez kevésbe fontos, mint az előző, legyen ennek a sorszáma 900. A harmadik sztori
vajon milyen prioritású legyen? Az elsőnél nem fontosabb, viszont a másodiknál igen.
Akkor legyen – mondjuk – 950.

Látható, ahogy egyre több sztorit priorizáltunk, egyre nehezebben találjuk meg az éppen
vizsgált sztori helyét a sorban, mert mindig végig kell néznünk az összes már bepriorizált
sztorit. Ezért célszerű inkább mérföldkövek alapján priorizálni. (Mi legalábbis erre
jutottunk.) Ld. esettanulmány a cikk végén.

(D) Sprint (mint product backlog táblázat oszlop)

Amikor egy sztori elkészül, beírjuk a táblázat megfelelő oszlopába, hogy melyik sprintben
készült el. Ezáltal utólag is látható, hogy milyen ütemben készültek el az egyes sztorik. (Pl.
ügyféllel történő találkozáskor.)

(E) Becsült sztoripont

A sztorikat előzetesen “besztoripontozzuk”, azaz minden sztorihoz megbecsüljük, hány
sztoripontot ér. (A sztoripontról majd a tervezési részben írok részletesen.) A csapat
teljesítménye a sprintek során nagyjából állandó, de legalábbis előre tervezhető
(szabadságolás, új ember kerül a projektre, valaki elmegy stb.) Ha tudom, hogy az elmúlt
sprintek alatt hány sztoripontot teljesített a csapat, akkor elvileg kiszámíthatom, hogy – a
prioritások alapján – az elkövetkezendő sprintekben milyen új sztorik fognak elkészülni.

3/7
A sprint tervezéssel ellentétben, ahol a csapat közösen becsli meg, hogy az adott sprintre
betervezett sztori hány sztoripontot ér, a product backlog priorizálása közben a
sztoripontozást én magam végeztem. (Mivel elég stabil volt a projekt és a csapat is, ezért
viszonylag egyszerűen (és gyorsan!) ment a dolog. Utólag visszanézve stabilan 20%-kal
felé lőttem a valóságnak, de ez annak is tudható volt, hogy mindig biztonságosan
próbáltam előre több hónapra becsülni.)

Az angol szakirodalomban a becslés ezen módszerét Yesterday’s weather-nek hívják,

azaz ha tudom, hogy az előző sprintben mennyit teljesített a csapat, akkor azzal számolva
jól becsülhetem, hogy a közeljövőben hogyan fogunk tudni újra teljesíteni.

(F) Megjegyzés

Ezt az oszlopot csak időnként töltjük, ha úgy látjuk, hogy egy sztori kapcsán felmerült
valamilyen releváns információ, amit célszerű feljegyezni. Akkor használjuk pl. ha a
sztori megnevezése nem elegendő, vagy pl. azt is beleírjuk, ha az ügyféllel előre egyeztetni
kell a sztori kapcsán.

Hogyan készül a product backlog?

Ha elkezdjük a Scrum-ot, csináljunk egy hozzávetőleges listát. Nem kell félnünk soha: a
product backlog arra teremtetett, hogy változzon. Ha elszúrunk valamit, bármikor
javíthatunk. Csináljuk kövspec alapján, csináljuk emlékezetből, nézzük a szoftver elkészült
képernyőit, esetleg képernyőterveket, ami eszünkbe jut, és még nincs kész, jegyezzük fel.
Ha terméket fejlesztünk, akkor különösképpen érdemes vizionált funkcionalitásokat is
bele írni. Így lesz már egy jó kis listánk.

Pár jótanács:

A nagyméretű sztorikat próbáljuk több kisebbé alakítani! Ezáltal külön is fogjuk

tudni priorizálni őket, és adott határidőre valójában kevesebb feladattal kell végezni
(mert a nagy sztori egyik fele általában későbbre is elég).
Próbáljuk végig gondolni reálisan azt, hogy mi a tényleges(!) hatása annak, ha nem
készül el időre egy sztori! Amin ilyenkor el szoktam gondolkozni: tényleg olyan nagy
gond? Meglepően sokszor nem az, csak mindenki túldramatizálja a helyzetet. Járjuk
körbe a témát, ne dőljünk be senkinek elsőre!
Végezzül el a priorizálást az ismert határidők, mérföldkövek alapján! (Ld.
esettanulmány a cikk végén)
Ha már minden kötél szakad, és tényleg az látszik, hogy teljesíthetetlen határidőre a
dolog, azonnal jelezzük az ügyfélnek a dolgot! A saját projektünkben az volt a
tapasztalat, hogy a problémákat már idejekorán fel lehetett ismerni. (Nem két héttel
a határidő előtt derül ki, hogy abszolut teljesíthetetlen a dolog.)

A product backlog állandóan változik. Mik a tipikusak?

4/7
 Ha az ügyfélnek menet közben jön ötlete: semmi gond, bele rakjuk a listába, és
bepriorizáljuk. Ha valóban fontos, akkor sorra fog kerülni, ha nem, akkor elsínylik.
Sokkal jobb annak az optikája, hogy mindent, amit mond, betervezünk, és majd az
idő (és pénz!) függvényében meglátjuk közösen, hogy tényleg belefér-e, mintha
egyből figyelmen kívül hagynánk, amit mond.
Nagy sztorik vannak a product backlog-ban, amiket később lebontunk. Előbb-utóbb
ki fog derülni, hogy vannak-e ilyenek, mert túl nagyok: nehezebben becsülhetőek, és
hogyha mind megcsinálnánk őket, kicsúsznánk az időből.
Sprint (implementáció) közben kiderül, hogy van valami, amire nem gondoltunk.
Ilyenkor két döntésünk van: vagy beleértjük a sprintbe az előre nem tervezett dolgot,
és ezzel a sikeres sprintet kockáztatjuk, vagy pedig új sztoriként bevesszük a
kérdéses elemet a product backlog-ba.
A későbbiekben a tesztelés során is kiderülhet, hogy valamire nem gondoltunk. Nem
arra gondolok, hogy a programozó hibázott, hanem arra, hogy egy probléma
hátterében valójában üzleti probléma áll. Mi rengeteg ilyennel találkozunk.

A product backlog és az ügyfél

A product backlog-ot az ügyféllel történő státusz egyeztetésekre is használjuk. Minden
sprint végén el szoktunk látogatni az ügyfél megfelelő vezetőjéhez, és elmondjuk, miket
csináltunk meg az elmúlt sprintben, és mik várhatóak az elkövetkezendőkben. Amikor az
ügyfél szakmai embereivel beszélgetünk, akkor közösen egyezünk meg a sztorik
prioritásáról. Magunktól végezzük el a sztorik priorizálását, és nekik ezt már csak
“tálaljuk”. Így nekik nem kell sokat dolgozni, viszont ha valamivel nem értenek egyet,
akkor azon közösen változtathatunk.

A product backlogot A3-as lapra nyomtatjuk, és úgy adjuk át az ügyfélnek. A közös

megbeszélésen mindenkinek van egy saját példánya. Nagyon szokták szeretni. Be szoktuk
rajzolni a táblázatba a mérföldköveket is.

Esettanulmány (prioritás meghatározása)

Mi a következőképpen gondolkoztunk 2008 év elején, amikor átnéztük a product
backlog-ot:

(A) az ügyfélnek májusban oda kell adni a szoftvert, hogy az ügyfél kulcsoktatói (3
fő) felkészülhessenek az oktatásra,
(B) júniusban kezdőnek az oktatások és egész nyáron át tartanak (a rengeteg
szabadságolás miatt), kb. 90 főt kell oktatni,
(C) október 1-jétől indul egy kéthónapos próbaüzem, amelynek célja, hogy a
felhasználók megállapíthassák, hogy alkalmas-e a szofver az éles használatra, és
kiderülhessenek valós felhasználás közben a szoftver hiányosságai,

5/7
 (D) következő év (2009) január 1-jétől indul az éles üzem.

Ügyfél mondása 2008. januárjában: “a júniusi oktatásokig _mindennel_ el kell készülni!”

Szeretem ezt a mondatot. Annyiszor hallottam már. A háttérben arról van szó, hogy
mindenki a saját s*ggét védi. A valóság persze ennél sokkal árnyaltabb. Ha a dolgok mögé
nézünk, és ügyesek vagyunk, a mission impossible szituációkat is megoldhatjuk.

A product backlog nálunk akkoriban kb. 100 sztorit tartalmazott. Először elvégeztünk egy
gyors “vágást”, és kizártunk minden olyan sztorit, aminek nem kell még működnie a
2009. január 1-jei éles indulásra. Ezeket elláttuk a 100-as prioritással. Ezzel a vágással a
sztorik egy nagy részét sikerült a hatókörünkből eltávolítani. Minden sztorit, ami nem
100-as prioritást kapott, 1000-es prioritással láttunk el.

Minden 1000-es prioritású sztorit megbecsültünk. Ez alapján kijött, hogy az éles

induláshoz (D) lefejlesztendő funkciókkal nem tudunk májusra (A) végezni, sőt, az összes
funkció lefejlesztése nagyjából a teljes évet igénybe veszi (vö. ügyfél mondása).
Kényszerhelyzetben voltunk, ezért tovább kellett gondolni a dolgot.

A következő lépés az volt, hogy meghatároztuk, hogy mik azok a funkciók, amik az (A) ill.
(B) mérföldkőhöz kellenek (azért így párban, mert viszonylag közel voltak egymáshoz, és
hasonlóak voltak az elvárások a két mérföldkőnél). A cél az volt, hogy azokat a sztorikat
valósítsuk meg addigra, amiket a felhasználók túlnyomó többsége a leginkább használ.
(Az nem annyira baj, ha van egy ritkán használt funkció, és nincs kész. Hiába oktatnák le a
felhasználóknak, mire október lesz, addigra úgyis elfelejtik, és úgyis meg kell nézni a
felhasználói kézikönyvet, vagy meg kell kérdezni a kulcsoktatót.)

A próbaüzemig (C) nagyjából mindennel készen kellett lenni. Ha egy funkciót nem tudtak
leoktatni (mert az oktatások során készültek el, vagy idő közben megváltoztak), azokról
készítettünk egy külön doksit a felhasználóknak.

Az időzítés nagyon fontos volt. Nem lehetett egy olyan rendszert oktatni, ami a
használatba vételig (próbaüzem) a felhasználók zöménél jelentősen megváltozik. Sokat
osztottunk-szoroztunk, sztorikat bontottunk fel kisebb sztorikra, abban a reményben,
hogy az egyik része fontos, a másik nem annyira, végül sikerült egy olyan prioritást
megalkotnunk, amely a mérföldkövekkel egybevágott. Az egyes mérföldkövekhez tartozó
prioritások nagyjából a következők voltak:

A: 1000,
B: 900,
C: 500,
D: 300,
egyéb: 100.

Az érdekesség az volt, hogy még tudtunk játszani azzal is, hogy az oktatások során milyen
sorrendben készüljenek el az újabb funkciók, ugyanis a felhasználók jól elkülöníthetően 3
csoportba tartoztak:

6/7
 ügyintézők (kb. 75 fő),
vezetők (kb. 10 fő),
“admin jellegű” felhasználók (kb. 5 fő).

Tehát az oktatások elejéig az ügyintézői funkciókkal kellett meglennünk, és az oktatások

végére kellett csak a vezetői ill. az “admin jellegű” felhasználók által használt funkciókkal
elkészülnünk. Ígyhát a B és C közötti mérföldkövek között is fel tudtunk állítani plusz
mérföldköveket, ill. prioritásokat.

Így sikerült megoldanunk azt a helyzetet, amikor az ügyfél kijelentette, hogy júniusra
minden funkció kell.

7/7