A mai cikkben a Scrum-ban alkalmazott becslés és történeti pontok témáját tárgyaljuk. A Scrum-ban végzett becslések segítenek előre jelezni a feladatok elvégzéséhez szükséges bonyolultságot és időt. A múlt elemzésével a teljes Scrum Csapat közösen előrejelzi, hogy mit tartogat a jövő.
Ezért minél tapasztaltabb a Scrum Csapat, annál pontosabbak a becsléseik. A csapat a Sprint Tervezés során együttműködik a feladatok elvégzéséhez szükséges becsült idő meghatározásában, figyelembe véve, hogy ez nem végleges kötelezettségvállalás, hanem előrejelzés. Pontossága számos változótól függ, amelyek folyamatosan kiszámíthatatlan változásokon és váratlan körülményeken mennek keresztül. Szerencsére a Scrum módszertan olyan technikákat és eszközöket tartalmaz, amelyek elősegítik a bizonyosság bizonyos fokát, és ma részletesen megvitatjuk őket, hogy megérthesse és azonnal alkalmazhassa őket!
Történeti pontok és becslés a Scrum-ban – tartalomjegyzék:
Bevezetés
Minden Sprint Tervezés során a Termékfelelős új Felhasználói Történeteket mutat be a csapatnak. A Termékfelelős azokat a Termék Hátralékból választja ki a következő Sprintben való megvalósításra. Ezután a Scrum Csapat tagjai közösen becslik a szükséges munkaterhelést ennek az új feladatcsomagnak a teljesítéséhez. Ez a fajta feladat egy becslés, követelmények becslése.
Úgy tűnik, a legegyszerűbb módja a feladat elvégzéséhez szükséges idő órákban vagy napokban történő meghatározása. Azonban a gyakorlat és a 1940-es évek óta végzett kutatások mást bizonyítanak. Az emberek képtelenek pontosan megbecsülni a nagyon jól meghatározott feladatok elvégzéséhez szükséges időt. Ezen kívül a feladat elvégzéséhez szükséges órák száma attól függ, hogy ki végzi a feladatot, és hogy mi történt – vagy nem történt – korábban. Ezért a Scrum jellemzően a történeti pontoknak nevezett egységeket használja.
A történeti pontok fontossága a Scrum-ban
Minden Fejlesztő Csapat a történeti pontok értékét a tapasztalatok és az egyes feladatok méretének figyelembevételével alkalmazza, azaz az empirikus elv követésével. Leggyakrabban a Sprint Tervezés során a Scrum Mester egy vagy több befejezett Felhasználói Történet mintát választ ki, amelyek referenciapontként szolgálnak a fejlesztendő Felhasználói Történetek értékének meghatározásához.
Ezért nem lehet történeti pontokban értékeket rendelni a kontextus nélkül. Például, ha az első feladat értéke 10, a következő feladatokat ehhez viszonyítva értékelik, mint nagyobb vagy kisebb. Ily módon a Scrum Csapat projektjén belül az összes feladat a Termék Hátralékban összefügg egymással. Ez azt jelenti, hogy hasonló feladatokat végző egy Fejlesztő Csapat hasonló számú pontot kap.

A történeti pontok relatív egységek. Ez azt jelenti, hogy:
- A történeti pont értéke csak egy adott Scrum Csapat által végzett feladatokra vonatkozik. A történeti pontok leírják egy csapat feladatainak elvégzésének sebességét. Más szavakkal, egy Felhasználói Történet, amelyet A Csapat 10 történeti pontra becsült, B Csapat által 50 pontot kaphat. Ennek az az oka, hogy, ahogy említettük, értékük relatívan van kiszámítva a csapat által végzett egyéb feladatokhoz és a hasonló feladatokkal kapcsolatos tapasztalataikhoz.
- A történeti pontokban befejezett Sprint értéke nem lehet alapja két Scrum Csapat teljesítményének összehasonlítására. Annak érdekében, hogy elkerüljük a hibákat a Scrum projektek kezelésében, fontos emlékezni arra, hogy a Fejlesztő Csapat sebessége, amelyet a történeti pontokban kifejeznek egy Sprintben, nem használható két Csapat teljesítményének összehasonlítására. Ennek az az oka, hogy párhuzamos Sprintekben végezhetik el ugyanazt a munkát, amelyet az egyik Csapat 10-re, a másik pedig 50 történeti pontra becsült.
Azt sem szabad elfelejteni, hogy a becslés sok ismeretlen elemet tartalmaz és hiányos adatok alapján készül. Ezért még egy nagyon tapasztalt Scrum Csapat előrejelzései is néha nagyon eltérhetnek a Felhasználói Történet teljesítéséhez szükséges valós erőfeszítéstől.
Relatív becslési technikák
Mik a leghatékonyabb becslési technikák a Scrum-ban? Nincs egyetlen, minden csapat számára megfelelő módszer.
A rugalmas módszertanokon belüli becslési technikák közül a leggyakoribbak a következők:
- Tervezési Póker. Ez a legnépszerűbb relatív módszer egy kártyajátékot használ a feladat elvégzéséhez szükséges munka mennyiségének kiszámítására. Részletes szabályait és folyamatát egy külön cikkben tárgyaljuk.
- Csapat Becsülési Játék. Ez a módszer a Felhasználói Történetek végrehajtásának hozzárendelését jelenti egy adott Sprintben, megfelelő numerikus értékek kiválasztásával a Fibonacci sorozatból. Ezt is külön cikkben tárgyaltuk.
A Scrum ezzel szemben elutasítja a klasszikus Abszolút Becsülési módszert a hagyományos projektmenedzsment módszertanban. A feladatok becslésének módja az, hogy előre meghatározzák az ember-hónapokat, a projekt időtartamát és költségét. Ez egy hosszú folyamat, nehezen megvalósítható, és szakértők részvételét igényli, akik hajlamosak megalapozni az indoklást és a magatartási kódexet, de nem tesznek lépéseket azokkal, akik nem feltétlenül végzik el a feladatokat, amelyek értékét megbecsülték. Más szavakkal, ez nemcsak fárasztó, hanem rendkívül hatástalan is.

