5.3 Story point becslés és időbecslés valósága

Áttekintő

Amikor először kerülsz egy agile csapatba, az egyik legzavaróbb dolog a becslés lesz. „Mennyi ez a feladat?" – kérdezi a teamlead. Te gondolsz egyet: „Talán 3 óra?" Aztán valaki azt mondja: „Legyen 5 pont." És te nem tudod, hogy ez jó vagy rossz, sok vagy kevés, és miért nem órákat mondtak.

Ez az alfejezet arra való, hogy megértsd, mi az a story point, miért nem ugyanaz, mint az óra, és hogyan kommunikálj hatékonyan akkor is, ha alulbecsülted a feladatot.

Részletes leírás

Mi az a story point?

A story point egy relatív mértékegység, amely a feladat komplexitását, erőfeszítést igénylő részét és bizonytalanságát fejezi ki – nem az elvégzéséhez szükséges pontos időt.

Az a kulcsgondolat, hogy két feladat összehasonlítható egymáshoz képest:

Ha az „A feladat" 2 pont, és a „B feladat" kétszer akkora erőfeszítést igényel, akkor B = 4 pont.
Hogy A 2 pontját elvégzi-e valaki 1 óra vagy 3 óra alatt, az a becslés szempontjából mellékes.

Ezért nem egyezik meg a story point az órával. Egy senior fejlesztő ugyanazt a 3 pontos feladatot elvégezheti 1 óra alatt, amíg egy junior 4 óra alatt végez vele – mégis ugyanannyi pont.

Miért nem használnak egyszerűen órákat?

Mert az órabecslés rendszeresen félrevezető. Emberi agy rosszul becsli az időt (különösen szoftverfejlesztésben), és mindenki másképp értelmezi az „1 óra munkát":

Beleértjük-e a review-t?
A deploy-t?
A tesztelést?
Az ismerkedést a kódbázissal?

A story point ettől elvonatkoztat: a nehézségről döntünk, nem az időről.

Hosszú távon a csapat kialakítja a saját velocity-ját (átlagosan hány pontot végez el sprintenként), és ebből megbízható előrejelzések adhatók – órabecslésekkel ez ritkán sikerül.

A Fibonacci-skála logikája

A legtöbb csapat nem lineáris skálát használ (1, 2, 3, 4...), hanem Fibonacci-szerűt: 1, 2, 3, 5, 8, 13, 21.

Miért? Mert a bizonytalanság is nő a feladat méretével. Egy kis feladatnál pontosan különbséget tehetsz 2 és 3 között. Egy nagy feladatnál már nem releváns, hogy 13 vagy 14 – inkább az a kérdés: 13 vagy 21? Vagy: inkább fel kellene bontani?

Ha valaki azt mondja egy feladatra, hogy „21 pont", az általában azt jelenti: bontsuk kisebb darabokra.

Planning poker – hogyan működik a becslés a csapatban?

A planning poker egy módszer, ahol a csapat tagjai egyszerre mutatják meg a becsléssel kapcsolatos kártyájukat. Ez azért fontos, mert ha egymás után mondanák, az első ember véleménye befolyásolna mindenkit mást.

A folyamat:

A PM/teamlead elmagyarázza a ticketet.
Mindenki gondolkodik, majd egyszerre mutatja a kártyáját (vagy digitális eszközben kattint).
Ha mindenki ugyanazt mondta: elfogadják.
Ha eltérések vannak (pl. valaki 3-t, valaki 13-t mondott): a két végletet megmagyarázzák, újra szavaznak.
Konszenzus → becslés rögzítve.

A divergáló becslések mögött mindig valami lényeges húzódik: az egyik ember tud valamit, amit a másik nem. Ez a legértékesebb rész a folyamatban.

Mit teszel, ha junior vagy és fogalmad sincs?

Ez normális, és nem kell titkolni. Két jó stratégia:

1. Kérdezz megértési kérdéseket a becslés előtt:
„Van valamilyen elfogadási kritériuma?" / „Érinti ez az auth modult is?" / „Van ehhez tesztünk írva?"
Ezek nem gyengeséget mutatnak – épp ellenkezőleg, ezek azok a kérdések, amik a becslést megalapozottabbá teszik.

2. Hasonlítsd korábbi jegyekhez:
„Mennyivel nagyobb ez, mint az X feladat, amit legutóbb csináltunk?" Ez a relatív gondolkodás az, amire a rendszer épül.

