Sprinttervezés: Hogyan vezessünk olyan megbeszélést, amely túlél egy sprintet?

Van oka annak, hogy az időjárás-előrejelzések 70%-os eső valószínűséget jeleznek, ahelyett, hogy azt ígérnék, hogy pontosan délután 3 órakor esni fog. A rendelkezésre álló információkat használják fel, figyelembe veszik a bizonytalanságot, és frissítik az előrejelzést, amint új adatok érkeznek. Még így is beoszthatod a délutánodat az előrejelzés alapján, feltéve, hogy nem téveszted össze az előrejelzést egy garanciával.

A sprinttervezés hasonló elven működik. A Scrum-csapatnak van egy termékbacklogja, a rendelkezésre álló kapacitás becslése és egy elérni kívánt célja. De egyes feladatok részletei csak a sprint előrehaladtával válnak világossá. Ha minden órára előre megtervezünk mindent, alig marad hely ezeknek a felfedezéseknek, míg ha közös irányvonal nélkül vágunk bele, nehezebb eldönteni, mire érdemes figyelmet fordítani.

A cél az, hogy megegyezzenek egy értékes eredményről, és előre megbecsüljék, mennyi munkát tud a csapat elvégezni annak elérése érdekében. Ebből kiindulva a csapat a sprint célját szem előtt tartva módosíthatja a tervét, ahogy egyre többet tanul.

Ez az útmutató kitér a backlog előkészítésére, az időbeosztásos tervezési napirendre, a gyakorlati kapacitásszámításokra, valamint egy kidolgozott példára, amely bemutatja, hogyan lehet a tervet a sprint során módosítani.

Mi az a sprinttervezés?

A sprinttervezés egy Scrum-esemény, amelyet minden sprint elején tartanak, hogy megegyezzenek abban, mit szeretne elérni a csapat, és hogyan fogja megközelíteni a munkát. Ez az esemény összehozza az egész Scrum-csapatot, beleértve a termékfelelőst, a Scrum-mestert és a fejlesztőket. Más szakemberek, például biztonsági mérnökök vagy ügyfélkapcsolati vezetők is csatlakozhatnak, ha véleményük segíti a csapatot a megalapozott döntések meghozatalában.

A Scrum Guide szerint minden tervezési ülésnek három eredményt kell hoznia: egy sprintcélt, amely megmagyarázza a munka értékét, a célt támogató termékbacklog-elemek kiválasztását, valamint azok megvalósítására vonatkozó kezdeti tervet. Ezek együtt alkotják a sprintbacklogot, amelyet a fejlesztők a sprint előrehaladtával folyamatosan frissítenek.

A Scrum Guide egy hónapos sprint esetén legfeljebb nyolc órát határoz meg, rövidebb sprinteknél pedig általában ennél kevesebb időre van szükség. Jól kidolgozott backlog esetén az alábbi napirend két órába is belefér.

Ha ezek közül néhány kifejezés nem ismerős Önnek, szótárunkban megtalálja az agilis módszertan és a Scrum alapjait.

A három kérdés, amelyre a sprinttervezés választ ad

Minden sprinttervezési ülés három kérdés köré épül:

A Scrum Guide ezekre a kérdésekre építi a tervezést, kezdve azzal az értékkel, amelyet át szeretnél adni. Ha ez mindenki számára egyértelmű, könnyebb eldönteni, mely backlog-elemek érdemelnek figyelmet, és mennyi munkát tud a csapatod ésszerűen vállalni.

Miért fontos a sprint?

A sprintcél irányt mutat a csapatnak, és segít az érdekelt feleknek megérteni, mire számíthatnak. Egyezz meg ebben a célban a Scrum-csapatoddal, mielőtt a tervezési ülés véget ér.

Írjon le olyan eredményt, amelyet az emberek felismerhetnek, például: „A próbaidőszakban lévő felhasználók meghívhatják csapattársaikat”, ahelyett, hogy munkaterhelési célt tűzne ki, mint például: „34 sztoripont befejezése”. Ha váratlan probléma merül fel, a cél segít a csapatnak eldönteni, mely feladatokat kell módosítani úgy, hogy a tervezett eredmény megmaradjon.

