Efor Tahminleme (Estimation) Yöntemlerinde Kurumsal Gerçeklik

Bir yazılım projesinde en zor sorulardan biri çoğu zaman teknik değildir: “Ne zaman biter?” Bu soru basit görünür, fakat altında kapsam, ekip kapasitesi, teknik risk, bağımlılıklar, bekleme süreleri ve henüz bilinmeyen işler bulunur. On yılı aşkın proje deneyiminde gördüğüm ortak nokta şu oldu: sorun çoğu zaman ekibin tahmin yapamaması değil, tahminin kurum içinde yanlış anlamda kullanılmasıdır. Bir ekip “yaklaşık üç sprint” dediğinde bu ifade birkaç toplantı sonra “altı haftada kesin teslim” biçiminde algılanabiliyor. Efor Tahminleme (Estimation) Yöntemlerinde Kurumsal Gerçeklik tam olarak bu noktada başlıyor. Bu rehberde yazılım projelerinde gerçekçi efor tahmini nasıl yapılır sorusunu yalnızca Story Point veya saat üzerinden değil, kapasite, risk, bağımlılık, tarihsel veri ve olasılıklı forecast yaklaşımıyla birlikte ele alacağız.

Yazılım Efor Tahminleme (Estimation) Nedir?

Yazılım efor tahminleme, bir işin tamamlanması için gereken çalışma büyüklüğünü mevcut bilgiler üzerinden değerlendirme sürecidir. Buradaki kritik ifade “mevcut bilgiler”dir çünkü proje ilerledikçe yeni teknik ayrıntılar, yeni gereksinimler ve yeni bağımlılıklar ortaya çıkar. Bu nedenle estimation ilk gün verilen ve proje sonuna kadar değişmemesi gereken bir rakam değildir. İyi kullanılan tahmin, ekibin plan yapmasına ve karar vericilerin seçenekleri karşılaştırmasına yardımcı olur. Kurumsal projelerde efor tahminleme yöntemleri nelerdir sorusuna tek bir yöntemle cevap vermek de bu nedenle doğru değildir.

Efor Nedir?

Efor, bir işin yapılması için harcanması beklenen aktif çalışma miktarını ifade eder. Beş kişi-günlük bir iş, bir kişinin beş gün boyunca kesintisiz çalışacağı anlamına gelmeyebilir. Aynı iş farklı uzmanlıklardan geliştirici, test uzmanı ve operasyon desteği gerektirebilir. Code review, test hazırlığı, güvenlik kontrolü ve dağıtım çalışması da gerçek eforun parçasıdır. Bu nedenle yalnızca kod yazma süresini efor olarak görmek proje planında ciddi boşluklar oluşturur.

Estimation Nedir?

Estimation, gelecekteki iş yükünü mevcut bilgi ve varsayımlar kullanarak yaklaşık olarak değerlendirmektir. Tahminin kalitesi yalnızca kullanılan tekniğe bağlı değildir. Gereksinim netliği, takım deneyimi, geçmiş veri kalitesi ve işin büyüklüğü sonucu doğrudan etkiler. Aynı ekip daha önce yaptığı bir entegrasyonu yeniden tahmin ederken güçlü referanslara sahip olabilir. Daha önce hiç kullanılmamış bir teknoloji söz konusu olduğunda ise daha geniş bir tahmin aralığı kullanmak daha sağlıklı olur.

Tahmin Neden Yapılır?

Tahminin temel amacı geleceği kusursuz biçimde bilmek değildir. Amaç, bugünkü seçenekler arasında daha iyi karar verebilmektir. Kurum bütçe ayırmak, ekip kapasitesini planlamak, müşteriye bir aralık sunmak veya bir projenin yatırım değerini değerlendirmek isteyebilir. Yazılım ekibi ise bir işi sprint içine alıp alamayacağını anlamaya çalışır. Bu ihtiyaçların her biri farklı hassasiyet seviyesinde tahmin gerektirir.

Tahmin Bir Amaç mı, Karar Destek Aracı mı?

Tahmini kendi başına başarı kriteri haline getirmek tehlikelidir. Bir ekip sürekli tahmini tutturmaya zorlanırsa doğal olarak daha büyük güvenlik payları eklemeye başlayabilir. Bu davranış tahmin kalitesini artırmaz, yalnızca metriği daha kolay tutturulabilir hale getirir. Sağlıklı yaklaşım, tahmin sonucunda hangi kararın verileceğini önce sormaktır. Hiçbir karar değişmeyecekse çok ayrıntılı estimation yapmak çoğu zaman gereksiz maliyet oluşturur.

Yazılım Tahminleri Neden Doğası Gereği Belirsizdir?

Yazılım geliştirme, aynı parçanın tekrar tekrar üretildiği standart bir üretim hattı değildir. Yeni gereksinimler, bilinmeyen entegrasyon davranışları ve mevcut sistemde saklı teknik problemler çalışmayı etkiler. Kullanıcı geri bildirimi geldikçe ürün kapsamı da değişebilir. Bu durum başarısız planlama anlamına gelmez, yazılım geliştirmenin öğrenmeye dayalı doğasının sonucudur. İyi estimation sistemi belirsizliği saklamaz, görünür hale getirir.

Estimate, Forecast, Commitment ve Deadline Arasındaki Fark

Kurumsal projelerde en fazla sorun çıkaran konulardan biri estimate, forecast, commitment, target date ve deadline kavramlarının aynı şeymiş gibi kullanılmasıdır. Bir geliştiricinin teknik değerlendirmesi, yönetim kararına veya müşteri sözleşmesine dönüştüğünde anlam değişir. Bu ayrım yapılmadığında ekip verdiği her tahmini söz gibi algılamaya başlar. Sonuç olarak insanlar daha fazla koruma süresi ekler veya tahmin vermekten kaçınır. Sağlıklı bir kurum, bu kavramların her birini açık biçimde tanımlar.

Estimate Nedir?

Estimate, işin büyüklüğü veya ihtiyaç duyduğu efor hakkında mevcut bilgiye dayalı değerlendirmedir. Story Point, saat, kişi-gün veya bir aralık biçiminde ifade edilebilir. Estimate doğal olarak yanlış çıkabilir çünkü yeni bilgi geldikçe varsayımlar değişebilir. Buradaki amaç teknik ekibin gördüğü çalışma büyüklüğünü görünür hale getirmektir. Estimate tek başına müşteriye verilmiş bir teslim sözü değildir.

Forecast Nedir?

Forecast, mevcut performans verisi ve kalan kapsam üzerinden gelecekte olabilecek sonucu tahmin etmeye çalışır. Örneğin ekip haftalık throughput geçmişini kullanarak kalan 40 işin hangi tarihler arasında tamamlanabileceğini hesaplayabilir. Forecast, estimate'ten daha fazla operasyonel veri içerebilir. Yeni işler tamamlandıkça forecast yeniden hesaplanabilir. Bu nedenle forecast yaşayan bir planlama aracıdır.

Commitment Nedir?

Commitment, kurumun belirli koşullar altında üstlendiği taahhüttür. Burada artık yalnızca teknik değerlendirme değil, iş riski ve yönetim kararı da vardır. Bir tarih commitment haline gelecekse kapsam, risk ve güven seviyesi birlikte değerlendirilmelidir. Teknik ekibin estimate vermesi otomatik olarak commitment oluşturmaz. Bu ayrım kurum içinde yazılı hale getirildiğinde gereksiz gerilim önemli ölçüde azalır.

Target Date Nedir?

Target Date, ulaşılmak istenen hedef tarihtir. Pazarlama kampanyası, konferans, satış dönemi veya iç yönetim hedefi nedeniyle belirlenebilir. Hedef tarih teknik tahminle uyumlu olabilir veya olmayabilir. Eğer uyumlu değilse doğru soru tahmini küçültmek değil, kapsama ve kaynak seçeneklerine bakmaktır. Böylece hedef tarih ile gerçekçi forecast birbirinden ayrılır.

Deadline Nedir?

Deadline, aşılması halinde belirgin bir hukuki, ticari veya operasyonel sonuç oluşan son tarihtir. Regülasyon değişikliği veya sözleşmesel zorunluluk buna örnek olabilir. Deadline varsa estimation süreci ortadan kalkmaz, aksine daha önemli hale gelir. Ekip hangi minimum kapsamın güvenli biçimde yetiştirilebileceğini hesaplamalıdır. Gerektiğinde aşamalı teslimat ve risk buffer planlanmalıdır.

“Tahmin Ettik” Nasıl “Söz Verdiniz”e Dönüşür?

Bu dönüşüm çoğu kurumda tek bir toplantıda olmaz. Teknik ekip yaklaşık bir sayı söyler, proje yöneticisi bunu plan dosyasına yazar ve daha sonra satış ekibi aynı tarihi müşteriye aktarır. Birkaç hafta sonra ilk teknik tahmin artık resmi beklenti haline gelir. Bu zincirin kırılması için estimate, forecast ve commitment alanları ayrı tutulmalıdır. Ayrıca tahminin hangi varsayımlarla verildiği kaydedilmelidir.

Kurum İçinde Bu Kavramlar Nasıl Ayrıştırılmalı?

Pratik yöntem, proje yönetim aracında her kavram için farklı alan kullanmaktır. Estimate teknik değerlendirmeyi, forecast güncel teslim ihtimalini ve commitment yönetim kararını göstermelidir. Target Date iş hedefini, deadline ise zorunlu son tarihi temsil etmelidir. Yönetim raporlarında da bu ayrım korunmalıdır. Böylece “teknik ekip bu tarihi verdi” şeklindeki yanlış aktarım büyük ölçüde önlenebilir.

Efor ile Süre Aynı Şey Değildir

Story point planning poker ve saat bazlı efor tahmini karşılaştırması yapılırken en sık gözden kaçan konu efor ile takvim süresinin aynı olmadığıdır. Bir iş için sekiz saat aktif çalışma gerekmesi onun bir iş gününde tamamlanacağı anlamına gelmez. Code review beklemesi, başka takımın API değişikliği, test ortamı sorunu veya onay süreci takvim süresini uzatabilir. Bu nedenle yazılım efor tahmininde kapasite risk bağımlılık ve belirsizlik nasıl hesaplanır sorusuna yalnızca adam/saat üzerinden yanıt verilemez. Flow metrikleri burada çok daha güçlü bir görünüm sağlar.

Effort Nedir?

Effort, işi tamamlamak için gereken aktif çalışma miktarıdır. Tasarım, geliştirme, test, inceleme ve operasyonel hazırlık bu miktara dahil olabilir. Effort bir kaynak tüketimi ölçüsüdür. Buna rağmen gerçek teslim tarihini tek başına açıklayamaz. Çünkü iş aktif çalışmanın yanında çeşitli bekleme dönemlerinden geçebilir.

Duration Nedir?

Duration, işin başlangıcı ile tamamlanması arasında geçen takvim süresidir. İki kişi-gün efor gerektiren bir işin duration değeri beş gün olabilir. Bunun nedeni işin başka bir ekipten yanıt beklemesi olabilir. Duration planlamada müşteri açısından daha görünür bir göstergedir. Bu yüzden efor ile birlikte izlenmesi gerekir.

Lead Time Nedir?

Lead Time, talebin sisteme girdiği andan müşteriye veya kullanıcıya teslim edildiği ana kadar geçen toplam süredir. Bu süre içinde sırada bekleme de bulunur. Özellikle kurumsal organizasyonlarda lead time aktif geliştirme süresinden çok daha uzun olabilir. Bu fark süreç darboğazlarını anlamak için değerlidir. Kanban yaklaşımında bu konuya ilişkin daha kapsamlı bir perspektif için https://www.diyarbakiryazilim.com.tr/posts/kanban-board-optimizasyonu-ve-darbogaz-bottleneck-analizi adresindeki çalışmaya da göz atabilirsiniz.

Cycle Time Nedir?

Cycle Time, bir iş üzerinde fiilen çalışılmaya başlanması ile işin tamamlanması arasındaki süredir. Lead Time'a göre daha dar bir pencereyi ölçer. Ekip süreçlerindeki akışı anlamak için oldukça değerlidir. Benzer işlerin cycle time dağılımı, gelecekteki teslimatlar için güçlü bir referans oluşturur. Bu nedenle olgun ekiplerde yalnızca point değil cycle time da izlenmelidir.

Bekleme Süresi

Bekleme süresi, aktif çalışma yapılmadığı halde işin tamamlanamadığı dönemdir. Review kuyruğu, test ortamı veya iş birimi yanıtı buna neden olabilir. Bu süre geliştiricinin estimate ettiği eforun dışında kalabilir. Fakat müşteri açısından teslim süresinin gerçek parçasıdır. Forecast hazırlanırken bekleme verisinin ayrıca izlenmesi gerekir.

Bağımlılık Süresi

Başka takım, servis veya tedarikçi bağımlılığı takvim süresini önemli ölçüde etkileyebilir. Ekip kendi işini iki günde tamamlayabilir fakat dış API değişikliğini bir hafta bekleyebilir. Bu durumda iki günlük effort doğru, iki günlük teslim forecast'i yanlıştır. Bağımlılıklar ayrı risk olarak kaydedilmelidir. Özellikle çoklu takım projelerinde dependency board faydalı olur.

Approval Süresi

Onay süreçleri kurumsal projelerde görünmeyen süre kaynaklarından biridir. Güvenlik, hukuk, mimari veya iş birimi onayı geliştirmeyi bekletebilir. Bu süreleri development estimate içine gizlemek sağlıklı değildir. Approval süresinin ayrıca ölçülmesi sorunun gerçekten nerede olduğunu gösterir. Böylece ekip performansı ile kurumsal akış birbirine karıştırılmaz.

5 Kişi-Günlük İş Neden 5 Takvim Gününde Bitmeyebilir?

Çünkü kişi-gün aktif çalışmayı temsil eder, takvim gününü değil. Aynı iş içinde farklı uzmanlıkların sırayla çalışması gerekebilir. Review, test veya dış bağımlılık işin ilerlemesini durdurabilir. Ayrıca ekip aynı anda üretim desteği ve başka sprint işleriyle ilgilenebilir. Bu nedenle gerçek teslim forecast'i efor, kapasite ve bekleme sürelerini birlikte değerlendirmelidir.

Kurumlar Neden Tahmine İhtiyaç Duyar?

Kurum açısından estimation teknik bir ritüelden çok ekonomik karar aracıdır. Bütçe, insan kaynağı, satış teklifi, yatırım sırası ve müşteri beklentileri tahmin verisinden etkilenir. Fakat her karar için aynı detay seviyesi gerekli değildir. Yıllık roadmap için saat bazlı task tahmini yapmak yüksek maliyet yaratır. Buna karşılık yakın tarihli ve sözleşmesel riski yüksek bir teslimat daha ayrıntılı analiz gerektirebilir.

Bütçe Planlama

Finans ekipleri gelecek dönemde ne kadar kaynak gerektiğini bilmek ister. Buradaki ihtiyaç her story'nin saatini bulmak değildir. Daha çok ekip maliyeti, proje süresi ve risk aralığı önemlidir. Kaba tahmin ve geçmiş burn rate birlikte kullanılabilir. Böylece bütçe tek bir kesin rakama bağlanmaz.

Kaynak Planlama

Kaynak planlamada temel soru kaç kişinin boş olduğu değil, hangi yetkinliğin ne zaman gerektiğidir. Beş geliştirici olması beş işin paralel tamamlanabileceğini garanti etmez. Kritik bilgi tek kişide bulunabilir. QA veya DevOps kapasitesi sınırlı olabilir. Bu nedenle kaynak planı rol ve bağımlılık düzeyinde ele alınmalıdır.

Roadmap

Roadmap uzak geleceği gösterdiği için hassasiyet düşük tutulmalıdır. Epic'leri saat seviyesinde tahminlemek yanıltıcı kesinlik üretir. T-Shirt Sizing veya geniş aralıklar daha uygundur. Yakın dönem geldikçe daha fazla discovery yapılabilir. Rolling-wave planning bu yaklaşımı destekler.

Satış Teklifi

Satış teklifi hazırlanırken teknik bilgi genellikle sınırlıdır. Buna rağmen fiyat ve süre beklentisi hızlı oluşur. Minimum discovery yapılmadan kesin rakam vermek ticari riski artırır. Varsayımlar, kapsam dışı alanlar ve risk reserve açıkça belirtilmelidir. Fixed-price projelerde bu disiplin özellikle önemlidir.

Müşteri Taahhütleri

Müşteri taahhüdü teknik estimate'ten farklı bir yönetim kararıdır. Taahhüt verilecekse ekip kapasitesi, scope ve risk görünür olmalıdır. Tek tarih yerine güven seviyesi içeren aralık sunmak daha açıklayıcıdır. Kritik teslimatlarda daha yüksek güven seviyesi seçilebilir. Böylece karar iş riskine göre alınır.

Yatırım Kararları

Her proje yapılmaya değer değildir. Efor tahmini yatırımın maliyet tarafını görünür hale getirir. İş değeri, gecikme maliyeti ve risk reduction ile birlikte değerlendirilmelidir. Büyük bir iş yüksek değer yaratıyorsa yine öncelikli olabilir. Bu nedenle estimation prioritization ile karıştırılmamalıdır.

Portföy Önceliklendirmesi

Portföy seviyesinde çok sayıda büyük iş karşılaştırılır. Bu seviyede ayrıntılı task estimate gereksizdir. Epic range, investment bucket ve kapasite payı daha kullanışlıdır. Belirsiz işlere discovery bütçesi ayrılabilir. Teslim bütçesi discovery sonrasında netleştirilebilir.

Tedarikçi Yönetimi

Dış tedarikçi ile çalışıldığında tahmin sözleşme modeline göre farklı anlam kazanır. Fixed Price modelinde riskin önemli bölümü tedarikçiye aktarılır. Time & Material modelinde ise bütçe ve scope sürekli gözden geçirilir. Acceptance kriterleri iki modelde de açık olmalıdır. Aksi halde tahmin tartışması kolayca kapsam tartışmasına dönüşür.

Regülasyon ve Zorunlu Tarihler

Zorunlu tarih varsa planlama daha erken başlamalıdır. Tarihi değiştirmenin mümkün olmadığı durumlarda scope esnekliği değerlendirilir. Must, Should ve Could ayrımı burada faydalıdır. Minimum güvenli kapsam öncelikle güvence altına alınmalıdır. Tarihe yaklaştıkça forecast yeniden hesaplanmalıdır.

Yazılım Ekibi Neden Tahmine İhtiyaç Duyar?

Yazılım ekibi için estimation yalnızca yönetimin istediği bir sayı üretmek değildir. İyi bir estimation görüşmesi teknik risklerin daha kod yazılmadan ortaya çıkmasını sağlar. Bir geliştirici veritabanı değişikliğini düşünürken QA geriye dönük test etkisini, DevOps ise deployment riskini fark edebilir. Bu nedenle Planning Poker'ın gerçek değeri çoğu zaman kartın üzerinde yazan sayı değil, ortaya çıkardığı konuşmadır. Ekip aynı zamanda kapasitesini ve sprint içine ne kadar iş alabileceğini daha bilinçli değerlendirebilir.

Sprint Planlama

Sprint planlama yakın dönem için tahminin en anlamlı olduğu alanlardan biridir. İşler yeterince anlaşılmışsa ekip kapasitesi ile boyut karşılaştırılabilir. Ancak point toplamını zorunlu hedef haline getirmek doğru değildir. Sprint içinde plansız iş için alan bırakılmalıdır. Son birkaç sprintin gerçek verileri bu kararı destekleyebilir.

Kapasiteyi Anlama

Kapasite yalnızca ekipteki kişi sayısı değildir. İzinler, toplantılar, destek talepleri ve operasyonel sorumluluklar kapasiteyi azaltır. Nominal kapasite ile gerçek kapasite ayrılmalıdır. Geçmiş focus factor bu farkı anlamaya yardımcı olabilir. Böylece ekip her sprint yüzde yüz doluluk varsayımıyla plan yapmaz.

Büyük İşleri Belirleme

Estimation sırasında yüksek boyut verilen işler dikkat sinyali üretir. Büyük iş daha fazla bilinmeyen barındırabilir. Bu durumda doğrudan sprint içine almak yerine parçalama yapılabilir. Vertical slicing daha küçük ve değer üreten parçalar oluşturur. Küçük işler daha hızlı feedback sağlar.

Risk ve Belirsizliği Görünür Kılma

İki geliştiricinin aynı story'ye çok farklı point vermesi sorun değildir. Tam tersine bu fark değerli bilgi taşır. Bir kişi gizli bağımlılığı biliyor olabilir. Diğer kişi acceptance kriterlerini farklı anlamış olabilir. Tartışma yapıldığında risk daha erken görünür hale gelir.

Ortak Anlayış Oluşturma

Planning Poker veya refinement görüşmelerinin önemli çıktısı ortak anlayıştır. Product, QA ve geliştiriciler aynı kapsam üzerinde konuşur. Eksik senaryolar toplantı sırasında fark edilebilir. Böylece kodlama başladıktan sonra çıkacak sürprizlerin bir bölümü azaltılır. Tahmin bu anlamda iletişim aracıdır.

Önceliklendirmeye Veri Sağlama

Efor bilgisi tek başına öncelik belirlemez. Fakat business value ile birlikte değerlendirildiğinde ekonomik karar vermeyi kolaylaştırır. Aynı değeri üreten iki seçenekten daha küçük olanı öne almak mantıklı olabilir. Buna karşılık büyük ama kritik bir risk azaltma işi daha değerli olabilir. WSJF benzeri yaklaşımlar bu ilişkiyi görünür hale getirir.

Teknik Bağımlılıkları Tartışma

Tahmin görüşmesi bağımlılıkları erken fark etmek için iyi bir fırsattır. API, veri, başka takım veya güvenlik onayı teslim süresini değiştirebilir. Bu bağımlılıklar effort ile waiting time olarak ayrıştırılmalıdır. Böylece teknik işin gerçek büyüklüğü korunur. Aynı zamanda program seviyesinde gecikme riski daha iyi görünür.

Kurumsal Estimation Probleminin Temel Çelişkisi

Kurumsal projelerde farklı ekiplerin aynı tahminden farklı şeyler beklemesi temel gerilim kaynağıdır. Yönetim tarih, finans bütçe, satış fiyat ve ürün ekibi scope esnekliği ister. Teknik ekip ise geliştirme ilerledikçe yeni bilgi öğrenir. Tek bir sayının bütün bu ihtiyaçları karşılaması beklenince tahmin olduğundan daha fazla anlam yüklenmiş bir rakama dönüşür. Sağlıklı modelde teknik estimate, delivery forecast ve ticari commitment ayrı katmanlarda yönetilir.

Yönetim Kesin Tarih İster

Yönetimin tarih istemesi doğal bir iş ihtiyacıdır. Pazarlama, bütçe ve müşteri iletişimi buna bağlı olabilir. Problem tarih istemekte değil, bilinmeyen işi kesin sayı gibi göstermektedir. Yöneticiye aralık ve güven seviyesi sunmak daha iyi karar sağlar. Bu yaklaşım belirsizliği saklamak yerine yönetilebilir hale getirir.

Yazılım Ekibi Belirsizlikle Çalışır

Teknik ekip yeni bilgiyi çalışma sırasında keşfeder. Legacy kod beklenenden farklı davranabilir. Üçüncü taraf API dokümantasyonu eksik çıkabilir. Test ortamı yeni sorunlar gösterebilir. Bu nedenle plan değişikliği her zaman kötü estimation anlamına gelmez.

Satış Ekibi Fiyat İster

Satış ekibi müşteriye anlaşılır bir fiyat sunmak zorundadır. Teknik belirsizlik fiyatlandırmayı zorlaştırır. Discovery yapılmadan verilen düşük teklif daha sonra teslim baskısı oluşturabilir. Risk Premium ve varsayım listesi bu sorunu azaltır. Büyük belirsizlik varsa aşamalı teklif daha güvenli olabilir.

Finans Bütçe İster

Finansın ihtiyacı genellikle planlama aralığıdır. Her task'ın saatini bilmesi gerekmez. Takım maliyeti, beklenen süre ve belirsizlik aralığı bütçe için daha anlamlıdır. Tarihsel burn rate burada değerli veri sağlar. Bütçe düzenli forecast güncellemeleriyle takip edilebilir.

Product Scope'u Değiştirmek İster

Ürün geliştirme öğrenmeye dayalıdır. Kullanıcı geri bildirimi geldikçe scope değişebilir. İlk günden tüm kapsamı sabitlemek çoğu zaman ürün değerini azaltır. Scope değiştiğinde forecast de güncellenmelidir. Eski tarihin yeni kapsamla aynı kalması beklenmemelidir.

Teknik Ekip Öğrendikçe Planı Değiştirir

Discovery ve geliştirme yeni teknik bilgi üretir. İlk tasarımın işe yaramadığı anlaşılabilir. Daha basit çözüm de bulunabilir. Bu nedenle estimate hem yukarı hem aşağı değişebilir. Re-estimation yalnızca karar üzerinde etkisi varsa yapılmalıdır.

Tek Bir Sayının Tüm Bu İhtiyaçları Karşılayamaması

Tek rakam farklı kullanıcılar için farklı anlam taşır. Story Point ekibin göreceli boyutlandırmasını desteklerken finans kişi-gün isteyebilir. Yönetim ise takvim tarihi görmek ister. Bu ihtiyaçları tek dönüşüm tablosuyla çözmeye çalışmak sorun üretir. Her iş ihtiyacı için uygun forecast çıktısı oluşturulmalıdır.

Tahmin ile Kesinlik Arasındaki Fark

Tahminin hassas görünmesi onun daha doğru olduğu anlamına gelmez. Projenin ilk haftasında “17 iş günü” demek, “yaklaşık üç ile beş hafta” demekten daha profesyonel görünebilir ancak bilgi seviyesi bu hassasiyeti desteklemiyorsa rakam yanıltıcı olur. Belirsizlik yükseldikçe kullanılan aralığın da genişlemesi gerekir. Bu yaklaşım karar vericinin riski anlamasını sağlar. Efor Tahminleme (Estimation) Yöntemlerinde Kurumsal Gerçeklik açısından en önemli kültürel dönüşümlerden biri, kesin görünmek yerine güven seviyesini açıkça ifade etmektir.

Tahmin Neden Tek Bir Doğru Sayı Değildir?

Gelecekte birden fazla olası senaryo vardır. İş beklenenden hızlı ilerleyebilir veya teknik risk gerçekleşebilir. Tek sayı bu dağılımı saklar. Aralık ise ihtimalleri daha görünür hale getirir. Bu nedenle özellikle büyük işler için range forecast tercih edilmelidir.

False Precision Nedir?

False Precision, eldeki bilginin desteklemediği kadar ayrıntılı sayı vermektir. Örneğin erken aşamadaki büyük epic için 317 saat tahmin vermek buna örnektir. Bu sayı hesaplanmış olduğu için güvenilir görünür. Oysa varsayımlar değiştiğinde sonuç hızla geçerliliğini kaybeder. Daha geniş aralık karar vericiye daha doğru sinyal verir.

17 Gün Demek 3 Hafta Demekten Daha Doğru mudur?

Her zaman değildir. İş yeterince küçük ve iyi biliniyorsa 17 günlük tahmin anlamlı olabilir. Ancak büyük belirsizlik içeren bir projede bu hassasiyet sahte güven yaratabilir. Üç ile dört hafta aralığı daha dürüst olabilir. Hassasiyet bilgi seviyesiyle uyumlu olmalıdır.

Belirsizlik Arttıkça Hassasiyet Neden Azalmalıdır?

Bilinmeyen sayısı arttıkça olası sonuç aralığı genişler. Yeni teknoloji, büyük bağımlılık veya belirsiz kapsam buna örnektir. Bu durumda dar tarih vermek riski ortadan kaldırmaz. Yalnızca riskin görünmesini engeller. Daha geniş aralık yönetimin erken önlem almasını sağlar.

Tek Sayı Yerine Aralık Kullanmak

Aralık kullanmak kararsızlık anlamına gelmez. Örneğin “yüzde 85 güvenle 10 ile 14 hafta” ifadesi güçlü bir yönetim bilgisidir. Risk toleransı yüksekse daha erken yüzde 50 tarihi de paylaşılabilir. Kritik taahhütlerde daha yüksek güven seviyesi seçilir. Böylece tarih iş riskine bağlanır.

Yazılım Tahminlerini Zorlaştıran Faktörler

İyi bir tahmin yönteminin başarısı, işi etkileyen gerçek koşulları ne kadar görünür hale getirdiğine bağlıdır. Belirsiz gereksinimler, legacy sistemler, teknik borç, entegrasyonlar, güvenlik gereksinimleri ve insan faktörü tahmin davranışını değiştirir. Bunların tamamını tek Story Point sayısının içine gizlemek bilgi kaybına yol açabilir. Özellikle kurumsal projelerde dependency risk ve blocked time ayrıca tutulmalıdır. Böylece tahmin hatasının kaynağı daha sonra analiz edilebilir.

Belirsiz Gereksinimler

Belirsiz story doğru tahmin edilemez. Acceptance criteria eksikse ekip farklı kapsamlar hayal edebilir. Bu durumda point tartışmak yerine gereksinimi netleştirmek gerekir. Gerekirse discovery yapılmalıdır. Minimum bilgi sağlanmadan tahmin ertelenebilir.

Teknik Bilinmezlik

Yeni servis veya bilinmeyen veri modeli teknik riski artırır. Ekip daha önce benzer çözüm yapmadıysa geçmiş referans zayıftır. Spike bu durumda yararlı olabilir. Kısa araştırma daha büyük işin aralığını daraltır. Tahmin öncesi öğrenme maliyeti kabul edilmelidir.

Legacy Sistem

Legacy sistemlerde görünen iş ile gerçek iş farklı olabilir. Küçük değişiklik beklenmedik yan etkiler üretebilir. Test kapsamı yetersizse risk büyür. Geçmiş tahminler yeni sistem için doğrudan referans olmayabilir. Teknik keşif süresi ayrıca planlanmalıdır.

Teknik Borç

Teknik borç aynı boyuttaki feature'ların farklı sürede tamamlanmasına yol açabilir. Zayıf test altyapısı rework oluşturabilir. Eski dependency değişikliği zorlaştırabilir. Bu nedenle teknik borç kapasite ve risk planında görünür olmalıdır. Feature eforuna gizlenmesi sorunun ölçülmesini engeller.

Entegrasyonlar

Entegrasyon işlerinde yalnızca kendi kodunuzu kontrol edersiniz. Karşı sistemin davranışı, veri kalitesi ve test ortamı belirsizlik yaratır. Benzer entegrasyon geçmişi önemli referans sağlar. Three-Point Estimation burada uygun olabilir. Pessimistic senaryoda dış bağımlılık açıkça değerlendirilmelidir.

Üçüncü Taraf Servisler

Harici servislerin SLA, dokümantasyon ve erişim süreçleri delivery süresini etkiler. API teknik olarak kolay olsa bile hesap açılması günler sürebilir. Bu waiting time development eforundan ayrılmalıdır. Vendor bağımlılığı risk listesinde tutulmalıdır. Forecast gerektiğinde bu riske göre güncellenmelidir.

Güvenlik Gereksinimleri

Security review son aşamaya bırakıldığında teslimat gecikebilir. Threat modeling, penetration test veya izin süreçleri önceden bilinmelidir. Definition of Done güvenlik gereksinimlerini içermelidir. Böylece development tamamlandığında işin gerçekten tamamlandığı varsayılmaz. Güvenlik eforu tahminin normal parçası olur.

Test Karmaşıklığı

Basit görünen geliştirme geniş regresyon testi gerektirebilir. Özellikle merkezi modüllerde değişiklik alanı büyür. QA perspektifinin estimation sırasında bulunması bu riski erken gösterir. Otomasyon seviyesi süreyi etkiler. Test yalnızca geliştirme sonrasında eklenen ayrı bir işlem olarak görülmemelidir.

İnsan Faktörü

Ekipler makine değildir. Öğrenme, iletişim, izin ve bağlam değişimi kapasiteyi etkiler. Aynı görevi senior ve yeni katılan geliştirici farklı sürede tamamlayabilir. Bu durum bireysel performans karşılaştırması için kullanılmamalıdır. Takım seviyesinde gerçek kapasite verisi daha güvenilir plan sağlar.

Organizasyonel Bağımlılıklar

Büyük kurumlarda bir iş birden fazla onay ve ekipten geçebilir. Bu yapı cycle time üzerinde güçlü etkiye sahiptir. Geliştirme hızlandırılsa bile toplam lead time değişmeyebilir. Darboğaz ekip dışında olabilir. Bu nedenle flow analizi teknik tahmin kadar önemlidir.

Bilinen Bilinmeyenler ve Bilinmeyen Bilinmeyenler

Tahmin kalitesi yalnızca iş büyüklüğünden değil, bilinmeyenlerin türünden de etkilenir. Bazı riskleri biliriz ve etkisini hesaplayabiliriz. Bazı risklerin varlığını biliriz fakat sonucunu henüz bilmiyoruz. Bir de başlangıçta aklımıza bile gelmeyen durumlar vardır. Bu ayrım risk buffer, spike ve forecast aralığı konusunda daha sağlıklı karar vermeyi sağlar.

Known Knowns

Known Knowns, ekip tarafından bilinen ve iyi anlaşılan alanlardır. Kullanılan teknoloji tanıdıksa ve benzer iş daha önce yapıldıysa tahmin daralabilir. Tarihsel veri burada güçlü referans sağlar. Bu işler story counting için de uygun olabilir. Fazla estimation toplantısı yapmak gerekli olmayabilir.

Known Unknowns

Known Unknowns, varlığını bildiğimiz fakat sonucunu bilmediğimiz konulardır. Harici API performansı buna örnek olabilir. Spike veya PoC ile bilgi kazanılabilir. Three-Point Estimation ile farklı sonuçlar modellenebilir. Bu riskler açıkça kaydedilmelidir.

Unknown Unknowns

Unknown Unknowns başlangıçta öngöremediğimiz olaylardır. Büyük ve yeni projelerde sayıları daha fazla olabilir. Bunları tek tek tahmin etmek mümkün değildir. Geniş range ve contingency bu nedenle gereklidir. Proje ilerledikçe yeni bilgi forecast'e eklenmelidir.

Tahminde Risk ile Belirsizliğin Ayrılması

Risk bilinen bir olayın gerçekleşme ihtimali ve etkisidir. Belirsizlik ise bilgi eksikliğini de içerir. Aynı araçla yönetilmeleri doğru değildir. Bilinen risk için contingency planlanabilir. Bilgi eksikliği için discovery yapılabilir.

Spike ve Proof of Concept ile Belirsizliği Azaltmak

Spike'ın amacı ürün özelliğini tamamlamak değil, bilgi üretmektir. Kısa teknik araştırma büyük bir yanlış yatırımı önleyebilir. PoC özellikle yeni teknoloji ve entegrasyonlarda değerlidir. Bu çalışmaların sonunda tahmin aralığı güncellenmelidir. Böylece öğrenme estimation sürecinin doğal parçası olur.

Tahmin Hassasiyeti Planlama Ufku ile Değişmeli

Uzak gelecekteki bir roadmap maddesine task seviyesinde tahmin vermek kaynak israfıdır. Çünkü kapsam değişme ihtimali yüksektir ve bugün yapılan ayrıntılı estimate birkaç ay sonra geçersiz olabilir. Yakın dönem için ise daha ayrıntılı story ve task analizi faydalıdır. Bu yaklaşım rolling-wave planning olarak uygulanabilir. Bilgi arttıkça forecast daralır ve karar kalitesi yükselir.

Yıllık Roadmap Tahmini

Yıllık roadmap geniş bir planlama ufkuna sahiptir. Bu nedenle T-Shirt Sizing veya büyük aralıklar uygundur. Amaç kesin teslim tarihi üretmek değildir. Yatırım ve kapasite yönünü görmek yeterlidir. Yakınlaşan işler daha sonra detaylandırılır.

Çeyreklik Tahmin

Çeyreklik plan daha fazla bilgiye sahiptir. Epic boyutları ve takım kapasitesi birlikte değerlendirilebilir. Tarihsel throughput kullanılabilir. Riskli işler discovery ile desteklenebilir. Forecast ay içinde yeniden güncellenebilir.

Epic Tahmini

Epic henüz birçok bilinmeyen içerir. Tek sayı yerine range veya T-Shirt daha uygundur. Çok büyük epic'ler parçalanmalıdır. Bağımlılıklar ayrıca işaretlenmelidir. Discovery tamamlandıkça tahmin yenilenir.

Sprint Tahmini

Sprint planlamada işler daha net olmalıdır. Definition of Ready burada yardımcıdır. Ekip son sprintlerdeki gerçek kapasiteye bakabilir. Tatil ve destek yükü hesaba katılmalıdır. Sprint hedefi point rekoru değil değer teslimi olmalıdır.

Story Tahmini

Story seviyesinde relative estimation etkili olabilir. İş küçük ve anlaşılırsa Planning Poker kısa tutulabilir. Reference story karşılaştırması hız kazandırır. Yüksek belirsizlik varsa story bölünmelidir. Point yalnızca takım içinde anlamlıdır.

Task Tahmini

Task saat tahmini bazı operasyonel ihtiyaçlarda faydalı olabilir. Ancak her işi saat seviyesinde parçalamak yüksek toplantı maliyeti yaratır. Küçük ve rutin işlerde buna ihtiyaç olmayabilir. Saat planlaması bireysel performans ölçümüne dönüşmemelidir. Karar değerine göre kullanılmalıdır.

Yaklaştıkça Daha Fazla Bilgiyle Forecast Güncellemek

İyi forecast sabit değildir. Scope, kapasite ve throughput değiştikçe yeniden hesaplanır. Yeni bilgi geldikçe aralık daralabilir veya genişleyebilir. Forecast değişikliği başarısızlık olarak yorumlanmamalıdır. Tam tersine sistemin yeni bilgiyi kullandığını gösterir.

Cone of Uncertainty Yaklaşımı

Cone of Uncertainty, projenin erken aşamasında tahmin aralığının daha geniş olmasını ve bilgi arttıkça bu aralığın daralmasını anlatır. Bu yaklaşım özellikle yöneticilere neden ilk gün kesin tarih verilmemesi gerektiğini açıklamak için yararlıdır. Discovery, prototip, ilk teslimatlar ve tarihsel veri belirsizliği azaltır. Ancak kapsam sürekli büyüyorsa tahmin otomatik olarak daralmaz. Forecast'in daralabilmesi için bilgi kalitesinin gerçekten artması gerekir.

Proje Başlangıcındaki Belirsizlik

Başlangıçta gereksinimler genellikle eksiktir. Teknik yaklaşım tam doğrulanmamıştır. Ekip bağımlılıkların tamamını bilmeyebilir. Bu nedenle geniş aralık normaldir. Kesin gün vermek gereksiz güven oluşturur.

Discovery Sonrası Belirsizlik

Discovery, scope ve teknik seçenekleri daha görünür hale getirir. Riskli alanlar için PoC yapılabilir. Kritik bağımlılıklar belirlenir. Bu bilgi tahmin aralığını daraltır. Aynı zamanda bazı işlerin kapsamdan çıkarılması mümkün olabilir.

Geliştirme İlerledikçe Tahminin Daralması

Gerçek throughput verisi oluşmaya başladığında forecast güçlenir. Kalan scope daha iyi bilinir. Teknik risklerin bir bölümü çözülür. Monte Carlo gibi yöntemler daha anlamlı sonuç verir. Tahmin tek seferlik işlem olmaktan çıkar.

Yönetimle Belirsizlik Aralığını Paylaşmak

Yöneticiye yalnızca en iyimser tarihi göndermek doğru değildir. Olasılık veya aralık birlikte açıklanmalıdır. Örneğin yüzde 50 ve yüzde 85 güven tarihleri yan yana gösterilebilir. Karar verici risk toleransına göre seçim yapabilir. Böylece belirsizlik iş kararının parçası olur.

Tahmini Periyodik Olarak Güncellemek

Forecast için düzenli ritim belirlemek faydalıdır. Haftalık veya sprint bazlı güncelleme yapılabilir. Scope change ve throughput değişimi kaydedilir. Önceki forecast'lerin neden değiştiği açıklanır. Bu yaklaşım kurum içinde güven oluşturur.

Efor Tahminleme Yöntemleri Nelerdir?

Kurumsal projelerde efor tahminleme yöntemleri nelerdir sorusunun cevabı projenin olgunluğuna ve eldeki veriye göre değişir. Expert Judgment hızlıdır, Relative Estimation takım içi karşılaştırma sağlar, Three-Point Estimation belirsizliği senaryolarla gösterir ve Probabilistic Forecasting tarihsel veriyi olasılıklarla birleştirir. Function Point veya COCOMO belirli kurumsal bağlamlarda kullanılabilirken ürün ekipleri çoğu zaman Story Point, throughput ve cycle time kombinasyonundan daha fazla fayda görür. Tek yöntemi kurum standardı yapmak yerine seviyeye göre yöntem seçmek daha etkilidir. Story için relative estimate, roadmap için T-Shirt ve teslim tarihi için probabilistic forecast gibi katmanlı yapı iyi çalışır.

Expert Judgment

Expert Judgment deneyimli kişilerin geçmiş bilgisine dayanır. Hızlı karar gereken durumlarda faydalıdır. Ancak tek uzmana bağlı kalmak anchoring ve optimism bias riski yaratır. Birden fazla uzman bağımsız görüş verebilir. Görüşler tarihsel veri ile karşılaştırılmalıdır.

Analogous Estimation

Analogous Estimation mevcut işi geçmişteki benzer işle karşılaştırır. Özellikle tekrar eden entegrasyon veya ürün geliştirmelerinde kullanışlıdır. Referans gerçekten benzer olmalıdır. Teknoloji veya ekip yapısı değiştiyse doğrudan kopyalama yapılmamalıdır. Farklar açıkça not edilmelidir.

Relative Estimation

Relative Estimation mutlak saat yerine işler arasındaki büyüklük ilişkisini ölçer. İnsanlar karşılaştırma yapmakta çoğu zaman mutlak süre söylemekten daha başarılıdır. Reference story bu süreci kolaylaştırır. Story Point en yaygın relative estimate biçimlerinden biridir. Ölçeğin takım içinde tutarlı olması önemlidir.

Planning Poker

Planning Poker ekip üyelerinin bağımsız tahmin verip sonuçları birlikte tartıştığı yöntemdir. Gizli oy anchoring etkisini azaltır. Farklı tahminler bilgi farkını görünür hale getirir. Yeniden oylama ortak anlayış sonrasında yapılır. Süreç timebox ile sınırlandırılmalıdır.

Story Points

Story Point efor, risk, belirsizlik ve teknik zorluğun göreceli birleşimini ifade edebilir. Saat birimi değildir. Bir takımın beş point'i başka takımın beş point'iyle karşılaştırılamaz. Takım zaman içinde kendi referanslarını oluşturur. Point performans metriğine dönüştürülmemelidir.

T-Shirt Sizing

T-Shirt Sizing, işleri XS, S, M, L ve XL gibi sınıflara ayırır. Özellikle roadmap ve büyük backlog için hızlıdır. Amaç ayrıntılı tahmin değil kaba boyutlandırmadır. XL işler daha sonra parçalanabilir. Discovery aşamasında iyi bir başlangıç sağlar.

Affinity Estimation

Affinity Estimation işleri birbirine göre hızlı biçimde sıralar. Çok sayıda backlog maddesi olduğunda faydalıdır. Ekip önce göreceli kümeler oluşturur. Yalnızca sıra dışı veya kritik işler ayrıntılı tartışılır. Bu yaklaşım estimation maliyetini azaltır.

Bucket System

Bucket System önceden tanımlanmış boyut kovaları kullanır. İşler hızlıca uygun kovaya yerleştirilir. Büyük ekiplerde paralel değerlendirmeye izin verir. Tartışma yalnızca anlaşmazlık olan maddelerde yapılır. Büyük backlog'larda verimlidir.

Three-Point Estimation

Three-Point Estimation optimistic, most likely ve pessimistic senaryoları kullanır. Tek rakam yerine belirsizlik görünür olur. Özellikle büyük epic ve entegrasyonlarda faydalıdır. PERT formülü ağırlıklı ortalama üretebilir. Ancak üç senaryonun arkasındaki varsayımlar da paylaşılmalıdır.

Ideal Days

Ideal Days kesinti olmayan ideal çalışma gününü düşünür. Gerçek takvim gününden farklıdır. Toplantı, destek ve bekleme süreleri sonradan kapasite planına eklenir. Kavram bazı ekiplerde anlaşılır olabilir. Fakat ideal günün gerçek teslim tarihi olarak algılanmamasına dikkat edilmelidir.

Function Point

Function Point yazılımın kullanıcıya sunduğu fonksiyonel büyüklüğü ölçmeye çalışır. Büyük kurumsal sistemlerde karşılaştırma amacıyla kullanılabilir. Teknolojiden görece bağımsız bir bakış sunar. Uygulaması uzmanlık ve veri disiplini ister. Agile ekiplerin günlük story planlamasında her zaman gerekli değildir.

COCOMO

COCOMO yazılım büyüklüğü ve çeşitli maliyet etkenlerinden hareketle efor hesaplayan modeldir. Büyük proje tahminlerinde tarihsel olarak kullanılmıştır. Modelin girdilerinin kalitesi sonucu belirler. Modern ürün geliştirmede tek başına yeterli değildir. Kurumsal portföy değerlendirmesinde destekleyici olabilir.

Story Counting

Story Counting benzer boyuttaki küçük işleri yalnızca adet üzerinden forecast eder. Ekip story boyutlarını kontrol altında tutuyorsa şaşırtıcı derecede etkili olabilir. Point toplantısını azaltır. Throughput geçmişiyle birlikte kullanılır. Heterojen işlerde dikkatli uygulanmalıdır.

Probabilistic Forecasting

Probabilistic Forecasting geçmiş throughput veya cycle time dağılımını kullanır. Tek tarih yerine olasılık sunar. Örneğin bir scope'un yüzde 85 güvenle hangi tarihe kadar bitebileceğini gösterebilir. Yeni veri geldikçe hesap tekrar yapılır. Yönetim için güçlü bir karar destek aracıdır.

#NoEstimates

#NoEstimates planlama yapmamak anlamına gelmez. Amaç gereksiz task estimate maliyetini azaltmaktır. Küçük iş parçaları, throughput ve cycle time kullanılır. Olgun ve stabil ekiplerde uygulanması daha kolaydır. Büyük belirsizlik veya fixed-price sözleşmede tek başına yeterli olmayabilir.

Hangi Tahmin Yöntemi Ne Zaman Kullanılmalı?

Yöntem seçimi projenin türüne, takımın olgunluğuna ve kararın seviyesine göre yapılmalıdır. Yeni üründe geçmiş veri zayıf olduğu için Planning Poker, Three-Point ve kısa forecast horizon daha uygun olabilir. Olgun üründe cycle time, throughput ve probabilistic forecasting güçlü hale gelir. Fixed-price projelerde discovery ve risk reserve daha önemli olurken büyük backlog'larda Affinity veya Bucket yaklaşımı maliyeti düşürür. Tek kurum politikası içinde farklı seviyeler için farklı yöntem tanımlamak en dengeli çözümdür.

Yeni Ürün

Yeni üründe tarihsel veri azdır. Reference story ve Planning Poker iyi başlangıç sağlar. Büyük belirsizlikte Three-Point kullanılabilir. Forecast horizon kısa tutulmalıdır. İlk sprintlerden sonra model yeniden kalibre edilmelidir.

Olgun Ürün

Olgun üründe geçmiş veri önemli avantajdır. Cycle time ve throughput düzenli izlenebilir. Story Counting bazı ekiplerde point ihtiyacını azaltabilir. Monte Carlo daha güvenilir veriyle çalışır. Estimation ceremony zamanla küçülebilir.

Büyük Backlog

Büyük backlog'un tamamını detaylı tahminlemek pahalıdır. Affinity, Bucket veya T-Shirt Sizing kullanılabilir. Yakın dönem maddeleri daha ayrıntılı ele alınır. Uzak maddeler kaba sınıfta kalır. Hiç yapılmayacak işlere fazla zaman harcanmaz.

Küçük Backlog

Küçük backlog daha doğrudan değerlendirilebilir. İşler benzerse story counting yeterli olabilir. Farklı boyutlar varsa relative estimation kullanılabilir. Estimation toplantısı kısa tutulmalıdır. Karar değeri düşük işler için ayrıntı artırılmamalıdır.

Ar-Ge Çalışması

Ar-Ge çalışması yüksek belirsizlik taşır. Kesin süre tahmini çoğu zaman yanıltıcıdır. Spike, PoC ve timebox daha uygundur. Amaç belirli sürede ne öğrenileceğini tanımlamaktır. Sonraki forecast bu öğrenmeye göre hazırlanır.

Fixed-Price Proje

Fixed-Price projede belirsizlik ticari riske dönüşür. Discovery yapılmadan fiyat vermek tehlikelidir. Kapsam varsayımları ve kabul kriterleri açık olmalıdır. Risk premium ve contingency reserve planlanabilir. Change Request mekanizması sözleşmede net olmalıdır.

Bakım ve Destek

Bakım işlerinde geçmiş talep dağılımı güçlü veri sağlar. Incident ve bug oranları ölçülebilir. Support capacity ayrı tutulabilir. Feature kapasitesinin tamamı planlanmamalıdır. Beklenmeyen iş oranına göre buffer ayrılmalıdır.

Legacy Modernizasyon

Legacy modernizasyonunda görünmeyen teknik risk yüksektir. Küçük discovery çalışmaları çok değerlidir. Referans class olarak benzer migration işleri kullanılabilir. Büyük paketler aşamalı teslim edilmelidir. Tek tarih yerine aralık tercih edilmelidir.

Regülasyon Tarihli Proje

Regülasyon projesinde tarih esnek olmayabilir. Bu nedenle scope seçenekleri hazırlanmalıdır. Must kapsam erken güvence altına alınmalıdır. Progressive delivery uygulanabilir. Forecast yüksek güven seviyesiyle takip edilmelidir.

Açık Kaynak Proje

Açık kaynak projelerde contributor kapasitesi değişken olabilir. Issue ve pull request geçmişi önemli veri sağlar. Cycle time ölçülebilir. Ancak gönüllü katkı yapısı kurumsal takımlardan farklıdır. Forecast bu bağlam farkını dikkate almalıdır.

Story Point Nedir?

Story Point, işin kaç saat süreceğini söyleyen bir ölçü değildir. Takımın bir işi diğer işlerle karşılaştırmasına yardımcı olan göreceli büyüklük göstergesidir. Efor, teknik zorluk, risk ve belirsizlik birlikte değerlendirilebilir. Takım kendi referans story'lerini zaman içinde oluşturur. Bu nedenle Story Point'i kurum genelinde standartlaştırmak veya çalışan performansına bağlamak ciddi davranış bozuklukları üretir.

Story Point Neyi Ölçer?

Story Point göreceli iş büyüklüğünü ifade eder. Takım kendi deneyimini ortak ölçeğe dönüştürür. Aynı sayı farklı teknik faktörlerin birleşiminden gelebilir. Bu nedenle point'in arkasındaki tartışma sayının kendisi kadar değerlidir. Ölçek yalnızca takımın kendi bağlamında anlamlıdır.

Efor

Daha fazla aktif çalışma gerektiren iş genellikle daha büyük point alabilir. Ancak point yalnızca saat miktarını temsil etmez. Risk ve bilinmeyenler de değerlendirmeye katılır. İki eşit saatlik iş farklı point alabilir. Bu durum Story Point'in göreceli yapısının doğal sonucudur.

Karmaşıklık

Teknik olarak zor bir değişiklik daha fazla analiz gerektirebilir. Çok sayıda modülü etkileyen çalışma küçük kod değişikliği olsa bile büyük değerlendirilebilir. Takım bu farkı reference story'lerle kalibre eder. Karmaşık iş parçalanabiliyorsa tahmin daha anlamlı hale gelir. Büyük point aynı zamanda parçalama sinyali olabilir.

Risk

Risk sonucun değişme ihtimalini artırır. Harici API veya kritik migration buna örnektir. Bazı ekipler risk seviyesini point içinde değerlendirir. Bazıları ayrıca risk alanı tutar. İkinci yaklaşım yönetim açısından daha görünür bilgi sağlar.

Belirsizlik

Bilgi eksikliği point'in yükselmesine neden olabilir. Fakat çok yüksek bilinmezliği point ile saklamak doğru değildir. Bu durumda spike yapmak daha değerlidir. Bilgi kazanıldıktan sonra yeniden değerlendirme yapılabilir. Böylece point belirsizliğin çöplüğü haline gelmez.

Story Point Neyi Ölçmez?

Story Point saat ölçmez. Kişisel performans puanı değildir. Takımlar arası üretkenlik karşılaştırması için kullanılmaz. Maaş veya prim kriterine dönüştürülmemelidir. Point'in amacı planlama ve ortak anlayışı desteklemektir.

Story Point Neden Takıma Özgüdür?

Her takım farklı referanslarla kalibrasyon yapar. Definition of Done, teknoloji ve deneyim farklıdır. Bu nedenle bir takımın sekiz point'i başka takımın sekiz point'i değildir. Zaman içinde takım kendi ölçeğini öğrenir. Ölçek değişirse geçmiş velocity dikkatle yorumlanmalıdır.

Story Point Neden Evrensel Bir Ölçü Birimi Değildir?

Story Point fiziksel bir ölçü gibi standart değildir. Metre veya saat gibi ortak dönüşüm katsayısı yoktur. Her takım kendi göreceli referansını oluşturur. Evrensel hale getirilmeye çalışıldığında sayı yapay biçimde normalize edilir. Bu durum ölçümün anlamını bozar.

Story Point ile Saat Arasındaki Fark

Story point planning poker ve saat bazlı efor tahmini karşılaştırması yapılırken ilk ayrım relative ve absolute estimation arasında kurulmalıdır. Story Point bir işi başka işlerle karşılaştırır. Saat ise belirli bir zaman miktarı hakkında doğrudan tahmin sunar. İkisi farklı soruları cevaplar ve biri diğerinin matematiksel dönüşümü değildir. Finans için saat gerekli olabilir, ancak bu ihtiyaç Story Point'i saate çevirmek yerine ayrı kapasite forecast'iyle karşılanmalıdır.

Relative vs Absolute Estimation

Relative estimation karşılaştırmaya dayanır. Absolute estimation doğrudan saat veya gün söyler. İnsanlar benzer işleri kıyaslamakta çoğu zaman daha tutarlıdır. Ancak bazı ticari kararlar mutlak zaman bilgisi gerektirir. Bu durumda geçmiş throughput ve kapasite birlikte kullanılabilir.

“1 Story Point = 4 Saat” Yaklaşımının Sorunu

Bu dönüşüm Story Point'in göreceli doğasını bozar. Point bir süre birimi olmadığı için sabit katsayı anlamlı değildir. Ekip zamanla point değerlerini saat hedefine göre vermeye başlayabilir. Böylece Planning Poker yeniden saat tahminine dönüşür. Story Point kullanmanın önemli avantajları kaybolur.

Kişiden Kişiye Süre Farkı

Aynı story farklı kişiler için farklı aktif süre gerektirebilir. Bunun nedeni deneyim ve sistem bilgisi olabilir. Point takım seviyesinde boyutlandırma yapar. Kişiye özel saat hesabı üretmeye çalışmak bu yapıyı bozar. Sprint kapasitesi takım seviyesinde değerlendirilmelidir.

Takımdan Takıma Story Point Farkı

Farklı takımların referansları farklıdır. Bir ekip üç point verdiği işe başka ekip sekiz point verebilir. Bu iki sayı arasında doğrudan verimlilik ilişkisi yoktur. Ortak point standardı kurmak çoğu zaman gereksizdir. Program seviyesinde throughput veya teslim forecast'i daha anlamlıdır.

Saat Gerekiyorsa Nasıl Ayrı Forecast Üretilmeli?

Finans veya teklif için saat gerekiyorsa kapasite modeli kurulabilir. Takımın gerçek focus factor değeri kullanılabilir. Geçmiş benzer işlerin kişi-gün verisi incelenebilir. Risk ve waiting time ayrıca gösterilir. Böylece point'in anlamı korunurken iş ihtiyacı karşılanır.

Story Point'i Saate Çevirmek Neden Kurumsal Olarak Caziptir?

Kurumlar ortak raporlama birimi ister. Finans maliyet, satış fiyat, yönetim tarih ve insan kaynakları kapasite görmek ister. Story Point'in belirsiz görünmesi bu nedenle rahatsızlık yaratabilir. Sabit dönüşüm tablosu kolay bir çözüm gibi görünür. Fakat kolay olması doğru olduğu anlamına gelmez ve çoğu zaman point sistemini yalnızca farklı isimle saat tahminine dönüştürür.

Finansın Adam/Saat İhtiyacı

Finans bütçeyi para birimine çevirmek zorundadır. Bunun için personel maliyeti ve tahmini çalışma süresi gerekir. Story Point doğrudan finansal maliyet değildir. Ekip kapasitesi ve burn rate ayrı hesaplanabilir. Böylece point'i finans birimine dönüştürmeye gerek kalmaz.

Satışın Fiyat İhtiyacı

Satış müşteriye teklif sunar. Bu ihtiyaç gerçek ve önemlidir. Fiyat oluştururken discovery, risk ve scope varsayımları kullanılmalıdır. Geçmiş benzer projeler güçlü referans sağlar. Point çarpı saat formülü tek başına güvenilir fiyat üretmez.

Yönetimin Takvim İhtiyacı

Yönetim “ne zaman?” sorusunun cevabını ister. Story Point bu soruyu doğrudan cevaplamaz. Tarihsel velocity veya throughput kullanılarak forecast oluşturulabilir. Olasılık seviyesi eklenebilir. Bu yöntem point'i saate çevirmekten daha açıklayıcıdır.

Kaynak Planlama İhtiyacı

Kaynak planlama kişi sayısından daha fazlasıdır. Rol, uzmanlık ve kullanılabilir kapasite değerlendirilmelidir. Point dönüşümü bu ayrıntıları saklayabilir. Gerçek kapasite takvim üzerinden hesaplanmalıdır. İzin, destek ve toplantılar hesaba katılmalıdır.

Kolay Görünen Fakat Yanlış Dönüşüm

Sabit point-saat oranı yönetim raporunu kolaylaştırır. Fakat ekip farklı iş türlerinde aynı oranı sürdüremez. Sonunda point'ler saat hedeflerine göre ayarlanır. Bu durum relative estimation faydasını ortadan kaldırır. Ayrı forecast modeli daha sağlıklıdır.

Story Point'i Saatleştirmeden İş İhtiyacını Karşılamak

Takım Story Point'i planlama için kullanabilir. Yönetim ise throughput tabanlı tarih forecast'i görebilir. Finans ekip burn rate üzerinden bütçe hesaplayabilir. Satış reference class verisiyle teklif hazırlayabilir. Böylece her ihtiyaca doğru ölçü sunulur.

Fibonacci Neden Kullanılır?

Fibonacci ölçeğinin amacı matematiksel bir kural uygulamak değildir. Asıl fayda, iş büyüdükçe tahmin hassasiyetinin doğal olarak azalmasını görünür hale getirmesidir. Bir ile iki arasındaki fark küçükken sekiz ile on üç arasındaki boşluk daha büyüktür. Bu durum büyük işlerdeki bilinmezliği yansıtır. Ekip dokuz mu on mu tartışmak yerine işin neden büyük olduğunu konuşur.

1–2–3–5–8–13 Ölçeği

Bu sıra göreceli boyut farklarını büyütür. Küçük işler daha ayrıntılı ayrılır. Büyük işler daha geniş sınıfa girer. Bu yapı aşırı hassasiyeti azaltır. Takım kendi reference story'lerini bu sayılarla eşleştirebilir.

Büyük İşlerde Belirsizliğin Artması

İş büyüdükçe daha fazla teknik alan etkilenebilir. Bağımlılık ve test sayısı artar. Bilinmeyenlerin oranı yükselir. Bu nedenle point aralıklarının genişlemesi mantıklıdır. Çok büyük işler parçalanmalıdır.

Sahte Hassasiyeti Azaltmak

Her sayının seçilebilir olması gereksiz tartışma yaratır. Sekiz ve dokuz arasındaki fark çoğu durumda anlamsızdır. Fibonacci daha büyük adımlar sunar. Ekip dikkatini iş riskine yöneltir. Bu yaklaşım estimation toplantısını kısaltabilir.

8 ile 9 Arasında Tartışmak Yerine İşin Bilinmezliğini Tartışmak

Point sayısı amaç değildir. İki kişi farklı düşünüyor ise bunun nedeni anlaşılmalıdır. Bir kişi entegrasyon riskini biliyor olabilir. Diğeri scope'u daha dar anlamış olabilir. Bu bilgi farkının çözülmesi sayı seçmekten daha değerlidir.

Planning Poker Nasıl Yapılır?

Planning Poker iyi uygulandığında tahmin toplantısından çok ortak teknik anlayış toplantısıdır. İş önce açıklanır, ekip sorular sorar ve varsayımlar netleştirilir. Her katılımcı bağımsız oy verir ve oylar aynı anda açılır. Büyük fark varsa en yüksek ve en düşük tahminin gerekçesi konuşulur. Ortak anlayış geliştikten sonra yeniden oylama yapılır ve süreç gereksiz uzamaması için timebox içinde tutulur.

İşin Açıklanması

Product Owner işin amacını ve beklenen sonucu açıklar. Acceptance criteria paylaşılır. Teknik çözüm doğrudan dikte edilmez. Ekip kapsamı anlamaya odaklanır. Eksik bilgi varsa önce bu eksik tamamlanır.

Soruların Sorulması

Geliştirici, QA ve diğer roller farklı sorular getirir. Veri, entegrasyon ve edge case'ler tartışılır. Bu sorular estimate kalitesini yükseltir. Sessizlik ortak anlayış anlamına gelmez. Her rolün katkı vermesi teşvik edilmelidir.

Varsayımların Netleştirilmesi

Tahmin çoğu zaman varsayıma dayanır. Hangi API'nin hazır olduğu veya tasarımın tamamlanıp tamamlanmadığı açıkça belirtilmelidir. Varsayım değişirse estimate de değişebilir. Bu bilgi kaydedilmelidir. Sonradan yapılan retrospective için güçlü veri sağlar.

Oyların Gizli Verilmesi

Gizli oy ilk söylenen sayının diğerlerini etkilemesini azaltır. Junior ekip üyesi senior görüşünden bağımsız düşünebilir. Yönetici etkisi de sınırlanır. Herkes kendi değerlendirmesini yapar. Bu süreç farklı bilginin görünmesini sağlar.

Eşzamanlı Açıklama

Oylar aynı anda açılmalıdır. Böylece katılımcılar diğer kişilerin sayısına göre karar değiştirmez. Farklı tahminler tartışma sinyalidir. Yakın tahminler ortak anlayışı gösterebilir. Amaç çoğunluğa göre sayı seçmek değildir.

En Yüksek ve En Düşük Tahminlerin Tartışılması

En uç görüşler genellikle en fazla bilgi taşır. Yüksek tahmin veren kişi gizli risk fark etmiş olabilir. Düşük tahmin veren kişi daha basit çözüm biliyor olabilir. Her ikisi de açıklama yapar. Takım yeni bilgi üzerinden kapsamı tekrar değerlendirir.

Yeniden Oylama

Tartışma sonrasında yeniden oy verilir. Amaç zorla aynı sayıya ulaşmak değildir. Yeterli ortak anlayış varsa sonuç kaydedilir. Fark devam ediyorsa iş fazla belirsiz olabilir. Bu durumda spike veya parçalama düşünülebilir.

Ortak Anlayış

Planning Poker'ın en önemli çıktısı ortak anlayıştır. Sayı yalnızca bu konuşmanın özetidir. Riskler ve bağımlılıklar görünür hale gelir. Product teknik etkileri öğrenir. Ekip geliştirme başlamadan önce daha fazla bilgiye sahip olur.

Planning Poker'ın Asıl Değeri Sayı mı, Tartışma mı?

Deneyimime göre Planning Poker'ın en değerli anı bütün kartların aynı çıkması değildir. Bir geliştiricinin üç, QA'nın sekiz ve DevOps'un on üç verdiği an daha değerlidir. Çünkü bu fark genellikle üç kişinin aynı işi farklı risklerle gördüğünü gösterir. Tartışma yapıldığında eksik test senaryosu, deployment bağımlılığı veya teknik borç ortaya çıkabilir. Bu nedenle toplantının başarısını yalnızca kaç point üretildiğiyle ölçmek doğru değildir.

Farklı Teknik Perspektiflerin Ortaya Çıkması

Her rol aynı probleme farklı açıdan bakar. Geliştirici kod değişikliğine odaklanabilir. QA regresyon etkisini görür. DevOps deployment sürecini düşünür. Bu fark tahmin kalitesini artırır.

QA'nın Gördüğü Risk

QA görünmeyen test kapsamını fark edebilir. Basit feature çok sayıda eski senaryoyu etkileyebilir. Test ortamı hazırlığı gerekebilir. Bu bilgi point'i veya forecast'i değiştirebilir. QA'nın estimation sürecinde bulunması bu nedenle değerlidir.

Developer'ın Gördüğü Karmaşıklık

Developer kod yapısındaki gizli bağımlılıkları bilir. Legacy modül değişikliği beklenenden geniş olabilir. Refactoring gerekebilir. Product bu teknik ayrıntıyı başlangıçta bilmeyebilir. Planning Poker bu bilgiyi görünür hale getirir.

DevOps'un Gördüğü Deployment Riski

Deployment her zaman otomatik ve risksiz olmayabilir. Migration, rollback veya environment farkı süreyi etkileyebilir. DevOps bu riskleri erken söyleyebilir. Release planı buna göre güncellenir. Böylece development done ile production done birbirine karıştırılmaz.

Product'ın Bilmediği Teknik Bağımlılık

Product iş değerini ve kapsamı iyi bilir. Teknik bağımlılığın tamamını bilmesi beklenmez. Geliştiriciler entegrasyon ve veri etkisini açıklayabilir. Product gerekli scope trade-off kararını verebilir. Böylece teknik bilgi iş kararına bağlanır.

Farklı Oyların Bilgi Eksikliği Sinyali Olması

Büyük oy farkı hemen uzlaşılması gereken sorun değildir. Önce farkın nedeni anlaşılmalıdır. Kapsam farklı algılanmış olabilir. Bir bağımlılık bazı kişiler tarafından bilinmiyor olabilir. Bu sinyal estimation sürecinin en değerli çıktılarından biridir.

Planning Poker Ne Zaman Gereksiz Maliyete Dönüşür?

Her backlog maddesi için uzun Planning Poker toplantısı yapmak estimation sürecini kendi başına iş yüküne dönüştürür. Yakın zamanda yapılmayacak bir story için yirmi dakika tartışıp altı ay sonra aynı işi yeniden tahminlemek gerçek değer üretmez. Benzer boyuttaki rutin işler için story counting daha ekonomik olabilir. Ekip estimation cost ile decision value arasında denge kurmalıdır. Gereksiz tören azaltıldığında geliştiriciler daha fazla zamanı gerçek teslimata ayırabilir.

Her Küçük İş İçin Uzun Toplantı

Rutin küçük işler için uzun tartışma gereksizdir. Reference story kullanmak yeterli olabilir. Takım benzer işleri hızlı sınıflandırabilir. Sadece sıra dışı maddeler konuşulur. Böylece toplantı maliyeti düşer.

Uzak Backlog Maddelerini Detaylı Tahmin Etmek

Uzak backlog yüksek değişim ihtimaline sahiptir. Ayrıntılı estimate kısa sürede güncelliğini kaybedebilir. T-Shirt veya range daha uygundur. Yaklaştıkça yeniden refinement yapılır. Bu yöntem estimation debt oluşmasını azaltır.

Aynı Tartışmaları Tekrarlamak

Benzer işler sürekli yeniden açıklanıyorsa reference data eksiktir. Takım öğrenilen dersleri kaydetmelidir. Reference story kataloğu oluşturulabilir. Böylece aynı konuşma tekrar edilmez. Estimation daha hızlı hale gelir.

Sayı İçin Tartışmak

Sekiz mi on üç mü sorusu bazen gereğinden fazla zaman alır. Asıl soru bunun hangi kararı değiştireceğidir. İki sayı aynı plan kararına yol açıyorsa tartışma bitirilebilir. Perfect estimate aramak maliyetlidir. Yeterince iyi bilgi çoğu zaman yeterlidir.

Tahmin Toplantısının Development Süresini Tüketmesi

Estimation toplantısının gerçek maliyeti ölçülmelidir. On kişinin iki saat toplantısı yirmi kişi-saat demektir. Ay boyunca bu süre önemli boyuta ulaşabilir. Karar değeriyle karşılaştırılmalıdır. Gereksiz toplantılar kaldırılabilir.

Timebox Kullanmak

Timebox tartışmayı odakta tutar. Belirli süre içinde sonuca ulaşılamıyorsa problem bilgi eksikliği olabilir. İş parçalanabilir veya spike açılabilir. Toplantının uzaması otomatik olarak daha iyi tahmin üretmez. Ekip bir sonraki adımı netleştirip ilerlemelidir.

T-Shirt Sizing Ne Zaman Kullanılmalı?

T-Shirt Sizing özellikle erken aşamada hızlı karar vermek için güçlü bir yöntemdir. XS, S, M, L ve XL gibi sınıflar detaylı saat tartışmasını ortadan kaldırır. Büyük backlog'u hızlı taramak ve hangi işlerin discovery gerektirdiğini görmek kolaylaşır. Roadmap seviyesinde yönetimin ihtiyaç duyduğu kaba kapasite görünümünü sağlar. Daha yakın döneme gelen işler sonradan daha ayrıntılı yöntemlerle değerlendirilebilir.

XS–S–M–L–XL

Bu ölçek kolay anlaşılır. Sayısal hassasiyet baskısını azaltır. Ekip göreceli büyüklüğe odaklanır. XL işler parçalama veya discovery adayı olabilir. Boyutların anlamı takım içinde örneklerle tanımlanmalıdır.

Roadmap Seviyesinde Kaba Tahmin

Roadmap için kesin saat gereksizdir. Yönetim büyük yatırım alanlarını görmek ister. T-Shirt hızlı karşılaştırma sağlar. Uzak tarihlerde esnek kalmayı destekler. İlerleyen dönemde estimate detaylandırılır.

Büyük Backlog

Yüzlerce maddeyi Planning Poker ile değerlendirmek pahalıdır. T-Shirt toplu sınıflandırmayı hızlandırır. Sadece büyük veya belirsiz işler tartışılır. Küçük işler hızlıca gruplanır. Backlog temizliği için de faydalıdır.

Discovery Aşaması

Discovery sırasında bilgi sınırlıdır. Kesin sayı vermek erken olabilir. Kaba boyut yatırım kararına yardımcı olur. Büyük alanlar için araştırma planlanır. Sonraki estimate daha güçlü bilgiyle yapılır.

Hassasiyet Gerektirmeyen Kararlar

Bazı kararlar için işin küçük mü büyük mü olduğunu bilmek yeterlidir. Saat hesabı ek bilgi sağlamaz. Bu durumda T-Shirt uygun maliyetlidir. Karar hızlı verilir. Ekip gereksiz estimation süresinden kurtulur.

Büyük Maddeleri Hızlı Belirlemek

XL iş alarm sinyalidir. Genellikle daha fazla bilinmeyen ve bağımlılık vardır. İş bölünebilir. Discovery planlanabilir. Böylece büyük riskler roadmap'in erken aşamasında görünür olur.

Affinity Estimation ve Bucket System

Affinity Estimation ve Bucket System büyük backlog'larda estimation maliyetini önemli ölçüde azaltabilir. İşler tek tek uzun tartışma yerine göreceli biçimde sıralanır veya önceden tanımlanmış boyut gruplarına yerleştirilir. Ekip yalnızca anlaşmazlık bulunan veya olağan dışı işleri detaylandırır. Bu yöntemler özellikle uzak backlog maddelerinde güçlüdür. Yakın döneme gelen kritik işler daha sonra Planning Poker veya Three-Point gibi yöntemlerle incelenebilir.

Çok Sayıda İşi Hızlı Boyutlandırmak

Toplu değerlendirme zaman kazandırır. İşler benzer özelliklerine göre gruplanır. Her madde için uzun tartışma yapılmaz. Sıra dışı olanlar ayrılır. Böylece büyük backlog yönetilebilir hale gelir.

Göreceli Sıralama

İşler önce birbirine göre sıralanabilir. Daha sonra bu sıra boyut sınıflarına dönüştürülür. İnsanların karşılaştırma becerisi kullanılır. Mutlak saat verme baskısı azalır. Sonuç roadmap planı için yeterli olabilir.

İlk Kaba Sınıflandırma

İlk sınıflandırma nihai estimate değildir. Amaç detay gerektiren işleri bulmaktır. Büyük ve belirsiz maddeler öne çıkar. Küçük rutin işler hızlı geçilir. Estimation yatırımı doğru yere yönelir.

Kritik İşleri Sonradan Detaylandırmak

Her iş aynı karar değerine sahip değildir. Yakın dönemde yapılacak veya büyük risk taşıyan işler ayrıntılı ele alınabilir. Uzak işlerin kaba tahmini korunur. Bu yaklaşım rolling-wave planning ile uyumludur. Tahmin bakımı azalır.

Estimation Maliyetini Azaltmak

Toplantı zamanı da bir maliyettir. Çok sayıda kişinin saatlerce tahmin yapması delivery kapasitesini azaltır. Affinity ve Bucket bu maliyeti sınırlar. Verilen kararın değerine uygun hassasiyet sağlanır. Daha az ceremony ile yeterli bilgi üretilebilir.

Three-Point Estimation

Three-Point Estimation özellikle belirsiz ve yüksek riskli işlerde tek sayıdan daha fazla bilgi sağlar. Ekip optimistic, most likely ve pessimistic senaryoları ayrı ayrı düşünür. Bu yaklaşım “kaç gün sürer?” sorusunu “hangi koşullarda ne kadar sürebilir?” sorusuna dönüştürür. Böylece riskler tahminin içinde görünür olur. Kurumsal teklif, entegrasyon ve regülasyon projelerinde oldukça kullanışlıdır.

Optimistic Estimate

Optimistic Estimate işlerin planlandığı gibi gittiği senaryodur. Kritik risklerin gerçekleşmediği varsayılır. Bu değer en erken gerçekçi sonucu temsil eder. Pazarlama hedefi olarak tek başına kullanılmamalıdır. Diğer senaryolarla birlikte değerlendirilmelidir.

Most Likely Estimate

Most Likely en olası normal çalışma koşulunu temsil eder. Ekip geçmiş deneyimine dayanır. Küçük sorunların oluşabileceği kabul edilir. Bu sayı kesin sonuç değildir. Dağılımın merkezi için referans sağlar.

Pessimistic Estimate

Pessimistic Estimate önemli risklerin gerçekleştiği senaryoyu düşünür. Harici bağımlılık veya rework buna dahil olabilir. Gerçekçi kötü senaryo olmalıdır. Sınırsız felaket varsayımı yapılmamalıdır. Risk reserve planında değerli bilgi sağlar.

Tek Sayı Yerine Senaryo

Senaryo yaklaşımı yönetim konuşmasını değiştirir. İnsanlar yalnızca bir rakam üzerinde pazarlık yapmaz. Hangi varsayımın sonucu değiştirdiğini görür. Scope ve risk seçenekleri tartışılır. Bu nedenle karar kalitesi yükselir.

Riskleri Erken Tartışmak

Pessimistic senaryo hazırlanırken riskler doğal olarak ortaya çıkar. Ekip bağımlılık ve teknik bilinmeyenleri konuşur. Bazı riskler erken aksiyonla azaltılabilir. Bu durumda tahmin aralığı da daralabilir. Estimation risk yönetimine bağlanmış olur.

PERT Yaklaşımı

PERT üç değerden ağırlıklı tahmin üretir. Most Likely değere daha fazla ağırlık verir. Sonuç planlama için tek özet sayı sağlayabilir. Yine de O, M ve P değerleri saklanmalıdır. Yalnızca ortalama gösterildiğinde risk bilgisi kaybolur.

O

O, optimistic değeri temsil eder. En iyi gerçekçi senaryodur. Kritik engellerin oluşmadığı kabul edilir. Gerçek dışı derecede düşük seçilmemelidir. Amaç olası alt sınırı göstermektir.

M

M, most likely değeri temsil eder. Ekibin normal şartlarda beklediği sonucu gösterir. Tarihsel veriden destek alınabilir. Tek başına commitment değildir. PERT formülünde en yüksek ağırlığa sahiptir.

P

P, pessimistic değeri temsil eder. Önemli risklerin gerçekleştiği kötü senaryodur. Makul üst sınır sağlamaya çalışır. Contingency planını destekler. Risklerin açıkça yazılması gerekir.

Ağırlıklı Tahmin

Klasik PERT hesabı O, dört M ve P değerini kullanır. Toplam altıya bölünür. Böylece most likely senaryoya daha fazla ağırlık verilir. Sonuç ortalama beklentiyi gösterir. Fakat güven seviyesi için tek başına yeterli değildir.

Three-Point Estimation Kurumlarda Nerede Kullanılabilir?

Three-Point Estimation her story için gerekli değildir. Yüksek belirsizlik taşıyan ve yanlış tahminin ciddi maliyet doğuracağı alanlarda daha değerlidir. Büyük epic, yeni entegrasyon, regülasyon projesi veya müşteri teklifi bu kapsama girebilir. Yönetim sunumunda tek rakam yerine üç senaryo göstermek karar seçeneklerini daha net hale getirir. Böylece risk yalnızca teknik ekibin zihninde kalmaz.

Teklif Hazırlama

Teklif hazırlanırken optimistic fiyatı tek gerçek gibi sunmak risklidir. Üç senaryo ticari riski görünür yapar. Scope varsayımları yazılır. Risk reserve daha bilinçli belirlenir. Müşteriye uygun teklif modeli seçilebilir.

Büyük Epic

Büyük epic çok sayıda bilinmeyen barındırır. Tek point sayısı yetersiz olabilir. O, M ve P aralığı daha fazla bilgi verir. Daha sonra epic küçük parçalara ayrılır. Geliştirme ilerledikçe forecast güncellenir.

Regülasyon Projesi

Tarih sabit olduğunda riskin etkisi büyür. Pessimistic senaryo planlama açısından kritiktir. Minimum scope belirlenebilir. Contingency ve progressive delivery kullanılır. Yönetim risk seviyesini açıkça görür.

Entegrasyon

Entegrasyonlarda dış sistem davranışı belirsiz olabilir. Test ortamı veya veri kalitesi sorun çıkarabilir. Üç senaryo bu belirsizliği temsil eder. Spike ile bazı riskler erken azaltılabilir. Tahmin daha sonra daraltılabilir.

Yeni Teknoloji

Yeni teknoloji öğrenme eğrisi taşır. Ekip normal hızını hemen yakalayamayabilir. PoC belirsizliği azaltır. Three-Point ilk plan için uygun olabilir. İlk gerçek teslimattan sonra model yeniden değerlendirilir.

Yönetim Sunumu

Yönetim tek tarih görmek isteyebilir. Üç senaryo bu isteği daha sağlıklı çerçeveye taşır. Her senaryonun varsayımı açıklanır. Karar verici risk toleransını seçebilir. Böylece teknik belirsizlik iş kararına çevrilir.

Expert Judgment Nedir?

Expert Judgment, deneyimli kişilerin geçmiş proje bilgisinden yararlanır ve özellikle erken aşamada hızlı karar vermek için değerlidir. Ancak uzman görüşü kusursuz değildir. Anchoring, optimism bias ve hiyerarşik baskı sonucu etkileyebilir. Bu nedenle mümkün olduğunda birden fazla bağımsız görüş alınmalı ve geçmiş gerçekleşmelerle karşılaştırılmalıdır. Uzman deneyimi veriyle birlikte kullanıldığında en güçlü sonucu verir.

Senior Uzman Görüşü

Senior uzman benzer teknik riskleri daha önce görmüş olabilir. Hidden complexity konusunda güçlü sinyal verir. Legacy davranışları erken fark edebilir. Fakat tek görüş mutlak gerçek kabul edilmemelidir. Takım diğer perspektifleri de paylaşmalıdır.

Uzman Görüşünün Avantajları

Hızlıdır ve az veri gerektirir. Yeni projelerde ilk kaba değerlendirmeyi sağlar. Benzer geçmiş iş varsa özellikle değerlidir. Teknik riskleri erken ortaya çıkarabilir. Discovery önceliğini belirlemeye yardımcı olur.

Tek Kişi Tahmininin Riskleri

Tek kişi tüm bilgiyi taşımaz. Kendi deneyimine fazla güvenebilir. Farklı test veya operasyon perspektiflerini kaçırabilir. Ayrıca sayı diğer ekip üyeleri için anchor olur. Bağımsız çoklu görüş daha sağlıklıdır.

Anchoring

İlk duyulan sayı sonraki tahminleri etkileyebilir. Özellikle yönetici veya senior kişi rakamı önce söylerse etki büyür. Gizli oy bu riski azaltır. Bağımsız expert estimate kullanılabilir. Sonra sonuçlar birlikte tartışılır.

Optimism Bias

İnsanlar işlerin planlandığı gibi ilerleme ihtimalini fazla değerlendirebilir. Özellikle tanıdık görünen işler küçük tahmin edilir. Tarihsel cycle time bu önyargıyı dengeler. Pessimistic senaryo ek perspektif sağlar. Tahmin sonrası retrospective de kalibrasyonu geliştirir.

HiPPO Etkisi

En yüksek pozisyondaki kişinin görüşü tartışmayı baskılayabilir. Ekip üyeleri farklı tahmini söylemekten kaçınabilir. Bu nedenle yönetici ilk sayı vermemelidir. Gerekirse teknik estimation ayrı oturumda yapılabilir. Yönetim beklentisi sonradan değerlendirilir.

Birden Fazla Uzmanın Görüşünü Kullanmak

Bağımsız görüşler farklı riskleri ortaya çıkarır. Uzmanlar önce ayrı tahmin verebilir. Büyük farkların nedeni tartışılır. Ortak varsayımlar oluşturulur. Sonuç geçmiş veriyle doğrulanabilir.

Reference Class Forecasting

Reference Class Forecasting, “bu iş ne kadar sürer?” sorusuna yalnızca içeriden bakmak yerine “benzer işler geçmişte gerçekten ne kadar sürdü?” sorusunu ekler. Bu değişiklik özellikle optimism bias etkisini azaltır. Kurum tamamlanmış epic, entegrasyon, migration ve proje verilerini sınıflandırabilir. Böylece yeni tahminler kişisel hafızadan değil ortak veri setinden destek alır. Zaman içinde kurum kendi estimation referans sistemini oluşturur.

“Bu İş Ne Kadar Sürer?” Yerine “Benzer İşler Ne Kadar Sürdü?”

İlk soru iç görüşe dayanır. İkinci soru gerçek gerçekleşmelere bakar. İkisini birlikte kullanmak daha güçlüdür. Benzer işlerin dağılımı tek örnekten daha değerlidir. Özellikle büyük projelerde bu yaklaşım faydalıdır.

Benzer Projelerin Tarihsel Verisi

Proje türleri sınıflandırılmalıdır. Migration, entegrasyon ve yeni ürün ayrı kategoriler olabilir. Tahmin ve gerçek süre birlikte saklanır. Scope change bilgisi eklenir. Yeni projede uygun reference class seçilir.

Benzer Epic'ler

Epic seviyesinde geçmiş veriler roadmap için değerlidir. Sadece point değil cycle time da tutulmalıdır. Epic'in kaç kez scope değiştirdiği önemlidir. Büyük sapmaların nedeni kaydedilir. Yeni epic tahmininde bu bilgi kullanılır.

Benzer Entegrasyonlar

Entegrasyonlarda tekrar eden riskler vardır. Vendor gecikmesi, test veri sorunu veya güvenlik onayı buna örnektir. Geçmiş entegrasyon süreleri önemli referans sağlar. Pessimistic senaryo daha gerçekçi kurulabilir. Risk reserve veriye dayanır.

İç Görüş Yerine Dış Görüş

İç görüş mevcut projenin özel koşullarına odaklanır. Dış görüş benzer işlerin genel dağılımına bakar. İkisi birlikte kullanılmalıdır. Yalnızca iç görüş aşırı iyimser olabilir. Yalnızca dış görüş ise proje bağlamını kaçırabilir.

Kurumsal Estimation Veri Seti Oluşturmak

Veri seti zamanla büyük değer üretir. Proje türü, teknoloji, scope ve gerçek süre tutulmalıdır. Defect, rework ve blocked time eklenebilir. Verinin düzenli güncellenmesi gerekir. Kalitesiz veri yanlış forecast üretir.

Geçmiş Veri Tahminde Nasıl Kullanılır?

Geçmiş veri tahmin kalitesini artırır ancak yalnızca doğru bağlamda kullanıldığında. Tamamlanan story sayısı, cycle time, throughput, lead time, defect oranı, rework ve scope change birlikte incelenebilir. Ortalama tek başına yeterli değildir çünkü dağılım önemli bilgi taşır. Özellikle uç değerler gerçek operasyon riskini gösterir. Estimation vs actual analizi kişileri değerlendirmek için değil sistemi kalibre etmek için kullanılmalıdır.

Tamamlanmış Story'ler

Tamamlanan story geçmiş iş yapısını gösterir. Benzer boyut ve türler reference olarak kullanılabilir. Çok eski veriler dikkatle değerlendirilmelidir. Teknoloji veya ekip değişmiş olabilir. Veri bağlamıyla birlikte saklanmalıdır.

Cycle Time

Cycle time işin başladıktan sonra ne kadar sürede bittiğini gösterir. Dağılım forecast için kullanılabilir. Ortalama yerine yüzdelikler daha açıklayıcıdır. Örneğin işlerin yüzde 85'inin sekiz gün içinde tamamlanması anlamlı bilgidir. Service Level Expectation buna göre oluşturulabilir.

Throughput

Throughput belirli dönemde tamamlanan iş sayısıdır. Haftalık veya sprint bazında ölçülebilir. Kalan scope ile birleştirilerek teslim forecast'i üretilebilir. Dağılım kullanılmalıdır. Tek ortalama kötü haftaları saklayabilir.

Lead Time

Lead time müşteri talebinden teslimata kadar geçen süreyi gösterir. Kuyruk ve bekleme süresini de içerir. Kurumsal süreç sorunlarını görmek için değerlidir. Development iyileştiği halde lead time değişmiyorsa başka darboğaz olabilir. Bu ayrım yönetim açısından önemlidir.

Defect Oranı

Yüksek defect oranı rework kapasitesini artırır. İlk estimate bunu hesaba katmıyorsa forecast sapabilir. Defect trendi kalite yatırımı kararını destekler. Aynı zamanda gerçek kapasiteyi etkiler. Bu veri performance cezası olarak kullanılmamalıdır.

Rework

Rework planlanandan farklı tekrar çalışma yaratır. Requirement değişimi veya kalite sorunu kaynaklı olabilir. Ayrı etiketlenmesi faydalıdır. Böylece tahmin hatası ile scope change ayrılır. Kurumsal öğrenme güçlenir.

Scope Change

Tahmin aynı kalırken scope büyürse karşılaştırma anlamını kaybeder. Scope change oranı mutlaka izlenmelidir. Burn-up grafik bu konuda yardımcıdır. Forecast güncellemesinin nedeni açık olur. Yönetim tarih değişimini daha doğru yorumlar.

Estimation vs Actual Analizi

Bu analiz “kim yanlış tahmin etti?” sorusu için kullanılmamalıdır. Amaç sistematik bias bulmaktır. Belirli iş türleri sürekli düşük tahmin ediliyor olabilir. Bu durumda reference data güncellenir. Süreç daha iyi kalibre edilir.

Velocity Nedir?

Velocity, genellikle bir sprint içinde tamamlanan toplam Story Point miktarıdır. Takım kendi ölçeğinde kısa dönem forecast için yararlı olabilir. Fakat velocity üretkenlik puanı değildir ve takımlar arasında karşılaştırılamaz. Point ölçeği, Definition of Done ve iş türleri farklıdır. Yönetim velocity yerine delivery forecast, throughput, cycle time ve business outcome gibi metriklere ağırlık vermelidir.

Sprint Başına Tamamlanan Story Point

Velocity yalnızca tamamlanan işlerden hesaplanmalıdır. Sprint sonunda bitmeyen story'nin point'i sonraki döneme taşınır. Ortalama birkaç sprint üzerinden değerlendirilebilir. Tek sprint büyük dalgalanma gösterebilir. Bu veri yalnızca takım içi kalibrasyonda kullanılmalıdır.

Velocity Ne İçin Kullanılabilir?

Kısa dönem kapasite beklentisini destekleyebilir. Benzer takım yapısı devam ediyorsa backlog forecast'i üretilebilir. Büyük değişikliklerden sonra yeniden kalibrasyon gerekir. Tatil ve incident etkisi dikkate alınmalıdır. Tek veri kaynağı olarak kullanılmamalıdır.

Velocity Ne İçin Kullanılmamalı?

Velocity bireysel performans ölçmez. Takımlar arası yarışma için uygun değildir. Hedef olarak zorunlu artırılmamalıdır. Point miktarı iş değeriyle aynı değildir. Yönetim primi velocity'ye bağlanmamalıdır.

Velocity Trendleri

Trend ani değişiklikleri görmek için faydalı olabilir. Düşüş kapasite veya scope sorununa işaret edebilir. Ancak neden analiz edilmeden yorum yapılmamalıdır. Daha küçük story'lere geçiş velocity'yi değiştirebilir. Flow metrikleriyle birlikte incelenmelidir.

Takım İçinde Forecast Yardımcısı Olarak Kullanım

Takım kendi geçmiş point dağılımını bilir. Kalan backlog point'i üzerinden kaba forecast yapılabilir. Güven seviyesi için geçmiş varyasyon önemlidir. Takım yapısı değiştiğinde model zayıflar. Throughput ve cycle time alternatif olarak değerlendirilebilir.

Velocity Neden Ekipler Arasında Karşılaştırılmamalı?

İki takımın velocity değerini yan yana koyup daha yüksek point tamamlayan ekibi daha üretken kabul etmek temel ölçüm hatasıdır. Çünkü point ölçeği ekip tarafından yerel olarak oluşturulur. Bir takım beş verdiği işe başka takım on üç verebilir. Definition of Done, teknik borç ve iş türü de farklı olabilir. Karşılaştırma başladığında ekipler doğal olarak point sayılarını büyütme eğilimi gösterebilir.

Story Point Ölçekleri Farklıdır

Her takım farklı reference story kullanır. Ölçek ortak fiziksel birim değildir. Bu nedenle doğrudan karşılaştırma anlamsızdır. Ortak standardizasyon da çoğu zaman yapaydır. Program seviyesinde teslim verisi kullanılmalıdır.

Definition of Done Farklıdır

Bir ekip test ve deployment'ı Done kapsamına alabilir. Başka ekip yalnızca development tamamlandığında Done diyebilir. Aynı point farklı iş miktarı temsil eder. Karşılaştırma bu farkı görmez. Önce süreç tanımları anlaşılmalıdır.

İş Türleri Farklıdır

Bir takım yeni feature geliştirirken diğer takım incident çözebilir. İş doğası farklıdır. Point toplamı aynı bağlamı temsil etmez. Business outcome karşılaştırması daha anlamlıdır. Flow metriği de iş türüne göre ayrılmalıdır.

Teknik Borç Farklıdır

Legacy sistemde küçük değişiklik daha fazla iş gerektirebilir. Modern ve testli sistemde aynı feature daha hızlı olabilir. Velocity bu altyapı farkını açıklamaz. Takımların karşılaştırılması yanlış teşvik yaratır. Teknik yatırım bağlamı ayrıca değerlendirilmelidir.

Takımlar Point Enflasyonu Yapabilir

Point hedef haline geldiğinde davranış değişir. Ekip aynı işi daha büyük point'lemeye başlayabilir. Rapor yükselir fakat teslim değeri değişmez. Bu Goodhart etkisinin tipik örneğidir. Metriği hedefe dönüştürmemek gerekir.

Karşılaştırmanın Bozuk Teşvik Üretmesi

Takımlar yüksek sayı için optimize etmeye başlar. Küçük ve değerli işlerden kaçınılabilir. İş parçalama davranışı değişebilir. Ortak çalışma azalabilir. Ölçüm gerçek performans yerine oyun alanına dönüşür.

“Bu Takım 40 Point, Diğeri 25 Point Yapıyor” Yanılgısı

Bu ifade kurumsal estimation kültüründeki en yaygın yanlışlardan biridir. Point üretkenlik birimi olmadığı için 40 ile 25 arasında doğrudan kalite veya hız ilişkisi kurulamaz. Böyle bir karşılaştırma başladığında ekiplerin point tanımı bozulabilir. Goodhart yasasının işaret ettiği gibi bir metrik hedefe dönüştüğünde ölçüm özelliğini kaybetmeye başlar. Yönetim outcome ve flow metriklerine yönelmelidir.

Point'in Üretkenlik Birimi Olmaması

Point yalnızca relative size göstergesidir. Üretilen iş değerini ölçmez. Kaliteyi de doğrudan göstermez. Takımlar arası standart değildir. Bu nedenle performans puanı olarak kullanılamaz.

Point Şişirme Riski

Hedef yükseldikçe ekip point'i artırabilir. Aynı iş eskiden üç iken beş olarak değerlendirilebilir. Rapor iyileşir görünür. Gerçek throughput değişmez. Ölçüm sistemi güven kaybeder.

Takım Davranışının Metriğe Göre Değişmesi

İnsanlar değerlendirildikleri metriğe göre davranır. Point ödüllendiriliyorsa point üretmeye odaklanırlar. Pair Programming daha az çekici hale gelebilir. Refactoring point üretmediği için ertelenebilir. Böylece sistem uzun vadede zarar görür.

Goodhart Yasası Perspektifi

Ölçü hedef olduğunda iyi ölçü olmaktan çıkabilir. Story Point bunun açık örneklerinden biridir. Takım planlama metriğini performans hedefi yapmamalıdır. Yönetim birden fazla outcome ve flow göstergesi kullanmalıdır. Tek sayıdan kaçınılmalıdır.

Outcome ve Flow Metriklerine Geçiş

Throughput, cycle time ve blocked time akışı gösterir. Business outcome ise teslimatın gerçek değerini değerlendirir. Defect ve change failure kalite sinyali sağlar. Bu metrikler birlikte okunmalıdır. Böylece performans daha dengeli değerlendirilir.

Story Point Bireysel Performans Ölçümünde Kullanılmalı mı?

Hayır. Developer başına Story Point, ticket sayısı, kod satırı ve bireysel velocity gibi metrikler ekip çalışmasının doğasını yanlış temsil eder. Bir geliştirici kritik code review yaparak başka üç kişinin hatasını önleyebilir fakat kendi point sayısı düşük kalabilir. Senior geliştirici mentorluk ve mimari çalışma nedeniyle daha az ticket kapatabilir. Bireysel point ölçümü bu değerli davranışları cezalandırabilir.

Developer Başına Point

Story Point takım seviyesinde oluşturulur. Bireye bölmek ölçüm amacını değiştirir. İnsanlar kendi ticket'larını büyütmeye başlayabilir. Ortak çalışma azalabilir. Bu nedenle performans değerlendirmesinde kullanılmamalıdır.

Ticket Sayısı

Ticket sayısı iş büyüklüğünü göstermez. On küçük ticket bir kritik sorundan daha kolay olabilir. Sayı hedef olursa işler yapay biçimde parçalanabilir. Kalite ve değer görünmez hale gelir. Takım outcome'a odaklanmalıdır.

Kod Satırı

Daha fazla kod daha iyi yazılım anlamına gelmez. İyi refactoring kod miktarını azaltabilir. Kütüphane kullanımı yüzlerce satırı ortadan kaldırabilir. Satır sayısını performans metriği yapmak yanlış teşvik üretir. Sürdürülebilirlik ve kalite daha önemlidir.

Bireysel Velocity

Velocity takım kavramıdır. Bireysel hale getirildiğinde işbirliği zayıflar. İnsanlar yardım etmek yerine kendi işlerini optimize edebilir. Pair Programming zarar görebilir. Bilgi paylaşımı azalabilir.

Neden Bu Metrikler Kolay Manipüle Edilir?

Çünkü sayıyı artırmanın iş değerini artırmayan yolları vardır. Ticket bölünebilir. Point büyütülebilir. Gereksiz kod yazılabilir. Bu davranışlar raporu değiştirir fakat müşteri sonucunu iyileştirmez.

İşbirliğini Nasıl Bozar?

Bireysel hedef ortak sorumluluğu azaltır. İnsanlar başka ekip üyesine yardım etmekten kaçınabilir. Review beklemeleri artabilir. Bilgi adaları oluşabilir. Takım toplam teslimatı zarar görür.

Pair Programming ve Code Review'u Nasıl Cezalandırabilir?

Pair Programming iki kişinin aynı işe katkı vermesini sağlar. Bireysel point sisteminde bunun kime yazılacağı sorun olur. Code review yapan kişi ticket kapatmayabilir. Bu nedenle değerli kalite işi görünmez kalır. Yanlış metrik ekip davranışını bozar.

“En İyi Yazılımcı” En Çok Story Point Bitiren Kişi midir?

İyi yazılımcıyı yalnızca tamamlanan ticket veya point sayısıyla değerlendirmek teknik mesleğin önemli bölümünü yok sayar. Problem çözme, code review, mentorluk, riskleri erken fark etme ve sürdürülebilir tasarım uzun vadeli değeri belirler. Bazen en güçlü katkı daha az kod yazarak daha basit çözüm bulmaktır. Bazen üretim incident'ını önleyen bir review, birçok feature'dan daha değerlidir. Bu nedenle bireysel performans çok boyutlu değerlendirilmelidir.

Teknik Kalite

Kaliteli kod gelecekteki değişiklik maliyetini azaltır. Test edilebilirlik önemlidir. Basit tasarım bakım kolaylığı sağlar. Point miktarı bunları ölçmez. Teknik değerlendirme ayrı yapılmalıdır.

Problem Çözme

Zor problemi doğru tanımlamak büyük değerdir. En hızlı kod yazan kişi her zaman en iyi çözümü bulmaz. Gereksiz feature'ı kaldırmak bile değer yaratabilir. Sistem düşüncesi önemlidir. Performans değerlendirmesi bunu dikkate almalıdır.

Code Review

Review ekip kalitesini yükseltir. Hataları production öncesi yakalar. Bilgi paylaşımı sağlar. Ticket sayısına doğrudan yansımayabilir. Buna rağmen delivery başarısı için kritiktir.

Mentorluk

Mentorluk takım kapasitesini uzun vadede artırır. Junior geliştiricilerin bağımsızlaşmasını sağlar. Senior kişinin kısa vadeli output'u azalabilir. Ancak toplam ekip performansı yükselir. Bu katkı point ile ölçülemez.

Riskleri Erken Görme

Deneyimli geliştirici büyük sorunu daha başlamadan fark edebilir. Yanlış mimari kararın önlenmesi haftalar kazandırabilir. Bu katkı ticket olarak görünmeyebilir. Estimation sırasında özellikle değerlidir. Kurum bu davranışı teşvik etmelidir.

Takımın Önündeki Engelleri Kaldırma

Bir kişi başka geliştiricilerin blocked işlerini çözebilir. Kendi point'i düşük kalabilir. Takım throughput'u ise artar. Sistem seviyesinde bakıldığında katkı büyüktür. Performans değerlendirmesi ekip etkisini görmelidir.

Sürdürülebilir Kod Üretme

Hızlı ama kırılgan çözüm gelecekte maliyet yaratır. Sürdürülebilir kod test, gözlemlenebilirlik ve bakım kolaylığı içerir. Bu efor kısa vadede daha fazla olabilir. Uzun vadede cycle time'ı düşürür. Point hedefi kaliteyi baskılamamalıdır.

İşbirliği ve Ownership

Ownership yalnızca kendi ticket'ını kapatmak değildir. Ürünün sonucu için sorumluluk almaktır. Ekip arkadaşına yardım etmek bunun parçasıdır. Incident sırasında katkı vermek de öyledir. İyi performans sistemi bu davranışları destekler.

Kapasite Nedir?

Kapasite, ekibin belirli dönemde gerçekten çalışmaya ayırabileceği kaynak miktarıdır. Nominal kapasite ile gerçek kapasite arasındaki fark çoğu kurumda tahmin sapmasının önemli nedenlerinden biridir. Beş kişinin iki haftalık sprintte yüz kişi-gün kapasitesi olduğu varsayımı gerçek yaşamı yansıtmaz. İzinler, toplantılar, incident, destek, mentorluk ve code review bu kapasitenin bir bölümünü kullanır. Efor tahmini kapasite değildir ve ikisinin ayrı modellenmesi gerekir.

Nominal Kapasite

Nominal kapasite kişi sayısı ile çalışma gününün basit çarpımıdır. Beş kişi ve on gün için elli kişi-gün görünür. Bu teorik üst sınırdır. Gerçek planlama için yeterli değildir. Kesintiler ayrıca hesaplanmalıdır.

Gerçek Kapasite

Gerçek kapasite kullanılabilir çalışma zamanıdır. İzin, tatil, toplantı ve destek çıkarılır. Geçmiş focus factor kullanılabilir. Ekip rol dağılımı dikkate alınır. Sprint planı bu değere göre yapılır.

Focus Factor

Focus Factor nominal zamanın ne kadarının planlı delivery işine gittiğini gösterir. Her kurum için aynı değildir. Geçmiş veriden hesaplanabilir. Zaman içinde trend izlenebilir. Hedef olarak yüzde yüze zorlanmamalıdır.

Sprint Capacity

Sprint kapasitesi o döneme özgüdür. İzin ve tatil sprintten sprinte değişebilir. Production support yükü de etkili olur. Son sprint velocity'sini doğrudan kopyalamak doğru değildir. Mevcut koşullar ayrıca değerlendirilmelidir.

Ekip Kapasitesinin Tahminden Ayrılması

Estimate işin büyüklüğünü ifade eder. Kapasite ise ekibin ne kadar iş yapabileceğini gösterir. Aynı iş ekibin kapasitesi azalınca büyümez. Sadece tamamlanma süresi değişir. Bu ayrım forecast modelinin temelidir.

Gerçek Kapasite Hesabına Neler Dahil Edilmeli?

Gerçek kapasite planlanırken yalnızca feature geliştirmeye bakmak önemli iş yüklerini görünmez kılar. Yıllık izin, resmi tatil, eğitim, toplantı, production support, incident, code review, mentorluk, işe alım görüşmeleri ve teknik borç çalışmaları aynı ekip zamanını kullanır. Bu faaliyetleri “boş zaman” gibi değerlendirmek hatalıdır. Kurum geçmiş dönemlerden gerçek dağılım çıkarabilir. Böylece planlanan kapasite ile gerçekleşen kapasite arasındaki fark daha az olur.

Yıllık İzin

İzin önceden biliniyorsa sprint planına eklenmelidir. Nominal kapasiteden çıkarılır. Özellikle yaz döneminde önemli fark yaratabilir. Takım bireysel izinleri paylaşmalıdır. Forecast buna göre güncellenir.

Resmî Tatil

Resmî tatil kapasiteyi doğrudan azaltır. Sprint uzunluğu aynı görünse bile çalışma günü azalır. Geçmiş velocity kör biçimde kullanılmamalıdır. Takvim planına tatiller eklenmelidir. Uluslararası ekiplerde ülke farkları da önemlidir.

Eğitim

Eğitim delivery dışı kayıp zaman değildir. Takım yetkinliğine yapılan yatırımdır. Ancak kapasite hesabında gerçek zaman tüketir. Önceden planlanmalıdır. Uzun vadede teknik riskleri azaltabilir.

Toplantılar

Toplantılar toplam kapasitede önemli yer tutabilir. Ceremony, yönetim ve koordinasyon toplantıları ölçülebilir. Gereksiz olanlar azaltılmalıdır. Fakat tüm toplantılar verimsiz değildir. Karar değerine göre değerlendirilmelidir.

Production Support

Production support düzenli kapasite tüketir. Geçmiş haftalardaki talep oranı ölçülebilir. Ayrı support capacity planlanabilir. Feature kapasitesi buna göre azaltılır. Böylece incident geldiğinde sprint tamamen bozulmaz.

Incident

Incident zamanı kesin olarak tahmin edilemez. Ancak tarihsel sıklık ve efor ölçülebilir. Risk buffer buna göre ayrılabilir. Kritik sistemlerde bu pay daha yüksek olabilir. Yüzde yüz feature planı yapılmamalıdır.

Code Review

Code review gerçek development eforudur. Plan dışında görülmemelidir. Büyük pull request'ler review kuyruğu oluşturabilir. WIP sınırı bu sorunu azaltabilir. Definition of Done review'u içermelidir.

Mentorluk

Mentorluk senior kapasitesinin bir bölümünü kullanır. Bu süre uzun vadeli takım yatırımıdır. Görünmez bırakılırsa senior sürekli aşırı planlanır. Gerçek kapasiteye dahil edilmelidir. Takımın öğrenme hızı da böylece desteklenir.

İşe Alım Görüşmeleri

Teknik mülakatlar özellikle büyüyen ekiplerde önemli zaman kullanır. Senior kişiler daha fazla görüşmeye katılabilir. Bu dönemsel yük kapasite planına yansıtılmalıdır. Aksi halde sprint commitment gereksiz yükselir. Forecast sapmasının nedeni yanlış yorumlanabilir.

Operasyonel Talepler

Erişim, veri düzeltme veya iç destek talepleri düzenli zaman tüketebilir. Bu işler ticket sisteminde görünür hale getirilmelidir. Historical demand ölçülebilir. Kapasite payı ayrılabilir. Sürekli büyüyorsa otomasyon yatırımı yapılabilir.

Teknik Borç

Teknik borç için kapasite ayırmak planlı yatırım olmalıdır. Feature estimate içine gizlenmesi doğru değildir. Ayrı backlog veya kapasite yüzdesi kullanılabilir. Risk bazlı öncelik verilebilir. Böylece ürün ve mühendislik dengesi görünür olur.

%100 Kapasite Planlaması Neden Gerçekçi Değildir?

Bir ekibin bütün çalışma zamanını önceden planlı işe ayırmak kağıt üzerinde verimli görünebilir fakat flow açısından risklidir. Plansız iş, incident, hastalık, öğrenme ve bağımlılık beklemeleri kaçınılmazdır. Yüzde yüz doluluk küçük bir gecikmenin bütün planı etkilemesine neden olur. Kuyruk teorisi açısından kapasite kullanım oranı üst sınıra yaklaştıkça bekleme süreleri hızla büyüyebilir. Bu yüzden capacity buffer verimsizlik değil sistem dayanıklılığıdır.

Plansız İş

Her ekipte beklenmeyen talepler oluşur. Bunları yok saymak planı gerçekçi yapmaz. Geçmiş oran ölçülmelidir. Belirli kapasite ayrılabilir. Kullanılmayan buffer teknik borca yönlendirilebilir.

Incident

Production sorunu öncelikleri anında değiştirebilir. Kritik sistemlerde incident yükü daha yüksektir. Tarihsel veri kullanılarak reserve planlanabilir. Feature planı buna göre yapılır. Böylece forecast daha dayanıklı olur.

Context Switching

Aynı anda çok fazla iş üzerinde çalışmak verimi azaltır. İnsan yeniden bağlam kurmak için zaman harcar. WIP yükselir. Cycle time uzar. Daha az işi eşzamanlı başlatmak daha fazla iş bitirmeyi sağlayabilir.

Hastalık ve İzin

Bazı izinler önceden bilinmez. Küçük ekiplerde etkisi büyük olabilir. Planın tamamen dolu olması esnekliği ortadan kaldırır. Capacity buffer bu riski azaltır. Forecast tek kişiye bağımlı olmamalıdır.

Learning Work

Yeni teknoloji ve sistem öğrenme zamanı gerektirir. Bu süreyi sıfır varsaymak gerçekçi değildir. İlk sprintlerde daha geniş kapasite payı ayrılabilir. Öğrenme arttıkça forecast kalibre edilir. Böylece ekip gereksiz baskı altında kalmaz.

Bekleme ve Bağımlılık

İş aktif çalışmaya hazır olsa bile bağımlılık nedeniyle durabilir. Bu sırada kişi başka işe geçer ve WIP yükselir. Program seviyesinde bu sorun büyür. Bağımlılıklar erken görünür olmalıdır. Blocked time metriği izlenmelidir.

Capacity Buffer

Buffer bilinmeyen işlere karşı açık koruma sağlar. Gizli padding'den farklıdır. Geçmiş demand verisine dayanabilir. Yönetim neden ayrıldığını bilir. Kullanımı düzenli olarak gözden geçirilir.

Utilization ile Flow Arasındaki Çelişki

Herkesi yüzde yüz meşgul etmek ile işleri hızlı bitirmek aynı hedef değildir. Sistem yüzde yüz doluluğa yaklaştığında yeni işlerin beklemesi artar ve kuyruklar büyür. Çoklu görev context switching yaratır. WIP yükseldikçe cycle time uzar. Bu nedenle daha az iş başlatıp daha fazla iş bitirmek çoğu yazılım ekibinde daha sağlıklı sonuç verir.

Herkesi %100 Dolu Tutmak

Dolu takvim verimlilik hissi yaratır. Fakat yeni kritik iş için alan bırakmaz. Küçük gecikme tüm sırayı etkiler. İnsanlar çok sayıda işi aynı anda taşır. Flow yavaşlar.

Kuyrukların Büyümesi

Her kaynak tam dolu olduğunda yeni iş bekler. Review ve test kuyrukları oluşabilir. Cycle time artar. Yönetim daha fazla iş başlatarak sorunu büyütebilir. WIP limiti daha etkili olabilir.

Bekleme Süresinin Artması

Aktif efor değişmese bile teslim süresi uzayabilir. Bunun nedeni sıradaki beklemedir. Lead time bu etkiyi gösterir. Yalnızca kişi-saat ölçümü sorunu yakalayamaz. Flow metriği gereklidir.

Multitasking

Multitasking çoğu zaman görev değiştirmedir. Her geçiş zihinsel maliyet yaratır. Hata ihtimali artabilir. İşlerin tamamlanması gecikir. WIP azaltmak odağı güçlendirir.

WIP

Work in Progress aynı anda açık iş sayısını gösterir. Yüksek WIP uzun cycle time ile ilişkilidir. Ekip kapasitesine uygun limit belirlenebilir. Bitirmeden yeni iş başlatma azaltılır. Akış daha görünür hale gelir.

Daha Az İş Başlatıp Daha Fazla İş Bitirmek

Bu yaklaşım ilk bakışta daha az üretim gibi görünebilir. Gerçekte tamamlanmış değer miktarı artabilir. Review ve test kuyrukları azalır. Feedback daha hızlı gelir. Forecast daha stabil hale gelir.

Scope, Time, Cost ve Quality Dengesi

Proje yönetiminde scope, time, cost ve quality aynı anda tamamen sabitlenmek istendiğinde risk hızla artar. Tarih değişmeyecek, bütçe değişmeyecek, kapsam eksilmeyecek ve kalite düşmeyecek denildiğinde bilinmeyenlerin yönetileceği alan kalmaz. Kurumsal planlama bu değişkenlerden hangisinin gerçekten sabit olduğunu açıkça belirlemelidir. Regülasyon projesinde zaman sabitse scope esnek olabilir. Fixed-price projede bütçe sabitse kapsam sınırları ve Change Request mekanizması daha kritik hale gelir.

Fixed Scope

Scope sabitse tüm gereksinimler teslim edilmelidir. Bu durumda tarih veya maliyet için esneklik gerekebilir. Scope change sıkı yönetilir. Acceptance kriterleri açık olmalıdır. Risk gerçekleştiğinde diğer değişkenler etkilenir.

Fixed Time

Tarih sabitse minimum scope düşünülmelidir. Must ve Could ayrımı faydalıdır. Progressive delivery yapılabilir. Risk buffer planlanır. Her şeyin aynı tarihe sığacağı varsayılmaz.

Fixed Cost

Bütçe sabitse kapasite sınırı vardır. Scope veya zaman bu sınıra göre ayarlanmalıdır. Remaining budget sürekli takip edilir. Burn rate görünür olmalıdır. Yeni talepler trade-off gerektirir.

Quality

Kalite genellikle gizli esnek değişken gibi kullanılır. Test veya review kısaltılarak tarih korunmaya çalışılır. Bu yaklaşım gelecekte defect ve incident maliyeti yaratır. Minimum kalite kriterleri Definition of Done içinde korunmalıdır. Kalite borçlanması açık karar olmalıdır.

Dört Boyutu Aynı Anda Sabitlemenin Riski

Belirsizlik yönetilecek alan bulamaz. Ekip gerçekçi olmayan planla çalışır. Risk gerçekleştiğinde gizli kalite düşüşü oluşabilir. Fazla mesai kalıcı çözüme dönüşebilir. Kurum en az bir değişkende esneklik tanımlamalıdır.

Hangi Değişken Esnek Olmalı?

Bu karar projenin iş bağlamına bağlıdır. Regülasyon tarihli projede scope daha esnek olabilir. Yeni ürün geliştirmede scope ve çözüm yaklaşımı değişebilir. Fixed-price sözleşmede Change Request mekanizması gerekir. Karar proje başında açıkça verilmelidir.

Fixed-Date Projelerde Estimation Nasıl Yapılır?

Fixed-Date projede “ne zaman biter?” sorusunun cevabı zaten verilmiştir. Bu durumda estimation'ın amacı tarihi yeniden tahmin etmek değil, hangi kapsamın o tarihe hangi güven seviyesinde sığacağını anlamaktır. Minimum Viable Scope ve Must, Should, Could sınıflandırması burada güçlü araçlardır. Risk buffer ayrılmalı ve mümkünse progressive delivery uygulanmalıdır. Tarihe yaklaştıkça scope burn-up ve throughput verisiyle forecast yenilenmelidir.

Tarih Sabitse Scope Esnekliği

Tarih değişemiyorsa kapsam seçenekleri oluşturulmalıdır. Her feature aynı öneme sahip değildir. Minimum güvenli teslimat belirlenir. Daha düşük öncelikler sonraki release'e bırakılabilir. Bu karar son haftaya ertelenmemelidir.

Must / Should / Could Ayrımı

Must olmazsa olmaz kapsamdır. Should önemli fakat gerektiğinde ertelenebilir. Could ek değer sağlar. Bu sınıflandırma tarih baskısında karar hızını artırır. Product ve teknik ekip birlikte yapmalıdır.

Minimum Viable Scope

Minimum Viable Scope tarihe ulaşmanın güvenli tabanını oluşturur. Gereksiz özellikler çıkarılır. Teknik kalite minimumları korunur. Kullanıcıya çalışan değer teslim edilir. Sonraki özellikler aşamalı eklenebilir.

Risk Buffer

Risk buffer bilinen risklerin etkisi için ayrılır. Gizli padding değildir. Yönetim ne kadar ve neden ayrıldığını bilir. Tarihsel veriye dayanabilir. Kullanım durumu düzenli raporlanır.

Progressive Delivery

Tek büyük release yerine kademeli teslim yapılır. Feature flag kullanılabilir. Kullanıcı grupları aşamalı artırılabilir. Risk erken görünür. Zorunlu tarihe büyük tek paketle gitme ihtiyacı azalır.

Scope Burn-Up

Burn-up tamamlanan ve toplam scope'u birlikte gösterir. Scope büyümesi görünür hale gelir. Yalnızca tamamlanan iş grafiği bu bilgiyi vermez. Forecast değişikliğinin nedeni anlaşılır. Yönetim gerektiğinde scope kararı alabilir.

Tarihe Yaklaştıkça Yeniden Forecast

Her yeni throughput verisi forecast'i güçlendirir. Kalan scope güncellenir. Gerçekleşen riskler hesaba katılır. Güven seviyesi yeniden hesaplanır. Son haftaya kadar eski planı savunmak yerine yeni veri kullanılır.

Fixed-Price Projelerde Estimation

Fixed-Price modelinde estimation yalnızca teknik planlama değil doğrudan ticari risk yönetimidir. Eksik discovery ile düşük fiyat verilen proje, ilerleyen dönemde ekip üzerinde teslim baskısı ve şirket üzerinde maliyet baskısı yaratabilir. Kapsam varsayımları, dahil olanlar, hariç olanlar ve acceptance criteria açık biçimde yazılmalıdır. Risk premium ve contingency reserve hesaplanmalıdır. Scope değişikliği için Change Request sürecinin sözleşmede tanımlanması gerekir.

Discovery Aşaması

Discovery teklif öncesi belirsizliği azaltır. Kritik süreçler anlaşılır. Entegrasyon ve veri ihtiyaçları belirlenir. Büyük riskler erken görünür. Tahmin aralığı daha güvenilir hale gelir.

Kapsam Varsayımları

Her teklif belirli varsayımlara dayanır. API'nin hazır olduğu veya tasarımın müşteri tarafından sağlanacağı varsayılabilir. Bunlar açıkça yazılmalıdır. Varsayım değişirse maliyet etkisi değerlendirilir. Ticari anlaşmazlık riski azalır.

Dahil Olanlar

Teslim edilecek iş net biçimde tanımlanmalıdır. Development kadar test ve deployment kapsamı da açıklanmalıdır. Dokümantasyon varsa belirtilmelidir. Acceptance süreci tanımlanmalıdır. Böylece tarafların beklentisi ortaklaşır.

Hariç Olanlar

Kapsam dışı konular da yazılmalıdır. Aksi halde sessiz beklenti oluşabilir. Veri temizliği veya üçüncü taraf lisans işleri buna örnek olabilir. Sonradan gelen talepler Change Request ile yönetilir. Proje bütçesi korunur.

Risk Premium

Belirsizlik ticari fiyat üzerinde etki yaratır. Yüksek riskli projede daha büyük reserve gerekebilir. Bu pay rastgele eklenmemelidir. Reference class verisi kullanılabilir. Risk azaltıldıkça fiyatlama daha rekabetçi olabilir.

Change Request

Scope değişikliği doğal olabilir. Fixed-price modelinde maliyet etkisi kontrol edilmelidir. Change Request yeni işin kapsamını ve fiyatını açıklar. Eski commitment ile yeni talep ayrılır. İlişki daha şeffaf yürür.

Acceptance Criteria

İşin ne zaman kabul edileceği önceden bilinmelidir. Belirsiz acceptance teslim sonunda tartışma yaratır. Test senaryoları mümkün olduğunca erken tanımlanmalıdır. UAT sorumluluğu belirlenir. Teslimat closure süreci hızlanır.

Contingency Reserve

Contingency bilinen riskler için ayrılır. Proje bütçesinde açıkça yönetilebilir. Kullanılmaması başarısız planlama anlamına gelmez. Risk gerçekleşmediğinde olumlu sonuçtur. Reserve miktarı periyodik gözden geçirilmelidir.

Tahmin Hatasının Ticari Riski

Düşük tahmin marjı doğrudan azaltabilir. Fazla tahmin ise teklifin kaybedilmesine yol açabilir. Bu nedenle reference data değerlidir. Tek uzmanın iyimser görüşüne dayanılmamalıdır. Ticari karar teknik riskle birlikte alınmalıdır.

Satış Ekibi ile Teknik Ekip Arasındaki Estimation Gerilimi

Satış hızlı teklif vermek isterken teknik ekip daha fazla bilgi talep edebilir. Bu iki tarafın da kendi açısından haklı olduğu bir gerilimdir. Sorun, minimum teknik discovery yapılmadan müşteriye kesin tarih verilmesiyle başlar. Pre-Sales Technical Review ve kısa varsayım listesi bu riski önemli ölçüde azaltır. Teklifte confidence level bulunması da teknik belirsizliği ticari konuşmaya taşır.

Müşteriye Hızlı Teklif Verme Baskısı

Pazar fırsatı uzun süre beklemeyebilir. Bu nedenle haftalarca analysis yapmak gerçekçi değildir. Minimum discovery çerçevesi oluşturulabilir. Kritik sorular hızlıca cevaplanır. Yeterli veri yoksa teklif aralık olarak sunulur.

Teknik Bilgi Eksikliği

İlk müşteri görüşmesinde teknik detay sınırlı olabilir. API, veri ve güvenlik koşulları bilinmeyebilir. Bu durum açıkça risk olarak yazılmalıdır. Kesin rakam vermek yerine range kullanılabilir. Discovery sözleşmenin ilk aşaması olabilir.

“Bunu İki Haftada Yaparız” Taahhüdü

Teknik değerlendirme olmadan verilen tarih risklidir. Daha sonra ekip bu tarihe estimate uydurmaya zorlanabilir. Bu durum gerçek tahmini ortadan kaldırır. Satış hedefi Target Date olarak kaydedilmelidir. Teknik forecast daha sonra oluşturulmalıdır.

Pre-Sales Technical Review

Kısa teknik review büyük riskleri erkenden yakalar. Entegrasyon, veri ve security soruları kontrol edilir. Benzer geçmiş proje bulunabilir. Senior teknik temsilci satış sürecine destek verir. Teklif kalitesi yükselir.

Tahmin Öncesi Minimum Discovery

Her proje için minimum soru seti oluşturulabilir. Kullanıcı sayısı, entegrasyonlar, veri migration ve non-functional requirement sorulur. Kritik bilinmeyenler işaretlenir. Gerekirse ücretli discovery önerilir. Tahmin daha güvenilir hale gelir.

Varsayım Listesi

Tahminin hangi koşullarda geçerli olduğu yazılmalıdır. “Müşteri test verisini sağlayacak” gibi maddeler net olmalıdır. Değişiklik halinde forecast güncellenir. Bu liste tartışmayı kişisel olmaktan çıkarır. Herkes aynı şartlara bakar.

Confidence Level

Confidence Level teklifin ne kadar belirsiz olduğunu gösterir. Discovery öncesi düşük olabilir. Teknik detay geldikçe yükselir. Müşteri farklı güven seviyelerinde tarih veya bütçe seçenekleri görebilir. Bu yaklaşım tek sayıdan daha şeffaftır.

Müşteriye Tahmin Nasıl Sunulmalı?

Müşteriye tahmin sunarken teknik detayları tamamen gizlemek veya aşırı teknik anlatımla konuyu ağırlaştırmak doğru değildir. Scope, tarih aralığı, güven seviyesi, temel varsayımlar ve başlıca riskler kısa ve anlaşılır biçimde paylaşılmalıdır. Tek tarih gerekiyorsa bu tarihin hangi güven seviyesinde olduğu belirtilmelidir. Ayrıca forecast'in ne zaman güncelleneceği söylenmelidir. Böylece müşteri tahmini sabit söz değil, kontrollü planlama bilgisi olarak görür.

Tek Tarih Vermek

Bazen ticari süreç tek tarih isteyebilir. Bu durumda tarih seçilen güven seviyesini temsil etmelidir. Varsayımlar ayrıca yazılmalıdır. İçeride daha geniş dağılım saklanmalıdır. Tarih değişirse nedeni açıklanmalıdır.

Tarih Aralığı Vermek

Aralık belirsizliği daha doğru yansıtır. Erken ve geç olası sonuç birlikte görünür. Müşteri planını buna göre yapabilir. Özellikle discovery aşamasında uygundur. Geliştirme ilerledikçe aralık daralabilir.

Güven Seviyesi Vermek

Yüzde 50 tarih ile yüzde 85 tarih farklı risk taşır. Müşteri kritik lansmanda daha yüksek güven isteyebilir. Düşük riskli iç özellikte daha düşük seviye kabul edilebilir. Böylece tarih seçimi risk iştahına bağlanır. Forecast ekonomik karara dönüşür.

Varsayımları Açıklamak

Tahmin her zaman koşullara dayanır. Scope'un değişmemesi veya müşteri onayının belirli sürede verilmesi gerekebilir. Bu maddeler açıkça paylaşılmalıdır. Değişiklik olduğunda forecast'in neden değiştiği anlaşılır. Güven ilişkisi güçlenir.

Scope'u Açıklamak

Tarihin hangi kapsam için geçerli olduğu net olmalıdır. “Proje biter” ifadesi farklı yorumlanabilir. Feature listesi ve acceptance kriterleri paylaşılmalıdır. Opsiyonel özellikler ayrılabilir. Scope büyümesi ayrıca takip edilir.

Riskleri Açıklamak

Müşteriye tüm teknik ayrıntıyı vermek gerekmez. Ancak teslim tarihini etkileyebilecek ana riskler bilinmelidir. Vendor, veri ve approval riski örnek olabilir. Risk azaltma planı da sunulmalıdır. Böylece konuşma yalnızca problem listesi olmaz.

Bir Sonraki Forecast Tarihini Belirtmek

Forecast'in ne zaman güncelleneceğini söylemek beklentiyi yönetir. Discovery sonrası yeni tarih verilebilir. Her sprint sonunda yeniden hesaplama yapılabilir. Müşteri değişikliklerin sürpriz olmadığını görür. İletişim ritmi güçlenir.

“Ne Zaman Biter?” Sorusuna Daha İyi Cevap Nasıl Verilir?

“Ne zaman biter?” sorusuna hemen bir tarih söylemek yerine önce elimizdeki verinin kalitesini değerlendirmek gerekir. Scope ne kadar net, geçmişte benzer işler var mı, throughput nasıl ve hangi güven seviyesi gerekiyor soruları cevabın kalitesini belirler. Eğer tarih zaten sabitse soru “hangi kapsam o tarihe sığar?” olarak değiştirilebilir. Bu yaklaşım tahmin tartışmasını pazarlık olmaktan çıkarır. Yönetim gerçek seçenekler arasında karar verir.

Elimizde Ne Kadar Veri Var?

Yeni takımda geçmiş veri az olabilir. Olgun takımda aylarca cycle time bulunabilir. Tahmin yöntemi buna göre seçilmelidir. Veri yokken yüksek hassasiyet beklenmemelidir. İlk dönem kısa horizon kullanılmalıdır.

Scope Ne Kadar Net?

Belirsiz scope dar tarih üretmeye uygun değildir. Acceptance criteria eksikse önce refinement yapılmalıdır. Büyük iş parçalanabilir. Discovery bilgi üretir. Scope netleştikçe forecast daralır.

Benzer İşlerin Geçmişi Ne?

Reference class güçlü dış görüş sağlar. Benzer işler ne kadar sürdü sorusu iyimserliği azaltır. Tek örnek yerine dağılım kullanılmalıdır. Ekip veya teknoloji farkı not edilmelidir. Sonuç güncel bağlamla kalibre edilir.

Mevcut Throughput Ne?

Throughput gerçek bitirme hızını gösterir. Kalan scope ile birleştirilebilir. Haftalık değişim dağılım olarak ele alınmalıdır. Ortalama tek başına yeterli değildir. Monte Carlo bu veriyi kullanabilir.

Hangi Güven Seviyesi İsteniyor?

Her tarih aynı risk seviyesine sahip değildir. Yüzde 50 daha erken olabilir fakat kaçırma ihtimali yüksektir. Yüzde 85 daha güvenlidir. Kritik sözleşmede yüksek güven seçilebilir. İç hedefte daha düşük seviye yeterli olabilir.

Scope veya Tarih Trade-Off'u

Her iki değişken de aynı anda sabit olmak zorunda değildir. Tarih kritikse scope küçültülebilir. Scope kritikse tarih genişletilebilir. Ek kapasite bazı durumlarda yardımcı olabilir. Karar açıkça yönetim tarafından verilmelidir.

Tek Tarih Yerine Olasılıklı Forecast

Olasılıklı forecast yönetimin daha güçlü risk kararı almasını sağlar. Tek tarih bütün ihtimalleri tek noktada saklar. Yüzde 50, yüzde 70, yüzde 85 ve yüzde 95 güven seviyeleri farklı risk toleranslarına karşılık gelir. Kritik bir regülasyon tarihi için yüzde 95 seviyesine yakın planlama tercih edilebilirken iç ürün denemesinde yüzde 70 kabul edilebilir. Buradaki amaç en geç tarihi seçmek değil, kararın risk maliyetini görünür hale getirmektir.

%50 Güven

Yüzde 50 medyana yakın sonucu temsil eder. Yaklaşık yarı senaryoda tarih aşılabilir. Agresif iç hedefler için kullanılabilir. Commitment olarak dikkatle değerlendirilmelidir. Risk açıkça paylaşılmalıdır.

%70 Güven

Yüzde 70 daha dengeli güven sunar. Çoğu senaryoda tarih korunur. Yine de önemli kaçırma ihtimali vardır. Orta riskli planlarda kullanılabilir. Scope değişimi forecast'i etkiler.

%85 Güven

Yüzde 85 birçok ekip için güçlü planlama seviyesi olabilir. Tarih daha fazla kötü senaryoyu kapsar. Müşteri iletişiminde uygun olabilir. Ancak her iş için standart olmak zorunda değildir. Risk toleransına göre seçilmelidir.

%95 Güven

Yüzde 95 çok düşük tarih kaçırma riski hedefler. Kritik regülasyon veya büyük ticari etkinlikte düşünülebilir. Tarih doğal olarak daha geç olur. Bu fark yönetim tarafından bilinmelidir. Yüksek güvenin maliyeti vardır.

Risk Toleransına Göre Güven Seviyesi

Tek doğru confidence yoktur. Kararın finansal ve operasyonel etkisi değerlendirilmelidir. Küçük iç feature ile yasal zorunluluk aynı riskte değildir. Yönetim risk iştahını açıkça seçmelidir. Forecast bu seçimi destekler.

Kritik Tarihlerde Daha Yüksek Güven

Kritik tarihin kaçırılması büyük maliyet yaratıyorsa daha yüksek güven gerekir. Scope erken azaltılabilir. Buffer korunabilir. Progressive delivery kullanılabilir. Son haftaya kadar risk biriktirilmemelidir.

Probabilistic Forecasting Nedir?

Probabilistic Forecasting tarihsel performansı kullanarak gelecekteki sonuçları olasılık dağılımı halinde gösterir. Tek bir “ortalama hız” yerine geçmişteki gerçek değişkenliği korur. Throughput ve kalan scope en sık kullanılan girdilerdendir. Her yeni tamamlanan iş forecast'in yeniden hesaplanmasına imkan verir. Bu nedenle özellikle olgun ürün ekiplerinde yönetim için güvenilir bir continuous forecasting yaklaşımı oluşturabilir.

Tarihsel Veriden Tahmin

Geçmiş throughput geleceğin tek garantisi değildir. Fakat gerçek çalışma sistemini yansıtır. Benzer koşullar varsa güçlü referanstır. Veri temiz olmalıdır. Takım değişikliği olduğunda yeniden kalibrasyon gerekir.

Tek Sonuç Yerine Dağılım

Dağılım farklı olası tarihleri gösterir. Böylece yalnızca ortalama görülmez. Uç senaryolar da hesaba katılır. Confidence percentile hesaplanabilir. Yönetim risk seviyesini seçebilir.

Throughput

Throughput belirli zaman aralığında tamamlanan iş adedidir. Haftalık ölçüm sık kullanılır. Monte Carlo geçmiş haftalardan örnekleme yapabilir. Kalan scope sıfırlanana kadar senaryo çalıştırılır. Binlerce tekrar dağılım üretir.

Scope

Forecast için kalan iş miktarı bilinmelidir. Scope sürekli büyüyorsa tarih daima hareket eder. Burn-up bu değişimi gösterir. Yeni işler modele eklenmelidir. Scope change raporlanmalıdır.

Olasılık

Sonuç “12 Ekim'de bitecek” şeklinde değildir. “12 Ekim'e kadar bitme ihtimali yüzde 85” gibi ifade edilir. Bu ayrım önemlidir. Olasılık risk konuşmasını mümkün kılar. Yönetim commitment seviyesini bilinçli seçer.

Sürekli Forecast Güncellemesi

Yeni throughput verisi geldikçe dağılım değişir. Scope azalır veya büyür. Risk gerçekleşebilir. Forecast periyodik yeniden hesaplanır. Eski tahmine bağlı kalmak yerine güncel veri kullanılır.

Monte Carlo Simulation Yazılım Teslimatında Nasıl Kullanılır?

Monte Carlo Simulation, geçmiş throughput veya cycle time verisinden tekrar tekrar örnek alarak binlerce olası gelecek senaryosu üretir. Diyelim ki backlog'da 50 iş kaldı ve ekibin son 20 haftalık throughput geçmişi var. Simülasyon bu geçmiş dağılımdan örnekler seçerek 50 işin farklı senaryolarda ne zaman biteceğini hesaplar. Sonuç tek tarih değil, tarihlerin olasılık dağılımıdır. Bu dağılımdan yüzde 50, yüzde 85 veya yüzde 95 confidence percentile seçilebilir.

Geçmiş Throughput Verisi

Veri gerçek çalışma sistemini temsil etmelidir. Sıfır tamamlanan haftalar da önemlidir. Sadece iyi haftaları seçmek sonucu iyimser yapar. Büyük organizasyon değişiklikleri not edilmelidir. Veri dönemi bağlama uygun seçilmelidir.

Kalan İş Sayısı

Scope mümkün olduğunca küçük ve benzer işlere ayrılmalıdır. Çok büyük item'lar dağılımı bozabilir. Kalan iş sayısı güncel tutulur. Yeni scope eklenirse model güncellenir. Burn-up ile birlikte izlenebilir.

Binlerce Olası Gelecek Senaryosu

Her simülasyon geçmiş performanstan farklı örnekler seçer. Bazı senaryolar hızlı, bazıları yavaş ilerler. Binlerce tekrar sonuç dağılımı oluşturur. Böylece doğal varyasyon modele dahil edilir. Tek ortalamadan daha gerçekçi görünüm elde edilir.

Sonuç Dağılımı

Dağılım olası tamamlanma tarihlerini gösterir. Sadece en sık görülen tarih kullanılmamalıdır. Confidence seviyeleri karar için daha faydalıdır. Kuyruğun uzunluğu risk hakkında bilgi verir. Yönetim bunu risk toleransıyla değerlendirebilir.

Confidence Percentile

Percentile belirli tarihe kadar tamamlanma ihtimalini ifade eder. Yüzde 85 seviyesi senaryoların yaklaşık yüzde 85'inin o tarihten önce tamamlandığını gösterir. Kritik kararlar daha yüksek percentile isteyebilir. Erken hedef daha düşük seviyede tutulabilir. Tek sayıdan çok daha zengin bilgi sunar.

“When” Forecast

When forecast belirli scope'un ne zaman tamamlanabileceğini sorar. Kalan item sayısı ve throughput kullanılır. Sonuç tarih dağılımıdır. Roadmap ve release planında faydalıdır. Scope değişirse yeniden hesaplanır.

“How Many” Forecast

How Many forecast belirli tarihe kadar kaç iş tamamlanabileceğini sorar. Fixed-Date projelerde özellikle değerlidir. Tarih sabit olduğunda scope seçenekleri üretir. Minimum ve olası teslim miktarı görülebilir. Product buna göre önceliklendirme yapar.

Monte Carlo Ne Değildir?

Monte Carlo geleceği kesin bilen bir hesaplama değildir. Kötü veri veya sürekli değişen çalışma sistemi kullanıldığında sonuç da zayıf olur. Simülasyonun amacı belirsizliği ortadan kaldırmak değil, mevcut varyasyonu görünür hale getirmektir. Yöneticiye yalnızca “yüzde 85” yazmak da yeterli değildir. Olasılığın hangi scope, varsayım ve iş kararına karşılık geldiği açıklanmalıdır.

Kesin Tarih Makinesi Değildir

Simülasyon olasılık üretir. Gerçek gelecek tek senaryo olacaktır. Yüzde 85 garanti anlamına gelmez. Kalan yüzde 15 risk hâlâ vardır. Yönetim bu riski bilerek karar verir.

Kötü Veriyi Sihirli Biçimde Düzeltmez

Ticket'lar güncellenmiyorsa throughput yanlış olur. Done tanımı tutarsızsa cycle time bozulur. Model bu hataları düzeltemez. Önce data hygiene yapılmalıdır. Simülasyon kaliteli girdiye ihtiyaç duyar.

Değişmeyen Bir Forecast Değildir

Forecast düzenli güncellenmelidir. Scope ve kapasite değişir. Yeni throughput verisi oluşur. Eski dağılım zamanla geçerliliğini kaybedebilir. Continuous forecasting yaklaşımı daha uygundur.

Yöneticiye Sadece Yüzde Göndermek Yeterli Değildir

Yüzdenin bağlamı açıklanmalıdır. Hangi tarih ve scope için hesaplandığı bilinmelidir. Veri dönemi paylaşılabilir. Başlıca riskler ayrıca gösterilir. Aksi halde sayı yeni bir yanlış kesinlik kaynağına dönüşebilir.

Olasılığı İş Kararına Çevirmek Gerekir

Forecast'in amacı karar vermektir. Yüzde 85 tarih geç kalıyorsa scope azaltılabilir. Ek discovery yapılabilir. Risk azaltma çalışması öne alınabilir. Veri eyleme dönüşmediğinde dashboard sayısından öteye gitmez.

Cycle Time ile Forecasting

Cycle time forecasting tek tek işlerin başladıktan sonra ne kadar sürede tamamlandığına bakar. Dağılım üzerinden “işlerin yüzde 85'i sekiz gün içinde tamamlanıyor” gibi Service Level Expectation oluşturulabilir. Bu yaklaşım özellikle küçük ve benzer işlerin aktığı ürün ekiplerinde faydalıdır. Work Started ve Work Done tanımlarının tutarlı olması gerekir. Kuyruk davranışını anlamak için Work Item Age de birlikte izlenebilir.

Work Started

Başlangıç noktası açık tanımlanmalıdır. Ticket'ın sprint'e alınması ile aktif çalışmanın başlaması farklı olabilir. Cycle time gerçek çalışma başlangıcını ölçmelidir. Takım aynı kuralı sürekli kullanır. Veri karşılaştırılabilir hale gelir.

Work Done

Done tanımı gerçek teslimi temsil etmelidir. Sadece development tamamlanması yeterli olmayabilir. Test ve deployment gerekiyorsa dahil edilmelidir. Definition of Done veri kalitesini etkiler. Takımlar arasında farklı olabilir.

Cycle Time Distribution

Dağılım ortalamadan daha fazla bilgi verir. Bazı işler çok hızlı, bazıları çok yavaş olabilir. Percentile değerleri risk seviyesini gösterir. Uç işlerin nedeni ayrıca incelenebilir. Process improvement için değerlidir.

Service Level Expectation

SLE garanti değildir. Geçmiş akışa dayalı beklentidir. Örneğin standart işlerin yüzde 85'inin on gün içinde bitmesi beklenebilir. Yeni iş türlerinde farklı olabilir. Düzenli olarak güncellenmelidir.

“İşlerin %85'i X Gün İçinde Bitiyor” Yaklaşımı

Bu ifade ekip ve stakeholder için anlaşılırdır. Story Point bilgisi gerektirmez. Gerçek cycle time verisine dayanır. Yeni iş başladığında olası süre hakkında referans sağlar. Büyük veya sıra dışı işler ayrı değerlendirilmelidir.

Throughput ile Forecasting

Throughput forecasting belirli zaman aralığında kaç işin tamamlandığına odaklanır. Ortalama throughput basit bir başlangıç olabilir fakat dağılım kullanmak daha güçlüdür. Kalan scope belli olduğunda tarih forecast'i, tarih belli olduğunda kapasite forecast'i yapılabilir. Monte Carlo bu iki soruyu da destekler. İşlerin boyutlarının aşırı farklı olmaması sonucu iyileştirir.

Haftalık Tamamlanan İş Sayısı

Haftalık throughput kolay ölçülür. Tatil ve incident gibi gerçek etkileri içerir. Geçmiş haftaların tamamı dağılım oluşturur. Kötü haftalar silinmemelidir. Gerçek sistem varyasyonu korunmalıdır.

Sprint Başına Tamamlanan İş

Sprint kullanan ekiplerde item count izlenebilir. Point yerine adet üzerinden akış görülebilir. Story'ler benzer boyuttaysa faydalıdır. Büyük item'lar ayrı işaretlenmelidir. Trend zaman içinde değerlendirilir.

Ortalama Yerine Dağılım

Ortalama haftalık beş iş gerçek oynaklığı gizleyebilir. Bazı haftalar iki, bazı haftalar dokuz olabilir. Forecast bu varyasyonu içermelidir. Dağılım risk aralığı üretir. Olasılıklı sonuç daha gerçekçidir.

Kapasite Forecast

Sabit tarihe kadar kaç iş bitebilir sorusu cevaplanabilir. Product scope seçiminde kullanılır. Confidence seviyesine göre farklı adetler görülebilir. Must scope güvenli seviyeye göre seçilir. Could işler daha düşük güven bandında kalabilir.

Tarih Forecast

Kalan scope sabitse ne zaman biteceği hesaplanabilir. Throughput dağılımı kullanılabilir. Scope değiştikçe tarih de değişir. Tek tarih yerine confidence percentile sunulur. Yönetim risk seviyesini seçer.

Story Counting Ne Zaman Story Point'ten Daha Basit Olabilir?

Takım story'leri küçük ve benzer boyutta tutmayı başarabiliyorsa her iş için point üretmek gereksiz hale gelebilir. Bu durumda yalnızca tamamlanan story sayısı güçlü throughput verisi sağlayabilir. Estimation toplantılarının süresi azalır. Ancak story boyutları zaman içinde büyürse counting yanıltıcı hale gelir. Bu nedenle küçük batch size ve düzenli item-size kontrolü önemlidir.

Benzer Büyüklükte Story'ler

Counting'in çalışması için item'lar aşırı heterojen olmamalıdır. Büyük story'ler bölünmelidir. Reference size kullanılabilir. Takım zamanla ortak boyut alışkanlığı geliştirir. Throughput daha istikrarlı hale gelir.

Küçük Batch Size

Küçük batch hızlı feedback sağlar. Cycle time düşer. Risk daha erken görülür. Forecast için daha fazla veri noktası oluşur. Büyük epic'ler doğrudan sayıma dahil edilmemelidir.

Throughput Geçmişi

Yeterli geçmiş veri counting'i güçlendirir. Haftalık tamamlanan item sayısı ölçülür. Dağılım forecast'e girdi olur. Takım değişirse yeniden kalibrasyon yapılır. Veri kalitesi korunmalıdır.

Point Toplantısını Azaltmak

Her story için kart oynamak gerekmeyebilir. Benzer işlerde doğrudan counting yapılabilir. Sadece sıra dışı item tartışılır. Refinement yine devam eder. Ortak anlayış estimate'ten bağımsız korunmalıdır.

Story Size Kontrolünü Kaybetmemek

Counting büyük item'ları görünmez yapmamalıdır. Takım maksimum story boyutu belirleyebilir. Cycle time outlier'ları incelenebilir. Çok büyük işler parçalanır. Böylece throughput anlamını korur.

#NoEstimates Nedir?

#NoEstimates yaklaşımı çoğu zaman yanlış biçimde “hiç plan yapmayalım” şeklinde yorumlanır. Asıl fikir, her task için ayrı tahmin üretmenin karar değerini sorgulamaktır. Küçük iş parçaları, throughput, cycle time ve sık feedback kullanılarak planlama yapılabilir. Olgun ve stabil ekiplerde bu yaklaşım ciddi ceremony maliyetini azaltabilir. Ancak tarihsel verisi olmayan veya büyük fixed-price risk taşıyan projelerde doğrudan uygulanması uygun olmayabilir.

“Hiç Planlama Yapmayalım” mı Demektir?

Hayır. Planlama devam eder. Sadece ayrıntılı estimate miktarı azaltılır. Gerçek akış verisi kullanılır. Scope düzenli önceliklendirilir.

Küçük İş Parçaları

Küçük item'lar tahmin ihtiyacını azaltır. Benzer boyutlar counting'i mümkün kılar. Feedback daha hızlı gelir. Büyük hata erken görülür. Forecast tarihsel akıştan yapılabilir.

Throughput

Tamamlanan iş sayısı delivery hızını gösterir. Düzenli ölçüm forecast'i destekler. Point gerektirmez. Tarih veya scope sorusuna cevap üretilebilir. Değişkenlik dağılım olarak ele alınmalıdır.

Cycle Time

Tek işin ne kadar sürede bittiğini gösterir. SLE oluşturulabilir. Work Item Age ile açık işler izlenir. Sürekli flow ortamında güçlü metriktir. Point hedefinden bağımsızdır.

Sık Feedback

Küçük teslimatlar kullanıcı geri bildirimi getirir. Yanlış scope erken fark edilir. Büyük plan değişikliği riski azalır. Öncelik düzenli güncellenir. Tahmine ihtiyaç duyulan ufuk kısalır.

Değer Odaklı Öncelik

Backlog sırası yalnızca efora göre belirlenmez. Business value ve risk reduction önemlidir. Küçük iş her zaman daha iyi değildir. Büyük ama yüksek değerli yatırım seçilebilir. Estimation kararın girdilerinden sadece biridir.

Task-Level Estimation'ı Azaltmak

Task saati her ekip için gerekli değildir. Küçük ve rutin işlerde maliyet yaratabilir. Team-level flow verisi yeterli olabilir. Kritik veya sıra dışı iş ayrı ele alınır. Böylece estimation ceremony küçülür.

#NoEstimates Hangi Kurumlarda İşe Yarayabilir?

#NoEstimates en iyi, takımın stabil olduğu, işlerin küçük tutulduğu ve güçlü tarihsel veri bulunduğu ortamlarda çalışır. Sürekli delivery yapan olgun ürün ekipleri bu profile daha yakındır. Scope esnek olduğunda ekip kısa geri bildirim döngüleriyle ilerleyebilir. Throughput ve cycle time düzenli tutuluyorsa ayrıntılı point toplantısına olan ihtiyaç azalır. Burada amaç estimate'i yasaklamak değil, karar değeri olmayan estimate'i azaltmaktır.

Olgun Ürün Takımları

Olgun ekip sistemi iyi tanır. Tarihsel veri güçlüdür. Benzer iş türleri tekrar eder. Forecast akış verisinden yapılabilir. Ceremony azaltılabilir.

Stabil Takımlar

Takım üyeleri sık değişmiyorsa geçmiş performans daha anlamlıdır. Throughput dağılımı korunur. Yeni kişi etkisi sınırlıdır. Forecast kalibrasyonu daha kolaydır. Takım davranışı öngörülebilir hale gelir.

Küçük ve Benzer İşler

Heterojen olmayan item'lar counting için uygundur. Büyük epic'ler parçalanır. Cycle time daha stabil olur. Monte Carlo daha anlamlı çalışır. Point ihtiyacı azalabilir.

Sürekli Delivery

Sık release gerçek feedback üretir. Büyük batch riski azalır. Flow metrikleri sürekli güncellenir. Forecast kısa aralıklarla yenilenir. Ağır planlama törenine daha az ihtiyaç olur.

Güçlü Tarihsel Veri

Veri olmadan #NoEstimates yalnızca tahmin yapmamak olur. Throughput ve cycle time düzenli tutulmalıdır. Veri temizliği önemlidir. Outlier'lar anlaşılmalıdır. Forecast gerçek geçmişe dayanır.

Esnek Scope

Scope'un düzenli önceliklendirilmesi yaklaşımı destekler. Tarih yaklaştığında düşük değerli işler çıkarılabilir. Product sürekli karar verir. Büyük commitment baskısı azalır. Outcome odaklı planlama güçlenir.

#NoEstimates Hangi Durumlarda Risklidir?

Yeni takım, büyük bağımlılıklar, fixed-price sözleşme, regülasyon deadline'ı ve yüksek teknoloji belirsizliği olduğunda #NoEstimates dikkatli uygulanmalıdır. Bu ortamlarda iş kararları için ayrı risk analizi ve tahmin gerekir. Tarihsel veri eksikse yalnızca throughput kullanmak mümkün değildir. Çok büyük ve heterojen işler counting modelini bozar. Önce işi küçültmek, discovery yapmak ve uygun range estimate oluşturmak daha güvenlidir.

Yeni Takım

Yeni takımın geçmiş verisi yoktur. İlk forecast belirsizdir. Reference story ve Planning Poker kullanılabilir. Kısa horizon planlanır. Birkaç sprint sonra gerçek veri oluşur.

Çok Büyük Bağımlılıklar

Başka ekip ve vendor etkisi yüksekse yalnızca kendi throughput'unuz yeterli olmaz. Waiting time ayrıca modellenmelidir. Program seviyesi dependency görünümü gerekir. Risk analizi yapılmalıdır. Scope seçenekleri hazırlanabilir.

Fixed-Price Sözleşme

Ticari fiyat için efor ve risk bilgisi gerekir. Yalnızca “akışa bakarız” demek yeterli değildir. Discovery ve range estimate gereklidir. Contingency hesaplanmalıdır. Change Request mekanizması kurulmalıdır.

Regülasyon Deadline'ı

Zorunlu tarih ciddi risk taşır. Minimum scope belirlenmelidir. Confidence seviyesi yüksek tutulmalıdır. Probabilistic forecast kullanılabilir. Sürekli risk takibi yapılır.

Yeni Teknoloji

Tarihsel ekip verisi yeni teknoloji için tam geçerli olmayabilir. Öğrenme eğrisi vardır. Spike ve PoC yapılmalıdır. İlk tahmin geniş tutulur. Gerçek data geldikçe kalibrasyon yapılır.

Çok Büyük ve Heterojen İşler

Counting farklı büyüklükleri aynı kabul eder. Bu durumda throughput yanıltıcı olabilir. Epic'ler parçalanmalıdır. Kaba sizing yapılabilir. Sonra küçük item flow'una geçilir.

Tarihsel Veri Eksikliği

Geçmiş veri olmadan olasılıklı forecast zayıftır. İlk dönem expert judgment kullanılabilir. Benzer takım veya proje reference class olabilir. Kısa horizon seçilir. Veri biriktikçe model değiştirilir.

Estimation Toplantılarının Maliyeti Nasıl Ölçülür?

Estimation ücretsiz değildir. Katılımcı sayısı, toplantı süresi ve aylık tekrar sayısı doğrudan delivery kapasitesinden tüketilir. Ayrıca hiç yapılmayacak backlog maddelerinin tekrar tekrar tahmin edilmesi görünmeyen bakım maliyeti oluşturur. Basit bir hesapla toplantıdaki kişi sayısını süreyle çarparak kişi-saat maliyeti bulunabilir. Bu maliyet, toplantının değiştirdiği kararın değeriyle karşılaştırılmalıdır.

Katılımcı Sayısı

Her katılımcının zamanı maliyettir. On kişilik toplantı kısa görünse bile toplam saat büyüyebilir. Gerekli roller seçilmelidir. Her story için tüm organizasyonun katılması gerekmez. Temsil dengesi korunmalıdır.

Toplantı Süresi

Toplantı süresi düzenli ölçülebilir. Gereksiz uzayan konular belirlenebilir. Timebox kullanılabilir. Büyük belirsizlik ayrı spike'a dönüştürülebilir. Böylece refinement daha odaklı olur.

Aylık Toplam Saat

Haftalık küçük toplantılar ay sonunda büyük maliyet oluşturabilir. Toplam kişi-saat raporlanabilir. Ceremony cost görünür hale gelir. Yönetim bu zamanı gerçek yatırım olarak görür. Gerekirse yöntem değiştirilebilir.

Yeniden Tahmin Edilen İşler

Sürekli re-estimate edilen backlog estimation debt işareti olabilir. İşler fazla erken tahminlenmiş olabilir. Re-estimate rate ölçülebilir. Uzak backlog için daha kaba yöntem kullanılabilir. Yakın zamanda yapılacak işler detaylandırılır.

Hiç Yapılmayan Backlog Maddeleri

Bazı item'lar aylarca backlog'da kalır ve sonunda silinir. Bunlara harcanan estimation zamanı boşa gitmiştir. Uzak backlog'u detaylandırmamak bu maliyeti azaltır. T-Shirt Sizing yeterli olabilir. Rolling-wave planning daha ekonomiktir.

Estimation Cost vs Decision Value

Her estimate sonunda hangi karar değişecek diye sorulmalıdır. Karar değişmeyecekse ayrıntılı tahmin gereksiz olabilir. Kritik teklif daha fazla analiz hak eder. Küçük bakım işi hızlıca geçilebilir. Hassasiyet karar değerine göre seçilmelidir.

Estimation Debt Nedir?

Estimation Debt, çok erken tahminlenen veya sürekli güncellenmesi gereken işlerin oluşturduğu bakım yüküdür. Backlog altı ay önceden ayrıntılı point'lenirse scope değiştikçe tahminler eski hale gelir. Ekip daha sonra bunları yeniden değerlendirir. Bu tekrar gerçek delivery kapasitesini tüketir. Just-in-Time Estimation, yakın dönem işlerini detaylandırıp uzak işleri kaba bırakmayı hedefler.

Çok Erken Tahmin Edilen Backlog

Uzak işlerin bilgi seviyesi düşüktür. Detaylı estimate hızla eskiyebilir. Kaba sizing daha uygundur. Yakın dönemde refinement yapılır. Böylece ilk tahmin emeği boşa gitmez.

Sürekli Yeniden Tahmin

Re-estimate oranı yüksekse süreç sorgulanmalıdır. Scope sürekli değişiyor olabilir. Tahmin fazla erken verilmiş olabilir. Sadece karar değişecekse yeniden tahmin yapılmalıdır. Toplantı maliyeti azaltılabilir.

Güncelliğini Kaybetmiş Estimate

Eski estimate yanlış güven yaratır. Takım veya teknoloji değişmiş olabilir. Scope büyümüş olabilir. Estimate age dashboard'da gösterilebilir. Kritik karar öncesi güncellik kontrol edilmelidir.

Kullanılmayan Tahmin Verileri

Bir sayı üretip bir daha kullanmamak değer yaratmaz. Estimate hangi karar veya forecast için kullanıldı bilinmelidir. Kullanım yoksa ceremony azaltılabilir. Veri toplamak amaç değildir. Karar desteklemek amaçtır.

Tahmin Bakım Maliyeti

Her değişiklik yeni estimation gerektiriyorsa maliyet büyür. Uzak backlog için bu maliyet daha yüksektir. Range veya T-Shirt bakım yükünü azaltır. Yakın işler detaylı tutulur. Seviye bazlı politika oluşturulmalıdır.

Just-in-Time Estimation

İş yapılmaya yaklaştıkça daha fazla bilgi vardır. Bu nedenle ayrıntılı estimate doğru zamanda yapılır. Uzak iş kaba boyutta kalır. Refinement sürekli ama hafif ilerler. Estimation debt azalır.

Backlog'un Ne Kadarı Tahminlenmeli?

Backlog'un tamamını aynı hassasiyetle tahminlemek çoğu ekip için verimsizdir. Yakın dönem daha ayrıntılı, orta dönem kaba ve uzak dönem yalnızca range veya T-Shirt seviyesinde değerlendirilebilir. Bu model hiç yapılmayabilecek işler üzerinde uzun toplantılar yapılmasını önler. Rolling-wave planning yeni bilgi geldikçe ayrıntıyı artırır. Böylece estimation yatırımı gerçekten karar verilecek alanlara yönelir.

Yakın Dönem: Daha Detaylı

Yakın sprintlerde yapılacak işler iyi anlaşılmalıdır. Acceptance criteria net olmalıdır. Planning Poker kullanılabilir. Bağımlılıklar kontrol edilir. Sprint kapasitesiyle karşılaştırılır.

Orta Dönem: Kaba

Çeyrek içindeki işler daha fazla değişebilir. Epic range veya T-Shirt yeterlidir. Büyük riskler işaretlenir. Discovery ihtiyacı belirlenir. Yaklaştıkça detaylandırılır.

Uzak Dönem: T-Shirt / Range

Uzak roadmap yüksek belirsizlik taşır. Saat tahmini uygun değildir. XS, S, M, L, XL veya geniş aralık kullanılabilir. Yatırım yönü için yeterli bilgi sunar. Gereksiz estimate bakımını önler.

Hiç Yapılmayabilecek İşleri Detaylandırmamak

Backlog'daki her fikir teslim edilmeyecektir. Bazıları önceliğini kaybeder. Ayrıntılı tahmin bu işlerde boşa gider. Kaba sınıflandırma yeterlidir. Değer yükselirse daha sonra detaylandırılır.

Rolling-Wave Planning

Plan zaman içinde ayrıntılanır. Yakın dönem net, uzak dönem esnek kalır. Yeni bilgi plana dahil edilir. Forecast sürekli güncellenir. Bu yaklaşım belirsizliği doğal biçimde yönetir.

Büyük İşler Neden Kötü Tahmin Edilir?

Büyük iş daha fazla bilinmeyen, bağımlılık, entegrasyon ve test alanı içerir. Bir epic içinde onlarca farklı teknik problem bulunabilir. Bunların bazıları ancak geliştirme başladıktan sonra ortaya çıkar. Blast Radius büyüdükçe hata ve rework ihtimali de yükselir. Bu nedenle büyük işlerin tahmin aralığı doğal olarak daha geniş olmalıdır.

Daha Fazla Bilinmeyen

İş büyüdükçe bilgi eksikleri artar. Her alt parça aynı anda net olmayabilir. Tek point sayısı bu farkı saklar. Epic bölünmelidir. Discovery önceliklendirilmelidir.

Daha Fazla Bağımlılık

Büyük scope daha fazla takım veya servisle temas eder. Her dependency yeni waiting time oluşturabilir. Program seviyesinde risk artar. Bağımlılık haritası çıkarılmalıdır. Kritik yol görünür olmalıdır.

Daha Fazla Entegrasyon

Entegrasyon sayısı arttıkça koordinasyon ihtiyacı büyür. Veri formatı ve erişim problemleri oluşabilir. Test ortamı daha zor hazırlanır. Pessimistic senaryo genişler. Büyük paketler küçük teslimatlara ayrılmalıdır.

Daha Fazla Test

Etki alanı genişledikçe regresyon kapsamı büyür. Otomasyon yetersizse süre daha çok artar. QA eforu başlangıçta planlanmalıdır. Test son hafta eklenen iş değildir. Definition of Done içinde yer almalıdır.

Daha Büyük Blast Radius

Merkezi sistem değişikliği birçok kullanıcıyı etkileyebilir. Rollback planı gerekir. Release riski yükselir. Progressive delivery değerli hale gelir. Küçük batch risk alanını azaltır.

Daha Geniş Tahmin Aralığı

Büyük iş için dar tahmin sahte güven yaratır. Range geniş tutulmalıdır. Discovery ilerledikçe daraltılır. Confidence level paylaşılır. Yönetim bu belirsizliği plan kararına dahil eder.

Büyük İşleri Küçültmek Tahmin Kalitesini Nasıl Artırır?

Büyük işi küçük, bağımsız ve değer üreten parçalara ayırmak yalnızca Agile pratik değildir, aynı zamanda estimation kalitesini artırır. Küçük işte daha az bilinmeyen bulunur. Cycle time kısalır ve daha hızlı feedback alınır. Bağımsız deploy edilebilir parçalar riskin daha erken ortaya çıkmasını sağlar. Ayrıca throughput verisi daha fazla ve daha düzenli hale gelir.

Epic'ten Story'ye

Epic iş hedefini geniş ölçekte ifade eder. Doğrudan sprint içine alınmamalıdır. Kullanıcı değeri taşıyan story'lere ayrılır. Her story daha kolay anlaşılır. Forecast daha güçlü hale gelir.

Vertical Slicing

Vertical slice kullanıcıya uçtan uca küçük değer sunar. Sadece frontend veya backend parçası değildir. Gerçek akışı test eder. Teknik risk erken görünür. Feedback daha hızlı alınır.

Minimum Valuable Increment

En küçük değerli artış belirlenir. Gereksiz scope sonraya bırakılır. Kullanıcı sonucu daha erken görür. Tahmin ufku kısalır. Product öğrenmeye göre sonraki adımı seçer.

Bağımsız Deploy Edilebilir Parçalar

Bağımsız parça release riskini azaltır. Büyük koordinasyon ihtiyacı düşer. Rollback daha kolay olur. Cycle time kısalır. Forecast için daha düzenli veri oluşur.

Daha Hızlı Feedback

Küçük teslimat erken kullanıcı geri bildirimi getirir. Yanlış gereksinim hızlı fark edilir. Büyük rework önlenir. Scope öğrenmeye göre değişebilir. Tahmine ihtiyaç duyulan uzaklık azalır.

Daha Kısa Cycle Time

Küçük iş daha hızlı akabilir. Kuyrukta daha az süre kalır. Outlier sayısı azalabilir. SLE daha anlamlı olur. Throughput forecasting güçlenir.

User Story Splitting Teknikleri

User Story Splitting tahmin kalitesini iyileştiren en pratik yöntemlerden biridir. Story'ler workflow adımına, business rule'a, veri türüne, happy path ve edge case ayrımına veya operasyon tipine göre küçültülebilir. Amaç teknik katmanlara bölmek değil mümkün olduğunca kullanıcıya değer sunan küçük parçalar oluşturmaktır. Bilinmeyen teknik alan ayrıca spike olarak ayrılabilir. Böylece ürün işi ile öğrenme işi birbirine karışmaz.

Workflow Adımlarına Göre

Uzun süreç farklı kullanıcı adımlarına ayrılabilir. Her adım bağımsız değer taşıyabilir. Önce temel akış teslim edilir. Sonraki adımlar eklenir. Tahmin daha küçük parçalar üzerinden yapılır.

Business Rule'a Göre

Birden fazla iş kuralı tek story'de toplanmayabilir. Önce en temel kural uygulanabilir. İstisnalar sonraya bırakılır. Acceptance criteria sadeleşir. Test kapsamı küçülür.

Happy Path / Edge Case

Önce temel başarılı senaryo geliştirilebilir. Edge case'ler ayrı story olur. Bu yaklaşım erken değer sağlar. Riskli istisnalar ayrı tahmin edilir. Product öncelik verebilir.

Veri Türüne Göre

Farklı veri tipleri ayrı akış gerektirebilir. Önce en yaygın veri türü seçilir. Diğerleri sonraki story'lere ayrılır. Test daha kontrollü olur. Entegrasyon riski küçülür.

Operasyona Göre

Create, update, delete gibi operasyonlar ayrılabilir. Hepsini tek story'ye toplamak gerekmez. Öncelik en değerli operasyona verilir. Feedback daha erken gelir. Story boyutu düşer.

Önce Basit Sonra Gelişmiş

İlk sürüm temel çözümü sunabilir. Otomasyon veya optimizasyon sonra eklenir. Kullanıcı değeri erken doğrulanır. Gereksiz geliştirme önlenebilir. Tahmin daha kolay hale gelir.

Spike ile Belirsizlik Ayırma

Bilinmeyen teknik konu feature story'nin içine saklanmamalıdır. Ayrı spike açılabilir. Timebox ile araştırma yapılır. Sonuç karar ve bilgi üretir. Feature estimate daha sonra güncellenir.

Definition of Ready Estimation'ı Nasıl Etkiler?

Definition of Ready, bir işin tahmin ve geliştirme için yeterli bilgiye sahip olup olmadığını anlamaya yardımcı olur. Çok katı kullanılırsa gereksiz bürokrasi yaratabilir, fakat temel amaç, tamamen belirsiz işleri sprint içine sokmaktan kaçınmaktır. Amaç, acceptance criteria, dependency, tasarım ve veri ihtiyacı yeterince anlaşılmış olmalıdır. Her ayrıntının önceden çözülmesi gerekmez. Tahmin için gerekli minimum bilgi seviyesi takım tarafından açıkça tanımlanabilir.

Amaç

Story'nin neden yapıldığı bilinmelidir. İş değeri anlaşılmadan teknik çözüm tartışması eksik kalır. Product amacı açıklar. Ekip alternatif çözüm önerebilir. Gereksiz scope azaltılabilir.

Acceptance Criteria

Kabul kriterleri işin sınırını gösterir. Eksik kriter farklı tahminlere neden olur. Ana senaryolar açık olmalıdır. Edge case'ler belirtilmelidir. Sonradan scope sürprizi azalır.

Bağımlılıklar

Başka takım veya API ihtiyacı önceden bilinmelidir. Blocker riski değerlendirilir. Waiting time ayrıca planlanabilir. Dependency owner belirlenir. Sprint içine alınmadan önce kritik erişimler doğrulanabilir.

Tasarım

Her story için tam tasarım gerekmez. Ancak kullanıcı akışını değiştiren işlerde temel ekran veya süreç anlaşılmalıdır. Tasarım belirsizliği point'i gereksiz büyütebilir. Gerekirse önce design task tamamlanır. Sonra development estimate yapılır.

Veri İhtiyacı

Verinin nereden geleceği bilinmelidir. Migration veya yeni schema ihtiyacı önemli efor yaratabilir. Privacy ve security etkisi olabilir. Test verisi gereksinimi planlanır. Bu bilgi estimate kalitesini artırır.

Belirsizlik

Tüm belirsizlik sıfırlanamaz. Ancak kritik bilinmeyenler görünür olmalıdır. Çok yüksek belirsizlik spike'a dönüştürülebilir. Takım neyi bilmediğini açıkça ifade etmelidir. Bu davranış desteklenmelidir.

Tahmin İçin Minimum Bilgi

Takım ortak minimum kriter belirleyebilir. Amaç, acceptance ve temel dependency bu kriterde olabilir. Fazla ayrıntı istemek flow'u yavaşlatır. Çok az bilgi ise rework üretir. Denge ekip deneyimiyle bulunur.

Definition of Done Efor Tahmininin Parçası Olmalı mı?

Evet. Efor yalnızca development tamamlanana kadar hesaplanırsa gerçek teslim maliyeti eksik görünür. Code review, test, security, documentation, deployment ve monitoring işin gerçekten Done olmasının parçaları olabilir. Takım estimate verirken kendi Definition of Done kapsamını dikkate almalıdır. Aksi halde development bittikten sonra haftalar süren görünmeyen kuyruk oluşabilir.

Development

Kodlama toplam işin yalnızca bir bölümüdür. Analiz ve tasarım da development içinde değerlendirilebilir. Teknik implementasyon tamamlanması ara adımdır. Test ve release hâlâ kalabilir. Done tanımı bunu açıkça belirtir.

Code Review

Review kalite kapısıdır. Pull request yazıldıktan sonra bekleme oluşabilir. Büyük PR review süresini artırır. Efor planına dahil edilmelidir. Kuyruk ayrıca flow metriğinde izlenir.

Test

Test manuel ve otomatik çalışma içerebilir. Regression kapsamı feature büyüklüğünü aşabilir. QA estimation sürecine katılmalıdır. Test verisi hazırlanması unutulmamalıdır. Done test tamamlanmasını içermelidir.

Security

Güvenlik bazı işlerde ayrıca review gerektirir. Threat model veya penetration test planlanabilir. Geç onay teslimatı geciktirir. Security gereksinimleri erken belirlenmelidir. Efor estimate'e dahil edilmelidir.

Documentation

Dokümantasyon özellikle API ve operasyonel sistemlerde önemlidir. Son güne bırakıldığında eksik kalır. Kullanıcı veya runbook dokümanı gerekebilir. Definition of Done kapsamına alınabilir. Efor normal iş olarak planlanmalıdır.

Deployment

Deployment otomatik değilse önemli süre yaratabilir. Change approval veya bakım penceresi gerekebilir. Migration planı ayrıca hazırlanır. Rollback adımı test edilir. Release eforu tahminden ayrı tutulmamalıdır.

Monitoring

Production'a çıkmak tek başına başarı değildir. Log, metric ve alarm hazırlanmalıdır. Yeni feature davranışı gözlemlenebilir olmalıdır. Monitoring incident riskini azaltır. Eforu başlangıçtan planlanmalıdır.

İşin Gerçekten “Done” Olmasına Kadar Olan Efor

Müşteri açısından iş ancak kullanılabilir olduğunda tamamlanır. Development done ile release done aynı olmayabilir. Tüm akış estimate ve forecast içinde görünmelidir. Waiting time ayrıca ayrılabilir. Gerçek teslim resmi böyle oluşur.

Sadece Development Eforu Tahminlemenin Riski

Kurumsal projelerde “geliştirme üç gün” ifadesi kolayca “üç günde biter” şeklinde anlaşılabilir. Oysa QA, DevOps, security review, UAT, dokümantasyon, release ve production validation sonradan günler veya haftalar ekleyebilir. Development estimate doğru olsa bile delivery forecast yanlış çıkar. Bu nedenle effort breakdown rol ve süreç bazında görünür olmalıdır. Takvim forecast'i tüm teslim akışını kapsamalıdır.

QA'nın Unutulması

Test süresi sonradan eklenirse plan gecikir. QA kapasitesi sınırlı olabilir. Regression kapsamı genişleyebilir. Test estimate'e dahil edilmelidir. Sprint planında QA WIP'i izlenmelidir.

DevOps'un Unutulması

Deployment hazırlığı teknik işin parçasıdır. Pipeline değişikliği gerekebilir. Environment ve secret yönetimi süre yaratabilir. DevOps kapasitesi önceden kontrol edilmelidir. Release son anda planlanmamalıdır.

Security Review

Güvenlik onayı zorunlu olabilir. Takvimde süre ayrılmalıdır. Kritik bulgu rework gerektirebilir. Erken review riski azaltır. Security yalnızca final kontrol olmamalıdır.

UAT

User Acceptance Test iş birimi kapasitesine bağlıdır. Teknik ekip işi bitirse bile kullanıcı onayı beklenebilir. Bu waiting time forecast'e dahil edilmelidir. UAT senaryoları erken hazırlanmalıdır. Sorumlu kişiler belirlenmelidir.

Dokümantasyon

Dokümantasyon çoğu zaman release öncesi unutulur. API ve operasyon dokümanı teslim için gerekli olabilir. Son dakika işi haline geldiğinde kalite düşer. Planlı efor ayrılmalıdır. Done kriterinde açıkça belirtilmelidir.

Release

Release penceresi veya Change Board onayı gerekebilir. Teknik efor küçük olsa bile takvim beklemesi büyür. Bu süre effort ile karıştırılmamalıdır. Delivery forecast'e eklenmelidir. Süreç verisi düzenli ölçülmelidir.

Production Validation

Deploy sonrası doğrulama gerçek kullanıcı akışını kontrol eder. Metric ve log izlenir. Gerekirse rollback yapılır. Bu çalışma release planının parçasıdır. “Deploy edildi” ifadesi otomatik olarak tamamlandı anlamına gelmez.

Bağımlılıklar Estimation'a Nasıl Dahil Edilir?

Bağımlılık doğrudan eforu artırabileceği gibi hiçbir aktif çalışma gerektirmeden takvim süresini uzatabilir. Başka takım, vendor, API, veri, onay veya environment bağımlılığı ayrı kaydedilmelidir. Effort ile waiting time ayrıldığında sorunun gerçek kaynağı daha net görünür. Dependency risk için olasılık ve etki değerlendirilebilir. Program forecast'i yalnızca her takımın kendi estimate toplamından üretilmemelidir.

Başka Takım

Başka takımın roadmap'i sizin kontrolünüzde değildir. Teslim tarihi erkenden doğrulanmalıdır. Interface contract oluşturulabilir. Blocked time ölçülmelidir. Kritik dependency program seviyesinde yönetilir.

Vendor

Tedarikçi SLA ve sözleşmesi süreyi etkiler. Geri dönüş zamanları geçmiş veriden incelenebilir. Alternatif plan hazırlanabilir. Vendor işi internal efor gibi varsayılmamalıdır. Risk reserve gerekebilir.

API

API hazır görünse bile davranış farkları çıkabilir. Dokümantasyon ve test ortamı kontrol edilmelidir. Rate limit veya güvenlik gereksinimi olabilir. Spike faydalı olabilir. Entegrasyon estimate'i range olarak tutulabilir.

Veri

Veri kalitesi tahminleri ciddi etkileyebilir. Migration sırasında beklenmeyen temizlik gerekebilir. Veri sahibi ekipten destek gerekebilir. Örnek veri erken incelenmelidir. Risk forecast'e dahil edilmelidir.

Onay

Architecture, security veya business approval bekleme yaratabilir. Bu süre development eforu değildir. Lead time içinde ayrı ölçülmelidir. Onay SLA'sı tanımlanabilir. Sürekli gecikiyorsa süreç iyileştirilmelidir.

Environment

Test veya production environment hazırlığı zaman alabilir. Erişim izinleri gecikebilir. Infrastructure kapasitesi sorun olabilir. Environment readiness erken kontrol edilmelidir. Son hafta beklemek risklidir.

Dependency Risk

Her bağımlılık aynı riskte değildir. Kritik yol üzerindeki dependency daha önemlidir. Olasılık ve etki birlikte değerlendirilir. Mitigation planı oluşturulur. Forecast confidence bu bilgiyle güncellenir.

Effort ile Waiting Time'ın Ayrılması

İki saatlik iş bir hafta bekleyebilir. Bu durumda effort iki saat olarak kalır. Duration ise bir haftadan uzun olabilir. Ayrım yapılmazsa geliştirici “yavaş” görünür. Flow analizi gerçek problemi gösterir.

Teknik Borç Efor Tahminlerini Nasıl Bozar?

Teknik borç aynı görünen iki feature'ın tamamen farklı sürede bitmesine neden olabilir. Eski kod, test eksikliği, dokümantasyon problemi ve eski dependency'ler küçük değişikliği geniş risk alanına dönüştürür. Tarihsel estimate'ler sistem değiştikçe geçerliliğini kaybedebilir. Bu nedenle teknik borç yalnızca mühendislik konusu değil forecast kalitesi konusudur. Kurum teknik borcu ayrı backlog ve risk görünümüyle yönetmelidir.

Gizli Karmaşıklık

Kod dışarıdan basit görünebilir. İç bağımlılıklar değişikliği zorlaştırabilir. Senior geliştirici bu riski daha erken fark edebilir. Spike yapılabilir. Tahmin geniş aralıkla verilebilir.

Legacy Kod

Legacy modül test ve dokümantasyon eksikliği taşıyabilir. Değişiklik yan etkisi öngörülemez olabilir. Refactoring ihtiyacı doğabilir. Benzer modern feature referans alınmamalıdır. Ayrı reference class kullanılmalıdır.

Test Eksikliği

Otomatik test yoksa manuel regresyon artar. Geliştirici değişiklik yaparken daha temkinli ilerler. Defect riski yükselir. Test altyapısı yatırımı uzun vadede cycle time'ı iyileştirebilir. Efor planında bu gerçeklik görünmelidir.

Dokümantasyon Eksikliği

Sistem davranışını anlamak daha fazla araştırma gerektirir. Yeni geliştirici için öğrenme süresi uzar. Eski kararlar tekrar tartışılır. Estimation confidence düşer. Teknik dokümantasyon yatırım değeri taşır.

Eski Dependency

Güncel olmayan kütüphane değişikliği engelleyebilir. Güvenlik gereği upgrade yapılması gerekebilir. Feature işi bir anda migration işine dönüşür. Dependency sağlığı düzenli izlenmelidir. Büyük sürprizler azalır.

Historical Estimate'lerin Geçerliliğini Kaybetmesi

Sistem yapısı değiştiğinde geçmiş kıyas geçersiz olabilir. Takım yeni platforma geçmiş olabilir. Eski cycle time doğrudan kullanılmamalıdır. Veri dönemi seçilirken bu kırılmalar dikkate alınır. Forecast yeniden kalibre edilir.

Yeni Teknoloji Tahminlerini Nasıl Etkiler?

Yeni teknoloji tahmini zorlaştırır çünkü ekip yalnızca feature geliştirmez, aynı zamanda öğrenir. Framework olgunluğu, dokümantasyon kalitesi, ekosistem ve topluluk desteği süre üzerinde etkili olabilir. İlk işlerde geçmiş velocity doğrudan kullanılamaz. Spike ve Proof of Concept belirsizliği azaltmak için güçlü araçlardır. İlk gerçek teslimatlardan sonra tahmin modeli yeniden kalibre edilmelidir.

Öğrenme Eğrisi

Yeni araçla ilk işler daha uzun sürebilir. Dokümantasyon okumak gerçek efordur. Ekip deneyim kazandıkça süre düşer. İlk sprint verisi uzun dönem ortalaması değildir. Forecast dönemsel güncellenmelidir.

Framework Olgunluğu

Yeni framework hızlı geliştirme vaat edebilir. Ancak tooling eksik olabilir. Breaking change riski bulunabilir. Enterprise gereksinimleri tam desteklenmeyebilir. Teknik seçim öncesi PoC yapılmalıdır.

Topluluk Desteği

Aktif topluluk problem çözmeyi hızlandırabilir. Nadir teknoloji için bilgi bulmak zor olabilir. Kütüphane sayısı sınırlı olabilir. Bu durum efora yansır. Teknoloji seçimi yalnızca syntax üzerinden yapılmamalıdır.

Dokümantasyon

Kaliteli dokümantasyon öğrenme süresini azaltır. Eksik doküman deneme yanılmayı artırır. Kritik entegrasyonlar önceden test edilmelidir. PoC bilgi kalitesini yükseltir. Tahmin confidence artabilir.

Ekosistem

Hazır kütüphane ve araçlar development hızını etkiler. Güvenlik ve observability entegrasyonları önemlidir. Eksik ekosistem daha fazla custom geliştirme gerektirir. Bu maliyet estimate'e yansıtılmalıdır. Uzun vadeli bakım da değerlendirilmelidir.

Spike

Spike kısa araştırma çalışmasıdır. Belirli teknik soruya cevap vermelidir. Süresi timebox edilir. Sonunda karar veya bilgi üretilir. Feature estimate bu bilgiyle güncellenir.

Proof of Concept

PoC teknik uygulanabilirliği test eder. Tam production çözümü değildir. Kritik riskleri erken ortaya çıkarır. Büyük yatırım öncesi değerlidir. Başarılı veya başarısız sonuç forecast'i etkiler.

“En İyi Programlama Dili” Tahmin İçin Ne İfade Eder?

Tahmin açısından tek bir “en iyi programlama dili” yoktur. Ekibin bildiği teknoloji çoğu zaman daha yüksek prediction confidence sağlar. Yeni dil veya framework ise learning curve ve ekosistem riski taşır. Bununla birlikte mevcut teknoloji iş gereksinimini karşılamıyorsa yalnızca tanıdık olduğu için seçilmemelidir. Dil seçimi önce teknik ve ürün kararı olarak değerlendirilip estimation etkisi daha sonra hesaplanmalıdır.

Tek Bir En İyi Dil Yoktur

Her dil farklı problem alanında avantaj sunar. Takım deneyimi önemlidir. Ekosistem ve operasyonel ihtiyaçlar değerlendirilir. Performans gereksinimi farklı seçim gerektirebilir. Tahmin tek başına dil seçmemelidir.

Ekibin Bildiği Teknolojinin Tahmin Avantajı

Bilinen sistemde reference data daha güçlüdür. Hidden risk sayısı daha düşüktür. Debug ve deployment deneyimi vardır. Forecast aralığı daralabilir. Bu gerçek iş planında avantajdır.

Yeni Dilin Learning Curve Riski

Yeni dilde ilk işler daha yavaş olabilir. Kod standardı henüz oluşmamıştır. Review daha uzun sürebilir. Eğitim zamanı kapasiteden tüketir. İlk dönem tahmin aralığı geniş tutulmalıdır.

Kütüphane ve Ekosistem Riski

İhtiyaç duyulan kütüphane olmayabilir. Güvenlik veya lisans sorunu çıkabilir. Custom geliştirme gerekebilir. PoC bu riski test eder. Estimate teknik seçimden sonra güncellenir.

Dil Seçimini Estimation'dan Önce Teknik Karar Olarak Ele Almak

En ucuz tahmin edilen teknoloji her zaman doğru seçim değildir. Uzun vadeli bakım ve işe alım düşünülmelidir. Operasyon ve security etkisi değerlendirilmelidir. Teknik karar kayda alınır. Sonra delivery forecast buna göre hazırlanır.

Takım Değişikliği Tahmin Verisini Nasıl Etkiler?

Forecast geçmiş takım davranışına dayanıyorsa takım değişikliği önemli bir kırılma noktasıdır. Yeni developer'ın katılması, senior kişinin ayrılması, ekip birleşmesi veya outsource kaynak kullanılması velocity ve throughput geçmişinin anlamını değiştirebilir. Bu durumda eski veri tamamen çöpe atılmaz, fakat yeni koşullarla kalibre edilir. Kısa süreli geniş confidence aralığı kullanılabilir. Yeni takım birkaç sprint çalıştıktan sonra model güncellenir.

Yeni Developer

Yeni kişi ilk dönemde öğrenme zamanı kullanır. Senior kişiler mentorluk yapar. Kısa vadeli kapasite artışı beklenenden düşük olabilir. Zamanla takım kapasitesi yükselir. Forecast bu geçişi dikkate almalıdır.

Senior Ayrılması

Senior kişinin sistem bilgisi kaybolabilir. Hidden dependency bilgisi azalır. Review ve mimari kapasite etkilenir. Eski velocity hemen geçerli kabul edilmemelidir. Risk seviyesi geçici olarak yükselir.

Takım Birleşmesi

İki takımın point ölçeği farklı olabilir. Velocity toplamı anlamsız hale gelir. Yeni çalışma sistemi oluşturulmalıdır. Flow verisi yeniden kalibre edilir. Ortak Definition of Done tanımlanır.

Outsource Kaynak

Yeni outsource ekip domain bilgisini öğrenir. İletişim ve erişim süreci zaman alabilir. Sözleşme modeli davranışı etkiler. İlk forecast geniş tutulmalıdır. Reference data bağlama göre seçilmelidir.

Tarihsel Velocity'nin Geçerliliği

Velocity stabil takım varsayar. Büyük ekip değişimi bu varsayımı bozar. Eski veri sadece kaba referans olabilir. Yeni sprint sonuçları daha fazla ağırlık alır. Gerekirse throughput modeline geçilebilir.

Forecast Verisini Yeniden Kalibre Etmek

Değişiklik sonrası kısa gözlem dönemi kullanılabilir. Yeni cycle time ve throughput toplanır. Confidence aralığı geçici olarak genişletilir. Birkaç dönem sonra dağılım güncellenir. Yönetim değişimin etkisini açıkça görür.

Yeni Takımlar Nasıl Tahmin Yapmalı?

Yeni takımın en önemli dezavantajı tarihsel verinin olmamasıdır. Bu durumda kesin sayı üretmeye çalışmak yerine kısa forecast horizon ve hızlı kalibrasyon yaklaşımı daha sağlıklıdır. T-Shirt Sizing, Reference Stories, Planning Poker ve Three-Point Estimate başlangıçta birlikte kullanılabilir. İlk sprintler veri toplama dönemi olarak görülmelidir. Ekip gerçek cycle time ve throughput oluştukça estimation modelini güncellemelidir.

Tarihsel Veri Eksikliği

Yeni takım kendi geçmişine sahip değildir. Başka takım verisi dikkatli kullanılabilir. Domain ve teknoloji farkı not edilmelidir. Forecast geniş aralıkla sunulur. İlk veriler geldikçe güncellenir.

T-Shirt Sizing

Kaba boyutlandırma başlangıçta kolaydır. Aşırı hassasiyet baskısını azaltır. Büyük işler erken görünür. Reference sınıflar oluşur. Daha sonra point veya counting'e geçilebilir.

Reference Stories

Birkaç örnek story ortak ölçek oluşturur. Küçük, orta ve büyük örnek seçilebilir. Yeni işler bunlarla karşılaştırılır. Takım dili ortaklaşır. Planning Poker hızlanır.

Planning Poker

Yeni ekipte ortak anlayış özellikle değerlidir. Farklı deneyimler ortaya çıkar. Domain bilgisi paylaşılır. Junior ve senior aynı tartışmaya katılır. Birkaç sprint sonra ceremony sadeleşebilir.

Three-Point Estimate

Büyük ve belirsiz işlerde üç senaryo faydalıdır. Yeni takım optimism bias yaşayabilir. Pessimistic senaryo riskleri konuşturur. Range yönetim için daha gerçekçi olur. Gerçek sonuçlarla kalibrasyon yapılır.

Kısa Forecast Horizon

Uzak geleceğe kesin plan vermek yerine yakın dönem değerlendirilir. Birkaç sprintlik horizon daha güvenlidir. Yeni bilgi hızlı kullanılır. Roadmap daha kaba kalır. Confidence zamanla yükselir.

İlk Sprintlerden Sonra Kalibrasyon

Gerçek velocity, throughput ve cycle time oluşur. İlk tahminlerle karşılaştırılır. Sistematik bias aranır. Reference story güncellenir. Forecast artık kendi takım verisine dayanır.

Olgun Takımlar Nasıl Tahmin Yapmalı?

Olgun takım aynı ürün ve çalışma sistemi üzerinde yeterli tarihsel veriye sahiptir. Bu durumda her story için uzun estimation ceremony yapmak yerine Historical Cycle Time, Throughput, Story Counting ve Probabilistic Forecasting daha fazla değer üretebilir. Point tamamen kaldırılmak zorunda değildir, fakat karar değeri düşükse azaltılabilir. Continuous Forecasting yönetimin düzenli güncel bilgi almasını sağlar. Ekip sayıya değil akış ve outcome'a daha fazla odaklanabilir.

Historical Cycle Time

Olgun ekip yeterli item geçmişine sahiptir. Percentile değerleri güvenilir hale gelir. SLE oluşturulabilir. Work Item Age ile riskli açık işler izlenir. Forecast gerçek akışa dayanır.

Throughput

Haftalık tamamlanan item dağılımı güçlü sinyal sağlar. Monte Carlo kullanılabilir. Kalan scope tahmin edilir. Tatil ve incident varyasyonu doğal olarak veride bulunur. Model düzenli güncellenir.

Story Counting

İşler küçük ve benzerse counting yeterli olabilir. Point toplantısı azalır. Refinement ortak anlayış için devam eder. Büyük item'lar ayrılır. Throughput daha basit hale gelir.

Probabilistic Forecasting

Yeterli veri olasılıklı forecast'i güçlendirir. Tek tarih yerine confidence sunulur. Yönetim farklı risk seviyeleri görür. Scope değişikliği modele dahil edilir. Forecast canlı bilgi haline gelir.

Daha Az Estimation Ceremony

Olgunluk daha fazla toplantı demek değildir. Rutin işler hızlı sınıflandırılabilir. Zaman riskli ve değerli konulara ayrılır. Estimation cost düşer. Delivery kapasitesi artar.

Daha Fazla Continuous Forecasting

Forecast yeni verilerle otomatik veya düzenli güncellenebilir. Yönetim eski roadmap rakamına bağlı kalmaz. Scope trendi görünür olur. Risk erken anlaşılır. Karar döngüsü hızlanır.

Tahminlerde Bilişsel Önyargılar

Estimation yalnızca matematik problemi değildir, aynı zamanda insan karar problemidir. Planning Fallacy, Anchoring, Optimism Bias, Confirmation Bias, Authority Bias, Groupthink ve Recency Bias tahminleri etkileyebilir. Bu etkiler tamamen ortadan kaldırılamaz ancak süreç tasarımıyla azaltılabilir. Gizli oy, bağımsız expert estimate, tarihsel veri ve blameless retrospective bu konuda faydalıdır. En önemlisi, ekip üyelerinin farklı görüş söyleyebilmesini sağlayan güvenli ortamdır.

Planning Fallacy

İnsanlar plan yaparken işleri olduğundan kolay görebilir. Geçmiş gecikmeler yeterince dikkate alınmaz. Reference Class Forecasting bunu dengeler. Benzer işlerin gerçek süresi incelenir. Plan yalnızca ideal senaryoya dayanmaz.

Anchoring

İlk sayı sonraki düşünceyi etkiler. Yönetici önce “iki hafta” derse ekip bu değerin çevresinde kalabilir. Gizli oy kullanılmalıdır. İlk estimate bağımsız verilmelidir. Daha sonra tartışma yapılır.

Optimism Bias

İnsanlar olumlu sonucu fazla bekleyebilir. Risklerin gerçekleşme ihtimali düşük görülür. Pessimistic senaryo faydalıdır. Geçmiş sapmalar incelenir. Buffer veriye göre planlanır.

Confirmation Bias

İnsanlar mevcut görüşlerini destekleyen bilgiyi seçebilir. Erken verilen tarihe uygun veri aranabilir. Bağımsız review bu riski azaltır. Ters senaryo soruları sorulabilir. “Bu plan neden başarısız olur?” yararlı bir sorudur.

Authority Bias

Hiyerarşik kişinin görüşü fazla ağırlık kazanabilir. Developer farklı düşündüğü halde susabilir. Yönetici estimate'i önce söylememelidir. Teknik ekip bağımsız değerlendirme yapmalıdır. Sonra iş hedefiyle karşılaştırılmalıdır.

Groupthink

Ekip hızlı uzlaşmayı doğruluk sanabilir. Farklı görüşler bastırılabilir. Gizli oy bağımsız düşünmeyi teşvik eder. En uç tahminler özellikle dinlenir. “Bilmiyorum” kabul edilebilir cevap olmalıdır.

Recency Bias

Son sprintin sonucu gereğinden fazla etkili olabilir. Çok iyi veya kötü tek dönem tüm planı değiştirmemelidir. Daha geniş tarihsel pencere kullanılmalıdır. Büyük sistem değişiklikleri ayrıca not edilir. Trend dağılımla değerlendirilir.

Anchoring Nasıl Önlenir?

Anchoring etkisini azaltmanın en basit yolu ilk sayının özellikle yönetici tarafından söylenmesini önlemektir. Planning Poker'da gizli oy ve eşzamanlı açıklama bu nedenle önemlidir. Büyük tekliflerde birden fazla uzman birbirinden bağımsız estimate verebilir. Sonra farkların nedeni tartışılır. Tarihsel veri kişisel görüşü dengeleyen ek referans sağlar.

İlk Tahmini Yöneticinin Söylememesi

Yönetici tarih hedefini paylaşabilir. Ancak bunu technical estimate gibi söylememelidir. Ekip önce bağımsız değerlendirme yapar. Daha sonra hedefle fark analiz edilir. Scope seçenekleri konuşulur.

Gizli Oy

Katılımcılar başkasının rakamını görmez. Junior kişi özgürce farklı sayı verebilir. İlk anchor etkisi azalır. Oylar aynı anda açılır. Fark bilgi sinyali olarak kullanılır.

Eşzamanlı Açıklama

Herkes kartını aynı anda gösterir. Böylece son anda uyum davranışı azalır. Yüksek ve düşük görüş tartışılır. Ortak anlayış geliştirilir. Sonra yeni oylama yapılabilir.

Bağımsız Expert Estimates

Büyük proje için uzmanlar ayrı değerlendirme yapabilir. İlk aşamada birbirlerinin rakamını görmezler. Sonra varsayımlar karşılaştırılır. Farklı riskler açığa çıkar. Sonuç daha dengeli olur.

Tarihsel Veriye Bakma

Geçmiş gerçek süre güçlü anchor olabilir. Kişisel iyimserliği dengeler. Ancak benzerlik kontrol edilmelidir. Eski teknoloji verisi doğrudan kullanılmamalıdır. Reference class doğru seçilmelidir.

Yönetici Estimation Toplantısında Olmalı mı?

Yöneticinin toplantıda bulunması otomatik olarak yanlış değildir. Gereksinim ve organizasyon bilgisi sağlayabilir. Ancak hiyerarşik baskı nedeniyle teknik ekibin bağımsız tahmin vermesini engelliyorsa süreç zarar görür. Yönetici ilk rakamı söylememeli ve tahmin sonucunu pazarlıkla düşürmeye çalışmamalıdır. Bazı kurumlarda teknik estimate ayrı oturumda hazırlanıp yönetim beklentisi sonradan karşılaştırılabilir.

Bilgi Sağlamak

Yönetici iş hedefi ve deadline bilgisini paylaşabilir. Organizasyonel dependency konusunda katkı verir. Bütçe sınırını açıklayabilir. Bu bilgi tahmin için değerlidir. Ancak teknik büyüklüğü belirlememelidir.

Kararı Etkilemek

Yönetici sonuç üzerinde doğal etkiye sahiptir. Bu etki estimate aşamasında minimum tutulmalıdır. Teknik ekip kendi görüşünü üretir. Daha sonra trade-off kararı yönetimle verilir. Roller ayrılır.

Hiyerarşik Baskı

Junior kişi yöneticinin beklediği rakama yaklaşabilir. Bu gerçek tahmini bozar. Gizli oy bile bazı ortamlarda yeterli olmayabilir. Psychological safety önemlidir. Gerekirse yönetici estimation kısmına katılmaz.

Developer'ların Güvenli Tahmin Yapabilmesi

Ekip “bilmiyorum” diyebilmelidir. Yüksek estimate cezalandırılmamalıdır. Risk söylemek negatif davranış olarak görülmemelidir. Farklı görüş teşvik edilmelidir. Güvenli ortam daha gerçekçi veri üretir.

Yönetici Beklentisinin Sonradan Tartışılması

Teknik estimate üretildikten sonra iş hedefiyle karşılaştırılır. Fark varsa scope veya kapasite seçenekleri konuşulur. Estimate rakamı pazarlıkla değiştirilmez. Yönetim commitment kararını ayrı verir. Böylece terminoloji korunur.

Product Owner Eforu Belirlemeli mi?

Product Owner iş değerini, scope'u ve önceliği belirlemede merkezi role sahiptir. Teknik efor ise geliştiricilerin değerlendirmesidir. Product Owner eforu doğrudan belirlerse teknik risklerin görünmesi zorlaşır. Buna karşılık geliştiriciler de business value kararını tek başına vermemelidir. Sağlıklı refinement iki tarafın bilgi alanını birleştirir.

Product Owner'ın Sorumluluğu

Product Owner kullanıcı ihtiyacını açıklar. Acceptance kriterlerini netleştirir. İş değerini ve önceliği belirler. Scope trade-off kararı verir. Teknik tahmini dikte etmez.

Value ve Priority

Değer ile efor farklı boyutlardır. Büyük iş yüksek değer taşıyabilir. Küçük iş düşük değerli olabilir. Product ekonomik önceliği belirler. Teknik ekip efor ve risk bilgisini sağlar.

Developers'ın Teknik Değerlendirmesi

Geliştiriciler architecture ve integration riskini değerlendirir. Implementation seçeneklerini görür. Test etkisini QA ile birlikte konuşur. Efor estimate'i bu bilgiyle oluşur. Product çözüm üzerindeki trade-off'u anlayabilir.

Scope Trade-Off

Tahmin yüksek çıktığında sayı düşürülmez. Önce kapsamın hangi bölümünün değişebileceği tartışılır. Daha basit çözüm seçilebilir. Could özellik ertelenebilir. Estimate gerçek kapsamı temsil etmeye devam eder.

Ortak Refinement

Product ve engineering aynı story üzerinde çalışır. İş amacı ile teknik gerçeklik birleşir. Eksik requirement erken görünür. Büyük işler parçalanır. Ortak anlayış daha güçlü estimate üretir.

Yönetim İstediği Tarihi Önceden Belirlemişse Estimation Ne İşe Yarar?

Tarih önceden belirlenmişse yapılan çalışma artık klasik “ne zaman biter?” estimate'i değildir. Daha çok feasibility analizi haline gelir. Ekip mevcut kapasiteyle hangi minimum scope'un tarihe sığabileceğini, başlıca riskleri ve bağımlılıkları değerlendirir. Bu yaklaşım teknik ekibi tarihi doğrulamaya zorlamak yerine karar seçenekleri üretir. “Bu tarihe ne sığar?” sorusu çok daha verimlidir.

Estimate Değil Feasibility Analizi

Hedef tarih girdi olarak kabul edilir. Ekip kapasite ve scope'u değerlendirir. Başarı olasılığı hesaplanır. Yetişmeyen kapsam belirlenir. Yönetim seçenekler arasında karar verir.

Scope Options

Must, Should ve Could paketleri hazırlanabilir. Her paket için confidence hesaplanır. Tarihe en güvenli kombinasyon görülür. Product öncelik verir. Scope kararı erken yapılır.

Risk Analizi

Kritik dependency ve teknik bilinmeyenler listelenir. Her riskin etkisi değerlendirilir. Mitigation planı oluşturulur. Tarih sabit olduğu için risk burn-down önemlidir. Yüksek risk erken ele alınır.

Kapasite Analizi

Takımın gerçek kapasitesi hesaplanır. İzin, support ve incident yükü çıkarılır. Kritik uzmanlıklar belirlenir. Sadece kişi sayısı artırmanın faydası sorgulanır. Forecast gerçek kapasiteye dayanır.

Minimum Scope

Başarılı sayılmak için gereken minimum çıktı belirlenir. Bu kapsam teknik kaliteyi yok saymamalıdır. Gereksiz özellikler ertelenir. Progressive delivery planlanır. Deadline riski azalır.

“Bu Tarihe Ne Sığar?” Sorusuna Geçiş

Soru değiştiğinde tartışma daha yapıcı olur. Ekip estimate'i küçültmeye zorlanmaz. Product scope seçer. Yönetim risk seviyesini görür. Commitment gerçek verilere dayanır.

Tahmin Yönetim Tarafından Aşağı Çekilirse Ne Olur?

“On gün çok, beş gün olsun” yaklaşımı estimate'i değiştirmez, yalnızca rapordaki sayıyı değiştirir. Teknik gerçeklik aynı kalır. Sağlıklı pazarlık estimate üzerinde değil scope, tarih, kapasite veya risk üzerinde yapılmalıdır. İstenen tarihin technical estimate olarak sisteme yazılması kurumsal veriyi bozar. Daha sonra estimation accuracy analizi de anlamsız hale gelir.

Estimate Negotiation vs Scope Negotiation

Estimate teknik değerlendirmedir. Scope ise iş kararıdır. Yüksek tahminde kapsam azaltılabilir. Alternatif çözüm bulunabilir. Sayıyı doğrudan küçültmek problemi çözmez.

“10 Gün Çok, 5 Gün Olsun” Problemi

Bu ifade hedefi estimate ile karıştırır. Beş gün Target Date olabilir. Teknik ekip beş güne hangi scope'un sığacağını söyleyebilir. Risk açıklanır. Böylece rakam zorla değiştirilmez.

Teknik Tahmini Pazarlık Konusu Yapmamak

Estimate değişebilir ama yeni bilgi nedeniyle değişmelidir. Yönetim isteği yeni teknik bilgi değildir. Pazarlık scope veya bütçe üzerinde yapılır. Bu ayrım güven yaratır. Ekip sayı saklamaya ihtiyaç duymaz.

Scope ve Risk Üzerinden Pazarlık

Daha erken tarih için daha küçük scope seçilebilir. Riskli özellik sonraya bırakılabilir. Ek test otomasyonu yatırım olarak eklenebilir. Progressive delivery uygulanabilir. Karar gerçek seçenekler üzerinden yapılır.

İstenen Tarihin Estimate Olarak Yazılmasını Önlemek

Tool içinde ayrı Target Date alanı olmalıdır. Technical Estimate farklı tutulur. Forecast üçüncü alan olabilir. Bu ayrım raporlama hatasını azaltır. Sonradan retrospective daha güvenilir olur.

Padding ve Buffer Arasındaki Fark

Gizli padding ile açık risk buffer aynı şey değildir. Padding, ekip üyelerinin baskıdan korunmak için tahmine fark ettirmeden ekstra süre eklemesidir. Buffer ise belirli risk ve tarihsel değişkenlik için görünür biçimde ayrılan koruma alanıdır. Gizli padding güven problemini büyütür çünkü kimse gerçek estimate'i bilmez. Açık buffer ise yönetimin riski bilinçli olarak yönetmesini sağlar.

Gizli Padding

Ekip geçmişte tahmin nedeniyle cezalandırıldıysa kendini koruyabilir. Gerçek estimate'in üzerine fark ettirmeden süre ekler. Yönetim de bunu bildiğini düşünerek tahmini düşürür. Karşılıklı güven bozulur. Sistem giderek anlamsızlaşır.

Açık Risk Buffer

Buffer hangi risk için ayrıldığıyla birlikte gösterilir. Tarihsel incident oranına dayanabilir. Yönetim miktarı görebilir. Risk gerçekleşmezse buffer kullanılmayabilir. Bu şeffaflık planlama güvenini artırır.

Management Reserve

Management Reserve proje seviyesindeki bilinmeyenler için ayrılabilir. Her story'nin içine dağıtılmaz. Yönetim belirli koşullarda kullanır. Kullanım kayıt altına alınır. Portföy seviyesinde de uygulanabilir.

Contingency

Contingency bilinen risklere karşı hazırlıktır. Risk register ile ilişkilendirilebilir. Olasılık ve etkiye göre hesaplanır. Project budget içinde görünürdür. Risk azaldıkça reserve yeniden değerlendirilebilir.

Gizli Koruma Süresinin Güven Problemi Yaratması

Yönetim gerçek estimate'i göremez. Ekip yönetimin sayıyı düşüreceğini varsayar. Her iki taraf da rakam üzerinde oyun oynar. Veri geçmişi işe yaramaz hale gelir. Açık risk modeli bu döngüyü kırar.

Riski Şeffaf Biçimde Modellemenin Avantajı

Riskin adı, olasılığı ve etkisi görünür olur. Mitigation yatırımı değerlendirilebilir. Management hangi riski kabul ettiğini bilir. Forecast değişikliği açıklanabilir. Kurumsal öğrenme güçlenir.

Tahmin Hatası Nasıl Ölçülmeli?

Estimated vs Actual analizi yalnızca “tuttu” veya “tutmadı” olarak yapılmamalıdır. Absolute Error, Percentage Error ve Bias farklı sinyaller verir. Ekip sürekli düşük tahmin yapıyorsa sistematik underestimation olabilir. Sürekli yüksek tahmin de overestimation göstergesidir. Aralık tahminlerinde gerçek sonucun verilen range içinde kalma oranı daha anlamlı olabilir.

Estimated vs Actual

İlk estimate ve gerçekleşen değer birlikte tutulur. Scope değişimi ayrıca kaydedilir. Aksi halde kıyas yanlış olur. Amaç kişiyi değerlendirmek değildir. Reference data oluşturmaktır.

Absolute Error

Absolute Error tahmin ile gerçekleşen arasındaki mutlak farktır. Yön bilgisini göstermez. Büyük ve küçük işlerde farklı yorumlanmalıdır. Basit hata görünümü sağlar. Diğer metriklerle birlikte kullanılmalıdır.

Percentage Error

Yüzde hata farklı büyüklükteki işleri karşılaştırmayı kolaylaştırır. Çok küçük işlerde aşırı değer üretebilir. Scope değişimi dikkate alınmalıdır. Tek KPI yapılmamalıdır. Trend analizi için destekleyici olabilir.

Bias

Bias hatanın yönünü gösterir. Tahminler sürekli düşük mü yüksek mi incelenir. Sistematik desen kalibrasyon ihtiyacına işaret eder. Belirli iş türlerinde ayrı analiz yapılabilir. Takım cezalandırılmamalıdır.

Sistematik Underestimation

Sürekli düşük tahmin belirli risklerin unutulduğunu gösterebilir. Test veya dependency eforu eksik olabilir. Definition of Done gözden geçirilir. Reference stories güncellenir. Estimation policy iyileştirilir.

Sistematik Overestimation

Sürekli yüksek tahmin fazla koruma davranışına işaret edebilir. Yönetim baskısı nedeniyle padding oluşmuş olabilir. Scope küçülmüş olabilir. Neden retrospective ile incelenir. Tahmini düşürme hedefi verilmez.

Aralık Tahminlerinin Başarı Oranı

Yüzde 85 forecast gerçek sonuçların yaklaşık yüzde 85'ini kapsamalıdır. Sürekli yüzde 99 başarı varsa aralık fazla geniş olabilir. Çok düşük başarı varsa model iyimserdir. Calibration chart kullanılabilir. Forecast güven seviyesi gerçek veriye göre ayarlanır.

“Estimate Accuracy” Doğru KPI mı?

Estimate Accuracy tek başına KPI olduğunda ekiplerin davranışını bozabilir. İnsanlar tahmini tutturmak için scope'u değiştirebilir veya fazla padding ekleyebilir. Riskli yeniliklerden kaçınabilir. Yeni bilgi nedeniyle plan değiştirmek cezalandırıldığı için öğrenme yavaşlar. Daha sağlıklı yaklaşım Forecast Reliability, confidence hit rate ve flow metriklerini birlikte kullanmaktır.

Tahmini Tutturmak İçin Davranışı Değiştirme

Metric hedef olduğunda davranış metric'e uyarlanır. Ekip daha kolay işleri seçebilir. Zor işi parçalama yerine erteleyebilir. Tahmin yükseltilerek güvenlik sağlanabilir. Gerçek performans görünmez hale gelir.

Scope Manipülasyonu

Tahmini tutturmak için kabul kriterleri sonradan daraltılabilir. Bu durumda tarih korunur fakat değer düşer. Scope change açıkça izlenmelidir. Burn-up kullanılabilir. Success yalnızca tarihle ölçülmemelidir.

Gereksiz Padding

Accuracy ödüllendirilirse insanlar yüksek tahmin vermeyi tercih edebilir. Böylece hedef kolay tutturulur. Sistem güvenilir görünür fakat kapasite kötü kullanılır. Buffer açık olmalıdır. Gizli padding teşvik edilmemelidir.

Risk Almaktan Kaçınma

Yenilikçi işler daha belirsizdir. Accuracy KPI'sı ekipleri yalnızca tanıdık işlere yönlendirebilir. Ar-Ge cezalandırılmış olur. Risk profiline göre farklı hedefler gerekir. Learning work ayrı değerlendirilmelidir.

Öğrenmeyi Cezalandırma

Yeni bilgi planı değiştirebilir. Eski tahmini korumak yanlış karara yol açabilir. Ekip forecast'i güncellediğinde başarısız sayılmamalıdır. Öğrenme beklenen davranıştır. Yönetim güncel veriyi ödüllendirmelidir.

Forecast Reliability'ye Geçiş

Reliability verilen confidence ile gerçekleşen sonuç arasındaki kalibrasyona bakar. Aralıkların ne kadar tutarlı olduğu ölçülür. Scope change ayrıca raporlanır. Cycle time ve throughput trendi destekleyici olur. Tek doğruluk oranı yerine sistem güvenilirliği değerlendirilir.

Estimation Retrospective Nasıl Yapılır?

Estimation Retrospective'in amacı yanlış tahmin yapan kişiyi bulmak değildir. “Neyi bilmiyorduk?”, “hangi bağımlılığı göremedik?” ve “scope değişti mi?” soruları çok daha değerlidir. Teknik borç, test beklemesi ve rework gibi etkiler ayrı incelenmelidir. Öğrenilen sonuçlar reference data'ya eklenmelidir. Böylece her sapma kurumun gelecekteki forecast kalitesini artıran veri haline gelir.

Hangi İşleri Yanlış Tahmin Ettik?

Büyük sapma gösteren işler seçilir. Hepsini tek tek incelemek gerekmez. Ortak desen aranır. Belirli iş türü sürekli sorunlu olabilir. Sonuç süreç iyileştirmesine dönüşür.

Neyi Bilmiyorduk?

Bilgi eksikleri açıkça listelenir. Requirement, teknoloji veya data bilinmeyeni olabilir. Gelecekte bu bilgi nasıl daha erken bulunur sorulur. Discovery checklist güncellenebilir. Suçlama yapılmaz.

Hangi Bağımlılık Görülmedi?

Başka takım veya approval süreci sonradan çıkmış olabilir. Dependency mapping geliştirilir. Pre-Sales checklist'e madde eklenebilir. Program yönetimi güncellenir. Aynı hata tekrar azalır.

Scope Değişti mi?

İlk estimate ile final scope aynı mı kontrol edilir. Scope growth varsa hata yalnızca estimate'e yazılmaz. Burn-up verisi kullanılır. Product kararları kaydedilir. Forecast geçmişi daha doğru yorumlanır.

Teknik Borç Etkiledi mi?

Legacy kod beklenmedik rework yaratmış olabilir. Bu bilgi technical debt backlog'una eklenir. Benzer modüller için risk katsayısı düşünülür. Refactoring yatırımı değerlendirilebilir. Gelecek estimate daha güçlü olur.

Review/Test Beklemesi Oldu mu?

Aktif efor doğru olabilir fakat cycle time uzun çıkabilir. Review ve test queue incelenir. Blocked time ölçülür. WIP limiti veya kapasite değişimi düşünülebilir. Sorun geliştiricinin tahmininden ayrılır.

Hangi Öğrenmeyi Reference Data'ya Eklemeliyiz?

Retrospective ancak bilgi saklanırsa kurumsal değere dönüşür. Benzer iş süresi kaydedilir. Risk faktörleri etiketlenir. Scope change ve defect bilgisi eklenir. Yeni tahminlerde tekrar kullanılır.

Tahmin Hatalarını Kişiye Değil Sisteme Bağlamak

“Kim yanlış tahmin etti?” sorusu kısa vadede sorumlu bulabilir fakat uzun vadede gerçek bilgiyi saklar. İnsanlar cezalandırılacağını düşünürse riskleri açıkça söylemez, yüksek padding ekler veya yalnızca güvenli tahmin verir. Blameless review ve psychological safety daha iyi veri üretir. Kurum her sapmayı sistem öğrenmesine çevirmelidir. Estimation Knowledge Base bu öğrenmeyi kalıcı hale getirebilir.

“Kim Yanlış Tahmin Etti?” Yerine “Neyi Göremedik?”

İkinci soru bilgi üretir. İlk soru savunma davranışı yaratır. Hidden dependency veya requirement değişimi bulunabilir. Checklist güncellenir. Gelecek forecast iyileşir.

Psychological Safety

Ekip üyesi bilmediğini söyleyebilmelidir. Yüksek risk belirtmek cezalandırılmamalıdır. Junior farklı tahmin verebilmelidir. Yönetici baskısı azaltılmalıdır. Güvenli ortam daha gerçekçi planning sağlar.

Blameless Review

Review olay ve süreç üzerine odaklanır. Kararlar o günkü bilgiyle değerlendirilir. Sonradan edinilen bilgi geçmişe uygulanmaz. Sistem iyileştirme aksiyonları çıkarılır. Kişisel suçlama yapılmaz.

Kurumsal Öğrenme

Her proje yeni veri üretir. Bu veri sonraki ekipler tarafından kullanılabilir. Ortak reference class oluşur. Pre-Sales ve roadmap kalitesi yükselir. Öğrenme kurum hafızasına dönüşür.

Estimation Knowledge Base

Benzer iş, risk ve gerçekleşen süreler kaydedilebilir. Arama yapılabilir format kullanılmalıdır. Proje sonrası dersler eklenir. Yeni ekipler bu veriden yararlanır. Tahmin kişisel hafızaya bağımlı kalmaz.

Kurumsal Estimation Veri Tabanı Nasıl Oluşturulur?

Kurumsal estimation veri tabanı, yalnızca “tahmin kaçtı, gerçekleşen kaçtı?” tablosu olmamalıdır. Proje türü, iş türü, teknoloji, tahmini efor, gerçek efor, cycle time, scope change, defect, risk ve öğrenilen ders birlikte tutulmalıdır. Bu yapı Reference Class Forecasting için güçlü kaynak oluşturur. Veri alanları fazla ağır olmamalıdır. Ekibin gerçekten güncelleyebileceği minimum ama anlamlı set seçilmelidir.

Proje Türü

Migration, yeni ürün, entegrasyon veya bakım olarak sınıflandırılabilir. Benzer işler kolay bulunur. Farklı risk profilleri ayrılır. Forecast daha doğru reference seçer. Portföy analizi kolaylaşır.

İş Türü

Feature, bug, incident veya technical debt ayrılabilir. Her türün cycle time davranışı farklıdır. Tek dağılım yanıltıcı olabilir. Forecast iş türüne göre yapılabilir. Kapasite paylaşımı daha görünür olur.

Teknoloji

Kullanılan stack tahmin bağlamını etkiler. Legacy ve modern platform ayrılabilir. Büyük version değişiklikleri kaydedilir. Reference data daha anlamlı olur. Yeni teknoloji geçişi görünür hale gelir.

Tahmini Efor

İlk estimate değiştirilmeden saklanmalıdır. Re-estimate ayrı versiyon olarak tutulabilir. Böylece değişim nedeni analiz edilir. Scope aynı mı kontrol edilir. Öğrenme kalitesi yükselir.

Gerçek Efor

Gerçek aktif çalışma mümkünse ayrı tutulur. Takvim süresiyle karıştırılmaz. Time tracking her ekipte gerekli değildir. Yaklaşık gerçekleşen efor da kullanılabilir. Ama veri amacına uygun olmalıdır.

Cycle Time

Started ve Done tarihinden hesaplanır. Flow forecasting için güçlüdür. Blocked time ayrıca tutulabilir. İş türüne göre dağılım oluşturulur. SLE üretilebilir.

Scope Change

İlk scope ile final scope farkı kaydedilir. Tahmin hatasının nedeni daha doğru anlaşılır. Product kararları görünür olur. Burn-up raporuyla desteklenebilir. Forecast geçmişi doğru yorumlanır.

Defect

Feature sonrası defect oluşması rework yaratır. Kalite etkisi estimate verisine eklenebilir. Yüksek defect'li iş türleri belirlenir. Test yatırımı kararı desteklenir. Business outcome ile ilişki kurulabilir.

Risk

Önceden bilinen riskler kaydedilir. Hangilerinin gerçekleştiği işaretlenir. Risk modelinin kalibrasyonu yapılır. Pessimistic senaryolar zamanla daha iyi kurulur. Management reserve daha veriye dayalı olur.

Öğrenilen Ders

Sayısal veri tek başına yeterli değildir. Kısa açıklama önemli bağlam sağlar. “Vendor sandbox erişimi iki hafta gecikti” gibi notlar değerlidir. Gelecek proje bu bilgiyi kullanır. Aynı riskin tekrarı azalır.

Jira ve Benzeri Araçlarda Hangi Veriler Tutulmalı?

Proje yönetim aracında çok fazla alan açmak veri kalitesini otomatik olarak artırmaz. Original Estimate, Story Point, Started Date, Completed Date, Blocked Time, Work Type, Scope Change, Dependency, Reopen ve Release gibi alanlar karar ihtiyacına göre seçilebilir. En kritik konu alanların gerçekten güncellenmesidir. Otomatik tarih üretilebilen yerlerde manuel giriş azaltılmalıdır. Forecast öncesinde data hygiene kontrolü yapılmalıdır.

Original Estimate

İlk tahmin tarihsel analiz için saklanır. Sonradan üzerine yazılmamalıdır. Re-estimate ayrı değer olabilir. Scope change ile birlikte incelenir. Sistematik bias bulunabilir.

Story Point

Takım kullanıyorsa point tutulabilir. Performans metriği yapılmamalıdır. Takımlar arası raporlanmamalıdır. Team-level forecast için kullanılabilir. Ölçek değişikliği kaydedilmelidir.

Started Date

Gerçek çalışma başlangıcı mümkünse otomatik tutulur. Sprint'e giriş tarihiyle karıştırılmamalıdır. Cycle time için gereklidir. Workflow state buna göre tasarlanabilir. Veri tutarlılığı kontrol edilmelidir.

Completed Date

Definition of Done gerçekleştiğinde kaydedilir. Development complete ile release complete farkı tanımlanmalıdır. Cycle time hesabının bitiş noktasıdır. Otomasyon hatayı azaltır. Reopen durumu ayrıca işlenebilir.

Blocked Time

Blocked süre dependency sorunlarını gösterir. Toplam cycle time'ın ne kadarının bekleme olduğunu açıklar. Büyük darboğazlar bulunabilir. Takım dışı sorunlar görünür olur. Yönetim iyileştirme yatırımı yapabilir.

Work Type

Feature, bug, incident ve technical debt ayrılabilir. Her türün throughput davranışı farklı olabilir. Kapasite dağılımı ölçülür. Forecast daha doğru yapılır. Portföy dengesi görünür hale gelir.

Scope Change

Story geliştirme sırasında büyümüş olabilir. Bu bilgi kaydedilmelidir. Estimate accuracy analizinde kullanılır. Product kararları görünür olur. Büyük değişiklikte yeni story açılması düşünülebilir.

Dependency

Bağımlı ekip veya sistem belirtilir. Program seviyesinde dependency ağacı oluşabilir. Blocked risk erken görünür. Owner atanabilir. Waiting time ölçülebilir.

Reopen

Reopen kalite veya requirement sorununa işaret edebilir. Cycle time yorumunu etkiler. Defect ve rework analizi yapılabilir. Sürekli reopen olan iş türleri incelenir. Definition of Done iyileştirilebilir.

Release

Done ile release farklıysa tarih ayrıca tutulmalıdır. Lead time hesabı güçlenir. Deployment beklemeleri görünür olur. Release frequency ölçülebilir. Product delivery daha doğru takip edilir.

Tool İçindeki Veri ile Gerçeklik Aynı mı?

Hayır. Jira veya benzeri araçlarda bulunan veri, ekip güncelleme disiplinine bağlıdır. Ticket iş başladıktan iki gün sonra In Progress'e alınırsa cycle time yanlış hesaplanır. Done statüsü gerçek production release'i temsil etmiyorsa lead time farklı çıkar. Bu nedenle forecasting öncesi veri kalitesinin doğrulanması gerekir. Tool yalnızca sürecin doğru kullanıldığı ölçüde gerçeği temsil eder.

Güncellenmeyen Ticket'lar

Status güncellenmiyorsa zaman verisi bozulur. Otomasyon yardımcı olabilir. Workflow basit tutulmalıdır. Ekip kullanım amacını bilmelidir. Veri ceza için değil iyileştirme için kullanılmalıdır.

İşin Ticket Açılmadan Başlaması

Gerçek başlangıç kaybolur. Cycle time olduğundan kısa görünür. Plansız iş görünmez hale gelir. Tüm önemli işlerin sisteme alınması gerekir. Incident ve support için basit kayıt süreci oluşturulabilir.

Done Durumunun Gerçek Release'i Temsil Etmemesi

Development Done ile müşteri teslimi farklı olabilir. Release date ayrıca tutulmalıdır. Approval bekleme süresi görülebilir. Lead time daha doğru hesaplanır. Yönetim gerçek delivery hızını görür.

Veri Kalitesi

Eksik veya yanlış veri forecast'i doğrudan etkiler. Alan sayısını artırmak çözüm değildir. Minimum kritik veri seçilmelidir. Otomasyon tercih edilmelidir. Düzenli data audit yapılabilir.

Forecast Öncesi Data Hygiene

Outlier ve status hataları kontrol edilir. Duplicate ticket'lar temizlenir. İş türleri doğrulanır. Büyük workflow değişiklikleri işaretlenir. Sonra model çalıştırılır.

AI Destekli Efor Tahminleme

AI araçları geçmiş issue'lar arasından benzer işleri bulma, story metnini analiz etme, risk önerisi üretme ve tarihsel benzetme yapma konusunda destek olabilir. En güçlü kullanım alanı doğrudan “doğru Story Point” söylemek değil, ekip için ikinci görüş ve bilgi arama desteği sunmaktır. Takıma özgü legacy bilgi ve gizli bağımlılıklar modele eksik yansıyabilir. Bu nedenle insan kararı korunmalıdır. AI çıktısı Planning Poker öncesinde referans olarak kullanılabilir.

Geçmiş Issue'lardan Benzer İş Bulma

Büyük backlog içinde benzer işleri manuel bulmak zordur. AI semantik benzerlik kullanabilir. Geçmiş cycle time ve riskler getirilebilir. Developer bu veriyi doğrular. Reference Class Forecasting hızlanır.

LLM ile Story Analizi

Story metnindeki eksik acceptance kriterleri fark edilebilir. Olası edge case önerilebilir. Dependency soruları çıkarılabilir. Bu çıktı otomatik gerçek kabul edilmemelidir. Refinement için soru listesi olarak kullanılabilir.

Otomatik Story Point Önerisi

Model geçmiş takım verisinden öneri verebilir. Ancak Story Point takım bağlamına özgüdür. Takım değişince model kalibrasyonu bozulabilir. Öneri anchor etkisi yaratabilir. Bu nedenle takım oyundan önce öneriyi görmeyebilir.

Risk ve Bağımlılık Önerisi

AI benzer issue'lardaki riskleri hatırlatabilir. API, security veya migration etkisi önerebilir. Bu liste checklist görevi görür. İnsanlar doğrular veya reddeder. Gizli organizasyon bilgisi yine ekipten gelir.

Historical Analogy

Model geçmiş proje açıklamalarını karşılaştırabilir. Benzer scope ve teknoloji bulabilir. Gerçek süreler referans olur. Bağlam farkları insan tarafından değerlendirilir. Böylece kişisel hafızaya bağımlılık azalır.

AI'ın İnsan Tahminini Desteklemesi

AI karar verici değil yardımcı rolünde daha faydalıdır. Bilgi bulur ve seçenek üretir. Takım teknik bağlamı ekler. Son estimate insan tarafından verilir. Sonuçlar gelecekteki model için veri olabilir.

AI Tahminine Neden Körü Körüne Güvenilmemeli?

AI modeli issue metnini okuyabilir fakat takımın son üç haftadır yaşadığı erişim problemi veya legacy sistemde yalnızca bir kişinin bildiği kritik davranış metinde bulunmayabilir. Veri kalitesi düşükse model de yanlış referans bulabilir. Yeni teknoloji için geçmiş örnekler sınırlı olabilir. Training Data Bias ve kurum içi bağlam farkları dikkate alınmalıdır. AI Estimate bu nedenle ikinci görüş olarak kullanılmalı, teknik kararın yerine geçmemelidir.

Takıma Özgü Bağlam

Story Point yerel ölçektir. Model farklı takım verisini karıştırırsa sonuç bozulabilir. Definition of Done farklı olabilir. Team context ayrı tutulmalıdır. Öneri takım tarafından doğrulanmalıdır.

Legacy Bilgisi

Eski sistemde undocumented davranışlar bulunabilir. Model bunları issue metninden öğrenemez. Senior developer bilgisi değerlidir. Knowledge Base modele destek olabilir. Yine de insan doğrulaması gerekir.

Gizli Bağımlılıklar

Organizasyonel dependency ticket'a yazılmamış olabilir. Vendor veya approval süreci bilinmeyebilir. Model eksik veriyle iyimser tahmin verebilir. Refinement sırasında dependency checklist kullanılmalıdır. İnsan deneyimi korunmalıdır.

Veri Kalitesi

Geçmiş issue'lar yanlış kapatılmış olabilir. Estimate alanları güncel olmayabilir. Model bu hataları öğrenebilir. Data hygiene yapılmalıdır. Kalitesiz geçmiş otomatik gerçeğe dönüşmemelidir.

Training Data Bias

Model belirli teknoloji veya iş türlerine daha fazla örnek görmüş olabilir. Nadir domain'de öneri zayıflayabilir. Confidence açıkça gösterilmelidir. Kullanıcı sonucu sorgulamalıdır. Kritik karar tek modele bırakılmamalıdır.

Yeni Teknoloji

Geçmiş benzer örnek bulunmayabilir. Model genel internet verisine fazla dayanabilir. Kurumun altyapısı farklı olabilir. PoC daha güvenilir bilgi üretir. İlk forecast geniş tutulmalıdır.

AI Estimate'i İkinci Görüş Olarak Kullanmak

AI sonucu takım oylamasından sonra göstermek anchor etkisini azaltabilir. Fark varsa neden araştırılır. Modelin bulduğu reference story incelenir. İnsan kararı kaydedilir. Süreç öğrenme üretir.

AI + Planning Poker Hibrit Modeli

Hibrit modelde AI önce geçmiş benzer story'leri ve olası riskleri hazırlar. Takım bu öneriyi doğrudan kopyalamak yerine bağımsız oy verir. Daha sonra AI önerisi ile insan tahminleri karşılaştırılır. Büyük farklar tartışılır ve karar ekip tarafından verilir. Final sonuç ile gerçekleşen süre kaydedildiğinde sonraki analiz için daha güçlü veri oluşur.

AI Benzer Story'leri Getirir

Model geçmiş backlog'u tarar. En yakın örnekleri listeler. Gerçek cycle time ve scope bilgisi getirilebilir. Takım benzerliği doğrular. Yanlış referanslar elenir.

AI İlk Range Önerir

Tek point yerine range daha güvenlidir. Model geçmiş dağılımdan aralık önerebilir. Confidence seviyesi açıklanır. Takım öneriyi henüz görmeden kendi değerlendirmesini yapabilir. Anchoring azaltılır.

Takım Bağımsız Oy Verir

Planning Poker normal biçimde yapılır. Her kişi kendi teknik bilgisini kullanır. AI önerisi ilk anchor olmaz. Junior görüşü korunur. Sonra sonuçlar karşılaştırılır.

Farklar Tartışılır

Model düşük, ekip yüksek tahmin vermiş olabilir. Gizli dependency bunun nedeni olabilir. Model eski reference kullanmış olabilir. Bu fark veri kalitesi sinyali üretir. Knowledge Base güncellenebilir.

İnsan Kararı Kaydedilir

Final estimate takım kararıdır. Varsayımlar da kaydedilir. AI önerisi ayrı alanda tutulabilir. Gerçek sonuç sonradan karşılaştırılır. Model kalibrasyonu ölçülebilir.

Sonuç Gelecek Modeller İçin Veri Olur

Her tamamlanan iş yeni örnek üretir. Tahmin, gerçek süre ve risk bilgisi saklanır. Benzerlik araması zamanla güçlenir. Kuruma özgü veri seti oluşur. AI desteği daha bağlamsal hale gelir.

Açık Kaynak Projeler Estimation İçin Veri Kaynağı Olabilir mi?

Evet, açık kaynak projeler issue ve pull request geçmişi üzerinden değerli gözlem verisi sunabilir. Public issue history, contributor sayısı ve cycle time gibi bilgiler Reference Class Dataset için kullanılabilir. Ancak açık kaynak çalışma biçimi ile kurumsal ekip aynı değildir. Gönüllü katkı, bakım önceliği ve release süreci farklılık gösterebilir. Bu nedenle veri doğrudan kopyalanmamalı, bağlam farklarıyla değerlendirilmelidir.

Public Issue History

Açık issue geçmişi iş türlerini gösterir. Başlangıç ve kapanış tarihleri analiz edilebilir. Label'lar sınıflandırma sağlar. Fakat gerçek çalışma başlangıcı bilinmeyebilir. Lead time ile cycle time karıştırılmamalıdır.

Pull Request History

PR açılış ve merge süreleri review davranışı hakkında bilgi verir. Büyük PR'ların etkisi incelenebilir. Review bottleneck görülebilir. Ancak çalışma PR açılmadan önce başlamış olabilir. Veri sınırlılığı unutulmamalıdır.

Cycle Time

Issue workflow yeterince açıksa cycle time çıkarılabilir. Farklı contributor modelleri sonucu etkiler. Kurumsal SLA ile aynı değildir. Yine de dış reference sağlar. Benzer proje türleri karşılaştırılabilir.

Contributor Sayısı

Daha fazla contributor otomatik olarak daha hızlı teslim anlamına gelmez. Koordinasyon maliyeti artabilir. Aktif ve dönemsel katkı ayrılmalıdır. Bus factor değerlendirilebilir. Takım stabilitesi forecast üzerinde önemlidir.

Issue Complexity

Label ve değişen dosya sayısı kaba sinyal sağlayabilir. Fakat gerçek business complexity farklıdır. Tek metrik kullanılmamalıdır. PR tartışması ek bağlam verir. İnsan değerlendirmesi gereklidir.

Reference-Class Dataset

Benzer open-source projeler gruplanabilir. Migration veya feature türleri ayrılır. Süre dağılımları çıkarılır. Kurumsal data yoksa ilk dış görüşü sağlayabilir. Sonra kurum kendi verisiyle kalibre eder.

Açık Kaynak Verinin Bağlam Farkları

Gönüllü contributor belirli süre çalışmayabilir. Issue aylarca önceliksiz bekleyebilir. Release süreci farklı olabilir. Bu nedenle raw lead time doğrudan kullanılmamalıdır. Çalışma modeli anlaşılmalıdır.

Open Source ve İşbirliği Tahmin Kalitesini Nasıl Etkiler?

Açık kaynak projelerde tartışmaların ve geçmiş kararların görünür olması estimation öğrenmesi için değerlidir. Birden fazla contributor farklı teknik perspektif sunar. Public discussion ve code review kayıtları geçmiş risklerin neden ortaya çıktığını gösterir. Maintainer deneyimi yeni issue'ların boyutlandırılmasını kolaylaştırabilir. Şeffaf kayıt, kurum içinde de benzer bir estimation knowledge loop oluşturmak için iyi örnektir.

Birden Fazla Contributor Perspektifi

Farklı kişiler farklı riskleri görür. Tek uzman görüşü azalır. Tartışma kayıtlı kalır. Yeni contributor geçmiş nedeni okuyabilir. Knowledge transfer güçlenir.

Public Discussion

Issue yorumları requirement değişimini gösterir. Scope neden büyüdü anlaşılabilir. Teknik seçenekler kayıtlıdır. Reference data daha zengin hale gelir. Kurumsal ekipler de karar kaydı tutabilir.

Issue Refinement

İyi issue'lar acceptance ve teknik bağlam içerir. Contributor başlamadan önce soru sorabilir. Belirsizlik azalır. Büyük işler bölünebilir. Tahmin veya seçim daha sağlıklı yapılır.

Code Review

Review ortak kalite standardı sağlar. Teknik bilgi paylaşılır. Hidden risk erken fark edilir. PR cycle time ölçülebilir. Büyük review kuyrukları görünür olur.

Maintainer Deneyimi

Maintainer sistem geçmişini bilir. Benzer issue'ları hatırlayabilir. Expert Judgment için değerlidir. Ancak contributor görüşünü bastırmamalıdır. Bağımsız perspektif korunmalıdır.

Geçmiş Kararların Görünür Olması

Eski tartışmalar tekrar aynı hatanın yapılmasını önler. Neden belirli çözüm seçildiği bilinir. Yeni tahmin daha iyi bağlamla yapılır. Kurum içinde ADR ve issue notları benzer değer sağlar. Kişisel hafıza bağımlılığı azalır.

Şeffaf Estimation Öğrenme Döngüsü

Tahmin, gerçekleşen sonuç ve öğrenilen ders birlikte tutulur. Her yeni iş reference data'yı büyütür. Ekip zamanla kalibre olur. Yeni katılan kişiler geçmişten öğrenir. Estimation bireysel sezgiden kurumsal bilgiye dönüşür.

Diyarbakır Yazılım Topluluğunda Estimation Pratiği Nasıl Geliştirilebilir?

Diyarbakır Yazılım Topluluğunda estimation pratiğini geliştirmek için yalnızca teorik eğitim yerine gerçek proje verisiyle çalışan atölyeler daha etkili olabilir. Ortak açık kaynak backlog'larında Planning Poker yapılabilir, junior ve senior geliştiricilerin tahmin farkları tartışılabilir ve tamamlanan işlerin cycle time verisi incelenebilir. Topluluk projeleri zaman içinde yerel bir reference dataset oluşturabilir. Monte Carlo ve flow metrics çalışmalarıyla tahmin, yalnızca point verme alışkanlığından çıkarılıp veri destekli karar verme pratiğine dönüştürülebilir. Topluluk projelerini incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Açık Kaynak Projelerde Ortak Backlog

Gerçek backlog eğitim için güçlü materyaldir. Katılımcılar aynı issue'yu değerlendirir. Varsayım farkları görünür olur. Sonuç daha sonra gerçek cycle time ile karşılaştırılır. Öğrenme uygulamalı hale gelir.

Planning Poker Atölyeleri

Atölyede sayıdan çok gerekçe konuşulmalıdır. Gizli oy uygulanır. En yüksek ve düşük görüş dinlenir. Farklı roller simüle edilebilir. Katılımcılar anchoring etkisini deneyimler.

Junior–Senior Ortak Tahmin

Junior görüşü ayrı bilgi sağlar. Öğrenme eğrisini görünür hale getirir. Senior hidden complexity aktarabilir. Ama senior ilk sayıyı söylememelidir. Oturum mentorluk fırsatına dönüşür.

Gerçekleşen Sürelerin İncelenmesi

Atölye tahminle bitmemelidir. İş tamamlandığında gerçek süre incelenir. Scope change ve blocker kaydedilir. Tahmin farkının nedeni tartışılır. Katılımcılar kalibrasyon öğrenir.

Estimation Retrospective

Düzenli retrospective ortak öğrenme sağlar. Kim yanlış tahmin etti sorusu sorulmaz. Hangi bilgi eksikti incelenir. Reference checklist güncellenir. Sonraki çalışma daha güçlü hale gelir.

Flow Metrics Atölyesi

Cycle time ve throughput gerçek board üzerinden hesaplanabilir. Work Item Age gösterilebilir. WIP etkisi incelenir. Story Point dışındaki forecast yöntemleri öğrenilir. Katılımcılar farklı ölçüm seçenekleri görür.

Monte Carlo Forecasting Çalışmaları

Geçmiş throughput verisiyle simülasyon yapılabilir. Farklı confidence seviyeleri karşılaştırılır. Fixed-Date örneğinde How Many forecast denenebilir. Kalan scope için When forecast üretilebilir. Olasılık yönetim kararına çevrilir.

Topluluk Projelerinden Yerel Benchmark Oluşturma

Zaman içinde tamamlanan issue verileri sınıflandırılabilir. Teknoloji ve iş türü eklenebilir. Reference class veri seti büyür. Yeni katılımcılar gerçek örnek üzerinden öğrenir. Yerel yazılım ekosisteminde ortak bilgi birikimi oluşur.

Yazılımcı Olmak İçin Estimation Bilmek Gerekir mi?

Estimation yalnızca proje yöneticisinin işi değildir. Yazılımcının teknik işi anlaması, kapsamı küçültmesi, bağımlılıkları fark etmesi ve riskleri iletişim kurarak açıklaması doğrudan mesleki beceridir. Her geliştiricinin Monte Carlo uzmanı olması gerekmez. Ancak estimate ile commitment arasındaki farkı bilmek ve Planning Poker'a anlamlı katkı verebilmek önemlidir. Bu beceri özellikle senior seviyeye doğru ilerledikçe daha fazla değer taşır.

Teknik İşin Kapsamını Anlama

İyi geliştirici yalnızca verilen task'ı kodlamaz. İşin sınırını anlamaya çalışır. Eksik requirement sorar. Gereksiz scope fark edebilir. Bu davranış estimation kalitesini yükseltir.

Riskleri Belirleme

Teknik risk erken görülürse plan değişebilir. Developer dependency veya migration etkisini söylemelidir. Risk saklanmamalıdır. Product karar verebilir. Forecast daha gerçekçi olur.

İşi Küçültme

Büyük story'yi küçük parçaya ayırmak önemli mühendislik becerisidir. Vertical slicing öğrenilmelidir. Küçük teslimat feedback'i hızlandırır. Cycle time düşer. Estimation kolaylaşır.

Bağımlılıkları Görme

Başka servis ve veri etkisi erken fark edilmelidir. Developer API contract kontrol eder. Environment ihtiyacını söyler. Blocker daha başlamadan azaltılır. Program riskleri görünür olur.

Teknik İletişim

Estimate yalnızca sayı değildir. Developer varsayımı ve riski anlatmalıdır. Yönetim teknik detay bilmeden karar verebilmelidir. Basit dil kullanılmalıdır. İletişim becerisi tahmin kadar önemlidir.

Planning Poker'a Katılım

Junior dahil herkes kendi görüşünü vermelidir. Başkasının sayısını kopyalamamalıdır. Gerekçe paylaşmalıdır. Farklı görüş öğrenme yaratır. Sessiz kalmak ortak anlayışı zayıflatabilir.

Estimate ile Commitment Arasındaki Farkı Bilmek

Developer teknik estimate verir. Commitment yönetim kararıdır. Bu ayrım bilinmezse tahmin vermek korkutucu hale gelir. Kurum terminolojiyi korumalıdır. Geliştirici riskini açıkça paylaşabilmelidir.

Senior Developer Estimation'da Nasıl Değer Katar?

Senior Developer'ın estimation katkısı daha büyük sayı söylemek değildir. Hidden complexity, architecture risk, integration risk, testing impact ve operasyonel etkiyi erken görmesi asıl değerdir. Benzer geçmiş işleri hatırlayarak reference sağlar. Bununla birlikte junior geliştiricinin farklı tahminini bastırmamalıdır. Junior'ın yüksek tahmini öğrenme eğrisi hakkında gerçek bilgi taşıyabilir.

Hidden Complexity

Senior sistemin görünmeyen bağlarını bilir. Küçük feature'ın büyük etki alanını fark edebilir. Bu bilgi risk listesini değiştirir. İş parçalanabilir. Estimate daha güçlü hale gelir.

Architecture Risk

Mimari değişiklik uzun vadeli etki taşır. Senior geçici çözümün maliyetini görebilir. Alternatif tasarım önerebilir. Spike ihtiyacını belirler. Tahmin yalnızca kod miktarına bakmaz.

Integration Risk

Geçmiş vendor sorunlarını hatırlayabilir. API contract farkını erken görebilir. Test ortamı riskini bilir. Pessimistic senaryoya katkı verir. Reference class seçimini kolaylaştırır.

Testing Impact

Merkezi modül değişikliğinin regresyon etkisini fark edebilir. QA ile kapsamı konuşur. Test eforu görünür olur. Feature yalnızca development üzerinden tahmin edilmez. Done daha gerçekçi tanımlanır.

Operasyonel Etki

Deployment ve monitoring gereksinimini düşünür. Migration rollback ihtiyacını fark eder. Production support riskini değerlendirir. DevOps ile erken koordinasyon sağlar. Delivery forecast güçlenir.

Benzer Geçmiş İşler

Senior geçmiş projelerden referans getirebilir. Ancak hafızaya tamamen güvenilmemelidir. Knowledge Base ile doğrulanabilir. Benzer ve farklı yönler açıklanır. Reference Class yaklaşımı güçlenir.

Junior Tahminini Bastırmamak

Junior farklı süre deneyimi yaşayacaktır. Bu bilgi sprint kapasitesi için değerlidir. Senior ilk rakamı söylememelidir. Farkın nedeni mentorlukla tartışılır. Psychological safety korunur.

Junior Developer'ın Tahmini Değersiz midir?

Hayır. Junior Developer'ın tahmini farklı perspektif ve öğrenme maliyetini görünür hale getirir. “Bilmiyorum” demesi bile önemli sinyaldir çünkü takımda bilgi paylaşımı ihtiyacını gösterir. Senior'ın iki saatte yaptığı iş junior için iki gün sürebilir ve sprint planında bu gerçeklik önemlidir. Junior tahmini performans yargısı olarak kullanılmamalıdır. Estimation oturumu aynı zamanda mentorluk alanı olabilir.

Farklı Perspektif

Yeni kişi uzmanların alıştığı varsayımları sorgulayabilir. Eksik dokümantasyonu fark eder. Kullanıcı açısından basit sorular sorabilir. Bu durum hidden knowledge'ı görünür yapar. Takım öğrenir.

Learning Curve

Yeni geliştirici sistemi öğrenirken daha fazla zamana ihtiyaç duyar. Bu gerçek kapasiteye yansır. Bireysel performans sorunu olarak görülmemelidir. Mentorluk planlanır. Zamanla süre düşer.

Bilgi Eksikliğinin Görünür Olması

Junior'ın sorusu dokümantasyon eksikliğini gösterebilir. Senior'ın bildiği bilgi ekip standardı değildir. Knowledge Base güncellenebilir. Bus factor azalır. Estimation ekip öğrenmesini destekler.

“Bilmiyorum” Oyununun Değeri

Bazı Planning Poker araçlarında soru işareti kartı bulunur. Bu kart bilgi eksikliği sinyalidir. Zorla point vermekten daha değerlidir. Önce eksik bilgi bulunur. Sonra tahmin yapılır.

Tahmini Mentorluk Fırsatına Dönüştürmek

Senior neden yüksek veya düşük düşündüğünü açıklayabilir. Junior teknik bağlam öğrenir. Aynı zamanda senior yeni perspektif duyar. Ortak reference oluşur. Estimation eğitim aracına dönüşür.

Estimation Kültüründe Psychological Safety

Gerçekçi tahmin için ekip üyelerinin kötü haber söyleyebilmesi gerekir. Yanlış tahmin cezalandırılırsa insanlar riskleri saklar veya tahminlere ekstra süre ekler. Yönetici baskısı optimism bias'ı daha da artırabilir. “Bu işi bilmiyoruz” veya “bu bağımlılık yüksek riskli” cümleleri profesyonel davranış olarak görülmelidir. Tahmini savunmak yerine risk ve seçenek tartışmak daha sağlıklı kültür oluşturur.

Yanlış Tahminin Cezalandırılmaması

Tahmin belirsiz gelecekle ilgilidir. Sonucun farklı çıkması tek başına başarısızlık değildir. Neden incelenir. Öğrenme kaydedilir. Sistem iyileştirilir.

Bilinmezliği Açıkça Söyleyebilmek

Ekip her şeyi biliyor gibi davranmamalıdır. Unknown alanlar listelenir. Spike açılabilir. Confidence düşürülebilir. Yönetim riski erken görür.

Yönetici Baskısından Kaçınmak

İstenen tarih ile estimate ayrılmalıdır. Yönetici hedefini söyleyebilir fakat teknik sayıyı zorlamamalıdır. Fark üzerinden scope konuşulur. Güven ilişkisi korunur. Veri daha dürüst olur.

Aşırı İyimserliğin Önlenmesi

“Yaparız” kültürü kısa vadede olumlu görünür. Fakat sürekli kaçan tarihler güveni azaltır. Pessimistic scenario ve historical data kullanılmalıdır. Risk söylemek negatiflik sayılmamalıdır. Gerçekçi plan desteklenmelidir.

Tahmini Savunmak Yerine Riski Tartışmak

“Neden sekiz point?” tartışması yerine hangi riskin sonucu değiştirdiği konuşulabilir. Scope seçenekleri oluşturulur. Risk azaltma yatırımı seçilir. Tahmin doğal olarak güncellenebilir. Sayı kişisel görüş olmaktan çıkar.

Çoklu Takımlarda Estimation

Birden fazla takım aynı programda çalıştığında Story Point standardizasyonu cazip görünür fakat çoğu zaman gereksizdir. Takımlar kendi relative scale'lerini koruyabilir. Program seviyesinde ortak ihtiyaç teslim forecast'i, cross-team dependency ve toplam flow bilgisidir. Team-Level Estimate kendi planlaması için kullanılırken Program-Level Throughput veya milestone forecast yönetim için daha anlamlı olabilir. Ortak point ölçeği kurmaya çalışmak yerel ölçümü bozabilir.

Ekipler Arasında Story Point Standardizasyonu Yapılmalı mı?

Genellikle gerekmez. Her takım kendi reference story'sine sahiptir. Ortak sayı yapay kalibrasyon gerektirir. Point performans karşılaştırmasına dönüşebilir. Program forecast'i başka metriklerden üretilebilir.

Ortak Reference Scale Sorunu

Aynı “beş point” farklı teknik sistemlerde farklıdır. Definition of Done değişebilir. Takım deneyimi farklıdır. Ortak ölçek sürekli bakım ister. Kazancı çoğu zaman düşüktür.

Program Seviyesinde Forecast

Program teslimatı takımların dependency'sine bağlıdır. Milestone veya feature flow izlenebilir. Monte Carlo program item'larıyla uygulanabilir. Critical dependency ayrıca değerlendirilir. Yönetim ortak tarih görür.

Team-Level Estimate

Takım kendi Story Point veya counting yöntemini kullanabilir. Yerel planning bu veriye dayanır. Yönetim mikro karşılaştırma yapmaz. Takım bağımsız kalibrasyonunu korur. Program için gerekli çıktı ayrı üretilir.

Cross-Team Dependency

Takımlar arası bekleme program gecikmesinin ana nedeni olabilir. Dependency board kullanılabilir. Blocked time ölçülür. Interface contract erken oluşturulur. Program forecast buna göre güncellenir.

Program-Level Throughput

Program seviyesinde tamamlanan feature veya epic sayısı izlenebilir. Item büyüklüğü kontrol edilmelidir. Point toplamından daha anlaşılır olabilir. Tarihsel trend forecast için kullanılabilir. Scope change ayrıca gösterilir.

Portföy Seviyesinde Efor Tahminleme

Portföy seviyesinde karar, hangi yatırım alanına ne kadar kapasite ayrılacağıdır. Bu seviyede story bazlı saat tahmini gereksiz ayrıntıdır. Epic Estimate, Investment Bucket, Capacity Allocation ve Strategic Themes daha uygun araçlardır. Belirsiz işlere önce Discovery Funding, daha net işlere Delivery Funding ayrılabilir. Tahmin aralığı doğrudan yatırım riskinin parçası olarak görülmelidir.

Epic Estimate

Epic için geniş range veya T-Shirt kullanılabilir. Amaç göreceli yatırım büyüklüğünü görmek olur. Büyük bilinmeyenler işaretlenir. Discovery önceliği belirlenir. Kesin sprint hesabı yapılmaz.

Investment Bucket

Kapasite stratejik yatırım gruplarına ayrılabilir. Growth, reliability veya technical debt örnek olabilir. Her bucket'ın payı yönetim kararıdır. Tahmin dağılımı bu kararı destekler. Portföy dengesi görünür olur.

Capacity Allocation

Ekiplerin ne kadar kapasitesinin hangi tema için ayrıldığı görülür. Yüzde yüz feature planı yapılmaz. Support ve technical debt payı korunur. Strateji kaynakla bağlanır. Gerçek kullanım sonradan karşılaştırılır.

Strategic Themes

Projeler ortak stratejik hedef altında gruplanabilir. Efor tek başına yatırım kararı değildir. Business outcome ve risk birlikte değerlendirilir. Theme bazlı capacity planlanır. Roadmap daha anlaşılır hale gelir.

Discovery Funding

Belirsiz fikir için doğrudan tam delivery bütçesi ayrılmayabilir. Önce küçük discovery yatırımı yapılır. Teknik ve pazar riski azaltılır. Sonra daha güvenilir estimate üretilir. Yatırım riski azalır.

Delivery Funding

Discovery sonrası scope daha netleşir. Delivery bütçesi bu bilgiye göre ayrılır. Confidence seviyesi yükselir. Büyük commitment daha bilinçli alınır. Portföy esnekliğini korur.

Tahmin Belirsizliğini Yatırım Kararına Dahil Etmek

Aynı beklenen değere sahip iki projeden biri çok daha belirsiz olabilir. Bu fark yatırım kararında önemlidir. Range genişliği risk göstergesi olabilir. Discovery ile belirsizlik azaltılabilir. Yönetim seçenekleri daha iyi karşılaştırır.

Proje Bazlı Yapı ile Ürün Takımı Arasında Tahmin Farkı

Geçici proje ekibi ile kalıcı ürün takımı aynı forecasting avantajına sahip değildir. Kalıcı takım zaman içinde kendi throughput ve cycle time geçmişini biriktirir. Geçici proje ekibi her başlangıçta yeniden kalibrasyon yapmak zorunda kalabilir. Stable Team bu nedenle yalnızca organizasyon modeli değil, forecast kalitesini artıran bir yapıdır. Ekip stabilitesi tarihsel verinin güvenilirliğini doğrudan etkiler.

Geçici Proje Ekibi

Proje için insanlar farklı ekiplerden toplanabilir. Ortak çalışma geçmişi yoktur. Point ölçeği yeni oluşur. İlk forecast geniş tutulmalıdır. Proje bitince veri devamlılığı kaybolabilir.

Kalıcı Ürün Takımı

Takım aynı ürün üzerinde uzun süre çalışır. Domain bilgisi birikir. Throughput ve cycle time daha stabil olabilir. Reference data güçlenir. Continuous forecasting kolaylaşır.

Tarihsel Veri Birikimi

Kalıcı takım her sprint yeni veri üretir. Outlier nedenleri öğrenilir. SLE kalibre edilir. Forecast confidence yükselir. Estimation ceremony azaltılabilir.

Takım Stabilitesinin Forecasting'e Etkisi

Sık ekip değişimi dağılımı bozar. Yeni öğrenme süresi oluşur. Senior ayrılması büyük etki yapabilir. Model geçici olarak genişletilir. Yeni data geldikçe yeniden kalibre edilir.

Stable Team Avantajı

Stable Team yalnızca velocity avantajı değildir. İletişim ve domain bilgisi güçlenir. Hidden dependency daha erken fark edilir. Reference data anlamlı kalır. Forecast güvenilirliği artar.

Outsource Projelerde Efor Tahmini

Outsource projelerde adam/gün, Fixed Price ve Time & Material modellerinin her biri estimation'a farklı anlam yükler. Fixed Price modelinde belirsizlik riskinin önemli kısmı tedarikçiye geçerken Time & Material modelinde müşteri ve ekip scope'u iteratif yönetebilir. Müşteri bağımlılıkları ve acceptance süreci mutlaka hesaba katılmalıdır. Scope change açık mekanizmayla yönetilmezse taraflar aynı tahmini farklı biçimde yorumlayabilir. Risk paylaşımı sözleşmede görünür olmalıdır.

Adam/Gün

Adam/gün aktif efor birimidir. Takvim süresi değildir. Fiyat hesaplamasında kullanılabilir. Bekleme ve dependency ayrıca değerlendirilmelidir. Kişi-gün ile teslim günü karıştırılmamalıdır.

Fixed Price

Fiyat önceden sabittir. Scope ve acceptance çok açık olmalıdır. Risk premium gerekir. Change Request süreci önemlidir. Eksik discovery ticari kayıp yaratabilir.

Time & Material

Gerçek kullanılan zaman üzerinden ücretlendirme yapılır. Scope daha esnek yönetilebilir. Burn rate ve remaining budget sürekli izlenir. Forecast düzenli güncellenir. Müşteri öncelik değiştirebilir.

Scope Değişimi

Outsource projede scope değişimi ticari etki yaratır. Değişiklik kayıt altına alınmalıdır. Fixed Price modelinde fiyat etkisi hesaplanır. T&M modelinde bütçe forecast'i güncellenir. Eski estimate yeni scope için geçerli sayılmaz.

Müşteri Bağımlılıkları

Test verisi veya onay müşteri tarafından sağlanabilir. Gecikme vendor'ın efor hatası değildir. Waiting time ayrıca kaydedilmelidir. Sorumluluk matrisi oluşturulur. Forecast buna göre güncellenir.

Acceptance

İşin kabul koşulu baştan belirlenmelidir. UAT süresi planlanır. Belirsiz acceptance proje sonunu uzatır. Defect severity tanımlanabilir. Commercial closure daha kolay olur.

Risk Paylaşımı

Sözleşme belirsizliği kimin taşıdığını belirler. Fixed Price daha fazla vendor riski taşır. T&M müşteriye daha fazla scope esnekliği verir. Hibrit modeller de kurulabilir. Risk dağılımı fiyatı etkiler.

Time & Material Modelinde Estimation

Time & Material modelinde estimation ortadan kalkmaz, amacı değişir. Kesin toplam fiyat yerine bütçe üst sınırı, burn rate, remaining budget ve scope trade-off sürekli izlenir. Product iteratif olarak en değerli işleri öne alabilir. Forecast her sprint yeni bilgiyle güncellenir. Bu model belirsiz ürün geliştirmede daha esnek olabilir ancak bütçe görünürlüğü disiplinli tutulmalıdır.

Bütçe Üst Sınırı

Müşteri maksimum yatırım sınırı belirleyebilir. Ekip bu sınır içinde scope yönetir. Burn rate düzenli izlenir. Forecast kalan bütçeye göre güncellenir. Son dakikada bütçe sürprizi azalır.

Iteratif Scope

Scope başlangıçta tamamen sabit olmak zorunda değildir. Her sprint öncelik yeniden değerlendirilebilir. Düşük değerli işler çıkarılabilir. Kullanıcı feedback'i plana girer. Yatırım değeri artar.

Sürekli Forecast

Her sprint kalan scope ve bütçe yeniden hesaplanır. Takım throughput'u güncellenir. Yeni riskler eklenir. Müşteriye güncel görünüm sunulur. Eski tahmin tek söz olarak tutulmaz.

Burn Rate

Burn rate dönemde harcanan maliyeti gösterir. Takım maliyeti ve kullanım süresiyle hesaplanabilir. Remaining budget ile birlikte izlenir. Forecast ekonomik açıdan güçlenir. Yönetim kapsam kararı verebilir.

Remaining Budget

Kalan bütçe kaç sprint veya ay daha çalışılabileceğini gösterir. Forecast ile bağlanır. Scope seçenekleri çıkarılır. Kritik işler öne alınır. Bütçe sıfıra yaklaşmadan karar verilir.

Scope Trade-Off

Yeni feature eklendiğinde başka iş ertelenebilir. Bütçe sabit kalıyorsa bu doğal trade-off'dur. Product value üzerinden seçim yapar. Teknik ekip efor ve risk bilgisini verir. Plan şeffaf ilerler.

Fixed Price vs Time & Material Estimation Gerçekliği

Bu iki model arasındaki temel fark yalnızca faturalandırma biçimi değildir. Belirsizliğin ekonomik riskini kimin taşıdığı değişir. Fixed Price modelinde tedarikçi daha fazla risk üstlendiği için risk premium ve Change Request önemli hale gelir. Time & Material modelinde müşteri bütçe ve scope kararını daha sık verir. Her iki modelde de şeffaf forecasting güven için gereklidir.

Belirsizliğin Kim Tarafından Taşındığı

Fixed Price vendor üzerinde daha fazla risk yaratır. T&M müşteriye daha fazla maliyet değişkenliği taşır. Scope belirsizliği sözleşmede açık olmalıdır. Risk paylaşımı fiyatı etkiler. Hibrit çözüm seçilebilir.

Risk Premium

Vendor bilinmeyenleri fiyat içine ekleyebilir. Discovery risk premium'u azaltabilir. Reference data daha doğru fiyatlama sağlar. Gizli padding yerine açık risk yaklaşımı tercih edilir. Müşteri fiyatın neden değiştiğini anlayabilir.

Change Request

Fixed Price modelinde kapsam değişikliği kontrollü ilerlemelidir. Yeni talep ayrı maliyet ve tarih etkisi üretir. T&M modelinde de backlog değişimi forecast'e yansır. Değişiklik ücretsiz değildir. Yalnızca ödeme şekli farklıdır.

Müşteri Güveni

Sürekli sürpriz tarih ve fiyat değişimi güveni azaltır. Varsayımlar açık olmalıdır. Forecast düzenli paylaşılır. Risk erken bildirilir. Şeffaflık sözleşme modelinden bağımsızdır.

Şeffaf Forecasting

Scope, confidence ve budget birlikte gösterilebilir. Fixed Price'ta margin riski de izlenir. T&M'de remaining budget ön plandadır. Her model güncel veriden faydalanır. Tek başlangıç estimate'i yeterli değildir.

Teknik Borç İçin Efor Nasıl Ayrılmalı?

Teknik borcu feature estimate'lerinin içine gizlemek, ürünün gerçek yatırım dengesini görünmez hale getirir. Ayrı backlog ve belirli Capacity Percentage kullanmak daha şeffaftır. Borç maddeleri risk bazlı önceliklendirilebilir. Her teknik borç eşit değerde değildir. Production riski, development hızına etkisi ve güvenlik sonucu yüksek olanlar öne alınmalıdır.

Ayrı Backlog

Teknik borç görünür item olarak tutulur. Etkisi ve risk açıklanır. Feature arkasına saklanmaz. Product ve engineering birlikte öncelik verir. Yatırım raporlanabilir.

Capacity Percentage

Takım kapasitesinin belirli yüzdesi teknik sağlık için ayrılabilir. Oran sabit olmak zorunda değildir. Incident ve debt trendine göre değişebilir. Yönetim bu yatırımı görür. Feature planı gerçek kapasiteye göre yapılır.

Risk Bazlı Öncelik

Borç “eski kod” olduğu için otomatik öncelikli değildir. İş etkisi ölçülmelidir. Incident riski, security ve cycle time etkisi değerlendirilebilir. En yüksek risk öne alınır. Ekonomik karar verilir.

Feature Eforuna Gizlememek

Her feature'a ekstra gün eklemek borcu ölçülemez hale getirir. Product neden hızın düştüğünü göremez. Ayrı debt item daha şeffaftır. Gerçek yatırım büyüklüğü görünür olur. Teknik tartışma güçlenir.

Investment Balance

Kısa vadeli feature ile uzun vadeli sistem sağlığı dengelenmelidir. Tamamen feature odaklı plan gelecekte cycle time'ı artırabilir. Tamamen refactoring de business value üretmeyebilir. Kapasite bilinçli bölünmelidir. Outcome ve risk birlikte izlenmelidir.

Bug ve Incident Eforu Nasıl Planlanmalı?

Bug ve incident tamamen öngörülemez görünse de geçmiş talep oranı güçlü planlama verisi sunar. Ekip haftalık support talebini, ortalama incident eforunu ve feature kapasitesine etkisini ölçebilir. Bu veriyle Support Capacity veya Incident Buffer ayrılabilir. Plansız iş oranı düzenli takip edilmelidir. Böylece her incident yeni bir “sürpriz” olmaktan çıkar.

Planlanamayan İş

Tek tek incident tarihi bilinmez. Toplam demand dağılımı tahmin edilebilir. Geçmiş haftalar analiz edilir. Buffer buna göre belirlenir. Feature kapasitesi kalan alana göre planlanır.

Historical Demand

Kaç bug ve incident geldiği ölçülür. Mevsimsel dönemler görülebilir. Release sonrası yük artabilir. Forecast bu bilgiyi kullanır. Sıfır demand varsayılmaz.

Support Capacity

Belirli kişi veya kapasite yüzdesi support için ayrılabilir. Rotasyon sistemi kurulabilir. Feature planı buna göre yapılır. Support yükü arttığında oran güncellenir. Burnout riski azalır.

Incident Buffer

Buffer geçmiş incident dağılımına dayanabilir. Kritik sistemlerde daha yüksek olur. Kullanılmayan süre başka önceliğe aktarılabilir. Gizli padding değildir. Yönetim nedeni bilir.

Feature Capacity ile Ayrıştırma

Toplam kapasitenin tamamı feature değildir. Support, debt ve operational work ayrı gösterilir. Product gerçek kullanılabilir kapasiteyi görür. Roadmap daha gerçekçi olur. Takım sürekli “neden plan tutmadı?” sorusuyla karşılaşmaz.

Beklenmeyen İş Oranı

Dönem içinde plansız iş yüzdesi hesaplanabilir. Trend yükseliyorsa sistem sağlığı sorunu olabilir. Reliability yatırımı değerlendirilebilir. Kapasite modeli güncellenir. Yönetim gerçek maliyeti görür.

Estimation ile Prioritization Aynı Şey Değildir

Efor bir işin büyüklüğü hakkında bilgi verir, öncelik ise o işe ne zaman yatırım yapılacağını belirler. Büyük iş kötü iş değildir ve küçük iş otomatik olarak öncelikli olmaz. Business Value, Cost of Delay, Risk Reduction ve Job Size birlikte değerlendirilmelidir. Bazen çok büyük bir güvenlik yatırımı en yüksek öncelik olabilir. Estimation ekonomik karara girdi sağlar ancak kararı tek başına vermez.

Büyük İş Kötü İş Değildir

Büyük feature büyük değer üretebilir. Yüksek efor yalnızca maliyet sinyalidir. Değerle birlikte karşılaştırılmalıdır. İş yine de parçalanabilir. Öncelik ekonomik sonuca bağlıdır.

Küçük İş Öncelikli Olmak Zorunda Değildir

Küçük task düşük değerli olabilir. Sırf hızlı bittiği için öne alınmamalıdır. Opportunity cost düşünülmelidir. Product değer sırasını belirler. Efor destekleyici bilgidir.

Business Value

Gelir, kullanıcı etkisi veya stratejik değer değerlendirilebilir. Sayısallaştırma mükemmel olmak zorunda değildir. Göreceli karşılaştırma yeterli olabilir. Teknik eforla birlikte ele alınır. Yatırım sırası oluşur.

Cost of Delay

Gecikmenin ekonomik maliyetini düşünür. Regülasyon veya satış fırsatında yüksek olabilir. Aynı eforlu iki iş farklı gecikme maliyeti taşıyabilir. Öncelik bu bilgiyle değişir. WSJF bu kavramı kullanır.

Risk Reduction

Bazı işler doğrudan feature üretmez. Büyük teknik veya operasyonel riski azaltabilir. Bu değer görünür olmalıdır. Security ve reliability yatırımları buna örnektir. Job Size ile birlikte değerlendirilir.

Job Size

Job Size eforun prioritization içindeki yeridir. Büyük iş daha yüksek maliyet taşır. Fakat yüksek value bunu haklı çıkarabilir. Relative size yeterli olabilir. Sahte hassasiyetten kaçınılmalıdır.

WSJF ve Efor

WSJF, Cost of Delay ile Job Size ilişkisini kullanarak göreceli öncelik üretmeye çalışır. Efor tahmini burada ekonomik kararın bir girdisidir. Yöntem güçlü olabilir ancak sayıların çok hassas görünmesi yeni bir yanlış kesinlik yaratabilir. Özellikle hem Cost of Delay hem Job Size göreceli tahminse sonucun matematiksel hassasiyetine fazla anlam yüklenmemelidir. Amaç seçenekleri konuşmak ve öncelik kararını yapılandırmaktır.

Cost of Delay

İşin gecikmesinin maliyeti değerlendirilir. Gelir kaybı veya risk etkisi olabilir. Tam para hesabı mümkün olmayabilir. Göreceli puan kullanılabilir. Varsayımlar açık olmalıdır.

Job Size

İş büyüklüğü denominator olarak kullanılır. Story Point veya kaba size olabilir. Takımlar arası karşılaştırmada dikkat gerekir. Aynı karar seti içinde relative kullanım daha uygundur. Çok büyük işler parçalanabilir.

Relative Prioritization

WSJF kesin ekonomik model değildir. İşleri birbirine göre sıralar. Tartışmayı daha yapılandırılmış hale getirir. Product ve engineering ortak değerlendirme yapar. Son karar iş bağlamına göre verilir.

Efor Tahminini Ekonomik Karara Bağlamak

Estimate tek başına rapor olarak kalmaz. Hangi yatırımın önce yapılacağına katkı verir. Büyük maliyet görünür olur. Değerle karşılaştırılır. Estimation karar destek görevini yerine getirir.

WSJF'nin Sahte Hassasiyet Riski

7.43 puanı 7.21'den kesin daha iyi kabul etmek yanlış olabilir. Girdiler zaten yaklaşık değerlerdir. Yakın sonuçlar için ek tartışma gerekir. Range kullanılabilir. Matematik kararın yerini almamalıdır.

Tahmin Kalitesi ile Requirement Kalitesi Arasındaki İlişki

Eksik requirement üzerinde iyi estimation yöntemi çalışmaz. Belirsiz user story, eksik acceptance criteria, tanımsız scope boundary ve unutulan non-functional requirements tahminin doğal olarak sapmasına yol açar. Mockup veya temel tasarım gerektiği halde yoksa ekip farklı çözümler düşünebilir. Dependency information özellikle kurumsal projelerde kritik öneme sahiptir. Tahmin kalitesini artırmak istiyorsanız yalnızca estimation ceremony'yi değil requirement akışını da iyileştirmelisiniz.

Belirsiz User Story

Story neyin yapılacağını açıkça söylemelidir. Çözümü fazla dikte etmek gerekmez. Kullanıcı amacı anlaşılmalıdır. Belirsizlik yüksekse refinement yapılır. Point vererek belirsizlik çözülmez.

Eksik Acceptance Criteria

Eksik kriter farklı scope yorumlarına yol açar. Edge case sonradan çıkabilir. Test eforu beklenenden büyüyebilir. Ana kurallar önceden yazılmalıdır. Tahmin daha karşılaştırılabilir olur.

Scope Boundary

İşe neyin dahil olmadığı da bilinmelidir. Entegrasyon veya migration scope dışı olabilir. Bu sınır açık yazılmalıdır. Sonradan scope creep azalır. Estimate hangi kapsamı temsil ettiği bilinir.

Non-Functional Requirements

Performance ve security sonradan eklenmemelidir. Scalability veya accessibility eforu değiştirebilir. Gereksinimler erken görünür olmalıdır. Architecture kararı buna göre verilir. Tahmin gerçek teslim koşulunu kapsar.

Mockup / Design

Kullanıcı akışı belirsizse teknik tahmin de değişebilir. Her story için yüksek detaylı tasarım gerekmez. Kritik ekranlar önceden netleşebilir. Tasarım change rate izlenebilir. Product ve engineering aynı beklentiyi görür.

Dependency Information

Hangi sistem ve takımın etkilendiği bilinmelidir. API erişimi kontrol edilir. Data owner belirlenir. Approval süreci görünür olur. Waiting time forecast'e eklenir.

Non-Functional Requirements Efora Nasıl Dahil Edilir?

Performance, Security, Accessibility, Observability, Scalability, Compliance ve Disaster Recovery gereksinimleri feature tamamlandıktan sonra eklenen ekstra işler değildir. Ürünün gerçek teslim koşullarının parçasıdır. Bir API fonksiyonel olarak çalışsa bile performans veya güvenlik kriterini karşılamıyorsa Done kabul edilmeyebilir. Bu nedenle non-functional requirement'lar estimation sırasında görünür olmalıdır. Definition of Done ve architecture checklist bu alanların unutulmasını önleyebilir.

Performance

Load test gerekebilir. Cache veya query optimizasyonu efor yaratabilir. Beklenen trafik bilinmelidir. Performance kriteri acceptance'a eklenir. Son hafta sürprizi azalır.

Security

Authentication ve authorization tasarımı önemlidir. Security review gerekebilir. Sensitive data yönetimi planlanır. Penetration test eforu eklenebilir. Compliance ile birlikte değerlendirilir.

Accessibility

UI geliştirmesinde accessibility kriterleri baştan düşünülmelidir. Sonradan düzeltmek daha pahalı olabilir. Test araçları kullanılabilir. Tasarım ekibi sürece katılır. Done kriteri açık olur.

Observability

Log ve metric olmadan production davranışı görülemez. Alarm tasarımı gerekebilir. Trace entegrasyonu efor yaratabilir. Operasyon ekibi katkı verir. Incident çözüm süresi azalır.

Scalability

Bugünkü trafik ile gelecek yük farklı olabilir. Architecture buna göre tasarlanır. Gereksiz premature optimization yapılmamalıdır. Ölçülebilir hedef belirlenir. Tahmin gerçek hedefe göre yapılır.

Compliance

Regülasyon ek belge ve kontrol gerektirebilir. Audit trail veya veri saklama koşulu olabilir. Hukuk ve security ekibi erken dahil edilmelidir. Approval zamanı forecast'e girer. Deadline planı buna göre yapılır.

Disaster Recovery

Backup ve restore süreci tasarlanmalıdır. RTO ve RPO hedefi olabilir. Test senaryosu gerekir. Infrastructure eforu artabilir. Kritik sistemlerde Done kapsamına alınmalıdır.

Kurumsal Estimation Policy Nasıl Oluşturulur?

İyi bir Estimation Policy her ekibe tek yöntem dayatmak yerine hangi seviyede hangi tekniğin kullanılacağını açıklar. Tahminin amacı, kimin tahmin yaptığı, kimin bu veriyi kullanabileceği ve performans değerlendirmesinde kullanılmayacağı yazılı hale getirilmelidir. Re-Estimate koşulları ve confidence gösterimi belirlenmelidir. Historical Data saklama standardı kurulmalıdır. Bu politika ekipleri kontrol etmek için değil ortak terminoloji ve karar kalitesi oluşturmak için kullanılmalıdır.

Tahminin Amacı

Her estimate'in hangi karar için üretildiği belirtilmelidir. Sprint planning, teklif veya roadmap farklı ihtiyaçtır. Aynı yöntem kullanılmak zorunda değildir. Gereksiz hassasiyet azaltılır. Kullanıcı beklentisi netleşir.

Hangi Seviyede Hangi Teknik?

Story için Relative Estimate seçilebilir. Epic için T-Shirt veya Range kullanılabilir. Proje için Probabilistic Forecast uygulanabilir. Portfolio için Coarse Estimate yeterli olabilir. Seviye bazlı standart oluşturulur.

Kim Tahmin Yapar?

Teknik eforu işi yapacak ekip değerlendirmelidir. Product scope bilgisini sağlar. Senior tek başına karar vermemelidir. Gerekirse uzman görüşü eklenir. Roller açık yazılır.

Kim Tahmini Kullanabilir?

Estimate'in bağlamı kullanıcıya göre açıklanmalıdır. Finans point'i maliyet birimi olarak kullanmamalıdır. Yönetim velocity ile performans ölçmemelidir. Forecast için doğru veri katmanı seçilir. Yanlış kullanım engellenir.

Performans İçin Kullanılmayacağı Kuralı

Story Point bireysel veya takımlar arası performansa bağlanmamalıdır. Bu kural açıkça yazılmalıdır. Ekip veri manipülasyonundan korunur. Psychological safety yükselir. Estimation asıl amacını korur.

Ne Zaman Re-Estimate Yapılır?

Scope önemli değiştiğinde yapılabilir. Büyük risk ortadan kalktığında güncellenebilir. Yeni teknik bilgi geldiğinde değer üretir. Kararı değiştirmeyecekse gereksizdir. Policy bu sınırı tanımlar.

Confidence Nasıl Gösterilir?

Range ve confidence birlikte kullanılabilir. Yüzde 50, 85 veya 95 seviyeleri tanımlanabilir. Her seviyenin iş anlamı açıklanır. Yönetim tek tarihi doğru okumayı öğrenir. Forecast iletişimi standardize olur.

Historical Data Nasıl Saklanır?

Minimum alan seti belirlenir. Cycle time ve throughput otomatik toplanabilir. Scope change ve risk işaretlenir. Veri retention politikası uygulanır. Reference Class Dataset oluşturulur.

Örnek Estimation Governance Matrisi

Governance matrisi her seviyenin aynı tahmin ritüeline girmesini önler. Story seviyesinde relative estimate, epic seviyesinde range veya T-Shirt, proje seviyesinde probabilistic forecast ve portfolio seviyesinde coarse estimate kullanılabilir. Sorumluluklar da seviyeye göre değişir. Developers story boyutlandırmasına, Product ve Engineering epic değerlendirmesine, Delivery ve Engineering proje forecast'ine katkı verir. Portfolio kararı ise yatırım perspektifinden ele alınır.

Story Seviyesi

Story yakın dönem planning içindir. İş yeterince küçük olmalıdır. Team-level relative estimate kullanılabilir. Karar sprint kapasitesini etkiler. Performans ölçümü yapılmaz.

Relative Estimate

Story başka story'lerle karşılaştırılır. Point veya basit size kullanılabilir. Saat dönüşümü yapılmaz. Reference story kalibrasyon sağlar. Takım yerel ölçeğini korur.

Developers

Teknik efor geliştiriciler tarafından değerlendirilir. QA ve diğer roller risk bilgisi verebilir. Product scope açıklar. Yönetici sayı dikte etmez. Ortak anlayış hedeflenir.

Sprint Planning

Estimate kapasiteyle birlikte değerlendirilir. İzin ve support load hesaba katılır. Sprint goal önceliklidir. Point doldurmak amaç değildir. Plansız iş buffer'ı korunabilir.

Epic Seviyesi

Epic daha yüksek belirsizlik taşır. Detaylı saat tahmini uygun değildir. Range veya T-Shirt kullanılabilir. Discovery ihtiyacı belirlenir. Roadmap kararı desteklenir.

Range / T-Shirt

Kaba boyut yatırım kararına yeterli olabilir. XL iş discovery adayıdır. Yaklaştıkça detay artırılır. Scope change beklenir. Sahte hassasiyet azaltılır.

Product + Engineering

Product iş değeri ve scope'u getirir. Engineering teknik risk ve eforu değerlendirir. Ortak trade-off yapılır. Bir taraf diğerinin rolünü üstlenmez. Epic kararı dengeli olur.

Roadmap

Roadmap kesin söz değildir. Büyük planlama yönü verir. Confidence daha düşük olabilir. Yakın dönem daha net gösterilir. Forecast düzenli güncellenir.

Proje Seviyesi

Proje bütçe ve takvim kararı gerektirir. Historical data ve risk modeli daha önemlidir. Tek point toplamı yeterli değildir. Probabilistic Forecast kullanılabilir. Scope trendi izlenir.

Probabilistic Forecast

Throughput veya cycle time dağılımı kullanılır. Tek tarih yerine confidence sunulur. Kalan scope modele girer. Yeni data geldikçe güncellenir. Yönetim risk seviyesini seçer.

Delivery + Engineering

Delivery takvim ve stakeholder ihtiyacını yönetir. Engineering teknik risk ve kapasite bilgisi sağlar. Ortak forecast oluşturulur. Product scope kararına katılır. Responsibility ayrımı korunur.

Bütçe ve Takvim

Forecast burn rate ile birleştirilebilir. Bütçe üst sınırı görünür olur. Tarih confidence seviyesiyle sunulur. Scope seçeneği hazırlanır. Yönetim ekonomik karar verir.

Portfolio Seviyesi

Portföy detaylı story hesabı gerektirmez. Stratejik yatırım karşılaştırılır. Coarse estimate yeterli olabilir. Discovery ve delivery funding ayrılır. Belirsizlik yatırım riskine dahil edilir.

Coarse Estimate

T-Shirt veya geniş range kullanılabilir. Amaç sıralama ve kapasite dağılımıdır. Detaylı task estimate yapılmaz. Büyük belirsizlik işaretlenir. Discovery kararı verilir.

Investment Decision

Efor business value ile birlikte değerlendirilir. Cost of Delay ve risk reduction eklenebilir. Kaynak sınırlılığı hesaba katılır. Portföy dengesi seçilir. Estimation karar destek görevini yerine getirir.

Tahmin Değiştiğinde Ne Yapılmalı?

Tahmin değiştiğinde ilk refleks eski rakamı savunmak olmamalıdır. Neden değiştiği açıkça gösterilmelidir: yeni bilgi mi geldi, scope mu büyüdü, risk mi gerçekleşti, dependency mi gecikti? Forecast güncellenir ve stakeholder iletişimi yapılır. Değişiklik geçmiş estimate'in “yanlış” olduğu anlamına gelmeyebilir. Güncel bilgiyle daha iyi karar vermek, eski sayıyı korumaktan değerlidir.

Neden Değişti?

Değişiklik kategorisi kaydedilmelidir. Scope, capacity, risk veya data olabilir. Sebep görünür olduğunda güven artar. Retrospective için veri oluşur. Sistematik desen bulunabilir.

Yeni Bilgi

Discovery veya development yeni bilgi üretir. Eski varsayım geçersiz olabilir. Estimate güncellenir. Bu normal öğrenme davranışıdır. Cezalandırılmamalıdır.

Scope Change

Kapsam büyüdüyse forecast doğal olarak değişir. Eski ve yeni scope karşılaştırılır. Burn-up grafiği yardımcı olur. Product kararı görünür olur. Tahmin ekibe yüklenmez.

Risk Gerçekleşmesi

Bilinen risk oluşmuş olabilir. Contingency kullanılır. Yeni tarih hesaplanır. Kalan riskler yeniden değerlendirilir. Management Reserve gerekebilir.

Dependency

Başka takım gecikmesi delivery süresini etkiler. Effort değişmemiş olabilir. Waiting time ayrıca raporlanır. Program planı güncellenir. Dependency owner aksiyon alır.

Forecast Güncelleme

Yeni throughput ve scope modele girer. Confidence yeniden hesaplanır. Eski forecast geçmiş olarak saklanır. Değişim trendi görülür. Yönetim güncel değeri kullanır.

Stakeholder İletişimi

Değişiklik erken paylaşılmalıdır. Neden ve etki açık anlatılır. Alternatif scope veya tarih sunulur. Sadece kötü haber verilmez. Karar ihtiyacı netleştirilir.

Eski Tahmini Savunmaya Çalışmamak

Eski sayı artık güncel değilse korumak değer yaratmaz. Gerçek bilgi kullanılmalıdır. Tahmin ego konusu değildir. Forecast karar aracıdır. Kurum öğrenmeye öncelik vermelidir.

Re-Estimation Ne Zaman Değer Üretir?

Re-Estimation ancak sonuç bir kararı değiştirecekse anlamlıdır. Scope önemli ölçüde değiştiğinde, büyük risk ortadan kalktığında veya yeni teknik bilgi geldiğinde yeni estimate değer üretir. Bunun dışında her küçük değişiklikte toplantı yapmak estimation cost'u artırır. Eğer yeni rakam roadmap, bütçe, tarih veya öncelik üzerinde hiçbir etki yaratmayacaksa yeniden tahmin gereksiz olabilir. Just-in-Time yaklaşım burada da faydalıdır.

Scope Önemli Ölçüde Değiştiğinde

Yeni feature veya acceptance kriteri eklenmiş olabilir. İlk estimate artık aynı işi temsil etmez. Re-estimate yapılır. Scope change kaydedilir. Forecast güncellenir.

Büyük Bir Risk Ortadan Kalktığında

PoC teknik bilinmeyeni çözebilir. Vendor API doğrulanmış olabilir. Pessimistic senaryo daralır. Yeni estimate daha düşük çıkabilir. Yönetim yatırım kararını güncelleyebilir.

Yeni Teknik Bilgi Geldiğinde

Implementation yaklaşımı netleşmiş olabilir. Daha basit çözüm bulunabilir. Hidden dependency ortaya çıkabilir. Re-estimate bilgiye dayanır. Sayı pazarlığı değildir.

Karar Değiştirecekse

Yeni estimate tarih veya scope kararını etkiliyorsa yapılmalıdır. Bütçe değişebilir. Öncelik değişebilir. Risk seviyesi farklılaşabilir. Estimation karar değerine bağlanır.

Re-Estimate Sonucu Hiçbir Kararı Değiştirmeyecekse Yapmamak

Bir sayı yalnızca raporu güncellemek için üretilmemelidir. Toplantının kişi-saat maliyeti vardır. Eski kaba estimate yeterli olabilir. Delivery devam edebilir. Estimation debt azaltılır.

Tahmin Sonucunda Hangi Karar Verilecek?

Her estimation talebinden önce sorulması gereken en güçlü soru budur. Tahmin yoksa gerçekten karar verilemiyor mu? Sonuç scope'u, tarihi, bütçeyi veya önceliği değiştirecek mi? Hiçbiri değişmeyecekse ayrıntılı estimate istemenin nedeni sorgulanmalıdır. Bu basit yaklaşım birçok kurumda toplantı yükünü ve anlamsız veri üretimini azaltabilir.

Tahmin Yoksa Karar Verilemiyor mu?

Bazı kararlar tahminsiz de verilebilir. Küçük bakım işinde uzun hesap gerekmeyebilir. Büyük yatırımda estimate daha kritiktir. Karar ihtiyacı açıkça tanımlanır. Uygun hassasiyet seçilir.

Scope Değişecek mi?

Estimate yüksek çıkarsa kapsam azaltılabilir mi sorulur. Cevap hayırsa estimate'in karar değeri farklıdır. Yine bütçe ve tarih etkisi olabilir. Scope seçenekleri önceden düşünülmelidir. Product sürece katılır.

Tarih Değişecek mi?

Tarih sabitse feasibility analizi yapılmalıdır. Tahmini küçültmek anlamlı değildir. “Tarihe ne sığar?” sorusu sorulur. Confidence seviyesi hesaplanır. Scope trade-off yapılır.

Bütçe Değişecek mi?

Estimate yatırım miktarını etkileyebilir. Bütçe sabitse scope veya süre değişmelidir. Burn rate kullanılabilir. Remaining budget görünür olur. Yönetim ekonomik karar verir.

Öncelik Değişecek mi?

Büyük efor düşük değerli işi geriye atabilir. Yüksek değerli büyük iş yine önde kalabilir. WSJF yardımcı olabilir. Estimate yalnızca girdidir. Product kararı verir.

Hiçbiri Değişmeyecekse Tahmin Gerekli mi?

Çoğu durumda ayrıntılı estimate gereksiz olabilir. Belki kaba size yeterlidir. Ekip doğrudan delivery'ye geçebilir. Ceremony cost azalır. Tahmin üretmek kendi başına hedef olmaz.

Estimation KPI'ları

Estimation KPI'ları insanları daha çok sayı üretmeye değil, sistemin karar kalitesini ölçmeye yöneltmelidir. Estimation Meeting Time, Estimate Age ve Re-Estimate Rate sürecin maliyetini gösterir. Forecast Accuracy ve Forecast Confidence Hit Rate tahmin sisteminin kalibrasyonunu ölçebilir. Scope Change Rate, Cycle Time ve Throughput ise delivery bağlamını açıklar. KPI'lar tek başına hedefe dönüştürülmemelidir.

Estimation Meeting Time

Toplam kişi-saat olarak izlenebilir. Sürekli artıyorsa ceremony sorgulanır. Karar değeriyle karşılaştırılır. Büyük backlog için yöntem değiştirilebilir. Timebox kullanılabilir.

Estimate Age

Tahminin ne kadar eski olduğu gösterilir. Uzak backlog'da eski değer normal olabilir. Kritik karar öncesi güncellenir. Scope değişikliğiyle birlikte değerlendirilir. Eski sayıya aşırı güven önlenir.

Re-Estimate Rate

Ne kadar işin tekrar tahmin edildiğini gösterir. Yüksek oran estimation debt sinyali olabilir. Scope churn de neden olabilir. Kök neden incelenir. Uzak backlog politikası değiştirilebilir.

Forecast Accuracy

Forecast ile sonuç karşılaştırılır. Tek tarih yerine range kullanılıyorsa farklı ölçüm gerekir. Scope değişimi ayrıca tutulmalıdır. Amaç ceza değildir. Model kalibrasyonudur.

Forecast Confidence Hit Rate

Yüzde 85 forecast'lerin yaklaşık ne sıklıkla tuttuğu incelenir. Çok düşük oran iyimserlik gösterir. Aşırı yüksek oran fazla geniş aralığa işaret edebilir. Model kalibre edilir. Güven seviyesi anlamlı hale gelir.

Scope Change Rate

Kapsamın dönem içinde ne kadar değiştiğini gösterir. Forecast sapmasını açıklamaya yardımcı olur. Product davranışı görünür olur. Yüksek oran kötü olmak zorunda değildir. Ürün discovery bağlamında normal olabilir.

Cycle Time

Flow sağlığını gösterir. Percentile ve trend izlenebilir. WIP ve blocked time ile birlikte değerlendirilir. Tek ortalama kullanılmamalıdır. Process improvement için değerlidir.

Throughput

Tamamlanan iş miktarını gösterir. İş türüne göre ayrılabilir. Trend forecast'e girdi olur. Point'ten bağımsız çalışabilir. Business outcome ile birlikte yorumlanmalıdır.

Yönetimin İzlemesi Gereken Metrikler

Yönetim için en değerli metrikler ekibin kaç point yaptığı değil, teslimatın ne kadar öngörülebilir ve değerli olduğudur. Delivery Forecast, Throughput Trend, Cycle Time, Work Item Age, Blocked Time, Scope Growth, Defect Rate, Change Failure Rate ve Business Outcome birlikte daha doğru resim sunar. Tek metriğe aşırı odaklanmak davranış bozukluğu yaratabilir. Flow ve outcome birlikte görülmelidir. Yönetim dashboard'u karar ihtiyacına göre sade tutulmalıdır.

Delivery Forecast

Kalan scope'un olası teslim tarihini gösterir. Confidence seviyesi eklenir. Scope değişimi görünürdür. Yönetim trade-off yapabilir. Tek tarih yerine risk bilgisi sunar.

Throughput Trend

Tamamlanan iş miktarının zaman içindeki değişimini gösterir. Ani düşüş neden analizi gerektirir. İş türü dağılımı kontrol edilir. Takım değişikliği etkisi olabilir. Performans cezası olarak kullanılmamalıdır.

Cycle Time

İşlerin sistemden ne kadar hızlı aktığını gösterir. Percentile değerleri daha anlamlıdır. Outlier'lar süreç sorununa işaret edebilir. WIP ile ilişki kurulabilir. Customer lead time ile birlikte izlenebilir.

Work Item Age

Henüz bitmemiş işin ne kadar süredir açık olduğunu gösterir. Yaşlanan item risk sinyali verir. Cycle time percentile ile karşılaştırılır. Ekip erken müdahale edebilir. Forecast sürprizi azalır.

Blocked Time

İşlerin ne kadar süre engelli kaldığını gösterir. Dependency kaynakları sınıflandırılabilir. Program darboğazı bulunabilir. Yönetim organizasyonel aksiyon alabilir. Developer performansıyla karıştırılmaz.

Scope Growth

Roadmap veya proje kapsamının zaman içinde büyümesini gösterir. Burn-up ile görülebilir. Forecast değişimini açıklar. Product kararları daha şeffaf olur. Deadline riskinde erken aksiyon sağlar.

Defect Rate

Kalite trendini gösterir. Yüksek defect rework kapasitesini artırır. Release baskısı kaliteye zarar veriyorsa görünür olur. Test yatırımı desteklenir. Business impact ile birlikte değerlendirilir.

Change Failure Rate

Deploy sonrası sorun çıkan değişiklik oranıdır. Delivery hızının kaliteyle dengeli olup olmadığını gösterir. Yüksek oran incident yükü yaratır. Forecast kapasitesini etkiler. DevOps performans görünümünde değerlidir.

Business Outcome

Teslim edilen feature'ın gerçek sonucunu gösterir. Kullanım, gelir veya hata azalması olabilir. Çok iş bitirmek tek başına başarı değildir. Outcome roadmap önceliğini değiştirir. Estimation yatırım kararına bağlanır.

Yönetimin İzlememesi Gereken Sahte Verimlilik Metrikleri

Developer başına Story Point, takımlar arası velocity, commit sayısı, kod satırı, ticket sayısı ve yüzde yüz utilization kolay ölçüldüğü için caziptir. Ancak bu metrikler gerçek müşteri değerini veya takım sağlığını güvenilir biçimde göstermez. Hedef haline geldiklerinde kolayca manipüle edilebilirler. Tahmini her zaman tutturan ekip de mutlaka daha iyi ekip değildir. Sağlıklı yönetim, çalışanları ölçmek yerine sistemin akışını ve sonucunu anlamaya odaklanmalıdır.

Developer Başına Story Point

Point takım ölçüsüdür. Bireysel hale getirildiğinde işbirliği bozulur. İnsanlar point peşinde koşar. Mentorluk görünmez olur. Kullanılmamalıdır.

Takımlar Arası Velocity

Point ölçekleri farklıdır. Definition of Done değişir. Teknik borç seviyesi farklıdır. Karşılaştırma point inflation üretir. Program forecast başka metrikle yapılmalıdır.

Commit Sayısı

Çok commit çok değer anlamına gelmez. Küçük commit alışkanlığı sayıyı artırır. Pair Programming etkisi görülmez. Refactoring farklı davranabilir. Kalite ve outcome daha değerlidir.

Kod Satırı

Daha az kod daha iyi çözüm olabilir. Otomasyon veya kütüphane satırı azaltır. Satır sayısı karmaşık çözümü ödüllendirebilir. Bakım maliyeti görünmez. Performans metriği olmamalıdır.

Ticket Sayısı

Ticket büyüklüğü değişir. İnsanlar işi yapay bölebilir. Büyük problem çözen kişi düşük görünür. İş değeri ölçülmez. Throughput bile bağlamla kullanılmalıdır.

“Utilization %100”

Yüzde yüz doluluk flow'u yavaşlatabilir. Kuyruk büyür. Acil iş için alan kalmaz. Context switching artar. Capacity buffer korunmalıdır.

Tahmini Her Zaman Tutturma Oranı

Her estimate'i tutturmak fazla padding göstergesi olabilir. Yeni bilgiye rağmen plan değişmiyorsa öğrenme cezalandırılıyor olabilir. Range calibration daha anlamlıdır. Scope change izlenmelidir. Tek doğruluk oranı hedef yapılmamalıdır.

Kurumsal Estimation Dashboard

Kurumsal Estimation Dashboard yönetim için fazla ayrıntılı task listesinden ziyade karar verilebilir bilgi sunmalıdır. Roadmap Forecast, Confidence Level, Scope Trend, Throughput, Cycle Time, Blocked Work, Capacity, Risk ve Forecast Changes temel alanlar olabilir. Dashboard tek kırmızı-yeşil tarih göstergesine indirgenmemelidir. Forecast'in neden değiştiği ve hangi kararın gerektiği görünmelidir. Bu yapı Efor Tahminleme (Estimation) Yöntemlerinde Kurumsal Gerçeklik yaklaşımının yönetim katmanındaki karşılığıdır.

Roadmap Forecast

Yakın ve uzak dönem farklı confidence ile gösterilir. Tek kesin tarih kullanılmaz. Büyük epic'ler range halinde olabilir. Scope trendi yanında gösterilir. Yönetim beklentisi daha gerçekçi olur.

Confidence Level

Her forecast'in güven seviyesi görünür olmalıdır. Erken roadmap daha düşük olabilir. Yakın release daha yüksek olmalıdır. Risk toleransı açıkça seçilir. Tarihin anlamı netleşir.

Scope Trend

Kapsamın büyüyüp küçüldüğü görülür. Forecast değişikliğini açıklar. Burn-up grafik kullanılabilir. Product kararları görünür olur. Deadline riski erken anlaşılır.

Throughput

Gerçek tamamlanma hızı gösterilir. Trend ve dağılım birlikte kullanılabilir. İş türü ayrımı yapılabilir. Point hedefiyle karıştırılmaz. Forecast girdisi olarak kullanılır.

Cycle Time

Percentile değerleri flow sağlığını gösterir. Yaşlanan item'lar ayrıca işaretlenebilir. WIP değişimiyle birlikte okunur. Outlier nedenleri incelenir. Delivery süreci iyileştirilir.

Blocked Work

Engelli iş sayısı ve süreleri gösterilir. Başlıca dependency kaynakları listelenebilir. Yönetim organizasyonel engelleri kaldırabilir. Takım dışı problem görünür olur. Forecast confidence buna göre değişebilir.

Capacity

Nominal değil gerçek kapasite gösterilmelidir. İzin ve support yükü dikkate alınır. Feature, debt ve incident dağılımı görülebilir. Aşırı planlama erken anlaşılır. Roadmap gerçekçi hale gelir.

Risk

Top riskler ve etkileri görünür olur. Risk owner belirlenebilir. Mitigation durumu takip edilir. Confidence ile ilişkilendirilir. Yönetim yalnızca tarihe bakmaz.

Forecast Changes

Önceki ve güncel forecast arasındaki fark gösterilir. Neden kategorisi eklenir. Scope, risk veya capacity etkisi anlaşılır. Değişiklik başarısızlık olarak değil yeni bilgi olarak yorumlanır. Kurumsal güven artar.

Efor Tahminleme Olgunluk Modeli

Estimation olgunluğu daha fazla hesap yapmak anlamına gelmez. İlk seviyelerde tarih yöneticiden gelebilir ve ekip bunu teknik olarak doğrulamaya zorlanabilir. Sonraki seviyelerde saat bazlı tahmin, Relative Estimation, Historical Data Supported Estimation ve Probabilistic Forecasting görülür. En ileri aşamada Continuous Forecasting ile estimation ceremony azalır ve outcome daha önemli hale gelir. Olgunluğun yönü daha fazla sayıdan daha iyi karar sistemine doğrudur.

Seviye 1: Yönetici Tahmini

Tarih üst yönetim tarafından belirlenir. Teknik ekipten sonradan onay beklenir. Risk görünürlüğü düşüktür. Estimate ile target date karışır. Tahmin sapması yüksek olabilir.

Seviye 2: Saat Bazlı Takım Tahmini

Takım task'ları saat olarak toplar. Bottom-up plan yapılır. Ayrıntı yüksek görünür. Meeting cost büyüyebilir. False Precision riski oluşur.

Seviye 3: Relative Estimation

Story Point ve Planning Poker kullanılır. Ortak anlayış güçlenir. Takım kendi ölçeğini oluşturur. Saat dönüşümü yapılmaz. Velocity yalnızca team-level forecast'e destek olur.

Seviye 4: Historical Data Supported Estimation

Reference story ve gerçek cycle time kullanılır. Estimate vs Actual analizi yapılır. Throughput ölçülür. Sistematik bias bulunur. Kalibrasyon veriyle desteklenir.

Seviye 5: Probabilistic Forecasting

Monte Carlo ve confidence seviyeleri kullanılır. Tek tarih yerine range sunulur. Risk commitment'a bağlanır. Scope trendi izlenir. Yönetim olasılıkla karar verir.

Seviye 6: Continuous Forecasting ve Outcome-Based Planning

Forecast her yeni veriyle güncellenir. Estimation ceremony minimuma iner. Akış verisi otomatik toplanır. Outcome roadmap kararının merkezine gelir. Tahmin yalnızca gerektiği kadar yapılır.

Seviye 1: Yönetici Tahmini

Bu seviyede tarih çoğu zaman teknik değerlendirmeden önce oluşur. Ekipten beklenen, verilen tarihi doğrulayacak estimate üretmektir. Scope seçenekleri veya confidence seviyesi fazla konuşulmaz. Bunun sonucu yüksek tahmin sapması ve düşük güven olabilir. İlk dönüşüm adımı target date ile estimate kavramını ayırmaktır.

Tarihin Yukarıdan Verilmesi

İş hedefi olarak tarih belirlenebilir. Problem bunun teknik gerçek gibi sunulmasıdır. Target Date alanı ayrı tutulmalıdır. Ekip feasibility analizi yapar. Scope seçenekleri sunar.

Teknik Ekibin Sonradan Doğrulaması Beklenmesi

Ekip özgür tahmin yapamaz. Sayı hedefe doğru çekilir. Riskler saklanabilir. Historical data bozulur. Bağımsız estimate süreci kurulmalıdır.

Yüksek Tahmin Sapması

Plan gerçek teknik bilgiye dayanmaz. Scope değişikliği görünmez olabilir. Capacity aşırı planlanır. Tarihler sık kaçar. Kök neden bireysel performans değildir.

Düşük Güven

Ekip verdiği sayının gerçekten kendisine ait olmadığını düşünür. Yönetim de tahmine güvenmez. Padding ve pazarlık oluşur. Terminoloji ayrımı güveni artırır. Blameless review gerekir.

Seviye 2: Saat Bazlı Takım Tahmini

Bu seviyede teknik ekip daha fazla söz sahibidir ancak planning ayrıntısı yüksektir. Task Hours ve Bottom-Up Estimation bütün işlerin saat olarak parçalanmasına dayanabilir. Yakın dönem için faydalı olsa da uzak roadmap'te yüksek estimation maliyeti yaratır. Ayrıca 237 saat gibi sonuçlar gereğinden fazla kesinlik izlenimi verebilir. Bir sonraki olgunluk adımı relative estimation ve risk görünürlüğüdür.

Task Hours

Task saat tahmini günlük planlamada kullanılabilir. Her iş için zorunlu olmamalıdır. Bireysel performansa bağlanmamalıdır. Gerçek kapasiteyle birlikte değerlendirilir. Uzak backlog için uygun değildir.

Bottom-Up Estimation

Büyük iş küçük task'lara bölünür. Her task tahmin edilir ve toplam alınır. Yakın scope netse faydalıdır. Bilinmeyenler toplamdan kaybolabilir. Risk reserve ayrıca eklenmelidir.

Yüksek Estimation Maliyeti

Yüzlerce task'ı tahminlemek saatler sürebilir. Scope değişirse tekrar gerekir. Meeting cost ölçülmelidir. Yakın dönem dışında kaba yöntem kullanılabilir. Just-in-Time yaklaşım daha ekonomiktir.

False Precision

Toplamın çok ayrıntılı çıkması doğruluğu garanti etmez. Her küçük estimate zaten belirsizdir. Toplam 286 saat gibi görünür. Yönetim bunu kesin plan sanabilir. Range daha sağlıklı olabilir.

Seviye 3: Relative Estimation

Relative Estimation seviyesinde ekip saat hesabından işlerin birbirine göre büyüklüğüne geçer. Story Point ve Planning Poker ortak anlayışı güçlendirir. Aynı zamanda sayısal hassasiyet baskısını azaltır. Team-Level Forecast geçmiş velocity ile desteklenebilir. Bu seviyedeki temel risk, point'in sonradan yeniden saat ve performans birimine dönüştürülmesidir.

Story Point

Göreceli iş büyüklüğünü gösterir. Saat değildir. Takıma özgüdür. Performans için kullanılmaz. Reference story ile kalibre edilir.

Planning Poker

Bağımsız oy anchoring'i azaltır. Farklı görüşler tartışılır. Ortak anlayış artar. Timebox kullanılmalıdır. Her küçük iş için zorunlu değildir.

Shared Understanding

Tahmin sürecinin en büyük değeri olabilir. Product, QA ve developer aynı scope'u konuşur. Riskler erken görünür. Acceptance netleşir. Rework azalabilir.

Team-Level Forecast

Velocity veya backlog size takım içinde kullanılabilir. Takım stabilse daha anlamlıdır. Tatil ve capacity etkisi eklenir. Tek sprint verisine güvenilmez. Takımlar arası kıyas yapılmaz.

Seviye 4: Tarihsel Veri Destekli Estimation

Bu seviyede ekip yalnızca tahmin üretmez, geçmiş gerçekleşmelerden sistematik biçimde öğrenir. Reference Stories, Cycle Time, Throughput ve Estimate vs Actual verileri birlikte kullanılır. Tahmin kalibrasyonu kişisel hafızadan kurumsal veri setine taşınır. Outlier nedenleri ve scope change kayıt altına alınır. Böylece benzer işler için daha güçlü forecast üretilebilir.

Reference Stories

Tamamlanmış işlerden örnek set oluşturulur. Küçük, orta ve büyük story seçilir. Yeni işler bunlarla karşılaştırılır. Gerçek cycle time da saklanır. Ölçek zamanla kalibre edilir.

Cycle Time

Gerçek akış performansını gösterir. Percentile değerleri çıkarılır. SLE oluşturulabilir. Story Point dışı forecast mümkün olur. WIP etkisi incelenir.

Throughput

Tamamlanan item sayısı izlenir. Haftalık dağılım kullanılır. Monte Carlo için temel olur. İş türleri ayrılabilir. Kalan scope forecast edilir.

Estimate vs Actual

Tahmin ve gerçekleşen karşılaştırılır. Scope change ayrı tutulur. Bias bulunur. Kişi değil sistem analiz edilir. Reference data güncellenir.

Kalibrasyon

Model geçmiş sonuçlarla ayarlanır. Confidence hit rate ölçülür. Aşırı iyimserlik veya geniş range görülür. Yöntem buna göre güncellenir. Forecast zamanla daha güvenilir olur.

Seviye 5: Probabilistic Forecasting

Probabilistic Forecasting seviyesinde kurum tek teslim tarihi yerine farklı confidence seviyeleriyle konuşmaya başlar. Monte Carlo Simulation tarihsel throughput veya cycle time verisini kullanır. Range Forecasts iş riskine göre commitment seçilmesini sağlar. Kritik proje ile düşük riskli internal feature aynı confidence hedefini kullanmak zorunda değildir. Tahmin doğrudan risk tabanlı karar mekanizmasına dönüşür.

Monte Carlo

Binlerce senaryo üretir. Geçmiş dağılımı kullanır. Kalan scope ile birleştirir. Tarih veya kapasite forecast'i çıkarır. Kesinlik değil olasılık sunar.

Confidence Levels

Yüzde 50, 85 veya 95 farklı risk seviyeleridir. Yönetim kararı destekler. Daha yüksek confidence daha geç tarih getirebilir. Kritik işe göre seçilir. Tek standart gerekmeyebilir.

Range Forecasts

Tek tarih yerine olası aralık sunar. Belirsizliği açıkça gösterir. Scope değişirse güncellenir. Stakeholder beklentisi daha sağlıklı yönetilir. Sahte hassasiyet azalır.

Risk-Based Commitments

Commitment teknik estimate'ten ayrı verilir. Yönetim risk toleransını seçer. Scope, buffer ve confidence birlikte değerlendirilir. Kritik riskler mitigation planına bağlanır. Ticari karar bilinçli hale gelir.

Seviye 6: Continuous Forecasting

Continuous Forecasting, forecast'i dönemsel proje dokümanı olmaktan çıkarıp yaşayan yönetim bilgisine dönüştürür. Scope, throughput, capacity ve risk değiştikçe sonuç otomatik veya düzenli olarak yeniden hesaplanır. Estimation ceremony giderek azalır çünkü tarihsel akış verisi daha fazla kullanılır. Yönetim olasılıklarla karar verir. Outcome, yalnızca estimate accuracy'den daha önemli hale gelir.

Forecast Her Yeni Veriyle Güncellenir

Yeni tamamlanan işler modele eklenir. Kalan scope azalır veya değişir. Risk gerçekleşebilir. Confidence yeniden hesaplanır. Eski forecast geçmiş olarak saklanır.

Scope Sürekli Görünürdür

Burn-up güncel kapsamı gösterir. Yeni talepler saklanmaz. Forecast değişikliği açıklanabilir. Product trade-off yapar. Yönetim scope creep'i erken görür.

Yönetim Olasılıklarla Karar Verir

Tek tarih yerine confidence seçilir. Risk toleransı açık hale gelir. Critical deadline için daha yüksek seviye kullanılır. Internal hedefte daha düşük olabilir. Karar ekonomik bağlama oturur.

Estimation Ceremony Minimuma İner

Rutin küçük işler akış verisiyle yönetilir. Point toplantısı sadece gerektiğinde yapılır. Büyük belirsizlik discovery'ye yönlendirilir. Meeting cost düşer. Delivery kapasitesi artar.

Outcome Estimation'dan Daha Önemli Hale Gelir

Asıl soru kaç point tamamlandığı değildir. Kullanıcı ve iş sonucu ölçülür. Estimation yatırım kararını destekler. Değer üretmeyen feature hızlı bitti diye başarı sayılmaz. Ürün yönetimi outcome'a odaklanır.

Kurumda Estimation Dönüşümü İçin İlk 30 Gün

İlk 30 günde yeni araç veya yöntem dayatmak yerine mevcut sistem haritalanmalıdır. Estimate'in hangi noktada commitment'a dönüştüğü, Story Point'in nerelerde kullanıldığı ve yönetim raporlarının hangi davranışı teşvik ettiği incelenmelidir. Historical Data kalitesi ölçülmelidir. Estimation Meeting Cost kişi-saat olarak hesaplanabilir. Bu dönem teşhis dönemidir ve dönüşüm hedefi gerçek probleme göre seçilir.

Mevcut Tahmin Sürecini Haritalamak

Talep nerede açılıyor incelenir. Kim estimate veriyor belirlenir. Tarih hangi toplantıda commitment oluyor görülür. Tool alanları kontrol edilir. Süreç haritası ortaklaştırılır.

Estimate'in Nerede Commitment'a Dönüştüğünü Bulmak

Teknik sayı satış teklifine nasıl gidiyor incelenir. Hangi onayın eksik olduğu görülür. Terminoloji karışıklığı belirlenir. Riskli geçiş noktaları işaretlenir. Yeni governance buna göre kurulur.

Story Point Kullanımını İncelemek

Point planning için mi performans için mi kullanılıyor bakılır. Takımlar arası kıyas varsa kaydedilir. Saat dönüşüm tablosu kontrol edilir. Ekip davranışı dinlenir. Yanlış kullanım öncelikli iyileştirme olur.

Yönetim Raporlarını İncelemek

Dashboard hangi metric'i ödüllendiriyor görülür. Velocity hedefi var mı kontrol edilir. Scope growth görünür mü bakılır. Confidence sunuluyor mu değerlendirilir. Raporlama davranış tasarlar.

Historical Data Kalitesini Ölçmek

Started ve Done tarihleri güvenilir mi kontrol edilir. Ticket güncelleme oranı incelenir. Scope change kaydı var mı bakılır. Büyük workflow değişiklikleri bulunur. Forecast için uygun data seti seçilir.

Estimation Meeting Cost Hesaplamak

Katılımcı sayısı ve süre toplanır. Aylık kişi-saat bulunur. Re-estimation maliyeti eklenir. Hiç yapılmayan backlog işlerine harcanan süre incelenir. Potansiyel tasarruf görünür olur.

31–60 Günlük Plan

İkinci aşamada ortak terminoloji ve temel ölçüm sistemi kurulabilir. Estimate, Forecast ve Commitment kavramları standardize edilir. Team Estimation Policy hazırlanır ve Story Point'in performans amacıyla kullanımı kaldırılır. Cycle Time ve Throughput veri toplama süreci iyileştirilir. Risk ve Confidence alanları eklenerek küçük bir pilot takım seçilir.

Estimate–Forecast–Commitment Terminolojisini Standardize Etmek

Her kavram kısa tanımla açıklanır. Tool alanları ayrılır. Eğitim yapılır. Satış ve yönetim aynı dili kullanır. Yanlış aktarım azalır.

Team Estimation Policy

Story seviyesinde yöntem belirlenir. Kimlerin katılacağı yazılır. Uzak backlog politikası tanımlanır. Re-estimate koşulları belirlenir. Team autonomy korunur.

Story Point Performance Kullanımını Kaldırmak

Takım karşılaştırma raporu kapatılır. Bireysel point KPI silinir. Yönetim flow metric eğitimine alınır. Ekip güveni desteklenir. Point tekrar planning aracına dönüşür.

Cycle Time ve Throughput Toplamak

Workflow tarihleri düzeltilir. Work Type eklenebilir. Otomatik rapor oluşturulur. Percentile değerleri hesaplanır. İlk baseline çıkarılır.

Risk ve Confidence Alanları Eklemek

Forecast yalnızca tarihten oluşmaz. Ana riskler kaydedilir. Confidence seviyesi gösterilir. Scope varsayımı eklenir. Yönetim daha zengin bilgi görür.

Pilot Takım Seçmek

Stabil ve veri kalitesi yeterli takım seçilebilir. Dönüşüm küçük ölçekte denenir. Mevcut ve yeni model karşılaştırılır. Öğrenilen ders kaydedilir. Sonra yaygınlaştırma yapılır.

61–90 Günlük Plan

Üçüncü aşamada Probabilistic Forecast pilotu uygulanabilir. Monte Carlo denemesi gerçek throughput verisiyle yapılır ve Roadmap Forecast confidence seviyeleriyle sunulur. Yönetim Dashboard'u scope, risk ve flow verisini içerecek şekilde güncellenir. Estimation Retrospective düzenli hale gelir. Eski ve yeni modelin toplantı maliyeti, forecast reliability ve karar kalitesi karşılaştırılır.

Probabilistic Forecast Pilot

Pilot takımın geçmiş verisi seçilir. Kalan scope belirlenir. Confidence seviyeleri hesaplanır. Yönetimle yorumlama oturumu yapılır. Tek tarih kültürü kademeli değişir.

Monte Carlo Denemesi

Throughput veri seti temizlenir. Binlerce senaryo çalıştırılır. When ve How Many örnekleri hazırlanır. Sonuç eski velocity forecast'iyle karşılaştırılır. Farklar tartışılır.

Roadmap Forecast

Epic'ler farklı confidence ile gösterilir. Yakın dönem daha dar aralık kullanır. Uzak dönem kaba kalır. Scope trendi eklenir. Yönetim düzenli güncelleme alır.

Yönetim Dashboard'u

Velocity ranking kaldırılır. Delivery Forecast eklenir. Throughput, cycle time ve blocked work gösterilir. Top risk ve decision needed alanı bulunur. Dashboard karar odaklı hale gelir.

Estimation Retrospective

Pilot sonuçları düzenli incelenir. Forecast neden değişti sorulur. Data quality problemi bulunur. Reference set güncellenir. Süreç kalibre edilir.

Eski ve Yeni Modeli Karşılaştırmak

Meeting time karşılaştırılır. Confidence hit rate ölçülür. Stakeholder memnuniyeti alınabilir. Scope change görünürlüğü incelenir. Yaygınlaştırma kararı verilir.

Estimation'da Sık Yapılan Hatalar

Story Point'i saate çevirmek, point'i performans ölçüsü yapmak, takımların velocity değerlerini karşılaştırmak ve yöneticinin estimate rakamını önceden söylemesi en yaygın hatalardandır. Scope belirsizken kesin tarih vermek ve uzak backlog'u ayrıntılı tahminlemek de büyük maliyet yaratır. Plansız iş için kapasite ayırmamak planı sürekli bozar. Test ve release eforunun unutulması development estimate ile gerçek teslim süresini birbirinden koparır. En zararlı hata ise tahmin sapmasını doğrudan developer'a yüklemektir.

Story Point'i Saate Çevirmek

Point relative size'dır. Sabit saat katsayısı kullanmak anlamını bozar. Takım saat düşünmeye geri döner. Finans ihtiyacı ayrı forecast ile çözülmelidir. Point yerel ölçü olarak kalmalıdır.

Story Point'i Performans Ölçüsü Yapmak

Point hedef olduğunda şişirilir. İşbirliği zarar görür. Takımlar arası yarış oluşur. Gerçek değer görünmez. Bu kullanım policy ile yasaklanmalıdır.

Takımlar Arası Velocity Karşılaştırmak

Ölçekler farklıdır. Definition of Done aynı olmayabilir. İş türü farklıdır. Sonuç yanıltıcıdır. Flow ve outcome metriğine geçilmelidir.

Yöneticinin Estimate Söylemesi

İlk sayı anchor olur. Ekip bağımsız düşünemez. Target Date estimate gibi algılanır. Yönetici hedefi ayrı söylemelidir. Teknik ekip kendi değerlendirmesini yapmalıdır.

Scope Belirsizken Kesin Tarih Vermek

Belirsizlik dar tarih ile ortadan kalkmaz. Range kullanılmalıdır. Discovery yapılabilir. Confidence düşük gösterilmelidir. Yeni bilgi geldikçe güncellenmelidir.

Uzak Backlog'u Detaylı Tahminlemek

Scope değişme ihtimali yüksektir. Estimation debt oluşur. T-Shirt veya coarse range yeterlidir. Yakınlaştıkça refinement yapılır. Meeting cost azalır.

Plansız İş İçin Kapasite Ayırmamak

Incident ve support her dönem ortaya çıkabilir. Tarihsel demand ölçülmelidir. Buffer ayrılır. Feature planı kalan kapasiteye göre yapılır. Sprint daha gerçekçi olur.

Test ve Release Eforunu Unutmak

Development done teslim anlamına gelmez. QA, security ve deployment süresi eklenmelidir. Waiting time ayrıca izlenir. Definition of Done geniş tutulur. Forecast gerçek delivery'yi temsil eder.

Tahmin Hatasını Developer'a Yüklemek

Bu davranış risk saklamayı teşvik eder. Padding artar. Psychological safety azalır. Sistem analizi yapılmalıdır. Öğrenilen ders reference data'ya eklenmelidir.

Estimate'i Commitment Gibi Kullanmak

Estimate teknik değerlendirmedir. Commitment iş kararıdır. Aradaki risk seçimi yönetim tarafından yapılır. Tool alanları ayrılır. Terminoloji eğitimle korunur.

Kurumsal Estimation Anti-Pattern'leri

Anti-pattern'ler genellikle iyi niyetli yönetim ihtiyacının yanlış soruya dönüşmesiyle oluşur. “Bu iş kaç saat?”, “bir point kaç saat?” veya “geçen sprint 30 yaptınız, şimdi 35 yapın” gibi sorular ölçümün amacını bozar. “Tarihi zaten verdik, estimate'i ona göre yapın” ifadesi ise tahmini tamamen ortadan kaldırır. Kurum bu cümleleri yasaklamak yerine altında yatan gerçek iş ihtiyacını doğru soruya dönüştürmelidir. Böylece estimation yeniden karar destek aracı olur.

“Bu İş Kaç Saat?”

Bazen saat gerçekten gerekir. Ancak iş belirsizse önce scope ve risk konuşulmalıdır. Saat tek başına teslim tarihini göstermez. Waiting time ayrıca vardır. Doğru seviyede estimate seçilmelidir.

“1 Point Kaç Saat?”

Sabit cevap yoktur. Point saat değildir. Aynı point farklı kişilerde farklı süre alabilir. Takım relative scale kullanır. Saat ihtiyacı başka modelle karşılanır.

“Geçen Sprint 30 Point Yaptınız, Bu Sprint 35 Yapın”

Velocity hedef değildir. Sprint kapasitesi değişebilir. Daha yüksek point daha fazla değer anlamına gelmez. Bu talep point inflation yaratır. Sprint goal ve outcome konuşulmalıdır.

“Diğer Takım Sizden Daha Fazla Point Yapıyor”

Takımların ölçeği farklıdır. Karşılaştırma anlamsızdır. İnsanlar sayı büyütmeye yönelir. İşbirliği zarar görür. Program flow metriği kullanılmalıdır.

“Tahmini 10 Gün Verdiniz ama 5 Günde Yapmanız Gerekiyor”

Beş gün hedef olabilir. Estimate'i beşe düşürmek teknik gerçeği değiştirmez. Scope azaltılabilir. Risk kabul edilebilir. Commitment ayrı karar olmalıdır.

“Tarihi Zaten Verdik, Estimate'i Ona Göre Yapın”

Bu artık estimation değildir. Feasibility analizi yapılmalıdır. Hangi scope'un tarihe sığdığı incelenir. Confidence hesaplanır. Risk seçenekleri yönetimle paylaşılır.

“Buffer Eklemeyin”

Gizli padding ile açık buffer ayrılmalıdır. Risk gerçektir. Buffer kaldırmak riski kaldırmaz. Tarihsel veriye dayalı reserve açıklanmalıdır. Yönetim riski bilinçli kabul edebilir.

“Risk Olursa Sonra Bakarız”

Bu yaklaşım gecikmiş karar yaratır. Yüksek risk erken ele alınmalıdır. Mitigation daha ucuz olabilir. Deadline yaklaşmadan scope seçeneği hazırlanır. Risk yönetimi estimation'ın parçasıdır.

Daha Sağlıklı Kurumsal Sorular

Estimation kültürü kullanılan sorularla değişebilir. “Kaç gün?” yerine “bu iş ne kadar belirsiz?”, “benzer işler geçmişte ne kadar sürdü?” veya “yüzde 85 güven için hangi tarihi söylemeliyiz?” soruları daha iyi bilgi üretir. Dependency ve scope trade-off konuşmaları gerçek teslimat riskini görünür hale getirir. “Daha küçük nasıl teslim edebiliriz?” sorusu ise tahmin kalitesi kadar flow'u da iyileştirir. Sağlıklı soru ekip üzerinde baskı kurmaz, karar seçeneği üretir.

Bu İş Ne Kadar Belirsiz?

Belirsizlik estimate hassasiyetini belirler. Yüksekse range geniş olmalıdır. Spike yapılabilir. Confidence düşürülebilir. Yönetim riski erken görür.

Benzer İşler Daha Önce Ne Kadar Sürdü?

Reference Class yaklaşımı devreye girer. Gerçek geçmiş kullanılır. Optimism bias azalır. Benzerlik farkları not edilir. Forecast daha veriye dayalı olur.

Hangi Scope ile Tarihe Ulaşabiliriz?

Fixed-Date durumda doğru soru budur. Must scope belirlenir. Could işler ayrılır. How Many forecast kullanılabilir. Product bilinçli trade-off yapar.

%85 Güven İçin Hangi Tarihi Söylemeliyiz?

Risk seviyesi açık hale gelir. Monte Carlo kullanılabilir. Tek tarih artık garanti gibi sunulmaz. Yönetim daha erken yüzde 50 tarihi de görebilir. Commitment bilinçli seçilir.

Forecast'i Değiştirecek En Büyük Risk Nedir?

Top risk odağı sağlar. Risk azaltılırsa tarih daralabilir. Mitigation planı oluşturulur. Management yatırım kararı verebilir. Risk dashboard'da izlenir.

Hangi Bağımlılık En Fazla Bekleme Yaratıyor?

Blocked time verisi kullanılır. En büyük dependency bulunur. Organizasyonel iyileştirme yapılabilir. Developer hızını artırmak yerine darboğaz çözülür. Lead time düşer.

Daha Küçük Nasıl Teslim Edebiliriz?

Vertical slicing düşünülür. Minimum Valuable Increment bulunur. Feedback hızlanır. Forecast ufku kısalır. Büyük risk küçük batch'lere bölünür.

Örnek Kurumsal Estimation Karar Ağacı

Karar ağacının ilk sorusu “estimate gerçekten gerekli mi?” olmalıdır. Küçük ve benzer işler Story Counting veya Historical Data ile ilerleyebilir. Belirsiz işte Spike veya Three-Point, büyük backlog'da T-Shirt, Affinity veya Bucket daha uygun olabilir. Kesin takvim sorusu Probabilistic Forecast gerektirirken Fixed-Price teklif için Discovery, Range ve Risk Reserve birlikte düşünülmelidir. Bu yapı tek yöntemin her probleme uygulanmasını önler.

Karar İçin Estimate Gerçekten Gerekli mi?

Tahmin sonucunda hangi karar değişecek belirlenir. Hiçbir şey değişmeyecekse kaba değerlendirme yeterli olabilir. Meeting cost düşünülür. Ekip gereksiz ceremony'den kaçınır. Karar değeri merkezde kalır.

İşin Boyutu Küçük mü?

Küçük ve rutin işte ayrıntılı Planning Poker gerekmeyebilir. Historical flow yeterli olabilir. Story Counting kullanılabilir. Cycle time SLE referans olur. Hızlı karar alınır.

Story Counting / Historical Data

Benzer item'lar adet üzerinden forecast edilir. Throughput geçmişi kullanılır. Point toplantısı azalır. Büyük item'lar ayrı tutulur. Data quality önemlidir.

İş Belirsiz mi?

Yüksek bilinmeyen varsa point büyütmek çözüm değildir. Önce bilgi üretilmelidir. Spike veya PoC kullanılabilir. Three-Point range sağlayabilir. Sonra estimate güncellenir.

Spike / Three-Point

Spike teknik soruya cevap verir. Three-Point farklı senaryoları görünür yapar. O, M ve P değerleri paylaşılır. Riskler erken konuşulur. Confidence daha gerçekçi olur.

Büyük Backlog mu?

Yüzlerce item detaylı tahmin edilmemelidir. Kaba sınıflandırma yapılır. Yakın dönem ayrıca refinement alır. Estimation debt azalır. Roadmap hızlı oluşturulur.

T-Shirt / Affinity / Bucket

Bu yöntemler toplu boyutlandırma sağlar. Büyük item'lar görünür olur. Tartışma sadece sıra dışı işlerde yapılır. Meeting cost düşer. Karar için yeterli bilgi üretilir.

Kesin Takvim Sorusu mu?

Takvim sorusu Story Point'i saate çevirerek cevaplanmamalıdır. Historical throughput kullanılabilir. Scope netleştirilir. Olasılık seviyesi seçilir. Yönetim risk bilgisi alır.

Probabilistic Forecast

Monte Carlo veya benzer dağılım yaklaşımı kullanılabilir. Tek tarih yerine confidence üretir. When ve How Many soruları cevaplanır. Yeni veri geldikçe güncellenir. Commitment kararını destekler.

Fixed-Price Teklif mi?

Belirsizlik doğrudan ticari risktir. Discovery gereklidir. Scope varsayımları yazılır. Risk reserve hesaplanır. Acceptance kriterleri netleştirilir.

Discovery + Range + Risk Reserve

Discovery bilinmeyeni azaltır. Range kalan belirsizliği gösterir. Risk Reserve ticari koruma sağlar. Change Request mekanizması kurulur. Tek iyimser sayı üzerinden fiyat verilmez.

Estimation Toplantısı İçin Örnek Kontrol Listesi

İyi estimation toplantısı uzun olmak zorunda değildir. Amaç açık mı, user story anlaşılıyor mu, acceptance criteria var mı ve Definition of Done dahil mi soruları ilk kontrolü sağlar. Bağımlılıklar ve riskler bilinmiyorsa sayı vermeden önce bunları konuşmak gerekir. İş gereğinden büyükse parçalanmalıdır. Geçmişte benzer iş olup olmadığı ve tahmin sonucunun hangi kararı değiştireceği de kontrol edilmelidir.

Amaç Açık mı?

Tahmin neden yapılıyor bilinmelidir. Sprint planning ile satış teklifi aynı değildir. Kullanıcı beklentisi belirlenir. Hassasiyet buna göre seçilir. Gereksiz iş azaltılır.

User Story Anlaşılıyor mu?

Takım aynı problemi anlıyor mu kontrol edilir. Farklı yorumlar varsa önce scope netleştirilir. Product soruları cevaplar. Teknik çözüm zorla belirlenmez. Ortak anlayış sağlanır.

Acceptance Criteria Var mı?

Ana kabul koşulları bulunmalıdır. Test senaryoları anlaşılır olmalıdır. Eksik kriter sonradan scope growth yaratır. QA katkı verir. Estimate daha güvenilir olur.

Definition of Done Dahil mi?

Test, review ve deployment unutulmamalıdır. Yalnızca coding tahmini verilmemelidir. Security ve documentation gerekiyorsa eklenir. Done gerçek teslimi temsil eder. Efor tamamı kapsar.

Bağımlılıklar Biliniyor mu?

Başka takım ve vendor kontrol edilir. API hazır mı sorulur. Veri ve environment ihtiyaçları belirlenir. Waiting time riski görünür olur. Kritik blocker erken çözülür.

Riskler Biliniyor mu?

Teknik ve organizasyonel risk listelenir. Yüksek risk için mitigation konuşulur. Confidence seviyesi etkilenir. Three-Point kullanılabilir. Risk point içine tamamen gizlenmez.

İş Gereğinden Büyük mü?

Çok büyük story estimation için zayıftır. Vertical slicing yapılabilir. Spike ayrılabilir. Minimum değerli parça bulunur. Cycle time kısalır.

Geçmişte Benzer İş Var mı?

Reference story aranır. Gerçek cycle time incelenir. Benzer riskler kontrol edilir. Kişisel hafıza veriyle desteklenir. Forecast kalibre edilir.

Tahmin Sonucu Hangi Kararı Değiştirecek?

Sonuç scope, tarih veya bütçeyi etkiliyor mu sorulur. Hiçbir karar yoksa ayrıntılı estimate gereksiz olabilir. Meeting cost düşünülür. Daha kaba yöntem seçilir. Estimation amaç değil araç olarak kalır.

Yöneticiye Forecast Sunum Şablonu

Yönetici sunumu teknik backlog dökümü olmamalıdır. Scope, Current Forecast, Confidence, Assumptions, Top Risks, Scope Change, Historical Throughput, Decision Needed ve Next Forecast Date gibi başlıklar çoğu karar için yeterlidir. Böyle bir şablon yöneticiye yalnızca “yeşil veya kırmızı” durum değil, neden ve seçenek gösterir. Forecast'in değişebileceği baştan kabul edilir. Bu yaklaşım sürpriz yönetimini azaltır.

Scope

Forecast'in hangi kapsam için geçerli olduğu yazılır. Must ve opsiyonel kapsam ayrılabilir. Toplam item sayısı gösterilebilir. Scope growth görünür tutulur. Tarih bağlamı netleşir.

Current Forecast

Güncel tarih veya aralık sunulur. Eski forecast ile fark varsa gösterilir. Tek tarih gerekiyorsa confidence belirtilir. Scope değişimiyle ilişkilendirilir. Yönetim güncel veriyi görür.

Confidence

Yüzde veya nitel seviye kullanılabilir. Confidence'ın ne anlama geldiği açıklanır. Kritik tarih daha yüksek seviye isteyebilir. Risk toleransı görünür olur. Yanlış garanti algısı azalır.

Assumptions

Forecast'in geçerli olduğu koşullar listelenir. Vendor teslimi veya scope stabilitesi buna örnektir. Varsayım değişirse güncelleme yapılır. Yönetim riskin kaynağını görür. İletişim şeffaflaşır.

Top Risks

Yalnızca en önemli birkaç risk gösterilir. Etki ve mitigation yazılır. Owner belirlenebilir. Tarihi değiştirecek riskler öne çıkar. Yönetim aksiyon alabilir.

Scope Change

Son forecast'ten beri eklenen veya çıkarılan iş gösterilir. Tarih değişikliği açıklanır. Product trade-off görünür olur. Burn-up referans olabilir. Ekip gereksiz suçlanmaz.

Historical Throughput

Son haftaların dağılımı özetlenir. Tek ortalama yerine trend gösterilebilir. Büyük değişiklik varsa açıklanır. Forecast'in veri temeli anlaşılır. Confidence daha anlamlı olur.

Decision Needed

Sunumun en değerli alanlarından biridir. Yönetimin neye karar vermesi gerektiği açıkça yazılır. Scope azaltma veya risk kabulü olabilir. Karar tarihi belirtilir. Dashboard pasif rapor olmaktan çıkar.

Next Forecast Date

Bir sonraki güncelleme zamanı belirtilir. Discovery sonrası veya sprint sonunda olabilir. Stakeholder ne zaman yeni bilgi alacağını bilir. Sürekli iletişim sağlanır. Sürpriz azalır.

Sık Sorulan Sorular

Efor tahminleme konusunda en çok sorulan sorular genellikle Story Point, saat dönüşümü, Planning Poker, kapasite ve probabilistic forecasting etrafında toplanır. Aşağıdaki kısa cevaplar kavramların birbirine karışmasını önlemeyi amaçlar. Tek bir tekniğin bütün proje tiplerinde en iyi sonucu vermediğini unutmamak gerekir. Takımın olgunluğu, tarihsel veri kalitesi ve işin belirsizlik seviyesi yöntemi belirler. Kurumsal planlama açısından asıl hedef tahmini tutturmak değil, karar riskini azaltmaktır.

Efor tahmini nedir?

Efor tahmini bir işi tamamlamak için gereken çalışma büyüklüğünün mevcut bilgi üzerinden değerlendirilmesidir. Saat, kişi-gün veya relative size biçiminde olabilir. Kesin söz değildir. Yeni bilgi geldikçe değişebilir. Amaç plan ve karar desteğidir.

Yazılım efor tahmini nasıl yapılır?

Önce scope ve Definition of Done netleştirilir. Risk ve dependency belirlenir. İşin seviyesine uygun yöntem seçilir. Geçmiş veri varsa kullanılır. Tahmin confidence ve varsayımlarla birlikte sunulur.

Story Point nedir?

Story Point göreceli iş büyüklüğü ölçüsüdür. Saat değildir. Efor, risk ve belirsizliği birlikte temsil edebilir. Takıma özgüdür. Performans puanı değildir.

1 Story Point kaç saattir?

Sabit bir saat karşılığı yoktur. Story Point süre birimi değildir. Aynı point farklı kişilerde farklı saat alabilir. Takım yalnızca relative size için kullanır. Saat ihtiyacı ayrı forecast ile çözülmelidir.

Story Point saate çevrilmeli mi?

Genellikle çevrilmemelidir. Sabit dönüşüm relative estimation mantığını bozar. Finans veya satışın saat ihtiyacı gerçek kapasite ve historical data üzerinden hesaplanabilir. Point takım içinde kalır. Böylece her ölçü kendi amacını korur.

Planning Poker nedir?

Takım üyelerinin bağımsız tahmin verip sonuçları tartıştığı yöntemdir. Oylar gizli verilir. Aynı anda açılır. Farkların nedeni konuşulur. Değerin önemli bölümü ortak anlayıştan gelir.

Planning Poker nasıl yapılır?

Story açıklanır. Sorular ve varsayımlar netleştirilir. Katılımcılar gizli oy verir. En yüksek ve düşük görüş tartışılır. Gerekirse yeniden oylama yapılır.

Fibonacci neden kullanılır?

İş büyüdükçe belirsizliğin arttığını yansıtır. Büyük sayılarda aralık genişler. Gereksiz hassasiyeti azaltır. Dokuz mu on mu tartışmasını önler. Ekip bilinmeyene odaklanır.

T-Shirt Sizing nedir?

İşleri XS, S, M, L ve XL gibi kaba sınıflara ayırır. Roadmap ve büyük backlog için uygundur. Hızlıdır. Ayrıntılı saat tahmini gerektirmez. Yakınlaşan işler sonradan detaylandırılabilir.

Three-Point Estimation nedir?

Optimistic, Most Likely ve Pessimistic senaryolar kullanır. Tek sayı yerine belirsizlik aralığı üretir. Riskleri erken konuşturur. PERT ile ağırlıklı sonuç hesaplanabilir. Büyük ve belirsiz işler için faydalıdır.

Story Point ile saat arasındaki fark nedir?

Story Point relative size, saat ise absolute time tahminidir. Birbirine sabit katsayıyla çevrilemez. Point takım ölçeğine bağlıdır. Saat belirli çalışma süresi ifadesidir. İkisi farklı planlama sorularına cevap verir.

Estimate ile forecast arasındaki fark nedir?

Estimate işin büyüklüğü hakkında değerlendirmedir. Forecast ise mevcut veriyle gelecekteki sonuç ihtimalini hesaplar. Forecast throughput ve scope kullanabilir. Estimate tek story düzeyinde olabilir. İkisi birlikte kullanılabilir.

Estimate ile commitment arasındaki fark nedir?

Estimate teknik değerlendirmedir. Commitment kurumun üstlendiği taahhüttür. Commitment risk ve iş kararı içerir. Teknik estimate otomatik söz değildir. Bu ayrım açıkça yönetilmelidir.

Velocity nedir?

Velocity sprint başına tamamlanan Story Point miktarıdır. Takım içinde forecast yardımcısı olabilir. Performans puanı değildir. Takımlar arasında karşılaştırılmaz. Takım değişirse yeniden kalibre edilir.

Velocity performans ölçmek için kullanılabilir mi?

Kullanılmamalıdır. Hedef olduğunda point şişirme davranışı yaratabilir. İşbirliğini azaltabilir. Takımların ölçekleri farklıdır. Flow ve business outcome daha anlamlıdır.

Takımların Story Point'leri karşılaştırılabilir mi?

Doğrudan karşılaştırılamaz. Her takım kendi reference scale'ini oluşturur. Definition of Done farklı olabilir. Teknik borç ve iş türü değişebilir. Program seviyesi farklı metric kullanmalıdır.

Efor ile süre arasındaki fark nedir?

Efor aktif çalışma miktarıdır. Süre takvimde geçen zamandır. Bekleme, approval ve dependency duration'ı uzatabilir. Beş kişi-günlük iş beş günde bitmek zorunda değildir. Forecast ikisini ayrı ele almalıdır.

Kapasite nasıl hesaplanır?

Nominal kişi-günden izin, tatil, toplantı ve support yükü çıkarılır. Focus Factor geçmiş veriden kullanılabilir. Role-specific kapasite değerlendirilir. Plansız iş için buffer ayrılır. Gerçek kapasite sprint bazında değişebilir.

%100 kapasite planlamak doğru mudur?

Genellikle değildir. Incident ve beklenmeyen iş için alan kalmaz. WIP ve kuyruk büyüyebilir. Context switching artar. Capacity buffer flow dayanıklılığı sağlar.

Monte Carlo forecasting nedir?

Geçmiş throughput veya cycle time verisinden çok sayıda gelecek senaryosu üretir. Sonuç tarih dağılımıdır. Confidence percentile hesaplanır. Tek kesin tarih vermez. Kalan scope ile sürekli güncellenir.

Probabilistic forecasting nedir?

Geleceği olasılık seviyeleriyle ifade eden forecast yaklaşımıdır. Tarihsel dağılım kullanır. Yüzde 50, 85 veya 95 gibi seviyeler sunabilir. Yönetim risk toleransına göre karar verir. Continuous forecasting için uygundur.

#NoEstimates nedir?

Planlama yapmamak değildir. Gereksiz task-level estimation'ı azaltmayı savunur. Küçük işler ve historical flow kullanılır. Throughput ve cycle time öne çıkar. Olgun ekiplerde daha rahat uygulanabilir.

Tahmin yapmadan Scrum uygulanabilir mi?

Scrum mutlaka Story Point gerektirmez. Ekip Sprint Goal ve kapasiteyi farklı yöntemlerle planlayabilir. Story Counting kullanılabilir. Historical throughput destek olabilir. Önemli olan takımın yeterli planlama bilgisine sahip olmasıdır.

Fixed-price projelerde efor nasıl tahmin edilir?

Discovery yapılmalıdır. Kapsam varsayımları ve acceptance criteria yazılır. Range estimate ve risk reserve kullanılabilir. Change Request mekanizması tanımlanır. Ticari risk teknik belirsizlikle birlikte değerlendirilir.

AI ile Story Point tahmini yapılabilir mi?

AI öneri üretebilir. Geçmiş benzer story'leri bulabilir. Ancak takım bağlamını tamamen bilmeyebilir. Son karar ekipte kalmalıdır. AI ikinci görüş olarak daha güvenlidir.

Yazılımcı olmak için estimation bilmek gerekir mi?

Temel estimation bilgisi önemlidir. Developer scope, risk ve dependency konuşabilmelidir. İşi küçültme becerisi gerekir. Estimate ile commitment farkını bilmelidir. İleri matematik her geliştirici için şart değildir.

En iyi programlama dili efor tahminini etkiler mi?

Tek bir en iyi dil yoktur. Ekibin deneyimli olduğu teknoloji daha yüksek forecast confidence sağlayabilir. Yeni dil öğrenme süresi yaratır. Ekosistem ve tooling önemlidir. Teknoloji seçimi daha geniş teknik karardır.

Açık kaynak projelerde efor nasıl tahmin edilir?

Issue ve pull request geçmişi kullanılabilir. Contributor davranışı değerlendirilir. Cycle time ve throughput ölçülebilir. Gönüllü katkı nedeniyle bağlam farkı dikkate alınmalıdır. Büyük issue'lar küçük parçalara ayrılabilir.

Kurumsal yazılım projelerinde efor tahminleme yöntemleri nasıl uygulanır?

Kurumsal projelerde tek estimation yöntemini her seviyeye uygulamak yerine katmanlı yaklaşım kullanılmalıdır. Story seviyesinde Relative Estimation veya Planning Poker, roadmap seviyesinde T-Shirt Sizing, büyük belirsizliklerde Three-Point ve takvim sorularında Probabilistic Forecasting tercih edilebilir. Kapasite, risk, dependency ve scope change ayrıca görünür tutulmalıdır. Historical cycle time ve throughput oluştukça tahmin daha fazla veriyle desteklenmelidir. Bu yaklaşım, kurumsal yazılım projelerinde efor tahminleme ve planlama danışmanlığı çalışmalarında da temel değerlendirme çerçevesi olarak kullanılabilir.

Story Point, Planning Poker ve adam/gün tahminleme yöntemlerinden hangisi daha gerçekçi sonuç verir?

Hiçbiri her durumda diğerlerinden daha gerçekçi değildir çünkü farklı sorulara cevap verirler. Story Point göreceli büyüklüğü, Planning Poker ekip içi ortak anlayışı, adam/gün ise tahmini aktif çalışma miktarını ifade eder. Teslim tarihi soruluyorsa historical throughput veya cycle time üzerinden oluşturulan forecast çoğu durumda daha anlamlıdır. Fixed-price teklifte adam/gün ekonomik hesap için gerekebilir. En güçlü model, bu yöntemleri birbirine dönüştürmek yerine doğru karar seviyesinde birlikte kullanır.

Efor tahminlerinde gerçekleşen süre ile tahmin arasındaki fark neden oluşur?

Gerçekleşen süre ile tahmin arasındaki fark yalnızca “yanlış estimate” nedeniyle oluşmaz. Scope change, blocked time, dependency, approval, incident, teknik borç ve yeni öğrenilen gereksinimler süreyi değiştirebilir. Development effort doğru tahmin edilmiş olsa bile calendar duration çok daha uzun olabilir. Bu nedenle Estimated vs Actual analizi yapılırken scope ve waiting time ayrıca incelenmelidir. Blameless Estimation Retrospective farkın nedenini kurumsal öğrenmeye dönüştürür.

Yönetim baskısı, sabit teslim tarihleri ve değişen gereksinimler efor tahminlerini nasıl etkiler?

Yönetim baskısı estimate'i hedef tarihe doğru çekmeye başladığında teknik veri güvenilirliğini kaybeder. Sabit teslim tarihi varsa doğru yaklaşım estimate'i küçültmek değil, feasibility ve scope seçeneklerini değerlendirmektir. Değişen gereksinimler forecast'in de değişmesini doğal hale getirir. Scope burn-up ve confidence level bu değişimi görünür kılar. Yönetim Target Date, Estimate, Forecast ve Commitment kavramlarını ayrı tuttuğunda planlama daha sağlıklı çalışır.

Efor tahminleme ve proje yönetimi eğitimi yakınımda nerede bulabilirim?

Yazılım proje planlama ve efor tahminleme danışmanlığı yakınımda şeklinde araştırma yapan ekipler için topluluk etkinlikleri, açık kaynak çalışmalar ve uygulamalı atölyeler iyi bir başlangıç noktası olabilir. Diyarbakır'da yazılım ekosistemiyle ilgili çalışmalar, projeler ve topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Uygulamalı proje çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects sayfası değerlendirilebilir. Eğitim ararken yalnızca Story Point anlatan içerikler yerine flow metrics, capacity, dependency, Monte Carlo ve forecasting konularını birlikte işleyen programları tercih etmek faydalıdır. Gerçek proje verisiyle yapılan çalışma teorik anlatımdan daha kalıcı öğrenme sağlar.

Sonuç: Kurumsal Gerçeklikte Amaç Tahmini Tutturmak Değil, Daha İyi Karar Vermektir

Efor Tahminleme (Estimation) Yöntemlerinde Kurumsal Gerçeklik açısından en önemli değişim daha fazla estimation toplantısı yapmak değil, tahminin ne amaçla üretildiğini netleştirmektir. Story Point saat değildir, velocity performans puanı değildir ve estimate commitment anlamına gelmez. Efor ile takvim süresi ayrıldığında dependency ve waiting time görünür hale gelir. Geçmiş gerçekleşmeler, cycle time ve throughput kurumun kendi reference data'sını oluşturur. Tek tarih yerine risk ve confidence konuşulduğunda yönetim daha bilinçli karar verir.

Estimate Bir Söz Değildir

Estimate mevcut bilgiyle yapılan teknik değerlendirmedir. Commitment ayrı iş kararıdır. Scope ve risk değiştiğinde forecast güncellenebilir. Bu ayrım ekip üzerindeki gereksiz baskıyı azaltır. Tahmin daha güvenilir bilgi haline gelir.

Story Point Bir Saat Birimi Değildir

Story Point göreceli büyüklük göstergesidir. Sabit saat dönüşümü yapılmamalıdır. Finans ihtiyacı capacity forecast ile karşılanabilir. Team scale korunur. Planning Poker gerçek değerini sürdürür.

Velocity Bir Performans Puanı Değildir

Velocity yalnızca takım içi planning yardımcısıdır. Takımlar arasında karşılaştırılamaz. Bireysel hedef haline getirilmemelidir. Flow ve outcome daha güçlü yönetim verisidir. Point inflation riski önlenmelidir.

Efor ile Takvim Süresi Ayrılmalıdır

Effort aktif çalışma miktarıdır. Duration waiting time dahil takvim süresidir. Dependency ve approval süreleri ayrıca ölçülmelidir. Böylece tahmin sapmasının gerçek nedeni bulunur. Developer performansı yanlış yorumlanmaz.

Büyük ve Belirsiz İşler Küçültülmelidir

Büyük iş daha fazla bilinmeyen taşır. Vertical slicing tahmin aralığını daraltır. Küçük batch feedback'i hızlandırır. Cycle time düşebilir. Probabilistic forecast daha iyi veri kazanır.

Geçmiş Gerçekleşmeler Tahminlerden Daha Değerli Veri Sağlar

Gerçek cycle time ve throughput çalışma sisteminin davranışını gösterir. Reference Class Forecasting bu veriyi kullanır. Kişisel hafızaya bağımlılık azalır. Kurumsal dataset zamanla güçlenir. Yeni forecast daha iyi kalibre edilir.

Tek Tarih Yerine Risk ve Güven Seviyesi Konuşulmalıdır

Tek tarih bütün belirsizliği saklar. Confidence seviyesi risk toleransını görünür yapar. Yüzde 50 ve yüzde 85 tarih farklı kararlar sunar. Yönetim hangi risk seviyesini kabul ettiğini bilir. Commitment daha bilinçli olur.

Forecast Yeni Bilgi Geldikçe Güncellenmelidir

Scope, throughput ve risk zamanla değişir. Forecast'in değişmesi normaldir. Eski rakamı korumak yerine yeni veri kullanılmalıdır. Değişim nedeni stakeholder'a açıklanır. Continuous forecasting daha sağlıklı plan sağlar.

En Olgun Organizasyonlar Tahmini Cezalandırma Aracı Değil Karar Destek Sistemi Olarak Kullanır

Olgun organizasyon tahmin sapmasında kişiyi aramaz. Sistemin hangi bilgiyi göremediğini araştırır. Historical data ve flow metrics ile öğrenir. Estimation ceremony gerektiği kadar kullanılır. Daha iyi karar, daha dürüst risk iletişimi ve sürdürülebilir delivery temel hedef haline gelir.

Kurumsal Estimation Pratiğinizi Bir Sonraki Seviyeye Taşıyın

Efor tahminleme süreciniz sürekli tarih pazarlığına dönüşüyorsa, Story Point performans metriği olarak kullanılıyorsa veya ekip her sprint kapasitesinin üzerinde plan yapıyorsa sorun yalnızca kullanılan estimation tekniğinde olmayabilir. Sürecin estimate, forecast, commitment, capacity ve dependency katmanları birlikte değerlendirilmelidir. Diyarbakır Yazılım Topluluğu'nun yaklaşımı, çalışmaları ve topluluk yapısı hakkında daha fazla bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresini ziyaret edebilirsiniz. Flow ve darboğaz yönetimini estimation sürecinizle birlikte geliştirmek isterseniz https://www.diyarbakiryazilim.com.tr/posts/kanban-board-optimizasyonu-ve-darbogaz-bottleneck-analizi içeriği iyi bir sonraki adım olabilir.