Ne félj tőle, hogy eltérsz a többiektől. Ha mindenki 3-at mond és te 8-at, az értékes – látod valamit, amit mások nem.

Mi történik, ha alulbecsülted?

Ez nem kivétel, hanem szabály – különösen kezdetben. Az a fontos, hogy korán jelezd, ne a sprint végén.

Az ideális kommunikáció:

Amint kiderül, hogy a feladat nagyobb: szólj a teamleadnek.
Ne várj a standudig, ha már biztosan tudod.
Konkrét okot adj: „Kiderült, hogy az auth réteget is módosítani kell, amit nem számítottam bele."
Javaslj megoldást: „Meg tudom csinálni az A részt sprintre, a B rész csúszik a következőre."

Az, hogy csúszasz, mindig elfogadhatóbb, mint az, hogy csendben maradtál és az utolsó pillanatban derul ki. A csapat tud kezelni egy setbacket – nem tud kezelni meglepetéseket.

Időbecslés vs. story point – mikor melyik?

Nem minden csapat használ story pointot. Néhány csapat egyszerű óra- vagy napbecslésekkel dolgozik, különösen kisebb helyeken. Ez is működőképes, ha következetes.

Amit tudnod kell:

Story point = relatív komplexitás, velocity-alapú tervezés, agile sprint kontextus.
Órabecslés = konkrét idő, egyszerűbb, de hajlamosabb a túloptimizmusra és a nyomásra.
A lényeg nem a módszer, hanem a kommunikáció: mindenki értse ugyanazt, és a csúszások időben derüljenek ki.

Életszerű példák

Példa 1: Az első sprint tervezés

Anna junior fejlesztő, első sprintje. A teamlead felolvassa a ticketet: „Implement email notification when user completes registration."

A csapat kártyákat mutat. Három senior 3-at mond. A tech lead szintén 3-at. Anna 8-at.

Mindenki Annára néz. Anna elmondja: „Nem tudom pontosan, hogyan néz ki az e-mail küldés infrastruktúrája, van-e már SMTP konfiguráció, és hogyan működik a notifik rendszerünk általában."

A tech lead azt mondja: „Jó pont, valóban van egy bonyolultabb template rendszerünk. Legyen 5."

Anna nem volt rossz – épp ellenkezőleg, értékes kérdéseket tett fel.

Példa 2: Alulbecslés, de jó reakció

Péter 3 pontos feladatot vállalt: „Fix the broken pagination on the user list page."

Kedden kiderül, hogy a pagination bug összefügg egy régebbi adatbázis-lekérdezési problémával, aminek a javítása önmagában 2 nap. Az eredeti hiba fixen felül egy N+1 query-t is ki kellene javítani, különben production-ban 10.000 user esetén le fog lassulni.

Péter szerdai standupján szól: „A pagination-bugnál kiderült, hogy egy mélyebb DB-probléma van mögötte, amire nem számítottam. A frontend fix megvan, de a backend része legalább még 2 napot vesz igénybe. Javaslom, hogy a DB-fix külön ticketre kerüljön, és azt a következő sprintre tegyük."

A teamlead: „Oké, split ki a ticketet." Senki sem haragszik Péterre.

Példa 3: A nem kommunikált csúszás

Gábor 5 pontos feladatot vállalt. Szerdán rájön, hogy nem fog menni sprintre. Nem szól. Csütörtökön sem szól. Sprint review-n a feladat „In Progress" státuszban van, és Gábor azt mondja: „Sajnos nem lett kész."

A teamlead és a PM most már nem tud tervezni. A sprint demo-n emiatt lyuk lesz. Más feladatokat esetleg blokkol ez a hiányzó funkció.

Ez az, amit el kell kerülni – nem a csúszást magát, hanem a késői kommunikációt.

Tesztfeladatok

1. feladat – Fogalomértés

Egy csapatban az „A feladat" 2 story point, a „B feladat" 5 story point. Mit jelent ez biztosan, és mit NEM jelent?

a) B feladat elvégzéséhez 2,5× annyi idő kell, mint A-hoz.
b) B feladat komplexebb és több erőfeszítést igényel, mint A.
c) B feladatot csak senior fejlesztő végezheti el.
d) A csapat velocity-ja alapján megbecsülhető, mikor készül el B.