Mit tud a csapat befejezni ebben a sprintben

Miután megegyeztetek a célban, itt az ideje kitalálni, hogy a csapat reálisan mit tud teljesíteni.

A fejlesztők a termékfelelőssel folytatott megbeszélés során választják ki a backlog-elemeket, figyelembe véve a rendelkezésre álló kapacitást, a korábbi teljesítményt és a „kész” definícióját. Ez egyben a megfelelő alkalom arra is, hogy áttekintsék az esetleges meglévő kötelezettségvállalásokat, amelyek befolyásolhatják, mennyi idő áll a csapat rendelkezésére a sprint munkájára.

Sok csapat használja a sztoripontokat a backlog-elemek relatív erőfeszítésének és összetettségének összehasonlítására. A Fibonacci-skála segíthet ezeknek a megbeszéléseknek a strukturálásában, különösen akkor, ha a szükséges erőfeszítés nem egyértelmű.

Hogyan fogja a csapat elvégezni a munkát?

A kiválasztott backlog-elemek alapján a fejlesztők kidolgozzák, hogyan alakítják azokat olyan késztermék-inkrementummá, amely megfelel a „Kész” definíciónak. A Scrum-útmutató azt javasolja, hogy a nagyobb elemeket kisebb munkadarabokra bontsák, amelyek mérete gyakran egy napot vagy annál rövidebb időt vesz igénybe.

Ez nem jelenti azt, hogy a sprint minden óráját pontosan le kell tervezni. Az első néhány napra részletesebb tervre lehet szükség, míg a későbbi feladatok nyitottak maradhatnak a módosításra, ahogy új részletek derülnek ki. Ha a korai becsléseket szilárd kötelezettségvállalásként kezeljük, az nyomást gyakorolhat a csapatra, hogy teljesítse az eredeti számokat, még akkor is, ha a feladat körét a folyamat közben módosítják.

Ahogy Dave West, a Scrum.org vezérigazgatója elmagyarázza:

Az egy határidő védelmére használt előrejelzés pontosan olyan viselkedést vált ki, amely aláássa a bizalmat, például a becslések felfelé kerekítését, a kockázatok elrejtését vagy a „kész” fogalmának csendes újradefiniálását a szám elérése érdekében.

Mi a különbség a sprinttervezés és a backlog-finomítás között?

A backlog finomítása segítségével a csapatod tisztább képet kap a közelgő feladatokról, még mielőtt eldöntenétek, mi kerüljön be a következő sprintbe. A sprinttervezés erre az előkészítésre épít, hogy megegyezzetek a célban, kiválasszátok a backlog-elemeket, és kidolgozzátok a kezdeti megvalósítási tervet.

A két tevékenység különböző célokat szolgál a Scrum keretein belül:

Gondoskodjon arról, hogy a közelgő backlog-elemek közül elegendő mennyiséget finomítson ki, hogy a csapatnak egyértelmű választási lehetőségei legyenek a sprinttervezés során. Az előkészítés mértéke attól függ, milyen gyorsan változnak a prioritások és mennyi bizonytalanság marad fenn. A backlogban hátrébb álló elemek kevésbé részletesek maradhatnak, amíg közelebb nem kerülnek a kiválasztáshoz.

Hogyan készüljünk fel a sprinttervezésre?

Néhány nappal előtte ellenőrizze, hogy a backlog rendben van-e, és mindenkinek megvan-e a döntéshozatalhoz szükséges információ. Így a megbeszélés során arra koncentrálhatnak, hogy mit kell megvalósítani és hogyan kell hozzáállni, anélkül, hogy minden követelményt a nulláról kellene megoldani.

Íme egy ellenőrzőlista, amelyet érdemes átnéznie a következő sprintje előtt:

Ha a sprint retrospektívát és a tervezési ülést egymáshoz közel ütemezi, hagyjon elegendő időt mindkét eseményen a megfelelő megbeszélésre. A retrospektíva eredményeinek be kell épülniük a következő sprint tervébe, ezért ügyeljen arra, hogy egyik ülés se legyen siettetett.

Sprinttervezési napirend: Időbeosztásos példa egy kéthetes sprintra

