Sprint Planlama

Makale
02/26/2013

Mitch Lacey tarafından.Sahip, çevik ve sağlam uyarlamalar ve geliştirmeler konusunda uzman bir danışmanlık firması olan Mitch Lacey & Associates, Inc'dir.

Ocak 2012.

Sprint planlamasının zorlu olması gerekmez.Bu çoğu zaman eğlencelidir ve bütün Scrum ekibinin "Ne yapmaya kendimizi adayabiliriz" sorusuna cevap vermek için birlikte çalışarak dostluklar kurmalarına fırsat tanır. Bu makalede yazarlar koşuşturma planlamasını odaklanmış ve verimli tutmak için örnekler ve stratejiler sağlıyor ve ekiplerin bir koşuşturma planlarken karşılaştıkları yaygın sorunlar için ayrıntılı potansiyel çözümler sunuyor.

Uygulama alanı:

Uygulama Yaşam Döngüsü Yönetimi; Team Foundation Server

Bu makalede

Giriş
Tahmin ve Teslim
Sprint Planlama nedir?
Bunu Nasıl Başarırız?
Sık Karşılaşılan Sorunlar
- Senaryo: Ekip, ürün sahibinin istediği tüm hikayeleri taahhüt edemiyor.
- Senaryo: Ürün sahibi, hazırlıklı gelmiyor.
- Senaryo: Bölüm 1, zaman kutusunu aşıyor.
- Senaryo: Bölüm 2, "timebox"unu aşıyor.
- Senaryo: Ürün sahibi uygun değil.
- Senaryo: Ekip, gereksinim duyduğu kabul ölçütlerine sahip değil.
- Senaryo: Ürün sahibi, bitti demek nedir bilmiyor.
- Senaryo: Scrum Lideri veya ürün sahibi, ekibin tahminlerini/çalışmasını tahmin ediyor/etkiliyor.
Sonuç

Biz plan yapmayız.Biz Scrum yapıyoruz, bu nedenle sadece yürütüyoruz.

Bunu her zaman duyuyorum.İnsanlar, Scrum ve çeviklikte planlama, tahmin, toplantı, hiçbir şey olmadığını düşünür!Bu gerçeklikten daha uzak olamaz.Hızlı bir projede çeşitli seviyelerde plan yapıyoruz: günlük plan ya da günlük durum, haftalık planlar (sprint veya yineleme, biriktirme), sürüm planı (ürün biriktirme) ve olası daha fazlası.

Bir sprint planlamasına odaklanalım.

Tahmin ve Teslim

2011 yazında, Ken Schwaber ve Jeff Sutherland yaptıkları Scrum Kılavuzunu incelemiştir.Bunun içinde, ekibin ürün sahibi ve müşterilere yaptığı taahhüt olan Scrum olarak bilinen uzun kurulan davranış kaldırıldı.Tamamlama tahmin ile yer değiştirmiştir.Ekiplerin çalışmalarını tahmin edebildiklerini ancak ona sadık kalmadıklarını söylüyorlar.

Mantıklarını anlamama karşın, aşağıdaki nedenlerle taahhütleri tercih ederim:

Bir şeyi yapıyor olmak ekibi sadece tahminden daha farklı bir zihniyete sürükler.Bir ekip tahmin yapıyorsa, yapabileceklerini söyledikleri şeyleri gerçekleştirememeleri kabul edilebilir bir davranıştır.Ekipler kendi tahminlerinden ders alabilirler, ancak sonuçta daha az tahmin sapması olduğunda, tahmin yapan ekiplerin sapmayı azaltması taahhüt yapan ekiplerinkinden daha uzun sürmektedir.
Tahmin ya da öngörü ürün biriktirimi için uygundur.Ancak, ekipler öyküleri ürün biriktirmeden sprint biriktirmeye taşıyıp ayırdıklarında, başka bir öğe boyu seviyesi eklerler, küçük ayrıntıları bulurlar ve kendi kendilerine "Bunu teslim edebilir miyiz?" diye sorarlar. Tahminin ekibi "sadece tahmine ihtiyacımız var, bir şeyleri atladıysak sorun yok, daha sonra hepsini hallederiz" diyerek tembel bir duruma düşürme riski vardır.

