Gönderiler

Sprint süresi: sprintleriniz 1, 2, 3 veya 4 hafta olmalı mı?

Sprint süresi seçimi, takımınızın nasıl planladığını, tahmin ettiğini, yansıttığını ve teslim ettiğini şekillendirdiğini fark etene kadar küçük bir karar gibi görünür. Her Scrum seremonisi sprint süresi ile ölçeklenir, bu da seçiminizin tüm geliştirme sürecine dalga dalga yayıldığı anlamına gelir. Çoğu takım bunu düşünmeden varsayılan olarak iki hafta seçer. Bu birçok kişi için iyi çalışır, ancak bu tek seçenek değildir ve her zaman en iyi seçenek de değildir. İşte takımınıza gerçekten uygun sprint süresini nasıl seçeceğiniz açıklanmaktadır.

Scrum Kılavuzu Ne Diyor

Scrum Kılavuzu bir kural belirler: sprintler bir ay veya daha az. Hepsi bu kadar. Minimum uzunluk yok, önerilen varsayılan yok, sadece bir tavan. Uygulamada, endüstri iki haftalık sprintlere yakınlaşmıştır. State of Agile raporuna göre, yaklaşık %58 takım bunları kullanır. Ancak bu popülarite onları evrensel olarak doğru yapmaz. Tek haftalık ve dört haftalık sprintlerin her birinin meşru kullanım durumları vardır ve üç haftalık sprintler belirli takım yapıları için sessizce iyi çalışır.

Sprint Sürelerini Karşılaştırma

Her sprint süresi geri bildirim hızı ile yürütme zamanı arasında farklı bir denge oluşturur. İşte nasıl karşılaştırıldıkları.

1 Haftalık Sprintler

Yön	Detay
Temel olarak	Startuplar, acil projeler, hızla değişen gereksinimler olan takımlar
Geri bildirim hızı	Çok hızlı, her hafta yeni bir şey öğrenirsiniz
Seremoni yükü	Yüksek, sprintin yaklaşık %20-25'i toplantıdır
Planlama çabası	Sprint başına daha düşük, ancak ayda dört kez planlarsınız
Risk	Düşük, öncelikler değişirse sadece bir haftalık iş tehlikede

Bir haftalık sprintler aşırı öncelikler belirlenmeyi zorlar. Sadece bir avuç öğeyi barındırabiliyor, bu takımın en önemli olana ne olduğu konusunda acımasız olması gerektiği anlamına gelir. Sprint planlama kısa (maksimum iki saat), ancak her hafta olur. Bu hız, gereksinimler sık sık değiştiğinde, ürün-pazar uyumunu keşfederken veya takımın paydaşlarla hizalı kalmak için sıkı geri bildirim döngülerine ihtiyaç duyduğunda çalışır. İş öğeleri doğası gereği büyük olduğunda veya takım serimonilerde bina olmaktan daha fazla zaman harcadığında başarısız olur.

2 Haftalık Sprintler

Yön	Detay
Temel olarak	Çoğu takım, iyi bir nedenden dolayı endüstri standardı
Geri bildirim hızı	Dengeli, çoğu paydaş ihtiyaçları için yeterince hızlı
Seremoni yükü	Orta, sprintin yaklaşık %12-15'i toplantıdır
Planlama çabası	İdare edilebilir, ayda iki kez
Risk	Düşük ila orta, iki haftalık iş tehlikede

İki haftalık sprintler çoğu kuruluş için tatlı noktaya vurur. Anlamlı çalışmayı tamamlamak için yeterli zaman vardır, ancak geri bildirim döngüsü yine de sorunları erken tespit etmek için yeterince kısa. Depo iyileştirmesi sprint başına bir veya iki kez gerçekleşir ve takımın serimoniler arasında yeni bilgi absorbe etmek için zamanı vardır. Bu bir nedeni vardır. Nereden başlayacağından emin değilseniz, buradan başlayın.