Két hetes sprint esetén kezdjen egy kétórás tervezési üléssel, különösen akkor, ha a backlogot már finomították. Számoljon be plusz időt, ha a feladatok összetett függőségeket tartalmaznak, vagy több olyan döntést igényelnek, amelyek megbeszélést igényelnek.

Ezt a minta napirendet a csapatod igényeihez igazíthatod.

A lezárás előtt végezhet egy gyors bizalomellenőrzést, például a Fist of Five módszerrel, amelynek során mindenki 0 és 5 ujj között értékeli, mennyire bízik a tervben. Ha valaki alacsony pontszámot ad, kérdezze meg, mi okozza az aggodalmat. Ez feltárhat egy megoldatlan függőséget, egy túl ambiciózus előrejelzést vagy egy olyan követelményt, amelyet alaposabban meg kell vitatni.

A cél az, hogy a tervet még módosítani lehessen, mielőtt a határidő lejárna.

Hogyan vezessünk sprinttervezést 6 lépésben

Miután előkészítette a backlogot és megerősítette a résztvevők névsorát, kezdje meg a tervezési ülést. A cél az, hogy segítse a csapatot abban, hogy prioritásait és rendelkezésre álló kapacitását olyan tervvé alakítsa, amelynek megvalósításában biztosnak érzi magát.

1. lépés: Tekintsük át az eddigi munkát, és állapodjunk meg a sprint céljában

Kezdje azzal, hogy röviden áttekinti, mi készült el, mi maradt befejezetlen, és hogy van-e olyan retrospektív intézkedés, amely befolyásolhatja a következő sprintet. Inkább azokra a dolgokra koncentráljon, amelyek megváltoztathatják a csapat prioritásait vagy megközelítését, ahelyett, hogy újra átvenné az egész sprint-áttekintést.

Ezután kérje meg a termékfelelőst, hogy mutassa be a javasolt sprintcélt, és magyarázza el, hogyan támogatja az a tágabb értelemben vett termékcélt. Adjon lehetőséget a fejlesztőknek, hogy kérdéseket tegyenek fel a sprint hatókörével kapcsolatban, felhívják a figyelmet a függőségekre, és módosításokat javasoljanak.

Például, ha a cél az, hogy az ügyfelek az értékesítési csapattal való kapcsolatfelvétel nélkül is végrehajthassák a fizetést, állapodjanak meg abban, hogy mi számít sikeres fizetésnek. Magában foglalja-e a fizetés visszaigazolását és a hibakezelést? Elengedhetetlen-e az automatikus nyugta-küldés az első kiadáshoz?

Ezek a megbeszélések segítenek meghatározni azt az eredményt, amelyre a csapat törekedhet. A megfogalmazás változhat a backlog-elemek kiválasztásával, de a tervezés befejezése előtt mindenkinek egyet kell értenie a végső célban.

2. lépés: Számítsa ki a csapat rendelkezésre álló kapacitását

A feladatok kiválasztása előtt állapítsa meg, hogy a fejlesztői reálisan mennyi időt tudnak a sprintre fordítani.

Kezdje a munkanapok számával és az egyes személyek várható rendelkezésre állásával. Ezután vegye figyelembe a tervezett szabadságokat, a Scrum-eseményeket, a támogatási feladatokat és az egyéb ismert kötelezettségeket. Ha egy fejlesztő a hét felét termelési problémák kezelésével tölti, azok az órák már lekötöttek, és nem állnak rendelkezésre a tervezett sprintmunkához.

Egy egyszerű számítás: Rendelkezésre álló kapacitás = Összes munkaidő − Ismert kötelezettségek

Például egy fejlesztőnek, akinek két héten át 80 munkaórája van, lehet 8 órája szabadsága, 10 órája megbeszélései és 12 órája támogatási feladatai. Ezzel 50 óra marad, mielőtt bármilyen további bizonytalansági tényezőt figyelembe vennénk.

Hasonlítsa össze ezt az ábrát a csapat korábbi teljesítményével. A sebesség azt mutatja, hogy a csapat mennyi munkát végzett el a korábbi sprintekben, míg a kapacitás a jelenlegi sprintre rendelkezésre álló időt tükrözi.