Ve daha hafif bir notta, karınıza, kocanıza veya sevgilinize şöyle dediğinizi hayal edin "Tahmin ediyorum ki on yıl beraber olacağız" veya karşıt olarak "Kendimi sana teslim ediyorum, evet herşey yolunda gidecek".

Sonuç olarak, Scrum ortak sağduyu hakkındadır.Size teslim yaklaşımı ve tahmin yaklaşımının ikisini de denemenizi öneririm.Bu, kullandığınız kelimelerle değil tamamen öğrenmeyle ilgili olduğu için, mantıklı olun, her ikisini de deneyin ve hem sizin hem de ekibiniz ve şirketiniz için en iyi olanı kullanın.

Sprint Planlama Nedir?

Ekibin bir sonraki sprintte ne oluşturacağını ve ekibin bunu nasıl oluşturacağını planlamak için bir sprint planlama toplantısı yaptık.Sprint planlama toplantı olarak başvurulmasına rağmen, o aslında iki çok farklı bölümden oluşur.Bölüm 1, ekipten oluşturması istenen şeye odaklanır ve hem ürün sahibi hem de ekip tarafından katılım gösterilir.Bölüm 2, ekibin, istenen işlevselliği nasıl oluşturmayı planladığına odaklanır.Tüm takımın Part 2’ye katılmak zorunda olmasına rağmen, ürün sahibinin katılımı isteğe bağlıdır.Herhangi bir nedenle, ürün sahibi Kısım 2'ye katılmazsa, ürün sahibi sorular için ulaşılabilir olmalıdır.

Sprint planlama toplantısının 1. Kısmında ürün sahibinin istediği hikaye kümelerini ekibe açıklama fırsatı vardır.Bu, hikayelerin hangi kısmı üzerine son derece ayrıntılı bir oturumdur.Ürün sahibi hikayeleri sunar, hikaye unsurlarının nasıl etkileşimde olduğunu gösterir ve arabirim boyunca kılavuzluk eder.Buna ek olarak, altyapı veya mimari öğeleri inceleyebilirler.Hedef, ekip üyelerinin kolektif zihinlerini işlevselliği nasıl oluşturacaklarını anlamaya başlamalarına yetecek kadar bilgiyle doldurmaktır.Ekip, toplantının nasıl olacağına ilişkin bilgi toplamak üzere şu şekilde çeşitli sorular soracaktır:

"Tüm bu öykülerin kabulü ölçütü nedir?"
"Hangi veri kaynaklarını kullanmakta olduğumuzu düşünüyorsunuz?"
"Bu Bileşende Arayüz Nasıl Görünmelidir?"

Sprint planlama toplantısının 2. Kısmında, ekip ilgisini sprint sırasında tamamlanması gereken öykü ve görevlerin bir listesi olan sprint biriktirmesini oluşturmaya yöneltir.Biriktirme listesi oluşturmak için ekip, ürün sahibinin istediği her bir hikayeyi görev düzeyine ayırır ve her göreve saatlik bir tahmin verilir.Bölüm 2'nin sonunda, ekip sprint esnasında tamamlamaya karar vereceği öyküleri seçebilir.

Sprint planlama toplantısının iki bölümü birlikte iki - sekiz saat sürebilir.Kullandığım genel baş parmak kuralı, her parçanın her bir haftalık sprint uzunluğu için bir saat sürmesi gerektiğidir.Başka bir deyişle, bir haftalık sprint çalıştırıyorsam, toplantı toplam iki saat sürecektir (1. Bölüm için bir saat ve 2. Bölüm için bir saat).Diğer taraftan, dört haftalık sprint'ler çalıştırıyorsam, toplantı toplam sekiz saat (Kısım 1 için dört saat ve kısım 2 için dört saat) sürer.

Bunu Nasıl Başarırız?

Takım öyküler listesini tamamlamayı vaat eden sprint planlama toplantısını terk ettiği sürece, takım sprint planlama amacını gerçekleştirmiş olacaktır.Ekibi, her üyenin sorumluluk yüklenmekte rahat olacağı bir duruma getirmek ise biraz ön planlama ve kolaylaştırma gerektirir.