3 Haftalık Sprintler

Yön	Detay
Temel olarak	Ağır bağımlılıkları veya karmaşık entegrasyon çalışması olan takımlar
Geri bildirim hızı	Daha yavaş, ancak istikrarlı ürünler için yeterli
Seremoni yükü	Daha düşük, sprintin yaklaşık %10-12'si toplantıdır
Planlama çabası	Daha az sık, ancak oturumlar daha uzun
Risk	Orta, üç haftalık çalışma ıskaya gidebilir

Üç haftalık sprintler nadirdir, bu bazı takımları bunlardan kaçınmaya yönlendirir. Ama gerçek bir sorunu çözerler: iki hafta anlamlı özellikleri tamamlamak ve entegre etmek için yeterli olmadığında, ancak dört hafta paydaş geri bildiriminden çok fazla kayma yaratır. Birden çok hizmet veya takım arasında karmaşık bağımlılıkları olan takımlar sıklıkla doğal olarak burada iner. Ekstra hafta, planlama ufuklarını çok uzağa genişletmeden entegrasyon ve test etme için soluk almaya ihtiyaç duyar.

4 Haftalık Sprintler

Yön	Detay
Temel olarak	Olgun takımlar, istikrarlı ürünler ve öngörülebilir çalışma
Geri bildirim hızı	Yavaş, paydaş kontrolleri arasında tam bir ay
Seremoni yükü	En düşük yüzde, sprintin yaklaşık %8-10'u
Planlama çabası	Ayda bir, ancak planlama oturumları daha uzun (8 saate kadar)
Risk	Daha yüksek, tam bir ay işi yeniden çalışmaya ihtiyaç duyabilir

Dört haftalık sprintler, seremoni yükünü toplam zamanın yüzdesi olarak en aza indirir. Takım daha fazla kesintisiz inşaat süresi alır, ancak geri bildirim döngüsü daha uzun. Takım yanlış yönde giderse, yön değiştirmek bir ay sürer. Bu, istikrarlı ürünler oluşturan ve gereksinimler sık değişmeyen olgun takımlar için en iyi çalışır. Paydaşlar düzenli görünürlük gerektiğinde veya pazar sprint döngünüzden daha hızlı hareket ettiğinde başarısız olur.

Seremoni Yükü Hesaplaması

İşte çoğu takımın asla sormadığı bir soru: sprintinizin yüzde kaçı gerçekten toplantılarda harcandı? Scrum beş olay belirtir, her biri sprint süresi ile ölçeklenen zaman kutuları. 40 saatlik haftalarda çalışan yedi kişilik bir takım için seremoni yükünü hesaplayalım.

Seremoni	1 haftalık sprint	2 haftalık sprint	3 haftalık sprint	4 haftalık sprint
Sprint Planlama	2 s	4 s	6 s	8 s
Günlük Standup	1,25 s	2,5 s	3,75 s	5 s
Sprint İncelemesi	1 s	2 s	3 s	4 s
Retrospektif	0,75 s	1,5 s	2,25 s	3 s
Iyileştirme	2 s	4 s	6 s	8 s
Toplam seremoni saatleri	7 s	14 s	21 s	28 s
Mevcut saatler	40 s	80 s	120 s	160 s
Yük %	17,5%	17,5%	17,5%	17,5%

Scrum Kılavuzunun orantılı zaman kutularını takip ettiğinizde yüzdeler kabaca eşittir. Ancak matematik göstermiyor: bağlam geçiş maliyetleri. Daha kısa sprintler "seremoni modu" ile "inşaat modu" arasında daha sık geçişler anlamına gelir. Bir haftalık sprintlerde takımlar sıklıkla seremoni yükünün rakamlar önerdiğinden çok daha yüksek olduğunu bildiriyor çünkü serimoniler birbirine yakın paketlenir. Uygulamada, bir haftalık sprintler çalıştıran birçok takım serimonileri orantılı olarak ölçeklendirmez. İki haftalık bir sprintte 90 dakika alan bir retrospektif, bir haftalık sprintte nadiren 45 dakikaya düşer. Gerçek yük farkı orada ortaya çıkar.