3. lépés: Az előző sprintből megmaradt feladatok újbóli értékelése

A befejezetlen backlog-elemeket érdemes újra átnézni, mielőtt hozzáadná őket az új sprinthez. Lehet, hogy egy két héttel ezelőtt még fontosnak tűnő elem prioritása megváltozott, vagy a csapat olyan információkhoz jutott, amelyek befolyásolják a hátralévő munka mennyiségét.

Tekintse át az egyes pontokat a termékfelelőssel, és vegye figyelembe a következőket:

Azoknál a feladatoknál, amelyek még a sprintbe tartoznak, a fennmaradó erőfeszítés alapján becsülje meg, mennyi kapacitásra lesz szükség. Egy félig befejezett feladat esetleg kevesebb munkát igényel, mint az eredeti becslés, de addig befejezetlennek számít, amíg nem felel meg a „Kész” definíciónak.

4. lépés: Válassza ki azokat a backlog-elemeket, amelyek támogatják a célt

Miután tisztában vannak a kapacitással és a fennálló feladatokkal, a fejlesztők kiválaszthatják azokat a termék-backlog-elemeket, amelyeket szerintük képesek lesznek befejezni.

Kezdje azokkal a feladatokkal, amelyek közvetlenül támogatják a sprint célját. Beszéljék meg azok elfogadási kritériumait, a technikai függőségeket és minden olyan bizonytalanságot, amely befolyásolhatja a megvalósítást. Ha egy feladat túl nagy vagy nem elég egyértelmű, fontolja meg annak kisebb részekre bontását, amelyek a sprint során értéket tudnak teremteni.

Lehet, hogy van helye karbantartási feladatoknak vagy más termékprioritásoknak is, de ellenőrizze, hogy az ilyen feladatok vállalása nem veszélyezteti-e a fő célt.

Mennyi kapacitást érdemes fenntartani?

A rendelkezésre álló kapacitás csupán 80%-ának tervezése ésszerű kiindulási pont lehet azoknak a csapatoknak, amelyek rendszeresen váratlan támogatási feladatokkal foglalkoznak, de a Scrum nem ír elő rögzített százalékot.

Ha a csapatod gyakori megszakításokat tapasztalt, a kiigazított kapacitás 10–20%-át fenntarthatod tartaléknak, és összehasonlíthatod ezt a tartalékot a korábbi sprintek során felmerült igényekkel. Egy stabil munkaterheléssel és kevés megszakítással rendelkező csapatnak kevesebb tartalékra lehet szüksége. Egy olyan csapatnak viszont, amely gyakori incidensekkel járó élő szolgáltatást támogat, több tartalékra lehet szüksége.

Kerülje el, hogy ugyanazt a kötelezettségvállalást kétszer számolja be. Ha a 2. lépésben már levonták a beütemezett támogatási órákat, a további tartaléknak az ismert munkaterhelésen túli bizonytalanságot kell fedeznie. Az így kapott kapacitást használja iránymutatásként a megbeszéléshez, ne pedig elérendő célként.

5. lépés: A feladatok lebontása és a függőségek ellenőrzése

Miután kiválasztotta a backlog-elemeket, a fejlesztők kidolgozhatják, hogyan fogják azokat megvalósítani. Ez magában foglalhatja a nagyobb elemek felosztását fejlesztési, tesztelési, integrációs és felülvizsgálati feladatokra.

Figyelmesen vizsgálja meg a feladatok sorrendjét. Ha a fizetési felület egy fizetési szolgáltató integrációjától függ, a csapatnak tisztában kell lennie azzal, hogy mikor kell ennek az integrációnak készen állnia. Ha egy másik csapatnak jóvá kell hagynia egy biztonsági változtatást, tisztázza, hogyan és mikor fog ez a döntés megszületni.

A közvetlenül esedékes munkát tervezze meg részletesebben, a későbbi feladatokat pedig hagyja nyitva további megbeszélésre. A Scrum Guide azt javasolja, hogy a kiválasztott feladatokat bontsák kisebb, általában egy napos vagy annál rövidebb munkatételekre, de a fejlesztők döntik el, hogyan szervezik és osztják el a munkát.

