Story Points: hogyan becsüljük meg a feladatok összetettségét az Agile módszertanokban?

Mik azok a történetpontok, és honnan származik ez a koncepció?

A történetpontok egy okos agilis projektmenedzsment eszköz, amely lehetővé teszi a csapatok számára, hogy felmérjék, milyen nagy és nehéz egy feladat. Fontos, hogy ezek nem órák, hanem nehézségi pontok, amelyek a következőket jelzik: méret (mennyit kell elvégezni?), összetettség (technikailag mennyire nehéz a feladat?) és kockázat (mennyire bizonytalan?). Ez egy összehasonlító becslés. A csapat vesz egy új feladatot, és összehasonlítja a már elvégzett feladatokkal. Ha az új feladat kétszer olyan nehéz, mint a régi, akkor kétszer annyi pontot kap (pl. 4 helyett 8 pontot). Az értékeléshez speciális számokat használnak, gyakran a Fibonacci-sorozatból (pl. $1, 2, 3, 5, 8, 13, 21$), hogy könnyebben látható legyen a nagy különbség egy egyszerű és egy nagyon bonyolult feladat között.

A történetpontok ötlete azért született meg, mert az órák számolása túlságosan megbízhatatlan. Az időbecslés attól függ, hogy az adott programozó milyen gyorsan dolgozik, hány szünetet tart, és milyen napja van. A történetpontok kiküszöbölik ezeket a problémákat. Azáltal, hogy az óra helyett a probléma objektív összetettségére összpontosítanak, a csapatok reálisabban terveznek, és jobb, stabilabb munkatempót (úgynevezett sebességet) érnek el. Az Agile megalkotta ezt az ötletet, a Scrum pedig teljes mértékben átvette, és a későbbi munkaidőszakok (az úgynevezett sprintek) tervezésénél használja. A gyakorlatban a történetpontok mindkét megközelítésben standard eszköznek számítanak.

A történetpontok becslésének alapelvei

Ahhoz, hogy a feladatokat megfelelően értékeljük a történetpontok segítségével, van néhány aranyszabály, amit szem előtt kell tartanunk. A legfontosabb az összehasonlítás: egy új feladatot mindig valamilyen már elvégzett feladathoz (a „sablonunkhoz”) viszonyítunk. Az értékelésnek az egész csapat közös döntésének kell lennie, nem pedig egy ember ötletének. Ráadásul a nehézség és a kockázat számít, nem az idő! Ehhez egy speciális, nem lineáris skálát használunk (pl. 1, 2, 2, 3, 5, 8$), mert minél nagyobb valami, annál bizonytalanabb. Ahhoz, hogy a csapat megegyezzen a történetpontok számában, két bevált technikát alkalmazunk:

• Póker tervezése: ez a legnépszerűbb „kártyajáték a becsléshez”. A feladat megbeszélése után mindenki titokban kiválaszt egy kártyát a választott becsléssel (pl. 5, 8, 13). A kártyákat egyszerre fedik fel. Ha a vélemények erősen megoszlanak (pl. az egyik személy 3-at, a másik 13-at adott), a csapatnak meg kell vitatnia, hogy honnan erednek ezek a különbségek, amíg mindenki ugyanazt a közös értéket nem jelzi.
• Póló méretezés: ezt a technikát akkor alkalmazzák, amikor nagyszámú feladatot kell nagyon gyorsan felmérni, például egy projekt legelején. Konkrét számok helyett a feladatokat a ruhákhoz hasonló méretekkel látják el (XS, S, M, L, XL). Ez lehetővé teszi, hogy gyorsan megkülönböztesse, mi a nagy és mi a kicsi. Csak később, amikor eljön a részletesebb projekttervezés, hogyan alakítjuk át ezeket a „pólókat” történetpontokká.

Hogyan vezessünk le egy történeti pontok becslési ülést?

Ahelyett, hogy magát a munkamenetet írná le, fontos, hogy a projektvezető vagy a terméktulajdonos a Scrumban hogy tisztában legyen a leggyakoribb hibákkal, amelyek szabotálják a történetpontok hitelességét és hatékonyságát. A megfelelő becslési munkamenet magában foglalja a következő buktatók elkerülését:

• A történetpontok órákká való átalakításának kísérlete: ez a legnagyobb hiba, amely tönkreteszi a pontok értelmét. Ha a csapatot arra kényszerítjük, hogy pontok ürügyén becsülje meg az időt, az felesleges nyomást és alulbecslést eredményez.
• A csapatok sebességének összehasonlítása: a sebesség (azaz a munkatempó) minden csapat esetében egyedi. Összehasonlítása egészségtelen versengést generál, és nem ad pontos képet a teljesítményről.
• A történetpontok nyomásgyakorló eszközként való használata: a történetpontok a reális tervezésre szolgálnak, nem pedig az ellenőrzésre és az alulbecslés kikényszerítésére. Ez ugyanis alááshatja a csapaton belüli bizalmat.
• A kis feladatok túlértékelése: túl sok időt tölteni az 1-2 pontot érő feladatok megvitatásával pazarlás. Jobb gyakorlat, ha automatikusan a legalacsonyabb értéket rendeljük hozzájuk.
• A kalibráció hiánya: a csapatnak meg kell állapodnia és rendszeresen emlékeztetnie kell magát arra, hogy mit jelent a „referenciafeladat” annak érdekében, hogy minden becslésben megmaradjon a következetesség és a viszonylagosság.

E buktatók ellenére a történetpontok univerzális eszköznek számítanak a különböző projektkörnyezetekben. A munka becslésére és rangsorolására, valamint a feladatok összehasonlítására használják. A Scrumban a Sprinttervezést és a sebességmérést támogató eszköz. Az idő megadása helyett a csapat a feladatok relatív méretét beszéli meg, például azt mondva, hogy „úgy tűnik, hogy 3 pont”, ami absztraktabb, sokoldalúbb, és lehetővé teszi, hogy ezt az intézkedést mind az IT-, mind az üzleti csapatokban (pl. marketing) használják.

FlexiProject és történetpontok kezelése

A FlexiProject egy olyan eszköz, amely lehetővé teszi a teljes történetpont-életciklus zökkenőmentes bevezetését és ellenőrzését, mind az Agile, mind a Scrum rendszerben. A rendszer lehetővé teszi, hogy a történetpontokat közvetlenül hozzárendelje a Backlogban lévő feladatokhoz, ami fontos a priorizáláshoz. A FlexiProject a feladatokhoz rendelt pontok és a csapat korábbi munkatempója (Velocity) alapján segít megtervezni a sprintek ütemezését, megmutatva, hogy a csapat reálisan hány pontot tud teljesíteni. Az eszköz automatikusan nyomon követi és megjeleníti a Velocity-t a következő iterációkban, ami elengedhetetlen ahhoz, hogy megjósolhassuk, milyen gyorsan fog haladni a munka. A vizualizáció és az ellenőrzés részeként fejlett burndown/burnup diagramok állnak rendelkezésre, amelyek folyamatosan mutatják, hogy mennyi munka (pontokban) van még hátra a sprintben vagy a teljes projektben. A Kanban tábla emellett lehetővé teszi a feladatok történetpontos becslésekkel történő kezelését, lehetővé téve a haladás és a munkafolyamat átlátható nyomon követését. Ezzel a műszerfallal a projektmenedzser ellenőrizheti az aktuális Velocity-t és az egész projektre vonatkozó előrejelzést, így könnyebbé válik a határidők betartása.

Story points vs. más becslési módszer

A történetpontok olyan eszköz, amely kifejezetten kerüli az időszámítást, ami a legnagyobb előnye. Az órákban történő becsléshez képest a pontok sokkal stabilabbak, mivel a feladat nehézségét értékelik, nem pedig azt, hogy az adott fejlesztő milyen gyorsan dolgozik. Az órák könnyen változhatnak (szünetek, megbeszélések, fáradtság), míg a feladat összetettsége változatlan marad. A sztoripontok ezért jobbak, mert inkább a problémára koncentrálunk, mint az időhiányra. Jobbak az Ideális napoknál is, amelyek, bár feltételezik, hogy nincsenek szünetek, mégis egy időegységet jelentenek, és könnyen összetéveszthetők a valós idővel. A hagyományos időbecslés (órákban vagy napokban) azonban akkor válik szükségessé, amikor előzetes, rögzített költségvetést kell készítenünk egy ügyfél számára, amikor kis, egyszerű szolgáltatási feladatokat kell elvégeznünk (nulla bizonytalansággal), vagy amikor olyan projekteken dolgozunk, amelyek a Waterfall-modellt igénylik.

Összefoglaló: Történetpontok mint a jobb Agile tervezés eszközei?

A történetpontok forradalmat jelentenek a tervezésben, mert ezek már nem órák, amelyek gyakran kudarcot vallanak, hanem pontok, amelyek egy feladat tényleges nehézségét, összetettségét és kockázatát mérik. Ez a stabil mérőszám kiküszöböli a találgatásokat. Ha a történetpontokat az Agile csapatok számára készült fejlett eszközök támogatják , mint például a FlexiProject, akkor a projektek hatékony, kiszámítható és nyugodt irányításának legjobb módjává válnak. A FlexiProject emellett a sprint menedzsment eszköz, mivel segít a Sprintek megtervezésében a csapat Velocityje alapján.