Bölüm 7: Story Estimation (Efor Tahminleme) Nedir? 📏🤔

Belki de başlangıçtaki en zorlu işlerden biri de bir eforun büyüklük tahminlemesinin yapılmasıdır. Product Backlog’daki tüm Story’lere bir eforu temsil eden puan atanır. Efor tahminleme için birkaç farklı yöntem kullanılmaktadır. Bunlardan bazılarını diğer yazılarımda detaylandıracağım. Efor tahminleme ile ilgili neden, nasıl ve ne zaman sorularına cevap vereceğim fakat öncesinde önemli bir noktayı aydınlatalım. Backlog’da hangi kalemler vardı hatırlıyor muyuz? 🤔

Initiatives/Themes > Epic > User Story > Task/Subtask 👌

İngilizcede “Story Estimation” olarak adlandırılan efor tahminleme işlemi sadece User Story’ler için yapıldığını unutmayalım. ⚡

Story Points (hikaye puanları) kavramı ilk bakışta kolay görünebilir fakat doğru uygulanması ve alışılması biraz zaman alıyor. User Story’lerin puanlama işlemi asla süre üzerinden değil işin büyüklüğü üzerinden gerçekleştirilmeli ve göreceli olmalıdır. Yani önünüzde örnek varsa o örneklerdeki puanları, yoksa da benzer User Story’lerdeki puanlarla karşılaştırarak bir puanlama yapabilirsiniz. Biraz daha detay mı gerekiyor? Hadi o zaman 🙂

Daha önce neler yapmıştık? Developer Team, Product Owner, Architectures, Stakeholders gibi teknik ekip arkadaşlarımız ile birlikte bir Product Backlog oluşturmuştuk. Şimdi de bu yığın içindeki hazır Story’lerimizin eforlarını büyüklüklerine göre ölçeklendireceğiz ama önce bu işi neden yaptığımızı bir tartışalım.

Story Estimation neden yapılır?

Unutmayın ki ölçemediğiniz şeyi yönetemezsiniz. Efor tahminlesi yapmanın ilk nedeni Product Backlog’taki işleri önceliklendirebilmek. Böylece önümüze çıkacak engelleri önceden görebilir ve ona göre konum alabiliriz. Bu da bize zamandan tasarruf olarak geri dönecektir. 😊

Story’leri oluşturuyorsunuz ve Backlog giderek büyümeye başladı. Büyüdükçe de karmaşıklaşmaya.. 😲 İlk Sprint’i koşmaya başlayacaksınız ama hangi işin ne kadar büyük olduğunu bilmiyorsunuz.. Belki o işi tamamlamak Sprint boyunca mümkün olmayacak.. Sprint’e dahil edeceğiniz iş miktarını ve Sprint sonunda ortaya çıkacak Increments’leri (ürün) hesaplamanız gerekiyor.. 🧾

Oluşan o büyük yığının içinde hangi işlerin ne kadar büyük olduğunu ve öncelikli olduğunu bilmeniz gerekiyor. Bu büyüklükler ayrıca maliyetleri de temsil ettiği için önemli. Bir diğer nedeni de; özelliğin tamamlanması için gereken iş miktarını ve ayrıca her bir Sprint’e ne kadar iş kattığınızı bilmeniz gerekiyor. Bir Sprint’e dahil ettiğiniz işi, ne kadarını bitirdiğinizi, nelerin eksik kaldığını ölçmeniz ve bir sonraki Sprint’i bu değerler doğrultusunda planlamanız gerekecek. Bu aşamalardan ileride tekrar detaylıca bahsedeceğim. Şimdi İlk işimiz Story Sizing (hikaye boyutlandırma). Az önce bahsettiğim gibi, bunu yaparak Sprint’in Velocity’sinin (hızının) izlenmesini sağlarken, Sprint’in kapasitesini de anlamış olacağız.

Evet, iki yeni kavramla daha tanıştık. 😄 Şimdilik Story Sizing için bir senaryo yazalım ve sonra dönüp yukarıdaki yazıyı tekrar okuyalım. O zaman herşey daha net anlaşılacak. 😉 Velocity’nin ne olduğunu Release Planning başlığında detaylıca açıklayacağım. 🙂