Ürün sahibi sprint planlama sırasında tek bir işe sahiptir: toplantıya katılarak istenen hikayeler grubunu anlatabilmek.Ekibin hedefi, hikayeleri ürün sahibinin bakış açısından anlayarak ürün sahibinin vizyonunu paylaşmaktır.Scrum Yöneticisi, ekibin yeterince soru sorduğundan ve kabul ölçütleri, taslaklar ve tahminler dahil olmak üzere tüm sonuç verilerini yakaladığından emin olmalıdır.Ayrıca, Scrum Yöneticisi ürün sahibine ekibin soruları görevlere ayırmaya başladıktan sonra ek soruları olabileceğini belirtmelidir.Ürün sahibinin nokta toplamları yaklaşık olarak takımın tarihsel hızına karşılık gelen hikayeler sunmasına rağmen, takım sonuçta gerçekten sprint planlama toplantısının 1. ve 2. Bölümleri sırasında ne öğrendiğine dayanarak verilen bir sprintteki öykülerin tamamını alıp alamayacağına karar verecek.

Takım bilgilerin tamamını ürün sahibinden aldıktan sonra öyküleri görevlere bölmeli ve bir sprint biriktirme listesi oluşturmalı, bu işlem belli bir sprint için öykülerin, notların, kabul ölçütünün, görevlerin ve tahminlerin tamamını yakalar.Bunu yapmak için birçok yöntem olsa da, ben tüm ekip üyelerinin düşüncelerinden yararlanan ve herkese görev ayrıştırmada söz hakkı veren aşağıdaki yöntemi kullanıyorum.

ScrumMaster'a veya toplantı yöneticisine bir öyküyü okutun ve "Herkes anlıyor mu? diye sorun. Ekip ürün sahibi ile kısa süre önce bunu tartıştığından anlamalıdır.Ekipteki bir kişi anlamıyorsa, öyküye yeniden yönelerek biraz zaman geçirin ve ürün sahibinin zorunlu sorularını sorun.
Daha sonra her bir ekip üyesi bir yapışkan pad yakalar.Her takım üyesinden tek bir görevi yapışkan notlara yazmalarını ve onu da masanın ortasına bırakmalarını isteyin.
- Her yapışkan not masanın ortasına bırakıldığında, bırakan görevi duyurur.O halde "depolanmış yordamı güncelle" yazılırsa, bu yüksek sesli demektir.Bu, yeni fikirler doğuracağı ve diğerlerinin "Evet, veri kaynağını güncelleştirmemiz gerekiyor" demelerine neden olacağı için önemlidir. Bu noktada, bir kişi yapışkan nota "veri kaynağını güncelleştir" yazarak ortaya atacaktır.Bu beyin fırtınası etkinliği, tüm ilişkili görevleri ortaya koyma konusunda gerçekten yararlıdır.Şu anda yinelenenler konusunda endişe etmeyin.Tüm görev yapışkan notlarının atılması, hikaye başına yaklaşık beş - on dakika sürer.
Yapışkan Notların tümü tablo üzerinde olduğunda, bunları sıralama zamanı gelir.Tümünü bir duvara yerleştirin, geri gidin ve bakın; bir sürü yapışkan not!Yinelenenleri tanımlayarak başlayın; yineleme gibi görünen yapışkan notları üst üste getirin.Daha sonra, birbirine benzedikleri için ya da bağımlı oldukları için uyumlu olan görevleri arayın.Örneğin, iki yapışkan notun benzer bir ilişkisi varsa, bunları aşağıdaki resimde gösterildiği gibi bir araya ve karşı karşıya koyun:

İki görev neredeyse aynı olacak şekilde çok yakından ilişkiliyse, onları aşağıda gösterildiği biçimde, neredeyse tamamen örtüştürün:

Yapışkan notları sıralayarak ekip görev listesini çağırabilir ve kalanlar arasındaki ilişkileri görselleştirebilir.
Görevler sıralandığında, tahmin etme zamanı gelir.Görev tahmini için yalnızca tek bir farkla planlama poker tekniğini kullanıyorum: Kartlardaki numaralar puan yerine saatleri temsil ediyor.Bunu yapmamın nedeni insanların özellikle büyük görevlerde gereksiz ayrıntılar üzerinde saatlerce uğraşmalarıdır.Endişelenmekte haklılar.Çok sıklıkla şirketler, ekibi yenmek için sopa olarak tahmin kullanır."8 saat sürer dediniz ama 12 saat sürdü.Sorun nedir?" veya "8 saat sürecek dediniz ancak yalnızca 4 saat sürdü.Tahminlerinizi dolduruyorsunuz."

Kartların hikaye noktası tahminlerini soyut tuttuğu şekilde, görev tahmini için kartların kullanılması ekibin arasından seçim yapılabilecek sabit sayı kümesi olduğu için daha özgürdür, ancak sonunda aralarından birisini seçmeye zorlanırlar.Bir görevin 6 saat olarak mı, 6,5 saat olarak mı yoksa 7 saat olarak mı tahmin edilmesi gerektiğine dair alevli tartışmaları ortadan kaldırır.

En son tahmin ne olursa olsun, tahminin ekip tarafından yapıldığını ve ekibin güvenini artırmasına yardımcı olmak ve hız bakımından ürün sahibinin istediği işi başarıp başarmayacağına karar vermek için yalnızca ekip tarafından kullanılmasının amaçlandığını unutmayın.Görev tahminleri, ölçüm değildir ve o amaçla kullanılmamalıdır.Hiçbir zaman tahminleri ekibe karşı bir silah olarak kullanmayın.
Görevler tahmin edildiğine göre şimdi ekibin daha fazla çalışma alma kapasitesine sahip olup olmadığını belirlemesi gerekir.Bunu yapmak için sizin ekibin kapasitesini, sprint boyunca ekibin uygun olduğu toplam saati bilmeniz gerekir.Kapasite belirlemek kendini tam olarak bu işe adamış bir ekibiniz varsa kolaydır, ancak birden fazla proje arasında bölünmüş yarı zamanlı kişilerden oluşan bir ekibiniz varsa bu iş zorlaşır.Herkesten günlük olarak projede ne kadar saat çalışabileceklerini yazmalarını isteyin (veya sprint başına toplam olarak)Takım için kullanılabilir saatlerin toplam sayısını almak için tüm sayıları birlikte ekleyin.Ekibin kapasitesinin 200 saat olduğunu varsayalım.Bir öykünün görevlerinin özetinin 30 saat alması tahmine diliyorsa, ekibe "Daha fazla iş alabilir miyiz?" diye sorun. Bu erken aşamada, cevap kesinlikle evettir.

Doldurmak için daha fazla kapasiteye sahip olduğunuzdan, sonraki öyküye gidin ve birden beşe kadar olan adımları yineleyin.

(Bu görevi Team Foundation Server kullanarak nasıl gerçekleştireceğiniz hakkında bilgi için bkz: Hızlı planlama ve yineleme.)

Belirli bir noktada, "Daha fazla iş alabilir miyiz?" sorusuna cevap vermekte zorlanacağınız zamanlar olacak. Bu takımınızın kapasitesine yaklaştığınız için böyledir.Bu işlem boyunca çalıştıkça, sprint kapasitesini doldurmak istemediğinizi göz önünde bulundurun.Bir bardağı ağzına kadar suyla doldurursanız, dökülme ihtimali çok yüksektir.Aynısı, sprint'ler için de doğrudur.Tahmini saatler tüm kullanılabilir zamanı tüketiyor ve sprintte daha sonra yeni bir görev tanımlanıyorsa, işler fazla gelir.Ortaya çıkabilecek görevler için yer bırakmalısınız.

Sprint taahhütleri düşünüldüğünde, eski sprintlerdeki geçmişe dönük verileri göz önünde bulundurmak kolaylaşır.Ekip sürekli olarak daha fazla iş getirmek zorunda mı kalıyor?Belki de ekip, sprint planlaması sırasında daha fazlasını taahhüt edebilir.Ekip sürekli olarak bir koşuşturma döneminde tüm işleri tamamlayamıyor mu?Ekip, tamamlanmamış sprint'lerin kök nedenini belirleyinceye kadar taahhütleri konusunda daha tutucu olmak zorunda kalabilir.