Történeti pontok és becslés – Összefoglalás
A becslés egy nagyon fontos készség, amely minden érett Scrum Csapatra jellemző. Az egyes feladatok elvégzéséhez szükséges idő és erőfeszítés megbecslése sok relatív becslési technika fő fókuszává vált, mint például a Tervezési Póker vagy a Csapat Becsülési Játék.
A történeti pontokkal rendelkező Felhasználói Történetek egy újabb hatékony mérési technika, amelyet leírtunk, remélhetőleg hasznos eszközöket biztosítva olvasóink számára. Fontos azonban szem előtt tartani, hogy ezek a számok csak a Scrum Csapat által végzett konkrét feladatokra vonatkoznak. Ezért a történeti pontok száma nem válhat alapjául a különböző Fejlesztő Csapatok sebességének összehasonlítására.
Ha tetszik a tartalmunk, csatlakozzon aktív közösségünkhöz a Facebookon, Twitteren, LinkedIn-en, Instagramon, YouTube-on, Pinterest-en.
Caroline Becker
Projektmenedzserként Caroline szakértő az új módszerek megtalálásában, amelyek a legjobb munkafolyamatok megtervezésére és a folyamatok optimalizálására szolgálnak. Szervezési készségei és a nyomás alatt végzett munka iránti képessége teszik őt a legalkalmasabb személyré, aki bonyolult projekteket valóra tud váltani.
Scrum Guide:
- Alapfogalmak, szerepek és fogalmak szótára
- Mi a Scrum?
- Scrum értékek
- Hogyan valósítsuk meg a Scrumot a vállalatunkban?
- Scrum Csapat - mi az és hogyan működik?
- Ki a terméktulajdonos?
- A Product Owner leggyakoribb hibái
- Ki a Scrum Master?
- A Scrum Master leggyakoribb hibái
- Milyen statisztikákat és mutatókat kell nyomon követnie a Scrum Masternek?
- Scrum fejlesztőcsapat
- A fejlesztők leggyakoribb hibái
- Scrum artefaktumok
- Skálázott Scrum
- Sprint Hátralék
- Mi az a termék hátralék?
- Mik azok a felhasználói történetek?
- A legjobb Felhasználói Történet létrehozása az INVEST elv alapján
- A leggyakoribb felhasználói történet hibák
- Felhasználói történet elfogadási kritériumok
- Becslés és Történetpontok a Scrum-ban
- Tervezési Póker
- Csapatbecslési játék
- Növekmény meghatározása
- Scrum események
- Mi az a Burndown Diagram?
- A burndown diagram előnyei és hátrányai
- Kanban táblák a Scrum és Scrumban keretrendszerben
- Sebesség a Scrum-ban - A Fejlesztő Csapat Sebessége
- Napi Scrum
- Sprint tervezés
- Sprint értékelés
- Mi az a Sprint Retrospektív?
- A Sprint Retrospektív során elkövetett gyakori hibák
- Termék Backlog ápolása
- Hogyan kell létrehozni és értelmezni egy burndown diagramot?
- Mi az a Sprint a Scrum-ban?
- A Terméktulajdonos és a Scrum Master közötti együttműködés
- Scrum Csapat Kötelezettségek - Termék Cél, Sprint Cél és Teljesítési Meghatározás
- A jó Scrum Master jellemzői