(Helyes válaszok: b és d. Az a) és c) nem következik a story point definíciójából.)

2. feladat – Becslési szituáció

Planning poker során te 8-at mondasz, mindenki más 3-at mond. Mi a helyes következő lépés?

a) Visszaveszed a becslésed és te is 3-at mondasz, hogy ne lassítsd a folyamatot.
b) Elmagyarázod, miért gondolod, hogy 8 – mi az, amit mások esetleg nem vesznek figyelembe.
c) Elfogadod a 3-at, de kommentben jelzed, hogy szerinted alulbecsülték.
d) Ragaszkodsz a 8-hoz, mert a tiéd az egyedi vélemény.

(Helyes válasz: b. A divergencia értékes – okát meg kell vizsgálni, nem eltitkolni.)

3. feladat – Skálaértés

Miért használ a legtöbb csapat Fibonacci-skálát (1, 2, 3, 5, 8, 13) a lineáris helyett?

a) Mert a Fibonacci-sorozatot könnyebb megjegyezni.
b) Mert a nagyobb feladatoknál a bizonytalanság is nő, ezért a pontos különbségtétel kevésbé releváns.
c) Mert így ritkábban kell vitatkozni a becslésekről.
d) Mert minden agile framework kötelezővé teszi.

(Helyes válasz: b.)

4. feladat – Csúszás kommunikáció

Hétfőn 3 pontos feladatot vállaltál, ami szerdán elvileg kész kellene legyen. Kedden kiderül, hogy még legalább 3 napod kell rá. Mit teszel?

a) Gyorsabban dolgozol, hogy mégis szerdára kész legyen.
b) Szerdán a standupban szólsz, hogy csúszni fog.
c) Amint kiderül (kedden), szólsz a teamleadnek, okkal és javasolt megoldással.
d) A sprint végén a retrospektívan hozod szóba.

(Helyes válasz: c. Minél korábban kerül napvilágra, annál jobban tud a csapat alkalmazkodni.)

5. feladat – Story point vs. óra

A teamlead megkérdezi: „Mennyit becsülsz erre a feladatra?" Te azt feleled: „Kb. 4 óra." Milyen problémája lehet ennek a válasznak, ha a csapat story pointban dolgozik?

(Szabad szöveges válasz. Elvárható tartalom: Az órabecslés konkrét időt sugall, amit a csapat velocity-számítása nem tud felhasználni. A story point relatív komplexitást mér, nem időt. Ráadásul az „4 óra" kötelezettségvállalásként értékelhető, ami nyomást kelt és elszámoltathatóvá tesz egy bizonytalan becslést.)

6. feladat – Szituációs döntés

Az alábbi szituációk közül melyik az ideális pillanat arra, hogy szólj a teamleadnek a feladatod csúszásáról?

a) A sprint végén, a demo előtt 1 nappal.
b) A retrospektívan.
c) Amint egyértelművé válik, hogy a feladat nagyobb, mint becsülted.
d) Csak akkor, ha a teamlead megkérdezi a standupon.

(Helyes válasz: c.)

7. feladat – Fogalom párosítás

Párosítsd a fogalmakat a definíciókkal!

Fogalom	Definíció
Story point	A csapat által elvégzett pontok átlaga sprintenként
Velocity	Szimultán kártyás becslési technika
Planning poker	Relatív komplexitási mértékegység
Fibonacci-skála	Nemlineáris pontskála, a növekvő bizonytalanság miatt

(Helyes párosítás: Story point → Relatív komplexitási mértékegység; Velocity → Átlagos elvégzett pontok sprintenként; Planning poker → Szimultán kártyás becslési technika; Fibonacci-skála → Nemlineáris pontskála)

8. feladat – Kritikus gondolkodás

Egy csapatban mindig pontosan annyi pontot végeznek el, amennyit sprintre vállaltak. Ez jó jel?

a) Igen, ez azt mutatja, hogy a csapat jól becsli a feladatokat.
b) Nem feltétlenül – lehetséges, hogy a csapat szándékosan keveset vállal, hogy biztonságban legyen.
c) Nem, mert a velocity mindig változó kellene legyen.
d) Igen, ez a scrum ideális működése.

(Helyes válasz: b. A túl „tökéletes" teljesítmény gyanús lehet – érdemes megnézni, hogy a vállalt mennyiség valóban ambiciózus-e.)