Ellenőrizze, hogy a terv figyelembe veszi-e a „Kész” definícióját, beleértve a szükséges tesztelési és integrációs feladatokat is. Ha valamely függőség megakadályozhatja a megvalósítást, vizsgálja felül a kiválasztott elemeket, vagy módosítsa a megvalósítási megközelítést, mielőtt véglegesítené a tervet.

6. lépés: A sprint-backlog véglegesítése és megosztása

Jegyezze fel a sprint célját, a kiválasztott termék-backlog elemeket és a kezdeti megvalósítási tervet olyan helyre, ahol a csapat hozzáférhet és frissítheti azokat. Ezek együttesen világossá teszik, mit kíván elérni a csapat, és mely feladatokra kell legközelebb figyelmet fordítani.

Az értekezlet lezárása előtt győződjön meg arról, hogy mindenki egyetért a céllal, és adjon lehetőséget mindenkinek, hogy felvetse az előrejelzéssel kapcsolatos esetleges fennmaradó aggályait. Ha egy fontos függőségi vagy kapacitási kérdés megoldatlan marad, beszéljék meg, mi kell változnia, mielőtt a csapat megkezdi a munkát.

A sprint során a napi scrum lehetőséget ad a fejlesztőknek, hogy ellenőrizzék a cél felé tett előrehaladást, és módosítsák a sprint-backlogot. A burndown- vagy burnup-diagram segíthet bemutatni az előrehaladás változásait, míg az alapul szolgáló feladatok részletes képet nyújtanak. Ha új információk befolyásolják a kiválasztott hatókört, a fejlesztők megbeszélhetik a módosításokat a termékfelelőssel anélkül, hogy a sprint célját veszélyeztetnék.

Sprinttervezési példa: egy 6 fejlesztőből álló csapat

Nézzük meg, hogyan működnek ezek a döntések a gyakorlatban.

Képzelje el, hogy egy kéthetes sprintet tervez egy B2B számlázási termékhez. A csapatában hat fejlesztő dolgozik, és a javasolt sprintcél a következő: „Az új ügyfelek a pénztárnál kártyával fizethetnek anélkül, hogy kapcsolatba lépnének az értékesítési csapattal.”

A backlog-elemek kiválasztása előtt tudnia kell, mennyi idő áll a csapat rendelkezésére. Ebben a példában tételezzük fel, hogy minden fejlesztőnek naponta hat órája van a projektre való koncentrált munkára, a tervezett Scrum-események és egyéb kötelezettségek levonása előtt.

Így működik a kapacitásszámítás 10 munkanapra vonatkozóan:

Miután egy példakénti 20%-os tartalékot különítettél el, most 216 órád van a tervezett munkára. A gyakorlatban ezt a tartalékot annak alapján választanád meg, hogy a korábbi sprintek során mennyi nem tervezett munka szakította meg a munkát.

Válassza ki azokat a feladatokat, amelyek támogatják a sprint célját

A kapacitás megállapítása után a fejlesztők a termékfelelőssel együtt áttekintik a kijelentkezéssel kapcsolatos backlog-elemeket.

Íme egy szemléltető példa, amely a kezdeti, feladat szintű erőfeszítés-becsléseken alapul:

Ezek a becslések 6 órás tartalékot hagynak a tervezett munkamennyiség keretén belül, plusz az 54 órás tartalékot a váratlan feladatokra. A csapat emellett egy jelentési irányítópult fejlesztését is felvette a termék-visszamaradékba. Bár ez értékes feladat, közvetlenül nem járul hozzá a „checkout” cél eléréséhez. A termékfelelős és a fejlesztők úgy döntenek, hogy ezt egy jövőbeli sprintre hagyják.

Ha valami megváltozik, módosítsa a tervet!

A hatodik napon a fizetési szolgáltató bevezet egy API-módosítást, amely az integráció egy részét megszakítja. A fejlesztők kivizsgálják a problémát, és felmérik a szükséges többletmunkát.