"Bardağınız ne kadar doldurulur" sorusuna yanıt vermenin bir yolu, plan boyutu büyümesinin dikkate alınmasıdır.Plan boyutu büyümesi, harcanan gerçek saatlerin ilk tahminlerle nasıl karşılaştırıldığını ölçer.Örneğin, ekibimizin 200 saatlik kapasiteye sahip olduğunu düşünelim.Ekip, tahminlere dayalı olarak inandığı şeyin 190 saat olacağına sadık kalır.Sprint sonunda, takım %20'lik planlı bir boyut büyümesiyle sonuçlanan, 240 gerçek çalışma saati gerektiren öyküleri hesaplar.

Bu tutarsızlığı bulan bir takımın, nedenleri geçmişe dönük araştırmaları sırasında bir süre geçirmesi gerekir:

Yürütme yapılırken, planlama sırasında tanımlanmamış olan birçok görevin olduğu mu anlaşıldı?
Ekip mevcut beceri kümesine dayalı olarak görevlerini küçümsüyor mu?
Ekip kapasiteyi fazla mı tahmin etti?
Ve buna benzer.

Ekip, aynı zamanda bir sonraki sprint planlama toplantısı sırasında bir hikayeye bağlı kalıp kalmayacağını belirlerken plan boyutunun büyümesini de göz önünde bulundurmalıdır.Örneğimize geri dönecek olursak, ekip hala 200 saatlik bir kapasite tahmin ediyorsa, ekip geçmiş verilere dayanarak "beklenen" plan boyutu büyümesi için en yüksek telafinin %20'sini çıkarmalıdır.Diğer bir deyişle, en azından bu sprint için dökülmeleri önlemek için ekip 160 saat aldığında kapasitesini bildirmesi gerekir.

Plan boyutu büyümesini göz önünde bulundurmak sprintin ne kadar dolu olması gerektiğini belirlemenin bir yoludur.Ancak, hedefin kapasiteyle tam olarak eşleşmediğine dikkat edin.Bunun yerine, ekibin uygun sayıda (ekibe fazla yüklenilmeden, ekibi teşvik edecek sayıda) hikayeye bağlanarak kendine güvenmesi sağlanır.Diğer tüm faktörler eşit kalırsa, plan boyutu büyümesi, sonraki sprint'in yaklaşık ne kadar dolu olması gerektiğini belirlemenin yalnızca bir yoludur.

Tüm öyküler tahmin edildiğinde veya tüm zaman öykülere harcandığında, ürün sahibine geri dönün ve ekibin teslim etme sözü verdiği sprint biriktirmeyi paylaşın.Sprint şimdi başlıyor, lütfen çalışmaya başlayalım!

Sık Karşılaşılan Sorunlar

Ekiplerin Scrum'u benimsemesine yardımcı olmak amacıyla onlara danışmanlık verdiğim yıllar boyunca, sprint planlamanın başarılı olmasını engelleyen aynı türden birçok problem gördüm.Sprint planlama kolay görünmesine rağmen, Scrum ile henüz çalışmaya başlamış takımlar uğraşma eğilimindedir.Bu sorunların çoğu ve olası çözümleri bu bölümde ayrıntılı olarak anlatılmıştır.

Senaryo: Ekip, ürün sahibinin istediği tüm hikayeleri taahhüt edemiyor.

Bunun ara sıra yapılacağını bilmelisiniz.Takım, bu konuda daha önce ele alınmış olan 4. ve 5. adımlardaki verilerle sözleri yedeklediği sürece, ürün sahibi memnun olacaktır.Bu başarısızlığın fazla doldurma ya da büyük görevler sonucu olup olmadığından emin olmak için dikkatli olmak istersiniz.Scrum Yöneticisi, aşırı tutucu görünen tahminleri doğru olduklarından emin olmak için sorgulamalıdır.Ürün sahibi, yalnızca çift rakamlı tahmine sahip bir görevi sorgulamalıdır.İki çalışma gününden daha fazla süreceği tahmin edilen bir görev daha küçük görevlere bölünmeli ve tekrar bir tahminde bulunulmalı.Bu, tüm projeler için doğrudur, ancak haftalık veya iki haftalık sprintler çalıştıran ekipler için özellikle yorucudur.

