Hava durumu tahminlerinin, saat 15:00'te kesinlikle yağmur yağacağını vaat etmek yerine %70 yağmur olasılığı olduğunu söylemesinin bir nedeni vardır. Mevcut bilgileri kullanır, belirsizliği hesaba katar ve yeni veriler geldikçe güncellerler. Tahmini bir garanti olarak algılamadığınız sürece, öğleden sonranızı bu tahminlere göre planlayabilirsiniz.
Sprint planlaması da benzer bir ilkeye dayanır. Bir Scrum Takımı’nın bir ürün birikimi, mevcut kapasitesine ilişkin bir tahmin ve ulaşmak istediği bir hedefi vardır. Ancak bazı iş detayları ancak sprint ilerledikçe netleşir. Her şeyi bir saat önceden planlamak bu tür keşiflere pek yer bırakmaz; öte yandan paylaşım olmadan işe başlamak ise neye öncelik verilmesi gerektiğine karar vermeyi zorlaştırır.
Amaç, değerli bir sonuç üzerinde anlaşmaya varmak ve takımın bunu başarmak için ne kadar iş tamamlayabileceğini tahmin etmektir. Bundan sonra takım, sprint hedefinden sapmadan, öğrendikçe planını uyarlayabilir.
Bu kılavuz, iş yığını hazırlığı, zamanlı planlama gündemi, pratik kapasite hesaplamaları ve sprint sırasında planın nasıl ayarlanacağını gösteren bir örnek çalışmayı kapsamaktadır.
Özet Sprint planlaması, Scrum Takımını bir araya getirerek tek bir sprint hedefi üzerinde anlaşmaya varmalarını, backlog öğelerini seçmelerini ve ilk teslimat planını oluşturmalarını sağlar:
- Yaklaşan işleri netleştirerek ve uygunluk durumunu, tamamlanmamış öğeleri, bağımlılıkları ve "Tamamlandı Tanımı"nı kontrol ederek hazırlık yapın.
- Tahmininizi, taahhütleri iki kez saymadan, izinleri, toplantıları, destek görevlerini ve belirsizlikleri hesaba katarak, gerçek kapasite ve geçmiş performansa dayandırın.
- Planlama toplantısından ortak bir sprint backlog'uyla ayrılın, ardından takım daha fazla bilgi edindikçe teslimat planını uyarlayın ve sprint hedefini koruyun
- İki saatlik örnek gündemi ve kapasite hesaplamasını başlangıç noktası olarak kullanın ve bunları takımın ihtiyaçlarına göre uyarlayın.
Sprint Planlaması Nedir?
Sprint planlaması, takımın neyi başarmak istediği ve işe nasıl yaklaşacağı konusunda mutabakat sağlamak amacıyla her sprintin başında düzenlenen bir Scrum etkinliğidir. Bu etkinlik, Ürün Sahibi, Scrum Master ve geliştiriciler dahil olmak üzere tüm Scrum Ekibini bir araya getirir. Güvenlik mühendisleri veya müşteri ilişkileri sorumluları gibi diğer uzmanlar da, katkılarının ekibin bilinçli kararlar almasına yardımcı olacağı durumlarda bu etkinliğe katılabilir.
Scrum Kılavuzu'na göre, her planlama oturumu üç şey ortaya çıkarmalıdır: işin değerini açıklayan bir sprint hedefi, bu hedefi destekleyen ürün backlog öğelerinin seçimi ve bunların teslimine yönelik bir başlangıç planı. Bunlar bir araya gelerek sprint backlog'u oluşturur ve geliştiriciler sprint ilerledikçe bu backlog'u güncellemeye devam ederler.
Scrum Kılavuzu, bir aylık bir sprint için en fazla sekiz saat öngörür; daha kısa sprintler genellikle daha az süre gerektirir. İyi bir şekilde düzenlenmiş bir iş yığınıyla, aşağıdaki gündem iki saatte tamamlanabilir.
Bu terimlerden bazılarına aşina değilseniz, sözlüğümüzde agile ve Scrum ile ilgili temel bilgiler yer almaktadır.
Sprint Planlamasının Cevapladığı Üç Soru
Her sprint planlaması oturumu üç soru etrafında şekillenir:
- Bu sprint neden değerlidir?
- Neler başarabiliriz?
- Peki, bu işleri nasıl yapacağız?
Scrum Kılavuzu, sunmak istediğiniz değerden başlayarak planlamayı bu sorular etrafında düzenler. Herkes bu konuda net bir fikre sahip olduğunda, hangi backlog öğelerinin dikkate alınması gerektiğine ve takımınızın makul olarak ne kadar iş üstlenebileceğine karar vermek daha kolay hale gelir.
| Soru | Kim liderlik eder? | Çıktı | 2 haftalık bir sprint örneği |
|---|---|---|---|
| Bu sprint neden değerlidir? | Ürün Sahibi önerir; tüm takım kabul eder | Sprint hedefi | Yeni müşteriler, satış ekibiyle iletişime geçmeden ödeme sırasında kartla ödeme yapabilir |
| Bu sprintte neler yapılacak? | Geliştiriciler, Ürün Sahibi ile birlikte işleri seçerler | Seçilen birikmiş iş öğeleri | Kartlı ödeme formu, ödeme sağlayıcısı entegrasyonu, makbuz e-posta, hata yönetimi |
| Seçilen işler nasıl tamamlanacak? | Geliştiriciler | İlk görev planı | Öğeler, genellikle her biri bir gün veya daha kısa süreli görevlere bölünür ve başlangıçtaki sorumluluklar üzerinde mutabık kalınır |
Sprint neden önemlidir?
Sprint hedefi, takıma ulaşılması gereken bir amaç sunar ve paydaşların ne beklemeleri gerektiğini anlamalarına yardımcı olur. Planlama oturumu sona ermeden önce bu hedef üzerinde Scrum Takımınızla mutabık kalın.
"34 hikaye puanı tamamlayın" gibi bir iş yükü hedefi yerine, "Deneme sürümü kullanıcıları takım arkadaşlarını davet edebilir" gibi, insanların tanıyabileceği bir sonucu tanımlayın. Beklenmedik bir sorun ortaya çıkarsa, hedef, takımın amaçlanan sonucu korurken hangi işleri ayarlayacağına karar vermesine yardımcı olur.
Daha Fazla Bilgi: Etkili Sprint Hedefleri Nasıl Yazılır (+Örnekler)
Takımın bu sprintte tamamlayabilecekleri işler
Hedef üzerinde anlaşmaya vardığınızda, takımın gerçekçi olarak neyi teslim edebileceğini belirleme zamanı gelir.
Geliştiriciler, mevcut kapasiteyi, geçmiş performansı ve "Tamamlanma Tanımı"nı göz önünde bulundurarak Ürün Sahibi ile görüşerek backlog öğelerini seçerler. Bu aynı zamanda, takımın sprint işleri için ne kadar zamana sahip olacağını etkileyebilecek mevcut taahhütleri gözden geçirmek için de doğru zamandır.
Birçok takım, birikmiş öğelerin göreceli çabasını ve karmaşıklığını karşılaştırmak için hikaye puanlarını kullanır. Bir Fibonacci ölçeği, özellikle gereken çabanın net olmadığı durumlarda bu tartışmaları yapılandırmaya yardımcı olabilir.
Hikaye puanları konusunda yeniyseniz veya bunların pratikte nasıl kullanıldığını görmek istiyorsanız, işte tahmin sürecine dair bir adım adım kılavuz.
Takım işi nasıl yapılacak?
Backlog öğeleri seçildikten sonra, geliştiriciler bunları "Tamamlandı Tanımı"na uyan bitmiş bir ürün artışı haline nasıl dönüştüreceklerini belirler. Scrum Kılavuzu, daha büyük öğelerin genellikle bir gün veya daha kısa sürede tamamlanabilecek boyutlarda daha küçük iş parçalarına bölünmesini önerir.
Bu, sprintin her saatini ayrıntılı olarak planlamanız gerektiği anlamına gelmez. İlk birkaç gün için daha ayrıntılı bir plana ihtiyaç duyulabilirken, sonraki görevler yeni ayrıntılar ortaya çıktıkça ayarlanmaya açık kalabilir. Erken aşamadaki tahminleri kesin taahhütler olarak ele almak, kapsam yarı yolda değişse bile takımı orijinal sayılara uymaya zorlayabilir.
Scrum.org'un CEO'su Dave West'in açıkladığı gibi:
Bir tarihi savunmak için kullanılan bir tahmin, tahminleri şişirmek, riski gizlemek veya bir sayıya ulaşmak için "tamamlandı" tanımını sessizce yeniden tanımlamak gibi güveni zedeleyen davranışları tam da teşvik eder.
Bir tarihi savunmak için kullanılan tahminler, tahminleri şişirmek, riskleri gizlemek veya bir sayıya ulaşmak için "tamamlandı" tanımını sessizce yeniden tanımlamak gibi, güveni zedeleyen davranışları tam da teşvik eder.
Sprint Planlaması ile Backlog İyileştirme Arasındaki Fark Nedir?
Backlog iyileştirme, bir sonraki sprinte nelerin dahil edileceğine karar verme zamanı gelmeden önce takımınıza gelecek işler hakkında daha net bir anlayış sağlar. Sprint planlaması, bu hazırlık üzerine inşa edilerek bir hedef üzerinde anlaşmaya varır, backlog öğelerini seçer ve ilk teslimat planını oluşturur.
Bu iki etkinlik, Scrum kapsamında farklı amaçlara hizmet eder:
| Boyut | Backlog iyileştirme | Sprint planlaması |
|---|---|---|
| Amaç | Yaklaşan iş yığını öğelerini netleştirin, bölün ve tahmin edin | Sprint hedefini belirleyin, işleri seçin ve teslimatı planlayın |
| Zamanlama | Sprint boyunca devam eder | Her sprintin başında |
| Scrum durumu | Sürekli devam eden bir faaliyet | Zaman sınırı olan resmi bir Scrum etkinliği |
| Kimler katılır? | Ürün Sahibi ve ilgili geliştiriciler | Tüm Scrum Takımı |
| Çıktı | Daha net ayrıntılar, tahminler ve kapsam içeren birikmiş öğeler | Sprint birikim listesi: sprint hedefi, seçilen öğeler ve teslimat planı |
Takımın sprint planlaması sırasında net seçimler yapabilmesi için, yaklaşan backlog öğelerinin yeterince detaylandırılmış olmasını sağlayın. Ne kadar hazırlık yapılması gerektiği, önceliklerin ne kadar hızlı değiştiğine ve ne kadar belirsizlik kaldığına bağlıdır. Backlog'un daha alt sıralarında yer alan öğeler, seçime yaklaşana kadar daha az detaylı kalabilir.
Ayrıca şunu da okuyun: Daha fazla rehberlik için, backlog düzenleme ve ürün backlog'unuzu organize ve öncelikli tutma konulu makalelerimize göz atın.
Sprint Planlamasına Nasıl Hazırlanılır?
Toplantıdan birkaç gün önce, iş yığınının düzgün durumda olduğunu ve herkesin karar vermek için ihtiyaç duyacağı bilgilere sahip olduğunu kontrol edin. Böylelikle, her bir gereksinimi sıfırdan çözmek zorunda kalmadan, oturumu neyin teslim edileceğini ve buna nasıl yaklaşılacağını tartışarak geçirebilirsiniz.
İşte bir sonraki sprintinizden önce gözden geçirmeniz gereken bir kontrol listesi:
- Sprint hedefi taslağı hazırlayın: Ürün Sahibi'nden, daha geniş kapsamlı Ürün Hedefi'ni destekleyen bir sonuç önermesini isteyin; böylece takıma tartışacakları somut noktalar sunmuş olursunuz.
- Ürün birikimini gözden geçirin: En yüksek öncelikli öğelerin sıralandığından, anlaşıldığından ve gerektiğinde tahminlerinin yapıldığından emin olun
- Takımın uygunluk durumunu kontrol edin: Geliştiricilerden, planlanmış izinlerini, destek nöbetlerini ve kapasitelerini etkileyebilecek diğer yükümlülüklerini paylaşmalarını isteyin
- Tamamlanmamış işleri yeniden gözden geçirin: Önceki sprintten devreden kalan işleri ve retrospektif sırasında belirlenen iyileştirmeleri gözden geçirin
- Bağımlılıkları belirleyin: Başka bir takımın katkısını veya onayını gerektiren işleri işaretleyin ve koordinasyonu kimin üstleneceğini netleştirin
- "Tamamlandı Tanımı"nı gözden geçirin: Herkesin, tamamlanan her bir iş listesi öğesinin karşılaması gereken kalite standartlarını anladığından emin olun
Sprint geriye dönük değerlendirmesi ile planlama oturumunu birbirine yakın bir zamanda planlıyorsanız, her ikisinde de kapsamlı bir tartışma için yeterli zaman ayırın. Geriye dönük değerlendirmenin sonuçları bir sonraki sprintin planını şekillendirmelidir; bu nedenle, hiçbir toplantının aceleye getirilmediğinden emin olun.
Sprint Planlaması Gündemi: 2 Haftalık Bir Sprint İçin Zamanlı Bir Örnek
İki haftalık bir sprint için, özellikle iş yığını önceden düzenlenmişse, iki saatlik bir planlama oturumuyla başlayın. İş, karmaşık bağımlılıklar içeriyorsa veya tartışılması gereken birkaç karar gerektiriyorsa, fazladan zaman ayırmayı planlayın.
Bu örnek gündemi takımınızın ihtiyaçlarına göre uyarlayabilirsiniz.
| Zaman | Gündem ögesi | Kim liderlik eder? | Beklenen çıktı |
|---|---|---|---|
| 0:00–0:10 | Önceki sprintin sonuçlarını, tamamlanmamış işleri ve retrospektif eylemlerini gözden geçirin | Scrum Master, süreci yönlendirir | Nereye dikkat edilmesi gerektiğine dair paylaşılan anlayış |
| 0:10–0:30 | Ürün Sahibinin önerdiği sprint hedefini tartışın ve istenen sonuç üzerinde anlaşmaya varın | Tüm Scrum Takımı | Herkesin anlayabileceği bir sprint hedefi taslağı |
| 0:30–0:45 | Takımın uygunluğunu teyit edin ve kapasite kısıtlamalarını gözden geçirin | Geliştiriciler | Mevcut kapasitenin gerçekçi bir tablosu |
| 0:45–1:15 | Hedefi destekleyen birikmiş iş öğelerini seçin | Geliştiriciler, Ürün Sahibi ile birlikte | Takımın tamamlayabileceğine inandığı işlerden oluşan bir seçim |
| 1:15–1:45 | Seçilen öğeleri ayrıntılara ayırın ve teslimat yaklaşımını tartışın | Geliştiriciler | İşi tamamlamak için bir başlangıç planı |
| 1:45–2:00 | Bağımlılıkları gözden geçirin, güven düzeyini kontrol edin ve sprint hedefini kesinleştirin | Tüm Scrum Takımı | Üzerinde anlaşmaya varılmış bir sprint hedefi ve takımın kullanıma hazır bir sprint backlog'u |
Toplantıyı bitirmeden önce, herkesin plana olan güvenini sıfırdan beş parmağa kadar derecelendirdiği Fist of Five gibi hızlı bir güven kontrolü yapabilirsiniz. Birisi düşük bir puan verirse, endişesinin nedenini sorun. Bu, çözülmemiş bir bağımlılığı, aşırı iddialı bir tahmini veya daha fazla tartışılması gereken bir gereksinimi ortaya çıkarabilir.
Buradaki amaç, planı ayarlamak için hâlâ zaman varken endişeleri ortaya çıkarmaktır.
6 Adımda Sprint Planlaması Nasıl Yapılır?
Backlog'u hazırladıktan ve katılımcıları belirledikten sonra planlama oturumuna başlayın. Hedef, takımın önceliklerini ve mevcut kapasitesini, teslim edebileceğinden emin olduğu bir plana dönüştürmesine yardımcı olmaktır.
1. Adım: Önceki işleri gözden geçirin ve bir sprint hedefi üzerinde anlaşın
Öncelikle, nelerin tamamlandığına, nelerin henüz bitmediğine ve geriye dönük değerlendirmelerden çıkan herhangi bir eylemin bir sonraki sprinti etkileyip etkilemeyeceğine kısaca göz atın. Sprint incelemesinin tamamını tekrar gözden geçirmek yerine, takımın önceliklerini veya yaklaşımını değiştirebilecek her şeye odaklanın.
Ardından, Ürün Sahibi'nin önerilen sprint hedefini tanıtmasını ve bunun daha geniş kapsamlı Ürün Hedefi'ni nasıl desteklediğini açıklamasını sağlayın. Geliştiricilere, hedefin kapsamını sorgulama, bağımlılıkları gündeme getirme ve ayarlamalar önerme fırsatı verin.
Örneğin, hedef müşterilerin satış ekibiyle iletişime geçmeden ödeme işlemini tamamlamasını sağlamaksa, başarılı bir ödeme işleminin neye benzediği konusunda mutabık kalın. Buna ödeme onayı ve hata yönetimi de dahil mi? İlk sürüm için otomatik makbuz gönderimi zorunlu mu?
Bu tartışmalar, takımın ulaşmaya çalışacağı bir sonucu tanımlamanıza yardımcı olur. Backlog öğeleri seçildikçe ifadeler değişebilir, ancak planlama sona ermeden önce herkes nihai hedef üzerinde mutabık kalmalıdır.
2. Adım: Takımın kullanılabilir kapasitesini hesaplayın
İşleri seçmeden önce, geliştiricilerinizin sprint'e gerçekçi olarak ne kadar zaman ayırabileceğini belirleyin.
Çalışma günlerinin sayısı ve her bir kişinin beklenen uygunluk durumuyla başlayın. Ardından planlanmış izinleri, Scrum etkinliklerini, destek sorumluluklarını ve diğer bilinen taahhütleri hesaba katın. Bir geliştirici haftasının yarısını üretim sorunlarını çözmekle geçiriyorsa, bu saatler zaten taahhüt edilmiş sayılır ve planlanan sprint çalışmaları için kullanılamaz.
Basit bir hesaplama şöyledir: Kullanılabilir kapasite = Toplam çalışma saati − Bilinen taahhütler
Örneğin, iki hafta boyunca 80 çalışma saati olan bir geliştiricinin 8 saat izni, 10 saat toplantısı ve 12 saat destek görevi olabilir. Bu durumda, olası ek belirsizlikler hesaba katılmadan önce 50 saat kalır.
Bu rakamı takımın geçmiş performansıyla karşılaştırın. Hız, takımın önceki sprintlerde ne kadar iş tamamladığını gösterirken, kapasite ise bu sprint için mevcut olan zamanı yansıtır.
Profesyonel İpucu: Kapasite planlaması için saat birimini kullanıyorsanız, bunu hikaye puanlarından ayrı tutun. Bu iki birim farklı şeyleri ölçer ve aralarında evrensel bir dönüştürme oranı yoktur.
3. Adım: Önceki sprintten kalan tamamlanmamış işleri yeniden değerlendirin
Bitmemiş backlog öğelerini yeni sprinte eklemeden önce bir kez daha gözden geçirin. İki hafta önce önemli olan bir öğenin önceliği değişmiş olabilir veya takım, kalan iş miktarını etkileyen yeni bilgiler edinmiş olabilir.
Her bir öğeyi Ürün Sahibi ile gözden geçirin ve şunları değerlendirin:
- Alaka düzeyi: Bu, önerilen sprint hedefini veya başka bir önemli ürün önceliğini hâlâ destekliyor mu?
- Kalan çaba: Öğenin bir kısmı tamamlandıktan sonra geriye ne kadar iş kaldı?
- Bağımlılıklar: Takımın ilerlemesini engelleyen herhangi bir şey var mı?
- Öncelik: Bu öğe, yeni iyileştirilmiş birikmiş iş listesi ögelerinden önce mi gelmelidir?
Hâlâ sprint kapsamında yer alan işler için, kalan çaba miktarını kullanarak bu işlerin ne kadar kapasite gerektireceğini değerlendirin. Yarısı tamamlanmış bir öğe, orijinal tahmininden daha az iş gerektirebilir, ancak "Tamamlandı" tanımına ulaşana kadar yine de tamamlanmamış olarak kabul edilir.
4. Adım: Hedefi destekleyen birikmiş iş öğelerini seçin
Kapasiteniz ve tamamlanmamış işleriniz netleştiğinde, geliştiriciler tamamlayabileceklerine inandıkları ürün biriktirme listesi öğelerini seçebilirler.
Sprint hedefini doğrudan destekleyen öğelerle başlayın. Bu öğelerin kabul kriterlerini, teknik bağımlılıklarını ve teslimatı etkileyebilecek olası belirsizlikleri tartışın. Bir öğe çok büyük veya belirsizse, onu sprint kapsamında değer yaratabilecek daha küçük parçalara bölmeyi düşünün.
Bakım veya diğer ürün öncelikleri için de yer ayırabilirsiniz, ancak bu işleri üstlenmenin ana hedefi tehlikeye atıp atmayacağını kontrol edin.
Ne kadar kapasite ayırmalısınız?
Mevcut kapasitenin yalnızca %80’ini planlamak, düzenli olarak beklenmedik destek işleriyle uğraşan takımlar için makul bir başlangıç noktası olabilir, ancak Scrum sabit bir yüzde belirlemez.
Takımınız sık sık kesintilerle karşılaşıyorsa, ayarlanmış kapasitesinin %10–20’sini ayırıp bu payı önceki sprintlerde ihtiyaç duyulan miktarla karşılaştırabilirsiniz. İş yükü istikrarlı ve kesintileri az olan bir takımın ihtiyacı daha az olabilir. Sık sık olayların yaşandığı canlı bir hizmeti destekleyen bir takımın ihtiyacı ise daha fazla olabilir.
Aynı taahhüdü iki kez saymaktan kaçının. Planlanan destek saatleri 2. Adımda zaten düşülmüşse, ek tampon, bilinen iş yükünün ötesindeki belirsizliği karşılamalıdır. Sonuçta ortaya çıkan kapasiteyi, ulaşılması gereken bir hedef olarak değil, tartışma için bir kılavuz olarak kullanın.
Unutmayın: Boş kapasitesi olan bir sprint, mutlaka yetersiz planlanmış olduğu anlamına gelmez. Sprint hedefine ulaşmak için yeterli iş seçtiyseniz, kalan saatleri konuyla ilgisiz görevlerle doldurmak, öncelikler arasında çakışmaya neden olabilir. Bazen daha küçük bir tahmin daha gerçekçidir; özellikle de seçilen iş önemli ölçüde belirsizlik içeriyorsa.
5. Adım: İşleri parçalara ayırın ve bağımlılıkları kontrol edin
Backlog öğelerini seçtikten sonra, geliştiriciler bunları nasıl teslim edeceklerini belirleyebilirler. Bu süreç, daha büyük öğelerin geliştirme, test, entegrasyonlar ve inceleme görevlerine bölünmesini içerebilir.
İşlerin sırasına dikkatle bakın. Ödeme arayüzü bir ödeme sağlayıcısıyla entegrasyona bağımlıysa, takım bu entegrasyonun ne zaman hazır olması gerektiğini anlamalıdır. Bir güvenlik değişikliğinin başka bir takım tarafından onaylanması gerekiyorsa, bu kararın nasıl ve ne zaman alınacağını netleştirin.
Yakın vadeli işleri daha ayrıntılı bir şekilde planlayın; sonraki görevleri ise daha sonraki tartışmalara açık bırakın. Scrum Kılavuzu, seçilen öğelerin genellikle bir gün veya daha kısa boyutlu daha küçük iş öğelerine bölünmesini önerir; ancak işin nasıl organize edileceği ve dağıtımının nasıl yapılacağına geliştiriciler karar verir.
Planın, gerekli test ve entegrasyon işleri de dahil olmak üzere "Tamamlanma Tanımı"nı dikkate aldığını kontrol edin. Bir bağımlılık teslimatı engelleyebilirse, planı kesinleştirmeden önce seçilen öğeleri yeniden gözden geçirin veya teslimat yaklaşımını ayarlayın.
6. Adım: Sprint birikimini son haline getirin ve paylaşımını yapın
Sprint hedefini, seçilen ürün biriktirme listesi öğelerini ve ilk teslimat planını, takımın erişip güncelleyebileceği bir yere kaydedin. Bunların hepsi bir araya geldiğinde, takımın neyi başarmayı hedeflediği ve hangi işlerin öncelikli olarak ele alınması gerektiği net bir şekilde ortaya çıkmalıdır.
Toplantıyı kapatmadan önce, hedef üzerinde mutabakat sağlandığını teyit edin ve herkese kalan tahminlerle ilgili endişelerini dile getirme fırsatı verin. Önemli bir bağımlılık veya kapasite sorunu çözülmemişse, takım çalışmaya başlamadan önce nelerin değişmesi gerektiğini tartışın.
Sprint süresince, Günlük Scrum toplantısı geliştiricilere hedefe yönelik ilerlemeyi gözden geçirme ve sprint backlog'unu ayarlama fırsatı sunar. Bir burndown veya burnup grafikleri, ilerlemedeki değişiklikleri göstermeye yardımcı olurken, altta yatan görevler ayrıntılı bilgi sağlar. Yeni bilgiler seçilen kapsamı etkiliyor ise, geliştiriciler sprint hedefini riske atmadan Ürün Sahibi ile ayarlamaları tartışabilirler.
Sprint Planlaması Örneği: 6 Geliştiriciden Oluşan Bir Takım
Bu kararların pratikte nasıl işlediğine bir göz atalım.
Bir B2B faturalandırma ürünü için iki haftalık bir sprint planladığınızı hayal edin. Takımınızda altı geliştirici var ve önerilen sprint hedefi şudur: “Yeni müşteriler, satış ekibiyle iletişime geçmeden ödeme sırasında kartla ödeme yapabilir.”
Backlog öğelerini seçmeden önce, takımın ne kadar zamana sahip olduğunu bilmeniz gerekir. Bu örnek için, planlanmış Scrum etkinlikleri ve diğer taahhütler düşülmeden önce her geliştiricinin günde altı saatlik odaklanmış proje işi yapabileceğini varsayalım.
Kapasite hesaplaması 10 iş günü boyunca şu şekilde yapılır:
| Kapasite hesaplaması | Saatler |
|---|---|
| Temel kapasite: 6 geliştirici × 10 gün × 6 saat | 360 |
| Planlanan izin: 1 geliştirici 2 gün boyunca işten uzak kalacak | −12 |
| Nöbet görevi: %50 hazırlık oranına sahip 1 geliştirici | −30 |
| Scrum etkinlikleri: Geliştirici başına 8 saat | −48 |
| Kullanılabilir kapasite | 270 |
| Beklenmedik işler için %20'lik bir pay ayırın | −54 |
| Planlanan işler için kullanılabilir kapasite | 216 |
Örnek olarak %20'lik bir tampon ayırdıktan sonra, planlanan işler için artık 216 saatiniz var. Uygulamada, bu payı önceki sprintleri ne kadar plan dışı işin kesintiye uğrattığına göre belirleyeceksiniz.
Sprint hedefini destekleyen işleri seçin
Kapasite belirlendikten sonra, geliştiriciler Ürün Sahibi ile birlikte ödeme işlemleriyle ilgili birikmiş öğeleri gözden geçirir.
İşte, ilk görev düzeyindeki çaba tahminlerine dayanan açıklayıcı bir seçim:
| Backlog öğesi | Tahmini çaba |
|---|---|
| Kartlı ödeme formunu oluşturun | 48 saat |
| Ödeme sağlayıcısını entegre edin | 88 saat |
| Başarısız ödemeleri ve doğrulama hatalarını yönetin | 50 saat |
| Ödeme onayı ve makbuz teslimatını ekleyin | 24 saat |
| Toplam planlanan iş | 210 saat |
Bu tahminler, planlanan iş kotası içinde 6 saatlik bir marj bırakıyor; buna ek olarak, beklenmedik işler için 54 saatlik bir tampon da bulunuyor. Takım ayrıca ürün birikim listesinde bir gösterge paneli iyileştirmesi de bulunuyor. Bu iyileştirme değerli olsa da, teslimat hedefi için doğrudan katkıda bulunmuyor. Ürün Sahibi ve geliştiriciler, bunu gelecek bir sprint için bırakmaya karar veriyor.
Bir değişiklik olduğunda planı güncelleyin
Altıncı gün, ödeme sağlayıcısı entegrasyonun bir kısmını bozan bir API değişikliği yapar. Geliştiriciler durumu inceler ve gerekli ek iş yükünü tahmin eder.
Orijinal görev sırasına devam etmek yerine, Ürün Sahibi ile bunun etkisini tartışırlar. Düzeltme, kalan kapasiteye sığıyorsa, buna öncelik verebilir ve isteğe bağlı makbuz tasarımını veya önceliği daha düşük başka bir görevi erteleyebilirler. Ödeme onayı ve diğer temel işler yine de "Tamamlanma Tanımı"na uymalıdır.
Düzeltme işi beklenenden daha büyükse, kalan kapsamı ve sprint hedefinin hâlâ ulaşılabilir olup olmadığını yeniden değerlendirmeleri gerekecektir.
Takım, başlangıçta öngörülenden daha az sayıda tamamlanmış birikmiş iş öğesiyle sprint'i bitirebilir. Ancak müşteriler ödeme işlemini amaçlandığı gibi tamamlayabiliyorsa ve iş "Tamamlanma Tanımı"na uyuyorsa, sprint hedefi gerçekleştirilmiş demektir.
Diğer takımlar için sprint hedefi örnekleri
Scrum, tanımlanmış sorumluluklar ve etkinlikler içeren özel bir çerçeve olsa da, aynı planlama yaklaşımını yazılım geliştirme dışındaki işlere de uygulayabilirsiniz.
Örneğin, bir pazarlama takımı “Web semineri açılış sayfasını yayınlamak ve ziyaretçilerin manuel yardım olmadan kayıt olabilmelerini sağlamak” gibi bir hedef belirleyebilir. Bir operasyon takımı ise “Bir sonraki işe alım grubundaki her çalışanın ilk gününde ihtiyaç duyduğu ekipmana ve sistem erişimine sahip olmasını sağlamak” gibi bir hedef belirleyebilir.
Her iki hedef de, sprint boyunca takımın kararlarına yön verebilecek sonuçları tanımlar. Backlog öğeleri ve teslimat planları farklılık gösterebilir, ancak takım yine de kapasitesini göz önünde bulundurmalı ve başarıyla tamamlanan bir teslimatın neye benzeyeceği konusunda mutabık kalmalıdır.
Sprint Planlamasında Sık Yapılan Hatalar ve Bunların Çözüm Yolları
Takımlar, bireysel performansı değerlendirmek için hikaye puanlarını kullandıklarında, net olmayan iş listesi öğelerini toplantıya getirdiklerinde, işleri çok katı bir şekilde dağıttıklarında veya test gereksinimlerini ve dış bağımlılıkları göz ardı ettiklerinde sprint planlaması sorunlarla karşılaşabilir.
Birkaç küçük ayarlamayla, bu sorunları teslimatı etkilemeden önce tespit edebilirsiniz.
| Hata | Neden sorunlara yol açar? | Nasıl düzeltilir? |
| Bireysel performansı ölçmek için hikaye puanlarının kullanılması | Geliştiricileri tamamlanan puanlara göre karşılaştırmak, abartılı tahminlere veya karmaşık işlerden kaçınmaya yol açabilir. | Hikaye puanlarını takım düzeyinde tahminlere odaklayın. Birkaç sprint boyunca tamamlanan işleri gözden geçirin ve iyileştirme aşamasında tahmin değişikliklerini tartışın. Kod kalitesi, işbirliği ve sonuçlar aracılığıyla bireysel performansı değerlendirin. |
| Belirsiz iş yığını ögelerini planlamaya dahil etme | Eksik kabul kriterleri veya yanıtlanmamış teknik sorular, planlamayı neyin geliştirileceğine dair bir tartışmaya dönüştürür ve teslimatın planlanması için daha az zaman kalmasına neden olur. | Geliştiricilerin makul bir tahmin yapabilmeleri için iş yığını iyileştirme aşamasında soruları çözün. Belirsizlik devam ederse, daha küçük ve daha iyi anlaşılmış bir iş parçasını değerlendirin. Mükemmel şartnameler yerine, karar verebilecek kadar netlik sağlamayı hedefleyin. |
| İşe başlamadan önce her görevi birine atama | Sabit görev dağılımı, öncelikler değiştiğinde veya bir geliştirici işini erken bitirirken bir diğerinin yardıma ihtiyaç duyduğunda uyum sağlamayı zorlaştırır. | İşin düzenlenmesini geliştiricilere bırakın. Acil sorumluluklar ve uzmanların katkıları konusunda anlaşın, ardından takım üyelerinin sprint sırasında görevleri üstlenmelerine, eşli çalışmaya veya görevleri yeniden dağıtmalarına izin verin. İşin tüm takım tarafından görünür olmasını sağlayın. |
| Dış bağımlılıkları çözülmemiş bırakmak | Eksik API kimlik bilgileri, güvenlik incelemeleri veya başka bir takımın teslimatları, takımın kendi kontrolü dışında kalan işleri beklemek zorunda kalmasına neden olabilir. | Sprint backlog'u kesinleştirmeden önce, gerekli girdileri, bunları kimin koordine edeceğini ve ne zaman teslim edilmesi gerektiğini belirleyin. Kritik bir bağımlılık belirsizliğini koruyorsa, alternatif bir öğeyi veya takımın bağımsız olarak teslim edebileceği daha küçük kapsamlı bir işi değerlendirin. |
Aynı sorunlar birden fazla sprintte tekrar tekrar ortaya çıkıyorsa, bunları sprint retrospektifine taşıyın ve bir sonraki sprintte test edebileceğiniz bir değişiklik üzerinde anlaşın. Bu sprint retrospektif şablonları, gözlemlerinizi kaydetmenize ve takip edilecek eylemleri belirlemenize yardımcı olabilir.
Sprintin sonunda, sprint gözden geçirme toplantısını kullanarak tamamlanan artışı paydaşlarla birlikte inceleyin ve takımın bundan sonra neye odaklanması gerektiğini tartışın.
ClickUp'ta Sprint Planlaması Nasıl Yapılır?
Görevler, kapasite tahminleri ve planlama kararları farklı araçlara dağılmışsa, sprint planlaması daha fazla çaba gerektirir. ClickUp bu bilgileri bir araya getirir; böylece takım, işleri kapasiteyle birlikte gözden geçirebilir ve plan değiştiğinde planlama kararlarını yeniden değerlendirebilir.
ClickUp Agile Sprint Planlama Şablonu ile başlayın. Şablondaki iş yığını, geliştirme durumu ve kaynak görünümleri, yaklaşan işleri gözden geçirmenize ve sprint planlaması görüşmesine hazırlanmanıza yardımcı olur.
İşte anahtar kararları nasıl alacağınız:
- Yaklaşan işleri değerlendirmeyi kolaylaştırın: Gereksinimleri, kabul kriterlerini, öncelikleri ve bağımlılıkları ClickUp Görevleri'ndeki bir listeye ekleyin. Bu ayrıntılar, geliştiricilerin iş seçmeden önce kapsamı tartışmasına ve çaba tahmininde bulunmasına yardımcı olur. Takım plan üzerinde anlaşmaya vardığında, seçilen görevleri sprinte ekleyin.
- Tutarlı bir planlama aralığı belirleyin: ClickUp Sprints'te sprint süresini ve başlangıç tarihlerini yapılandırın. Çaba düzeyini değerlendirmek ve takımın ne kadar iş üstlenebileceğini belirlemesine yardımcı olmak için Sprint Puanları veya Zaman Tahminlerini kullanın.
- İşlerin uygunluğunu kontrol edin: ClickUp İş Yükü Görünümü'nde atanan işleri her bir kişinin kapasitesiyle karşılaştırın. Dengesiz iş yüklerini gözden geçirin ve tahmini kesinleştirmeden önce olası değişiklikleri tartışın.
- Gündemi ve kararları işin merkezinde tutun: Zamanlı gündem, önerilen sprint hedefi ve ilgili görevlere bağlantılar için ClickUp Docs'u kullanın. Oturum sırasında kapsam kararlarını ve çözülmemiş soruları kaydedin, böylece takım işin ilerlemesiyle bunlara tekrar göz atabilir.
- Planlama görüşmesini kaydedin: ClickUp AI Notetaker, Zoom, Google Meet, Microsoft Teams veya SyncUps'taki toplantıları kaydedebilir ve özet, önemli kararlar ile eylem öğelerini bir belgeye kaydedebilir. Notları gözden geçirin, ardından üzerinde anlaşmaya varılan takip adımlarıyla sprint görevlerini güncelleyin.
- Tartışmalara yön vermek için ilerleme verilerini kullanın: Tamamlanan işleri ve kalan çaba miktarını gözden geçirmek için ClickUp Gösterge Panellerine Sprint Burndown veya Burnup kartları ekleyin. İlerleme planından saptığında, dikkat edilmesi gereken gecikmeler veya kapsam değişiklikleri olup olmadığını görmek için ilgili görevleri inceleyin.
Bir sonraki planlama oturumundan önce Brain²'e şunu sorun: "Son sprint planlaması oturumumuzda hangi çözülmemiş bağımlılıklar ortaya çıktı?" Brain, kaydedilmiş toplantı notlarından bağlam bilgilerini alabilir. Bu ayrıntıları, bir sonraki tahmininizi hazırlarken kullanmadan önce mevcut görevlerle karşılaştırın.
ClickUp fiyatlandırması
En uygun olduğu durumlar: Birden fazla sprint'i, paylaşılan bağımlılıkları ve değişken iş yüklerini yöneten ve tek bir Çalışma Alanı'nda backlog yönetimi, kapasite planlaması ve ilerleme raporlamasına ihtiyaç duyan Scrum takımları. Ayrıca, sprint çalışmalarını daha geniş kapsamlı ürün veya iş projeleriyle koordine eden takımlar için de idealdir.
Şu durumlarda atlayın: Takımınızın yalnızca küçük bir iş yığını ve asgari düzeyde raporlama içeren temel bir Scrum panoya ihtiyacı varsa. ClickUp’ın esnekliği, sprint ayarları, görünümler ve alanlarla ilgili kurulum kararlarıyla sağlanır. Bazı gelişmiş sprint raporlama ve otomasyon özellikleri de üst düzey planlar gerektirir; bu da basit bir ş Akışı için gereksiz olabilir.
Bir Sprint Başlamadan Önce Ne Kadar Planlama Yapmalısınız?
Bir sprint planlaması oturumu, takımın işe başlaması için yeterli netliği sağlamalıdır.
Yukarıdaki zamanlı gündem ve kapasite örneği bir başlangıç noktası sağlar. Bunları takımın iş yüküne göre uyarlayın, ardından tahminleri tamamlanan işler ve kesintilerle karşılaştırarak bir sonraki planlamayı iyileştirin.
ClickUp'ta, planlama notlarını sprint görevlerine bağlayabilir ve işler değiştikçe sprint birikimini güncelleyebilirsiniz. Takım, neyi ayarlayacağına karar verirken üzerinde anlaşmaya varılan plana başvurabilir.
Sprint Planlaması Hakkında Sık Sorulan Sorular
Sprint planlaması ile sürüm planlaması arasındaki fark nedir?
Sprint planlaması, takımınızın bir sprint boyunca neyi başarmayı hedeflediğine ve bu işi nasıl teslim edeceğine odaklanır. Sürüm planlaması ise daha uzun vadeli bir bakış açısını göz önünde bulundurur; örneğin, hangi özelliklerin birkaç sprint boyunca kullanıma sunulabileceği ve kullanıcıların bunları ne zaman alabileceği gibi. Ekipler daha fazla bilgi edindikçe sürüm tahminleri değişebilir, ancak her sprint hedefi, o sprint içindeki çalışmaları yönlendirir.
Sprint planlaması için bir "Hazırlık Tanımı"na mı ihtiyacınız var?
Hayır. Scrum, resmi bir "Hazırlık Tanımı" gerektirmez. Bazı takımlar, seçim öncesinde backlog öğeleri için ortak beklentiler belirlemek amacıyla bunu kullanır; örneğin net gereksinimler, yönetilebilir kapsam ve bilinen bağımlılıklar gibi. Bu kriterleri, takımın gerektiğinde öğeleri iyileştirmesini engellemeden tartışmayı destekleyecek kadar esnek tutun.
Planlamadan sonra bir sprint iptal edilebilir mi?
Evet. Yalnızca Ürün Sahibi bir sprint'i iptal edebilir ve iptal, sprint hedefinin artık geçerliliğini yitirmesi durumunda (örneğin, iş öncelikleri veya piyasa koşullarında önemli değişiklikler olması nedeniyle) bir seçenek olarak değerlendirilebilir. Zor bir görev veya yanlış bir tahmin tek başına, sprint'in iptal edilmesini haklı çıkarmaz.
Sprint ile çeviklik arasındaki fark nedir?
Çeviklik, Çeviklik Manifestosu'nun değer ve ilkelerine dayanan, iş yönetimine yönelik daha geniş kapsamlı bir yaklaşımdır. Sprint, Scrum çerçevesi içinde bir ay veya daha kısa süreli sabit bir dönemdir; bu süre zarfında takım, sprint hedefine ulaşmak için çalışır ve kullanılabilir bir artış oluşturur. Sprint kullanmadan da Çeviklik ilkelerini uygulayabilirsiniz. Örneğin Kanban, sabit uzunlukta yinelemeler gerektirmeden iş akışının kesintisiz devam etmesini destekler.
Bir sprintin birden fazla sprint hedefi olabilir mi?
Scrum, bir sprint hedefini sprintin tek amacı olarak tanımlar. Bu hedefi tehlikeye atmadıkları sürece, diğer öncelikleri destekleyen backlog öğelerini seçebilirsiniz. Takımınızın düzenli olarak birbiriyle ilişkili olmayan birkaç hedefe ihtiyacı varsa, planlama öncesinde işin daha geniş kapsamlı bir ortak sonucu destekleyip desteklemediğini veya çakışan öncelikleri çözmeniz gerekip gerekmediğini tartışın.
Sprint planlaması sırasında hataları hikaye puanlarıyla tahmin etmeli misiniz?
Scrum'da hikaye puanları isteğe bağlıdır; bu, hatalar için de geçerlidir. Hataları tahmin eden takımlar, bunu ne zaman ve neden yapacakları konusunda anlaşmalıdır. Bilinen kusurlar planlama sırasında değerlendirilebilirken, geliştirme sırasında keşfedilen hatalar "Tamamlandı" tanımı için zaten gerekli olan iş kapsamına girebilir. Aynı çabaı iki kez saymaktan kaçının.