Sprinttervezési napirendsablon fejlesztőcsapatoknak

Miért terhelődnek túl a sprintek

A sprinttervezésnek van egy strukturális hibája, amelyet a sablonok nem előznek meg: a csapatok kiválasztják a sprint-backlogot, mielőtt bárki ellenőrizné a kapacitást. Az eredmény egy sprint, amely a táblán elérhetőnek tűnt, és szerdára összeomlik, amikor két mérnök a hét felében távol van, egy jegy hatóköre megháromszorozódik, és három tételnek volt egy ki nem mondott függősége egy szolgáltatástól, amelyet a platformcsapat éppen újraír.

A javítás egyszerű, és szinte soha nem történik meg: köteleződj el a kapacitás mellett, mielőtt a munka mellett elköteleződnél. Az alábbi sablon pontosan ezért nyit egy kapacitás-áttekintéssel.

A napirend (másold és illeszd be)

Időtartam: 2 óra egy 2 hetes sprinthez; 1 óra egy 1 hetes sprinthez
Formátum: moderált, a teljes csapat számára látható backloggal

1. szakasz — Sprintcél (10 perc)

Egy mondat: hogyan néz ki kívülről egy sikeres sprint?
A cél legyen elég konkrét ahhoz, hogy bármely csapattag a sprint végén értékelni tudja, elérted-e
Utasítsd el azokat a célokat, amelyek csak jegyek listája („fejezd be az auth-refaktort és a számlázási oldalt”) — ez egy backlog, nem egy cél

2. szakasz — Kapacitás-áttekintés (15 perc)

Sorold fel név szerint minden csapattagot
Mindegyiknél: tervezett szabadság (PTO), ügyeleti rotáció, ismétlődő megbeszélések, ismert külső kötelezettségek
A kapacitást elérhető story pointként vagy napként fejezd ki — ne létszámként
Ez a szám a felső határ; ne válassz több munkát, mint amennyit elbír

3. szakasz — Backlog-kiválasztás (45 perc)

Járd végig a legmagasabb prioritású tételeket a finomított backlogból
Minden jelöltnél: van-e a csapatnak elég ahhoz, hogy elkezdje, vagy vannak nyitott kérdések, amelyekre a sprint kezdete előtt válasz kell? A nyitott kérdések a finomítási sorba tartoznak, nem a sprintbe
Hagyd abba a kiválasztást, amikor eléred a kapacitás 80%-át; a fennmaradó 20% nyeli el a túlcsordulást és a nem tervezett munkát

4. szakasz — Elfogadási kritériumok (20 perc)

Minden kiválasztott tételnél: fogalmazd meg a kritériumot, amely késszé teszi
Ha a csapat 60 másodperc alatt nem tud megfogalmazni egy kritériumot, a jegy nincs eléggé finomítva — tedd vissza a backlogba
Írd bele most a jegybe, a teremben; ne bízz a „majd hozzáadjuk később”-ben

5. szakasz — Kockázatok és függőségek (15 perc)

Mi blokkolhatja a sprintcél teljesítését, amit a csapat nem irányít?
Nevezd meg a függőség felelősét; hozd felszínre most, amíg van idő feloldani a sprint közepe előtt
A megoldatlan függőségek megnevezett felelőst kapnak a csapatból, aki nyomon követi őket

Zárás (15 perc)

Erősítsd meg, hogy a sprintcél a kiválasztott munka fényében még érvényes
Jelöld ki a sprint-összefoglaló jegyzőjét, vagy erősítsd meg az automatizált jelentés beállítását
Erősítsd meg a következő tervezési dátumot

Mit mulasztanak el a legtöbb sprinttervezési sablonok

A legnépszerűbb sprinttervezési sablonok a backlog-gondozásra és a definition-of-done-ra összpontosítanak. Mindkettő fontos. Egyik sem foglalkozik azzal a tervezési hibával, amely a legtöbb sprintbukást okozza: a munka kiválasztása a rendelkezésre állás ellenőrzése nélkül.

Egy öt mérnökből álló, teljes kapacitáson lévő csapatnak nagyjából 200 story point áll rendelkezésére 2 hetes sprintenként. Egy ötfős csapatnak, amelyből két mérnök szabadságon van, egy ügyeletben rotál, és egy egy háromnapos offsite-on, talán 110. Ha a második sprintben 180 pontot választasz ki, már megbuktál. A kiválasztási lépés az, ahol a túlvállalás történik, és a kapacitásnak meg kell előznie.

A második hézag az elfogadási kritériumok. A csapatok gyorsan haladnak át a tervezésen, és a kritériumokat később szándékoznak megírni. A később nem történik meg ugyanazon a konkrétsági szinten. Az a személy, aki a teremben pontos kritériumot írt volna, másnap emlékezetből valami homályosabbat ír, vagy egyáltalán nem írja meg. A sprint közbeni viták arról, hogy mit jelent a „kész”, szinte mindig a tervezésben kihagyott elfogadási kritériumokra vezethetők vissza.

Ezeknek a hézagoknak a halmozódó költsége — túlterhelt sprintek, sprint közbeni felfedezések, újratárgyalt definíciók — világosan megmutatkozik, amikor összeadod: A megbeszélési adó.

Miért nehezebbek a sprinttervezési jegyzetek, mint amilyennek látszanak

A sprinttervezés több információt generál, mint szinte bármely más ismétlődő megbeszélés: a sprintcélt, a kapacitásszámokat, a tételről tételre haladó kiválasztás indoklását, jegyenkénti elfogadási kritériumokat, függőségi felelősöket, kockázati tételeket. Egy hasznos összefoglaló megírása mindezt olyan formában kell rögzítenie, amely három nappal később hasznos, amikor valaki megkérdezi: „miért vágtuk ki azt a tételt?”.

A Pavleur automatikusan generálja a sprinttervezési jelentést a hívás végén. Rögzíti a sprintcélt, a kiválasztott backlogot indoklással, az elfogadási kritériumokat a megbeszélésen elhangzott formában, és a függőségi felelősöket megnevezésük szerint. Ha valaki megosztott képernyőn a backlogot vagy a kapacitás-táblázatot, az a vizuális elem a jelentésben szerepel a vita mellett — olyan kontextus, amelyet a csak hangot rögzítő eszközök, mint az Otter vagy a Fireflies, teljesen elmulasztanának. Bárki, aki később csatlakozott, vagy egy döntést kell ellenőriznie a sprint közepén, rendelkezik a teljes feljegyzéssel. Arról, hogy ez miben különbözik a csak hangot rögzítő eszközöktől: Pavleur vs. alternatívák.

A sprint közbeni tervváltozás kezelése

A sprintterv vállalás, nem szerződés. Amikor valami a sprint közepén valóban érvényteleníti a tervet — egy éles incidens, egy kritikus függőség, amely három jegyet blokkol, egy prioritásváltás a vezetéstől —, a helyes válasz egy gyors újratervezési hívás, nem néma hatókör-elhagyás. Az újratervezési hívás 20 percet vesz igénybe, és egy frissített sprintcélt eredményez, amely tükrözi a valóságot. Az alternatíva egy olyan sprint, amely papíron megbukik, de informálisan úgy módosult, ahogyan azt senki sem írta le, ami nehezebbé teszi a retrospektívet, és értelmetlenné a sebességszámokat.

Építsd ki a kifejezett újratervezés szokását. Használd ugyanazt a struktúrát: frissített kapacitás, felülvizsgált kiválasztás, újrafogalmazott cél. Sokkal kevesebb időt vesz igénybe, mint a zűrzavar, amelyet megelőz.