Senaryo: Ürün sahibi, hazırlıklı gelmiyor.

Bir Scrum değeri, saygıdır.Bir toplantıya hazırlıksız gelmek saygısızcadır.O halde ürün sahibi, ekibin gereksinim duyduğu bilgiler olmadan görünürse, ekip ne yapmalıdır?Bir seçeneğin ürün sahibi hazır olana kadar toplantıyı ertelemek olmasına rağmen, böyle yapmak yalnızca aynı davranışı teşvik eder – bundan kaçının.Diğer bir seçenek, sprinti iptal etmektir.Bu çalışabilmesine rağmen aşırıdır.

Bence en iyi çözüm iki katlı olmasıdır.İlk olarak, ürün biriktirme bir çeşit öncelik sırasında olmalıdır, böylelikle ürün sahibinin uygun bir öykü dizisi yoksa, ekip ve ürün sahibi kapasitelerine yeteceğine inanana kadar öyküleri öncelik sırasına göre tartışabilir.Böylece, ekip her zaman olduğu gibi toplantının 2. kısmında tam taahhüde karar verebilir.

Toplantıdan sonra ScrumMaster'ın neden ürün sahibinin hazır olmadığını anlaması için çalışması gerekir.Bağlantı yetersizliği sorunu varsa, ScrumMaster ürün sahibini toplantıya bir dizi öykü ile gelmenin önemi konusunda bilgilendirebilir.Diğer taraftan sorun, ürün sahibinin hazırlanamamasıysa (örneğin; ekibin temizleme işlemine yardımcı olmaması nedeniyle), ScrumMaster bu sorunları çözmek için de yardımcı olmalıdır.

Senaryo: Bölüm 1, zaman kutusunu aşıyor.

Diğer değer odaktadır.Toplantının 1. kısmı bitiyorsa, odak eksikliği bunun belirtisidir.Bazen çok sayıda hikayenin açıklanmaya çalışılması, önceliklendirme ve hazırlık eksikliği nedeniyle, ürün sahibi odağı kaybeder.Diğer zamanlarda odağın olmaması, ekibin "ne" ile ilgili görüşmelerinin "nasıl" ile ilgili konuşmalarla sapmasından kaynaklanabilir.

Scrum Yöneticisi, ürün sahibinin tam olarak açıklanamayan tüm hikayeleri tabloda göstermesi ve ekibin 1. Kısım ile ilgili olarak detaylı uygulama tartışmaları yapması konusunda ısrar ederek işlerin ilerlemesine yardımcı olmalıdır.Odaklanılmamış bir tartışma için uygulanabilecek basit bir düzeltme, kronometre veya zamanlayıcı kullanılmasıdır.

Senaryo: Bölüm 2, "timebox"unu aşıyor.

Yeniden odaklan.Çok konuşan bir ekibiniz varsa, tartışmaları sınırlayacak disiplinin getirilmesi, bazen toplantıların düzene sokulması için gerekli olan tek şeydir.Bir mutfak saati getirin ve görev tahminleri arasındaki görüşmeleri bir-iki dakikada tutun.Hedef doğruluktur, %100% kesinlik değil.

Diğer zamanlarda, Bölüm 2 sırasında odağın olmaması, sprint yürütme sırasında ürün biriktirme listesi temizlemesinin olmadığını belirtir.Temizlik, ekibin gelecekteki öykülere bakıp ürün sahibiyle birlikte tasarım yönlendirmelerini sabitleştirmek için öyküler ya da değişiklikler eklemesi veya mimari sorunlarla ilgilenmesi için uygun bir zamandır.Düzenli ürün biriktirme listesi temizliği olmaksızın sprint biriktirme listesi planlaması hantal ve eziyetli olur.

