Mühendislik Ekipleri için Sprint Planlama Gündemi Şablonu

Sprintler neden aşırı yüklenir

Sprint planlamasının şablonların önlemediği tek bir yapısal başarısızlığı vardır: ekipler kapasiteyi kontrol etmeden sprint backlog'unu seçer. Sonuç, beyaz tahtada ulaşılabilir görünen ve iki mühendisin haftanın yarısı için dışarıda olduğu, bir biletin kapsamının üçe katlandığı ve üç maddenin platform ekibinin yeniden yazdığı bir servise dile getirilmemiş bağımlılıkları olduğu Çarşamba günü çöken bir sprinttir.

Çözüm basit ve neredeyse hiç yapılmıyor: işe taahhütte bulunmadan önce kapasiteye taahhütte bulunun. Aşağıdaki şablon tam olarak bu nedenle bir kapasite incelemesiyle açılır.

Gündem (kopyala-yapıştır)

Süre: 2 haftalık bir sprint için 2 saat; 1 haftalık bir sprint için 1 saat
Format: Yönetilir, backlog tüm ekibe görünür halde

Bölüm 1 — Sprint hedefi (10 dk)

Tek cümle: dışarıdan bakıldığında başarılı bir sprint nasıl görünür?
Hedef, herhangi bir ekip üyesinin sprint sonunda tuttuğunuzu değerlendirebileceği kadar belirli olmalı
Yalnızca bir bilet listesi olan hedefleri reddedin ("auth yeniden yapılandırmasını ve fatura sayfasını bitir") — bu bir backlog'dur, bir hedef değil

Bölüm 2 — Kapasite incelemesi (15 dk)

Her ekip üyesini adıyla listeleyin
Her biri için: planlanan izin (PTO), nöbet rotasyonu, tekrarlayan toplantılar, bilinen dış taahhütler
Kapasiteyi mevcut story point veya gün olarak ifade edin — kişi sayısı olarak değil
Bu sayı tavandır; onun destekleyebileceğinden fazla iş seçmeyin

Bölüm 3 — Backlog seçimi (45 dk)

Rafine edilmiş backlog'daki en yüksek öncelikli maddeleri gözden geçirin
Her aday için: ekibin başlamak için yeterli bilgisi var mı, yoksa sprint başlamadan önce yanıt gerektiren açık sorular mı var? Açık sorular sprint'e değil, rafine etme kuyruğuna aittir
Kapasitenin %80'ine ulaştığınızda seçmeyi bırakın; kalan %20 taşmayı ve plansız işi emer

Bölüm 4 — Kabul ölçütleri (20 dk)

Seçilen her madde için: onu tamamlanmış kılan ölçütü belirtin
Ekip 60 saniyede bir ölçüt belirtemiyorsa, bilet yeterince rafine değildir — onu backlog'a geri taşıyın
Şimdi, odada, bilete yazın; "sonra ekleriz"e güvenmeyin

Bölüm 5 — Riskler ve bağımlılıklar (15 dk)

Ekibin kontrol etmediği, sprint hedefi teslimini engelleyebilecek ne var?
Bağımlılık sorumlusunu belirtin; sprint ortasından önce çözmek için zaman varken bunu şimdi ortaya çıkarın
Çözülmemiş bağımlılıklara, onları takip edecek ekipten adı belli bir sorumlu atanır

Kapanış (15 dk)

Seçilen iş göz önüne alındığında sprint hedefinin hâlâ geçerli olduğunu teyit edin
Sprint özeti not tutucusunu atayın ya da otomatik rapor kurulumunu teyit edin
Bir sonraki planlama tarihini teyit edin

Çoğu sprint planlama şablonunun kaçırdığı nokta

En popüler sprint planlama şablonları backlog düzenlemeye ve tamamlanma tanımına odaklanır. İkisi de önemlidir. Hiçbiri en çok sprint başarısızlığını üreten planlama hatasını ele almaz: uygunluğu kontrol etmeden iş seçmek.

Tam kapasitede beş mühendislik ekibinin 2 haftalık sprint başına yaklaşık 200 story point'i mevcuttur. İki mühendisi izinde, biri nöbette ve biri üç günlük bir toplantıda olan beş kişilik bir ekibin belki 110'u vardır. İkinci sprintte 180 point seçerseniz, zaten başarısız olmuşsunuzdur. Seçim adımı, aşırı taahhüdün gerçekleştiği yerdir ve kapasite ondan önce gelmelidir.

İkinci boşluk kabul ölçütleridir. Ekipler planlamada hızlı ilerler ve ölçütleri sonra yazmayı niyet eder. Sonra, aynı belirlilik düzeyinde gerçekleşmez. Odada kesin bir ölçüt yazacak olan kişi, ertesi gün hafızadan daha belirsiz bir şey yazar ya da hiç yazmaz. "Tamamlandı"nın ne anlama geldiği konusundaki sprint ortası anlaşmazlıklar neredeyse her zaman planlamada atlanan kabul ölçütlerine kadar izlenebilir.

Bu boşlukların birikimli maliyeti — aşırı yüklenmiş sprintler, sprint ortası keşifler, yeniden tartışılan tanımlar — topladığınızda açıkça görünür: Toplantı vergisi.

Sprint planlama notları neden göründüğünden daha zor

Sprint planlaması, neredeyse diğer tüm tekrarlayan toplantılardan daha fazla bilgi üretir: sprint hedefi, kapasite sayıları, madde madde seçim gerekçesi, bilet başına kabul ölçütleri, bağımlılık sorumluları, risk maddeleri. Faydalı bir özet yazmak, tüm bunları, üç gün sonra biri "o maddeyi neden kestik?" diye sorduğunda işe yarayacak bir biçimde yakalamayı gerektirir.

Pavleur, görüşmenin sonunda sprint planlama raporunu otomatik olarak oluşturur. Sprint hedefini, gerekçesiyle seçilen backlog'u, toplantıda belirtildiği şekilde kabul ölçütlerini ve belirtildiği şekilde bağımlılık sorumlularını yakalar. Biri backlog'u veya kapasite tablosunu ekran paylaşımıyla gösterdiyse, o görsel tartışmayla birlikte rapora eklenir — Otter veya Fireflies gibi yalnızca sese dayalı araçların tamamen kaçıracağı bir bağlam. Geç katılan ya da sprint ortasında bir kararı kontrol etmesi gereken herkes tam kayda sahiptir. Bunun yalnızca sese dayalı araçlardan nasıl farklı olduğunun bir karşılaştırması için: Pavleur ve alternatifleri.

Sprint ortası plan değişikliğini ele almak

Sprint planı bir taahhüttür, bir sözleşme değil. Sprint ortasında bir şey planı gerçekten geçersiz kıldığında — bir prodüksiyon olayı, üç bileti engelleyen kritik bir bağımlılık, liderlikten bir öncelik değişikliği — doğru yanıt hızlı bir yeniden planlama görüşmesidir, sessiz bir kapsam düşürme değil. Yeniden planlama görüşmesi 20 dakika sürer ve gerçeği yansıtan güncellenmiş bir sprint hedefi üretir. Alternatif ise kağıt üzerinde başarısız olan ama kimsenin yazmadığı şekillerde gayriresmi olarak ayarlanmış bir sprinttir ki bu, retrospektifi zorlaştırır ve hız (velocity) sayılarını anlamsız kılar.

Açık yeniden planlama alışkanlığını edinin. Aynı yapıyı kullanın: güncellenmiş kapasite, revize edilmiş seçim, yeniden belirtilmiş hedef. Önlediği kafa karışıklığından çok daha az zaman alır.