Ahelyett, hogy az eredeti feladatsorrend szerint haladnának tovább, megbeszélik a hatásokat a termékfelelőssel. Ha a javítás belefér a fennmaradó kapacitásba, akkor prioritást adhatnak neki, és elhalaszthatják az opcionális átvételi stílus kialakítását vagy egy másik, alacsonyabb prioritású feladatot. A fizetési visszaigazolásnak és más alapvető feladatoknak továbbra is meg kell felelniük a „Kész” definíciónak.

Ha a javítás a vártnál nagyobb mértékű, akkor újra kell értékelniük a fennmaradó munkaterületet, és azt, hogy a sprintcél még mindig elérhető-e.

Előfordulhat, hogy a csapat a vártnál kevesebb backlog-elemet fejez be. Ha azonban az ügyfelek a tervezett módon tudják végrehajtani a fizetést, és a munka megfelel a „kész” definíciónak, akkor a sprint célja teljesült.

Sprint-célpéldák más csapatok számára

Ugyanezt a tervezési megközelítést alkalmazhatja a szoftverfejlesztésen kívüli feladatokra is, bár maga a Scrum egy specifikus keretrendszer, meghatározott felelősségi körökkel és eseményekkel.

Például egy marketingcsapat olyan célt tűzhet ki, mint „A webinárium céloldalának közzététele, valamint a látogatók számára a manuális segítség nélküli regisztráció lehetővé tétele”. Egy operációs csapat célja pedig az lehet, hogy „Biztosítsa, hogy a következő beillesztési csoport minden alkalmazottja rendelkezzen az első napján szükséges felszereléssel és rendszerhozzáféréssel”.

Mindkét cél olyan eredményeket ír le, amelyek a sprint során irányt mutathatnak a csapat döntéseinek. A backlog-elemek és a megvalósítási tervek eltérőek lesznek, de a csapatnak mindenképpen figyelembe kell vennie kapacitását, és meg kell állapodnia abban, hogy mit jelent a sikeres megvalósítás.

Gyakori hibák a sprinttervezés során és azok kijavítása

A sprinttervezés során problémák merülhetnek fel, ha a csapatok a story pointokat az egyéni teljesítmény értékelésére használják, nem egyértelmű backlog-elemeket hoznak be az értekezletre, túl mereven osztják el a feladatokat, vagy figyelmen kívül hagyják a tesztelési követelményeket és a külső függőségeket.

Néhány apró módosítás segíthet abban, hogy ezeket a problémákat még mielőtt hatással lennének a megvalósításra, időben észrevegye.

Ha ugyanazok a problémák több sprint során is felmerülnek, vegye fel őket a sprint-visszatekintés napirendjébe, és állapodjanak meg egy olyan változtatásban, amelyet a következő sprint során kipróbálhatnak. Ezek a sprint-visszatekintési sablonok segíthetnek a megfigyelések rögzítésében és a szükséges intézkedések meghozatalában.

A sprint végén a sprint-áttekintő megbeszélés keretében vizsgálja át az érdekelt felekkel a befejezett inkrementumot, és beszéljék meg, mivel foglalkozzon a csapat legközelebb.

Hogyan vezessünk sprinttervezést a ClickUp-ban

A sprinttervezés több erőfeszítést igényel, ha a feladatok, a kapacitásbecslések és a tervezési döntések különböző eszközök között vannak szétszórva. A ClickUp összefogja ezeket az információkat, így a csapat áttekintheti a munkát a kapacitás mellett, és felülvizsgálhatja a tervezési döntéseket, ha a terv változik.

Kezdje a ClickUp agilis sprinttervezési sablonjával! A backlog-, fejlesztési állapot- és erőforrás-nézetek segítségével áttekintheti a közelgő feladatokat, és felkészülhet a tervezési megbeszélésre.

Szerezzen be egy ingyenes sablont

Így hozhatja meg a legfontosabb döntéseket:

A következő tervezési ülés előtt kérdezze meg a Brain²-t: „Milyen megoldatlan függőségek merültek fel a legutóbbi sprinttervezési ülésen?” A Brain képes összefüggéseket kiolvasni a rögzített ülésjegyzetekből. Hasonlítsa össze ezeket a részleteket a jelenlegi feladatokkal, mielőtt felhasználná őket a következő előrejelzéshez.