Senaryo: Ürün sahibi uygun değil.

Ürün sahibi herhangi bir nedenle toplantıya katılamıyorsa ve proxy atamadıysa, ürün sahibi toplantıyı hazırlıksız gelmiş gibi davranın.Üst öğeler arasında çalışın ve onları elinizden geldiği kadar iyi yapın.Ürün sahibinin zamanlamasına uyacak şekilde toplantı saatini değiştirmek isteyebilirsiniz.Yapma.Toplantı saatinin kaydırılması, bir kişinin gereksinimi için birçoğunun gereksiniminden taviz verilmesine neden olur.Buna değmez.

Senaryo: Ekip, gereksinim duyduğu kabul ölçütlerine sahip değil.

Ben her zaman ekiplere Kısım 1 sırasında ürün sahibine "Bunun kabul ölçütleri nelerdir?" veya "İşi kabul etmenizi sağlamak için ne yapmamız gerekiyor?" sorusunu sormalarını öneririm. Bu yapılmadığında, Kısım 2'de ekip görevleri belirlerken öyküyü nasıl bitirecekleri konusunda ekibin hiçbir fikri olmaz.Ekibin 1. kısımda duyduklarına dayanarak tahmin etmesi gerekiyorsa, ürün sahibinin sprint sonunda öykünün bitmediğine karar vermesi riski vardır.Her öykü için başlangıçtan kabul ölçütünü isteyin.Scrum Liderleri—bu verileri sağlamak için ürün sahiplerinize koçluk yapın.

Senaryo: Ürün sahibi, bitti demek nedir bilmiyor.

Ekibin kabul ölçütü istemesi gibi, ürün sahibine ekibin "hikaye bitti" ifadesiyle ne demek istediği konusunda güncel bir açıklama yapılması gerekir. Bu bitti listesi açık şekilde gönderilmiş, güncel ve ürün sahibinin her zaman kullanabileceği bir şey olmalıdır.Bittinin nasıl görüneceğiyle ilgili ortak bir anlayış olmayacağından güncel olmayan bir bitti listesi plan yapmayı zorlaştırır.Bitti listesinin her sprint gözden geçirmesinin veya geçmişe dönük bir parçası olduğunun güncelleştirildiğinden emin olun.

Senaryo: Scrum Lideri veya ürün sahibi, ekibin tahminlerini/çalışmasını tahmin ediyor/etkiliyor.

Ürün sahibi, toplantının 2. Kısmında kabul edilir, ancak ürün sahibinin 2. Kısımdaki rolü herhangi bir gerekliliği açıklamak ya da belirli bir soruya yanıt vermekle sınırlandırılmalıdır.Ürün sahibi, kesinlikle ekibin hikayenin nasıl uygulanacağına yönelik tartışmasına karışmamalı ve herhangi bir görevin tahminine katkıda bulunmamalıdır.Ürün sahibi, ekibin işi yapacağına güvenmelidir.

Ürün sahibi bu yönergeler dışında davranıyorsa, ScrumMaster ürün sahibini daha iyi bir rol için eğitmelidir.Ürün sahibi daha pasif bir rolü kabul etmezse, ScrumMaster ürün sahibinden gitmesini isteyebilir.

Sprint planlamasının zorlu olması gerekmez.Bu çoğu zaman eğlencelidir ve bütün Scrum ekibinin "Ne yapmaya kendimizi adayabiliriz" sorusuna cevap vermek için birlikte çalışarak dostluklar kurmalarına fırsat tanır. Unutmayın, eğer toplantılarınızın uzun sürdüğünü fark ederseniz, muhtemelen buna kök neden meseleleri yol açıyordur.ScrumMaster iseniz, ürün sahibi ve ekibin ürünün biriktirme listesini düzenlediğinden emin olarak odağın toplantıda tutulmasını sağlayın.Toplantıdan önce öykü kabul ölçütlerini hazır bulundurarak ürün sahibinin hazırlıklı gelmesini sağlayın.Son olarak, sprinte ne katkıları olabileceğini belirleyerek ürün sahibi ve ekibin elinizdeki göreve odaklanmasına yardımcı olun.