İki arkadaşınıza bir futbol sahasının iki korner direği arasını 1 tur koşmalarının ne kadar süreceğini sorun.. İkisi de aslında sahanın tam uzunluğunu bilmiyor, kendilerini süzüp göz kararı (yaş, boy, kilo, kondisyon kriterleri ile) bir değerlendirme yapıyorlar ve sonuçta birbirlerinden farklı süre tahmininde bulunuyorlar.. İşte efor tahminlemede istemediğimiz tam da bu! 😄 İstediğimiz şey ise; süre cinsinden yaklaşmak yerine sahanın büyüklüğünü (uzunluk cinsinden) yani işin büyüklüğünü tahmin etmeleri. Böylece ne ile karşı karşıya olduklarını görebilmelerini sağlamak.

Story Estimation nasıl yapılır? Story Sizing toplantısı nedir?

Eforlama süreci için en bilinen yöntem fibonacci sayıları ve T-shirt sizeları (XSmall, Small, Medium vs.) kullanmaktır. Bunlarının kullanılmasının sebebi işin büyüklüğünü aşina olduğumuz bir değer üzerinden kıyaslama yapabilmemizi sağlamak. 🙂 Bazı şirketler işi renklendirip kaykay, bisiklet, motorsiklet, araba gibi büyüklük kavramları kullanılıyor. Eğer yöneticinizi ikna edip bu linkteki kartları satın almasını onaylatırsanız toplantılarda bu gösterişli kartları da kullanabilirsiniz. 😅 Ben fibonacci yöntemini pratikte çok gerçekçi bulmadığım için 1–3–5–8–10 sayılarını kullanıyorum. Benim için, eğer bir iş 10'dan büyükse riski de büyüktür ve daha küçük parçalara bölünebilir. Bu iş için yeni bir story oluşturmak daha keskin bir tahminleme yapmanızı sağlayacaktır. Sizing (eforlama) işlemleri için bağımsız sizing toplantıları düzenleyebilir veya bir sonraki başlıkta bahsedeceğim toplantılarda gerçekleştirebilirsiniz.

Sizing için bir diğer kullanılan yöntem ise “Planning Poker”. Onun dinamikleri biraz daha farklı olduğu için başka bir yazımda açıklayacağım.

Sizing işlemlerini yaparken kullanabileceğiniz faydalı ve uygulaması kolay bir şablonu aşağıda paylaşıyorum. Bu şablon riskleri kolayca görmenizi ve Sprint planlama aşamasında daha keskin eforlama yapmanızı sağlayacaktır.

Story Estimation ne zaman yapılır?

User Story’leri oluşturulurken efor tahminlemesi yapılamaz. Bunun için daha kapsamlı ve ilgili ekiplerin dahil olacağı bir toplantı organize etmek gerekir. Ne zaman yapılacağı projenin gidişatına veya takımın tercihine göre değişir. Story Sizing genelde aşağıdaki aşamalarda yapılması tercih edilir.

Backlog Refinement Meeting: Bir diğer adı Backlog Grooming olan bu toplantıda, Product Backlog’daki itemlara ayrıntı ekleme, efor tahminleme ve yeniden sıralama gibi güncellemeler gerçekleştirilir. Takım, Backlog Refinement toplantılarının ne zaman ve nasıl yapılacağına kendisi karar verir.

Şunu hatırlamakta fayda var; Backlog’daki itemların güncellenmesi ile ilgili bir kısıtlama yok. Product Owner tarafından veya onun takdiriyle projenin her aşamasında ve herkes tarafından güncellenebilir. (Henüz işleme alınmamış itemlardan bahsettiğimizi unutmayalım 😊)

Release Planning Meeting: Bir sonraki Release publish edilmeden önce yapılması hedeflenen işlerin, bir diğer tabirle müşteriye sunulmak üzere tamamlanması gereken feature’ların seçildiği ve yol haritasının oluşturulduğu toplantılardır. Efor tahminleme süreci bu toplantılara dahil edilebilir.