Karar Faktörleri

Sprint süresini seçmek sadece matematik değildir. Bunlar gerçekten önemli olan faktörler.

Dikkate alınması gereken diğer faktörler

İş öğelerinin boyutu. Çoğu kullanıcı hikayesi tamamlamak için 3-5 gün sürerse, bir haftalık sprintler neredeyse hiçbir hata payı bırakmaz. İki veya üç haftalık sprintler daha fazla esneklik sunar. Öğeleri tahmin etmek ve bunların farklı sprint sürelerine nasıl uyacağını görmek için Planlama Pokeri'ni iyileştirme sırasında kullanın. Takım boyutu. Daha büyük takımlar (7-9 kişi) daha fazla koordinasyon yükü oluştururlar. Daha uzun sprintler bu maliyeti daha iyi emebilir. Daha küçük takımlar (3-5 kişi) daha kısa sprintlerle hızlı hareket edebilir. Yapılmış Tanımı Karmaşıklığı. Yapılmış Tanımınız ağır test, güvenlik incelemeleri veya uyum denetimleri içeriyorsa, bu süreçlerin zamanı gerekir. Bir haftalık sprint kapsamlı kalite kapılarını barındıramayabilir.

Sprint Süresini Değiştirebilir misiniz?

Evet. Ve mevcut kadansınız işe yaramıyorsa bunu yapmalısınız. Sprint süresini değiştirmenin en iyi zamanı, takım kadansı sorunların köklü nedeni olarak belirlediği retrospektif'dir. Bir değişime ihtiyaç duyduğunuzun yaygın işaretleri:

Geçişe Nasıl Gidilir

1. Retrospektifte Tartış

   Mevcut sprint süresinin neden işe yaramadığını ortaya çıkarmak için retro'yu kullanın. Sadece duygular değil, spesifik örnekler toplayın. Takım düzenli olarak iş %40'ını bir sonraki sprinte taşıyorsa, bu değerlendirilecek bir veri noktasıdır.

2. 3-4 Sprintler için Yeni Uzunluğu Deneyin

   Bir sprint yargılamak için yeterli değildir. Yeni bir uzunluktaki ilk sprint, takım hala kalibre ettiği için garip hissettirecektir. Karar vermeden önce ona en az üç yineleme verin.

3. Seremoni Uzunluklarını Orantılı Olarak Ayarlayın

   İki haftalık sprintlerden bir haftalık sprintlere geçiyorsanız, seremoni zaman kutularınızı yarıya indirin. İki saatlik bir retro'yu bir haftalık sprintye sıkıştırmayın.

4. Hızı Yeniden Kalibre Edin

   Sprint hızı sprint süreleri arasında doğrudan aktarılmaz. Hızınız'ı yeni kadansta izleyin ve takıma güvenilir bir temel oluşturmak için üç sprint verin. Hedefleri yeni uzunluk için uygun şekilde kapsamlı tutmak için bir sprint hedefi jeneratörü kullanın.

5. Değerlendir ve Karar Ver

   Deneme döneminden sonra, sprint süresi değişikliği üzerine odaklanmış bir retro yapın. Eski ve yeni kadans arasında teslimat tahmini, takım memnuniyeti ve paydaş geri bildirimi ile karşılaştırın.

Hızlı Bir Karar Çerçevesi

Basit bir başlangıç noktası istiyorsanız, bunu kullanın: Seçtiğiniz ne olursa olsun, sprint süresinin bir sabit değil bir değişken olduğunu unutmayın. En iyi takımlar bu kararı düzenli olarak yeniden ziyaret ederler ve öğrendikleri temelinde ayarlarlar.