A ClickUp árai

Mennyit érdemes megtervezni a sprint kezdete előtt?

A sprinttervezési ülésnek olyan egyértelműséget kell biztosítania a csapat számára, hogy megkezdhessék a munkát.

A fenti, időbeosztással ellátott napirend és kapacitási példa kiindulási pontként szolgál. Igazítsa őket a csapat munkaterheléséhez, majd hasonlítsa össze az előrejelzést a befejezett munkával és a közbejött eseményekkel, hogy a következő tervet továbbfejlessze.

A ClickUpban a tervezési jegyzeteket összekapcsolhatod a sprintfeladatokkal, és a munka változásainak megfelelően frissítheted a sprint-backlogot. A csapat a megállapodott tervre hivatkozhat, amikor eldönti, mit kell módosítani.

Gyakran feltett kérdések a sprinttervezésről

Mi a különbség a sprinttervezés és a kiadástervezés között?

A sprinttervezés arra összpontosít, hogy a csapat mit kíván elérni egy sprint alatt, és hogyan fogja azt megvalósítani. A kiadástervezés hosszabb távlatokat vesz figyelembe, például azt, hogy mely funkciók válhatnak elérhetővé több sprint alatt, és mikor kaphatják meg azokat a felhasználók. A kiadási előrejelzések változhatnak, ahogy a csapatok egyre többet tudnak meg, míg az egyes sprintcélok az adott sprint keretein belül irányítják a munkát.

Szüksége van egy „kész állapot” definícióra a sprinttervezéshez?

Nem. A Scrum nem követeli meg a „kész állapot” formális meghatározását. Egyes csapatok használnak ilyet a backlog-elemek kiválasztása előtti közös elvárások meghatározására, például egyértelmű követelmények, kezelhető hatókör és ismert függőségek formájában. Ezeket a kritériumokat tartsa elég rugalmasnak ahhoz, hogy támogassák a megbeszélést, anélkül, hogy megakadályoznák a csapatot abban, hogy szükség esetén finomítsa az elemeket.

Lemondható-e egy sprint a tervezés után?

Igen. Csak a termékfelelős törölheti a sprintet, és a törlés akkor jöhet szóba, ha a sprint célja elavulttá válik, például azért, mert az üzleti prioritások vagy a piaci körülmények jelentősen megváltoztak. Egy nehéz feladat vagy egy pontatlan becslés önmagában nem feltétlenül indokolja a törlést.

Mi a különbség a sprint és az agilis módszer között?

Az agilis módszertan az Agilis Nyilatkozat értékeire és elveire épülő, tágabb értelemben vett munkaszervezési megközelítés. A sprint a Scrum keretrendszerben egy hónapos vagy annál rövidebb, rögzített időtartam, amely alatt a csapat a sprint céljának elérésén dolgozik, és használható inkrementumot hoz létre. Az agilis elveket sprintek használata nélkül is követhetjük. A Kanban például támogatja a munka folyamatos áramlását anélkül, hogy rögzített hosszúságú iterációkra lenne szükség.

Lehet-e egy sprintnek több sprintcélja?

A Scrum a sprint egyetlen célját határozza meg. Kiválaszthat olyan backlog-elemeket, amelyek más prioritásokat támogatnak, feltéve, hogy azok nem veszélyeztetik ezt a célt. Ha a csapatának rendszeresen több, egymástól független célra van szüksége, a tervezés előtt beszéljék meg, hogy a munka egy szélesebb körű, közös eredményt támogat-e, vagy előbb meg kell-e oldaniuk az egymással versengő prioritásokat.

A sprinttervezés során a hibákat is story pointokban kell becsülni?

A sztoripontok a Scrum-ban opcionálisak, a hibákra is. Azok a csapatok, amelyek becsülik a hibákat, meg kell állapodjanak abban, hogy mikor és miért teszik ezt. Az ismert hibákat a tervezés során lehet értékelni, míg a fejlesztés során felfedezett hibák a „Kész” definíciójának teljesítéséhez már szükséges munkakörbe tartozhatnak. Kerülje el, hogy ugyanazt a munkát kétszer számolja el.