.

Sprint Planning Meeting: Bir Sprint’te tamamlanması planlanan işler Product Backlog’tan seçilir ve Sprint Backlog’a atılır. Genellikle birçok ekip efor tahminleme işlemini bu toplantıda gerçekleştirmektedir.

Release ile Sprint (iteration) farkını birkaç başlık sonra öğreneceğiz ama şimdilik PMBOK’dan aldığım şu güzel görsel ile giriş yapabilirim.

Story Estimation ne zaman yapılır açıkladık. Şimdi de bir Story Estimation süreci nasıl yürütülür adım adım açıklayalım.

• Developer Team, System architectures, QA Team ve diğer teknik paydaşlar katılır.
• Product Owner, üründe olmasını istediği özelliği açıklar. Bu aşamada, talep edilen feature’ın hedefleri (goals) ve bu özelliği geliştirerek elde etmeye çalıştığımız metrikleri anlamak efor tahminleme aşamasında kritik önem taşıyacaktır. O yüzden Developer Team’in dikkatle dinlemesi ve Scrum Master’ın sorgulayıcı olması çok önemli 👮
• Product Owner, daha sonra her bir User Story’nin üzerinden geçer ve söz konusu Story’den neyin gerekli olduğuna ilişkin üst düzey bir genel bakış oluşturur.
• Ekip daha sonra Story’nin teknik ayrıntılarını tartışır ve kabul kriterlerini inceleyerek (değişiklik gerekiyorsa güncelleyerek) herkesin işi anladığından emin olur.
• Scrum Master daha sonra Fibonacci sayılarını (1,3,5,8,10) (veya sizing için kullandıkları farklı bir yöntem varsa onu) kullanarak bir tahmin ister ve ekip işin büyüklüğünü temsil eden bir sayı gösterir.
• Ekip Story’nin 10'dan büyük olduğunu düşünürse, Product Owner Story’i daha küçük parçalara ayırır çünkü bir Sprint’te 10'dan daha büyük bir Story’nin varlığı Sprintin zamanında tamamlanmasını riske sokabilir.
• Ekip üyeleri seçtikleri sayı için gerekçelerini açıklar. Örneğin; bir Developer Team üyesi, API ile ilgili bir hikaye için kısmi bir kontrol oluşturmaları gerektiğini düşünerek daha büyük bir sayı gönderebilir, ancak diğerleri, daha önce böyle bir kod parçası kullandıklarını ve bu yapıyı oradan temin edebileceklerini ve bu nedenle çok fazla çalışma gerektirmeyeceğni işaret edebilir. Herkes tek fikir olana ve tek bir sayı üzerinde anlaşana kadar tartışma devam eder.
• Story estimating Testing sürecini de kapsadığı için QA ekip temsilcisinin katılması ve toplantı sırasında test sürecinin her bir Story’e dahil edildiğinden emin olmalıdır.
• Eğer Story bilinmezler içeriyor ve takım eksik bilgi nedeniyle eforlayamıyorsa toplantıda aşağı yukarı bir tahminle yaparlar. Product Owner, doğru bir şekilde tekrar tahminlenmesi için detayları öğrenip bir sonraki toplantıda tekrar eforlanmasını sağlar.

Product Backlog’da bulunan Story’leri tüm ekiple birlikte ölçtük, biçtik ve bir büyüklük değeri atadık. Peki bu atadığımız değer ne işe yarayacak? İleride Release ve Sprint planlarken bunlara ne kadar iş yükleyeceğimizi hesaplayacağız. Böylece projenin takibi çok daha kolay olacak.

Gelin şimdi de büyüklük tahminlerini yaptığımız Story’leri öncelik sırasına koyalım.

Bölüm 8: Story Prioritization (Hikaye Önceliklendirme) Nedir? 🎰 ↪

Bir önceki bölüme göz atmak ister misiniz?
Bölüm 6: Acceptance Criteria (Kabul Kriterleri) ve Definition of Done (Bitti Tanımı) Nedir? ⚔️ ↩