Story pontok — a feladatok összetettségének relatív mértékegységei az agilis fejlesztési módszertanokban. Az órákkal ellentétben a story pontok nemcsak az időt, hanem a feladat összetettségét, kockázatait és bizonytalanságát is figyelembe veszik. A Scrum.org, 2023 adatai szerint a story pontokban relatív értékelést használó csapatok 25%-kal ritkábban csúsznak ki a sprint határidőkből, mint az órákban értékelő csapatok.
Főbb pontok
Story pontok — a feladat összetettségének mérőszámai, amelyeket a Scrum és más Agile módszertanok használnak. A csapat minden feladatot nem órákban, hanem relatív egységekben értékel: „ez a feladat kétszer olyan összetett, mint a referencia”. Ez a megközelítés semlegesíti a különböző fejlesztők sebességbeli különbségét, és az összetettségre összpontosít.
A story pont fogalma a 2000-es évek elején jelent meg a Scrum népszerűsödésével. Az egyik első, aki leírta a módszert, Ron Jeffries volt az Extreme Programming (XP) keretében. Az ötlet az volt, hogy eltávolodjanak a mindig pontatlan „ember-óra” értékeléstől a relatív összetettség felé, amelyet a csapat kollektíven határoz meg. Ma a story pontok az ipari szabvány az Agile csapatok számára.
A story pontokkal történő értékelésnél a csapat három tényezőt vesz figyelembe: a munka mennyiségét (kódmennyiség, képernyők, logika), az összetettséget (technikai kihívások, új technológiák) és a bizonytalanságot (homályos követelmények, kockázatok). Egy story pont jelenthet „kockázatok nélküli egyszerű feladatot”, a 8 pedig „magas bizonytalanságú összetett feladatot”.
A story pont skála megválasztása befolyásolja az értékelés pontosságát és a tervezés kényelmét. A legnépszerűbb skála a Fibonacci-sorozat, de vannak alternatívák is.
| Skála | Értékek | Előnyök | Hátrányok |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Természetes szórásnövekedés nagy feladatoknál | Bonyolult az új csapatoknak |
| Lineáris | 1, 2, 3, 4, 5 | Egyszerű és érthető | Nincs szórás nagy feladatoknál |
| Hatvány | 1, 2, 4, 8, 16, 32 | Maximális szórás nagy feladatoknál | Nagy feladatokat nehéz megkülönböztetni |
| T-Shirt | S, M, L, XL | Gyors durva értékelés | Pontatlan, konverzió szükséges |
A Fibonacci-sorozatot nem véletlenül választották. Az 1 és 2 közötti különbség minimális (50%), a 13 és 21 között viszont jelentős (62%). Ez tükrözi a valóságot: a kis feladatokat pontosabban értékeljük, a nagyokat — nagyobb szórással. Amikor egy feladatot 21 story pontra értékelnek, a csapat megérti: „nem tudjuk, mennyi ideig tart, de biztosan több mint 13”. A Fibonacci-skála megakadályozza a hamis pontosságot.
A skála működéséhez a csapat megegyezik egy referenciáról: „X feladat — 1 story pont”. Általában a referencia egy egyszerű, jól ismert feladat: „szövegmező hozzáadása a képernyőhöz” vagy „gépelési hibás bug javítása”. Az összes többi feladatot a referenciához viszonyítva értékelik. Referencia nélkül a story pontok értelmüket vesztik — mindenki másképp értelmezi az egységet.
Velocity (a csapat sebessége) — a story pontok átlagos száma, amelyet a csapat egy sprint alatt teljesít. Ez a kulcsmetrika a projekt határidőinek előrejelzéséhez.
A velocity-t a befejezett feladatok alapján számítják: összeadják az összes olyan feladat story pontjait, amelyeket a csapat sikeresen befejezett (a definition of done teljesült). A befejezetlen feladatokat nem veszik figyelembe. A pontosság érdekében az utolsó 3-5 sprint átlagát veszik. Például, ha a csapat az utolsó 4 sprintben 20, 22, 18 és 24 story pontot teljesített, a velocity = 21 sp.
A velocity és a backlog teljes story pontban kifejezett mennyiségének ismeretében előrejelezhető a kiadásig szükséges sprintek száma. Például, ha a backlogban 210 story pont van, és a velocity = 21, akkor 10 sprint szükséges. Ez egy durva előrejelzés, amely a munka során finomodik. Fontos: a velocity átlag, nem kötelezettség. Az alsó határ (18 sp) alapján tervezzen, ne az átlag alapján.
A velocity-t nem lehet parancsra növelni — ez a folyamatok egészségének tünete. A velocity fenntartható növekedése a következőkkel érhető el: technikai adósság csökkentése, code review folyamatok javítása, kontextusváltások csökkentése, tesztelés és CI/CD automatizálása. Fontos: a különböző csapatok velocity-je nem hasonlítható össze — minden csapat másképp határozza meg a story pontokat.
A story pontoknak és az óráknak különböző céljaik vannak, és a köztük való választás a kontextustól függ. A tapasztalt csapatok mindkét megközelítést használják különböző feladatokhoz.
Story pontok nélkülözhetetlenek a sprinttervezéshez: nem függenek attól, hogy ki végzi a feladatot. Junior napi 2 sp-t teljesíthet, senior — 4 sp-t, de a feladat értékelése mindkettőjüknél 2 sp marad. A story pontok lehetővé teszik a csapat termelékenységének nyomon követését anélkül, hogy összehasonlítanánk a fejlesztőket. Ez csökkenti a politikai nyomást és javítja a csapat légkörét.
Órák a külső kötelezettségekhez szükségesek: szerződések, költségvetések, ügyféljelentések. Az ügyfél nem „8 story pontot” akar tudni, hanem „3 hetet”. A story pontok órákra való konvertálásához historical conversion rate-t használnak: a csapat tudja, hogy 1 sp = körülbelül 4 óra munka. A konverziónak átláthatónak és adatokon alapulónak kell lennie, nem találgatásokon.
Sok csapat kombinált megközelítést használ: a feladatokat story pontokban értékelik a sprinttervezéshez, majd a menedzser órákra/napokra konvertálja őket a külső jelentésekhez. Fontos, hogy ne keverjünk két rendszert egy folyamatban: vagy story pontokban értékelünk és az időt a velocity-ből vezetjük le, vagy közvetlenül órákban értékelünk.
A story pontok bevezetését gyakran kísérik olyan hibák, amelyek semmissé teszik a relatív értékelés előnyeit. Íme a leggyakoribbak.
A leggyakoribb hiba — a csapat megegyezik: „1 sp = 4 óra”. Ebben az esetben a story pontok értelmüket vesztik, és órákká válnak más néven. A story pontoknak relatívnak kell lenniük, nem kötődhetnek időhöz. Ha az A feladat kétszer olyan összetett, mint a B feladat, akkor 2 sp-t kap, függetlenül attól, hogy hány órát vesz igénybe.
Amikor egy feladatot a végrehajtás után értékelnek — ez nem értékelés, hanem tény megállapítása. A story pontokat a munka megkezdése előtt kell meghatározni, a maximális bizonytalanság pillanatában. A post-factum értékelés torzítja a velocity-t, és nem hoz hasznot a tervezés számára. Ráadásul hamis pontosságérzetet kelt.
Az A és B csapat velocity-jének összehasonlítása — értelmetlen gyakorlat. Minden csapat másképp határozza meg a referenciát és a skálát. Az egyik csapatnak 1 sp egy egyszerű egyórás feladat, a másiknak — egy egynapos feladat. Csak ugyanazon csapat velocity-je hasonlítható össze dinamikában: növekszik vagy csökken.
Amikor különböző feladatok azonos összetettséggel különböző story pontokat kapnak, a bonyolultabbak pedig kevesebbet, a skála elromlik. A csapatnak rendszeresen kalibrálnia kell a skálát: 3-6 sprintenként retrospektíven ellenőrizni, mennyire feleltek meg az értékelések a valós összetettségnek. Ez javítja az értékelések konzisztenciáját.
Gyakran Ismételt Kérdések
A story pontoknak nincs rögzített óra-egyenértékük. Ez egy relatív egység: 1 sp = a referenciafeladat összetettsége. Az órákra való konverzióhoz használja a csapata historical conversion rate-jét: ossza el a sprintben ledolgozott átlagos órák számát a velocity-vel. Általában 1 sp = 4-8 óra, de ez csapatonként egyéni.
Igen, a story pontok használhatók a Kanbanban, de fenntartásokkal. A Kanbanban nincsenek rögzített sprintek, ezért a velocity-t nem sprintenként, hanem hetente vagy havonta számítják. A Kanban csapatok gyakran a story pontok helyett a Cycle Time-ot — a feladat kezdetétől végéig tartó időt — használják. A választás a csapat specifikumaitól függ.
Ha az értékelések eltérnek (az egyik 3 sp-t ad, a másik 13-at), az annak a jele, hogy a feladatot nem értik jól. Bontsa a feladatot kisebb részekre. Beszélje meg a különböző fejlesztők által látott kockázatokat és bizonytalanságokat. Ha a feladat nagy — értékelje Spike-ként (2-4 napos kutatás) a story pontok helyett.
Az átállás 3-6 sprintet vesz igénybe. Kezdje a skála kiválasztásával (Fibonacci — safest choice) és a referenciafeladat meghatározásával. Tartson 2-3 Planning Poker ülést. Minden sprint után számítsa ki a velocity-t. Ne konvertálja a story pontokat órákra — hagyja, hogy a csapat hozzászokjon az új rendszerhez. 3 sprint után látni fogja, mennyit javult a tervezés.
Nem, az értékelés nem változik. A story pontok a munka megkezdése előtt készített előzetes összetettségi értékelések. A feladat végrehajtása után az értékelés ugyanaz marad, még akkor is, ha a tényleges erőfeszítés eltérő volt. Az értékelés utólagos megváltoztatása torzítja a statisztikákat, és értelmetlenné teszi az előrejelzést. Elemezze az eltéréseket a retrospektíveken, de ne változtassa meg az értékelést utólag.
Összefoglalás
Kulcsrakész mobilalkalmazást fejlesztünk
Az IT Sectr 2017 óta készít iOS és Android alkalmazásokat induló vállalkozásoknak és vállalkozásoknak. Tanácsot adunk, és a legjobb megoldást javasoljuk.
Olvassa el is