Yazılım Mühendisliği

Scrum

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

Giriş

Öğrenme Kazanımları

Bu dersin sonunda:

  • Scrum’ın bir metodoloji değil çerçeve olduğunu, Agile ile farkını, üç direğini ve değerlerini açıklayabilecek,
  • Scrum Takımı’ndaki üç rolü ayırt edebilecek, Scrum Master’ın proje yöneticisinden farkını açıklayabilecek,
  • Ürün iş listesini, ürün hedefini ve backlog refinement’ı ilişkilendirebilecek,
  • Sprint hedefi ve kapasiteye göre örnek bir Sprint planı oluşturabilecek,
  • Daily Scrum, Definition of Done ve Increment’in Sprint içindeki rolünü açıklayabilecek,
  • Sprint Review ile Sprint Retrospective’i amaç ve katılımcılar açısından ayırt edebilecek,
  • Story point, T-shirt size ve ideal gün gibi efor ölçülerini karşılaştırıp Planning Poker ile tahmin yapabilecek.

Scrum’a Giriş

Scrum Nedir?

  • Scrum, karmaşık ürün geliştirme çalışmalarının yönetimi ve geliştirilmesi için kullanılan, çevik bir yaklaşım sunan popüler bir çerçevedir.
  • Esas amacı, ekiplerin değişen gereksinimlere hızlı bir şekilde adapte olmasını sağlarken, değer üretimini artırmak ve iş süreçlerini sürekli olarak iyileştirmektir.

Scrum

https://www.scrum.org/learning-series/what-is-scrum/

Scrum Bir Metodoloji Değildir

  • Scrum, adım adım nasıl yazılım geliştirileceğini söyleyen bir metodoloji değildir.
  • Bir çerçeve (framework) sunar.
  • Amaç:
    • Şeffaflığı sağlamak
    • Sürekli geri bildirim almak
    • Değişime hızlı uyum sağlamaktır

Not

Scrum, ekiplerin kendi süreçlerini keşfetmeleri ve iyileştirmeleri için bir iskelet sunar.

Scrum ve Agile Aynı Şey Değildir

  • Agile, bir değerler ve prensipler bütünüdür.
  • Scrum, Agile felsefeyi uygulamak için kullanılan yöntemlerden biridir.

Agile Manifesto özetle:

  • Bireyler ve etkileşimler
  • Çalışan yazılım
  • Müşteri ile iş birliği
  • Değişime yanıt verme

Uyarı

Scrum kullanmak, otomatik olarak Agile olmak anlamına gelmez.

Scrum’ın 3 Temel Direği (Empirical Process Control)

Scrum, ampirik süreç kontrolüne dayanır:

  • Şeffaflık (Transparency)
    Herkesin aynı gerçekliği görmesi

  • Gözlem (Inspection)
    Ürünün ve sürecin düzenli olarak değerlendirilmesi

  • Adaptasyon (Adaptation)
    Gerekli durumlarda hızlı değişiklik yapılması

Not

Scrum’da planlar değil, öğrenme ve uyum merkezde yer alır.

Scrum’ın 3 Temel Direği

Scrum Değerleri (Scrum Values)

Scrum’un doğru çalışabilmesi için ekiplerin şu 5 değeri benimsemesi gerekir:

  • Cesaret (Courage) – Zor kararlar alabilmek
  • Odak (Focus) – Sprint Goal’a odaklanmak
  • Taahhüt (Commitment) – Hedefe ulaşmak için sorumluluk almak
  • Saygı (Respect) – Takım üyelerine ve rollerine saygı duymak
  • Açıklık (Openness) – Sorunları ve ilerlemeyi açıkça paylaşmak

Uyarı

Bu değerler yoksa Scrum mekanikleşir ve Zombie Scrum ortaya çıkar.

Scrum Takımı (Scrum Team)

Scrum Rolleri

Scrum, belirli roller aracılığıyla iş birliğini ve süreçlerin etkin yönetimini sağlar. Scrum’da 3 temel rol vardır:

  • Scrum Master (Scrum ustası)
  • Product Owner (Ürün sahibi)
  • Developers (Geliştiriciler)

Rollerin işbirliği

  • Scrum Master, süreçlerin doğru işlemesini sağlarken, Ürün Sahibi ürünün iş hedeflerini temsil eder. Geliştiriciler ise Ürün Sahibi’nin belirlediği önceliklere göre çalışır.
  • Bu üç rolün etkili bir şekilde işbirliği yapması, Scrum sürecinin başarısının temelini oluşturur.

Scrum Master

  • Ekip üyelerine Scrum süreçlerini anlamaları ve uygulamaları için rehberlik eder.
  • Engelleri (impediments) kaldırarak ekibin hedeflerine odaklanmasını sağlar.
  • Scrum değerlerini ve ilkelerini korur.
  • Çevik bir çalışma ortamı oluşturmak için ekibin etkinliğini artırmaya çalışır.
  • Takımın yüksek performans gösterdiği bir ortam oluşturur ve sürekli iyileştirme sağlamak gibi liderlik eder.

Scrum Master ≠ Proje Yöneticisi

  • Scrum Master:
    • Emir-komuta zinciri kurmaz
    • Görev dağıtmaz
    • Performans ölçmez
  • Scrum Master bir hizmetkâr liderdir (Servant Leader):
    • Süreci korur
    • Engelleri kaldırır
    • Takımın gelişimini destekler

Uyarı

Scrum Master, “takımın şefi” değildir.

Product Owner (Ürün Sahibi)

  • Ürün vizyonunu tanımlar ve ekip ile bu vizyonu paylaşır.
  • Ürün iş listesi (Product Backlog) öğelerini belirler, önceliklendirir ve netleştirir.
  • Müşteri ve paydaşlarla yakın iletişim içinde olup, onların ihtiyaçlarını Scrum ekibine iletir.
  • Teslim edilen ürünün iş hedeflerini karşılamasını sağlar.

Developers (Geliştiriciler)

  • Increment’i (ürün artışını) üretmekten sorumludur.
  • Sprint boyunca Sprint Backlog’u yönetir ve gerektiğinde günceller.
  • Kendi kendini organize eder; iş bölümü konusunda özerktir.
  • Kaliteyi Definition of Done ile güvence altına alır.

Sprint’e Hazırlık (Sprint Preparation)

Ürün İş Listesi

  • Ürün İş Listesi (Product Backlog), Scrum kapsamında ürünün geliştirilmesi için yapılması gereken tüm işlerin yaşayan listesidir.
  • Bu liste, ürün geliştirme sürecinde yer alacak tüm öğeleri – özellikler, geliştirmeler, hata düzeltmeleri ve teknik işler gibi – içerir.

Ürün iş listesi özellikleri

  • Dinamik: Ürün geliştikçe değişikliklere açıktır. Yeni gereksinimler eklenebilir veya mevcut öğeler güncellenebilir.
  • Öncelikli: İşler, ürün sahibi (Product Owner) tarafından önceliklendirilir ve ekibin iş önceliğini belirler.
  • Net ve Anlaşılır: Her iş öğesi, ekibin anlayabileceği ve geliştirme sürecine başlayabileceği kadar net olmalıdır.

Product Goal (Ürün Hedefi)

  • Product Goal, ürünün orta vadeli yönünü tanımlar.
  • Product Backlog, bu hedefe ulaşmak için şekillenir.
  • Uzun süre sabit kalabilir, gerektiğinde güncellenebilir.

Not

Product Goal olmadan Product Backlog sadece bir görev listesine dönüşür.

Ürün iş listesi öğeleri

Ürün İş Listesi’nde yer alan öğeler genellikle şu unsurlardan oluşur:

  • Kullanıcı Hikayeleri (User Stories): Kullanıcı gereksinimlerini basit ve anlaşılır bir şekilde ifade eder.
  • Görevler (Tasks): Daha küçük ve spesifik geliştirme işleri.
  • Hatalar (Bugs): Üründeki mevcut sorunlara ait kayıtlar.
  • Teknik İşler: Performans iyileştirmeleri, teknik borçların giderilmesi gibi geliştirme dışındaki işler.

Ürün iş listesi için iyi uygulamalar

  • KISS Prensibi (Keep It Simple, Stupid): Listeyi sade ve anlaşılır tutun.
  • INVEST Kriterleri: İş öğelerinin, bağımsız (Independent), müzakere edilebilir (Negotiable), değerli (Valuable), tahmin edilebilir (Estimable), küçük (Small) ve test edilebilir (Testable) olmasını sağlayın.
  • Düzenli İnceleme: Backlog öğelerini düzenli aralıklarla gözden geçirin ve önceliklendirin.

Örnek Ürün İş Listesi

ID Başlık Öncelik Tahmin Durum
1 Kullanıcı oturum açma ekranı geliştirilmeli Yüksek 5 SP Geliştirmede
2 Ürün filtreleme özelliği geliştirilmesi Orta 8 SP Bekliyor
3 API performans iyileştirmesi yapılmalı Düşük 3 SP Tamamlandı

Backlog Refinement (Backlog İyileştirme)

  • Product Backlog’un:
    • Gözden geçirilmesi
    • Detaylandırılması
    • Tahminlenmesi
    • Önceliklendirilmesi sürecidir
  • Resmi bir Scrum event’i değildir
  • Ancak düzenli yapılması kritik öneme sahiptir

Not

İyi refinement yoksa, Sprint Planning verimsiz olur.

Backlog Refinement (Sprint’in kapısı)

Refinement sonunda amaç, Sprint Planning’e “hazır” girmek:

  • Backlog maddeleri daha net hale gelir (kabul kriterleri vb.)
  • Büyük işler bölünür
  • Öncelikler güncellenir
  • Tahminler ve riskler daha görünür olur

Not

Refinement, planlama toplantısının verimini belirleyen ana faktörlerden biridir.

Sprint Planlama Süreci

Sprint Planlama

  • Sprint planlaması, Scrum çerçevesinin en önemli aşamalarından biridir.
  • Sprint’in nasıl geçeceğini belirleyen temel unsurları içerir.
  • Bu aşamada, takım belirli bir zaman diliminde (genellikle 2-4 hafta) tamamlamayı hedeflediği işleri seçer ve Sprint boyunca yapılacak işlerin kapsamını netleştirir.

Sprint Planlama Adımları

Sprint Hedefinin Belirlenmesi

  • Sprint planlamasının ilk adımı, Sprint’in genel amacını belirlemektir.
  • Bu hedef, ekip üyelerine neyi başarmaları gerektiğini ve Sprint’in nihai amacını anlatır.
  • Hedef, genellikle ürün sahibi tarafından önerilir ancak ekip tarafından da tartışılarak kesinleştirilir.
  • Sprint hedefi, ürün iş listesinde yer alan öğelerden seçilir ve bu öğelerin tamamlanması hedeflenir.

Sprint Goal (Sprint Hedefi)

  • Sprint Goal, Sprint’in tek resmi taahhüdüdür
  • Sprint boyunca değişmez
  • Sprint Backlog değişebilir

Uyarı

Scrum’da bağlılık (commitment), backlog maddelerine değil Sprint Goal’a yöneliktir. Sprint Goal sabit; Sprint Backlog yaşayan plan.

Ürün İş Listesinin Gözden Geçirilmesi

  • Ürün sahibi (Product Owner), ürün iş listesini (Product Backlog) gözden geçirir ve her bir öğenin öncelik sırasını belirtir.
  • Ekip, ürün sahibiyle birlikte hangi öğelerin bu Sprint için seçileceğine karar verir. Bu öğeler, hedefe ulaşmak için gerekli olan ve tamamlanabilir işler olmalıdır.
  • Her bir öğe, işin ne kadar karmaşık ve zaman alıcı olduğunu belirlemek için tahmin edilmelidir.

Sprint İçin Seçilen Öğelerin Detaylandırılması

  • Sprint planlamasında seçilen iş öğeleri (user stories), daha küçük parçalara ayrılabilir ve her bir parçanın yapılması gereken detaylar açıklanabilir.
  • Bu aşamada, ekip üyeleri işin detaylarını anlamalı ve teknik gereksinimleri belirlemelidir. Gerekiyorsa, teknik borç veya bağımlılıklar belirlenir.
  • Detaylı olarak tanımlanan iş öğeleri, ekibin Sprint boyunca daha verimli bir şekilde çalışmasını sağlar.

Efor ve Süre Tahminlerinin Yapılması

  • Seçilen iş öğeleri için tahminler yapılır.
  • Her bir iş için karmaşıklığına, büyüklüğüne göre değerler atanır.

Sprint Planının Oluşturulması

  • Tüm öğeler tamamlandığında ve tahminler yapıldığında, ekip bu öğeleri Sprint boyunca tamamlamak için bir plan oluşturur.
  • Ekip, hangi öğelerin hangi günlerde tamamlanacağını ve hangi görevlerin kim tarafından yapılacağını netleştirir.
  • İş yükü tüm ekip üyeleri arasında dengeli bir şekilde dağıtılır.
  • Plan, yüksek öncelikli öğelerin öncelikli olarak yapılmasını sağlayacak şekilde hazırlanır.

Sprint Backlog

  • Sprint için seçilen işlerin oluşturduğu listedir.
  • Ekibin bir sprint süresince nelerle meşgul olacağını ifade eder.
  • Product Backlog’un bir alt kümesidir.

Sprint Backlog Sabit Değildir

  • Sprint boyunca:
    • Yeni görevler eklenebilir
    • Gereksiz işler çıkarılabilir
    • Teknik detaylar değişebilir
  • Değişmeyen tek şey:
    • Sprint Goal

Not

Sprint Backlog, hedefe ulaşmak için yaşayan bir plandır.

Sprint İçinde Planlanmamış İş (Hotfix) Ne Olur?

  • Sprint sırasında acil bir iş çıkarsa:
    • Etkisi Sprint Goal’a göre değerlendirilir
    • Sprint Backlog güncellenebilir (Developers yönetir)
  • Eğer iş Sprint Goal’u anlamsızlaştırıyorsa:
    • Sprint iptali teorik olarak mümkündür (nadir)
    • Daha gerçekçi çözüm: hedefi ve backlog’u yeniden düzenlemek

Uyarı

“Her gelen acili sprinte alalım” yaklaşımı, Sprint disiplinini hızla bozar.

Sprint Döngüsü

Sprint (Timebox)

  • Sprint, Scrum’un kalbidir: 1 ay veya daha kısa timebox.
  • Sprint boyunca:
    • Planning yapılır
    • Daily Scrum ile plan uyarlanır
    • Increment üretilir
    • Review ve Retro ile öğrenilir

Not

Sprint boyunca amaç: Sprint Goal’a ilerlemek ve değer üretmektir.

Örnek Senaryo

Bir yazılım geliştirme ekibi, bir e-ticaret platformu üzerinde çalışıyor. Takım, ürünün ödeme sistemi özelliklerini geliştirecek. Sprint planlaması sırasında, bu görevlerin nasıl tahmin edileceğini ve sprint kapasitesinin nasıl belirleneceğini görmek istiyoruz.

  • Sprint Hedefinin Belirlenmesi: Sprint’in hedefi, “Ödeme sayfasının tasarımını tamamlamak ve ödeme gateway entegrasyonunu başlatmak” olarak belirlenir.

Product Backlog’un İncelenmesi

  • Backlog Maddesi 1: Ödeme sayfası tasarımının yapılması
  • Backlog Maddesi 2: Ödeme gateway API entegrasyonunun yapılması
  • Backlog Maddesi 3: Ödeme başarı ve hata mesajlarının yapılandırılması

Backlog Maddelerinin Sprint’e Çekilmesi

Takım, Product Backlog’dan Sprint’e dahil edilecek işleri seçer. Örnek olarak, aşağıdaki görevler seçilmiştir:

  • Tasarımlar için gerekli UI elemanları oluşturulacak (2 gün)
  • API entegrasyonu yapılacak (3 gün)
  • Mesajlaşma sisteminin yapılandırılması (1.5 gün)

Efor Tahmini ve Kapasite Hesaplama

Efor tahmini yaparken, ekip story points (öykü puanları) kullanır. Story points, genellikle 1, 2, 3, 5, 8 gibi sayılarla ifade edilir ve her bir işin zorluk seviyesini temsil eder. Örnek olarak:

  • Ödeme sayfası tasarımı: 5 story points
  • API entegrasyonu: 8 story points
  • Mesajlaşma sistemi: 3 story points

Not

Bu tahminler, geçmiş sprintlerden edinilen verilerle karşılaştırılarak yapılabilir. Örneğin, ekip geçmişte benzer tasarım görevlerini 5 story points olarak tahmin ettiyse, bu değer geçerli kabul edilir.

Sprint Planının Sonuçlandırılması

  • Ekip üyeleri, mevcut kapasiteyi göz önünde bulundurarak hangi görevleri alacaklarını belirler.
  • Örneğin, 3 yazılımcıdan oluşan bir ekip için toplam kapasite 30 story points olacaksa, yukarıdaki görevlerin toplamı (5 + 8 + 3 = 16 story points) bu sprint için uygun bir hedef olabilir.

Daily Scrum

  • Daily Scrum, Scrum takımının günlük olarak bir araya gelip, Sprint hedeflerine doğru ilerlemeyi tartıştığı kısa bir toplantıdır.
  • Amaç, her takım üyesinin işlerini senkronize etmesi ve engelleri hızla tespit edip çözmektir.
  • Kısa süreli toplantılar. Herkes katılır
  • Sık kullanılan üç soru (zorunlu değil):
    • Dün ne yaptım?
    • Bugün ne yapacağım?
    • Engellerim neler?
  • Bu sorular bir “kalıp” değil; ekibin planı uyarlamasına yardımcı olan bir araçtır.

Daily Scrum Ne Değildir?

  • Rapor toplantısı değildir

  • Yöneticilere hesap verme zamanı değildir

  • Asıl amacı:

    • Sprint Goal’a ulaşmak için planı uyarlamak

Not

Sorular araçtır, amaç adaptasyondur.

Definition of Done (DoD)

  • Sprint sonunda “ne gösteriyoruz?” sorusunun cevabı için önce “Done”ı netleştirmeliyiz.

  • Definition of Done, bir işin:

    • Ne zaman “tamamlandı” sayılacağını
    • Hangi kalite kriterlerini karşılaması gerektiğini tanımlar

Örnek DoD: Kod yazıldı → Testler geçti → Kod incelemesi yapıldı → Entegrasyon başarılı

Uyarı

“Çalışıyor” demek, “Done” demek değildir.

Increment (Ürün Artışı)

  • Increment:
    • Sprint sonunda ortaya çıkan
    • Çalışan
    • Kullanılabilir ürün parçasıdır
  • Increment:
    • Definition of Done’a uygun olmalıdır
    • Her Sprint’te değer üretmelidir

Scrum Artefaktları ve Taahhütler

Artefakt Commitment
Product Backlog Product Goal
Sprint Backlog Sprint Goal
Increment Definition of Done

Not

Scrum Guide 2020 ile birlikte her artefaktın bir taahhüdü vardır.

Sprint Sonu Değerlendirme

Sprint İncelemesi

  • Sprint Review toplantısı, Sprint’in sonunda yapılan bir değerlendirme toplantısıdır ve takımın Sprint sırasında tamamladığı işlerin (DoD’ye uygun Increment) paydaşlara gösterildiği, geri bildirimlerin alındığı ve gelecekteki yön hakkında tartışmaların yapıldığı bir süreçtir.
  • Sprint İncelemesi, sadece ekibin değil, tüm paydaşların katılımıyla gerçekleştirilir.

Sprint review’in amacı

  • Ürün İncelemesi: Sprint boyunca tamamlanan özellikler, işlevsellikler ve iyileştirmeler gözden geçirilir. Ürün sahibi ve paydaşlar, yapılacak olan işlerin (şu anda veya gelecekteki Sprintlerde) beklentilerini açıkça ifade ederler.
  • Geri Bildirim Alınması: Sprint Review sırasında, ürünün tamamlanan kısmı üzerinden alınan geri bildirimler, gelecekteki geliştirme süreçlerini etkileyebilir. Bu geri bildirimler, bir sonraki Sprint’in yönünü belirlemek ve ürünü daha iyi hale getirmek için kullanılır.

Sprint review’in amacı (devam)

  • Paydaşlarla İletişim: Paydaşlar, ürün geliştirme süreci hakkında daha fazla bilgi edinir ve projeye olan katılımlarını artırırlar. Bu etkileşim, ürünün hedeflere uygun gelişmesini sağlar.

Alınan Geri Bildirimlerin Sonraki Sprint’lere Etkisi

Sprint Review toplantısı, doğrudan sonraki Sprint’lere etki eder. Alınan geri bildirimler, ürünün doğru yolda ilerleyip ilerlemediğini gösterir ve bu geri bildirimler, planlamalarda ve uygulamalarda değişikliklere neden olabilir.

  • Öncelik Değişiklikleri
  • Hedeflerin Güncellenmesi
  • İyileştirmeler ve Engellerin Aşılması

Sprint Review’in Sonuçları

Sprint Review sonunda, aşağıdaki sonuçlar elde edilebilir:

  • Ürün Artışı
  • Geri Bildirimlerin Toplanması
  • Gelecek Sprint’in Yönü

Sprint Sonu İyileştirme (Süreç odaklı)

Sprint Retrospektifi

  • Sprint Retrospektifi, Scrum sürecinde her Sprint’in sonunda yapılan, ekibin süreçleri değerlendirdiği ve iyileştirmeler için aksiyonlar belirlediği önemli bir toplantıdır.
  • Bu toplantının amacı, takımın iç süreçlerini analiz etmek, güçlü yönlerini vurgulamak, zayıf yönleri belirleyerek iyileştirme fırsatları yaratmaktır.
  • Sprint Retrospektifi, takımın sürekli gelişimine olanak tanır ve Scrum ekibinin daha verimli çalışmasını sağlar.

Sprint Review vs Sprint Retrospective

Sprint Review Sprint Retrospective
Ürün odaklı Süreç odaklı
Paydaşlar katılır Sadece Scrum Team
Ne yaptık? Nasıl yaptık?
Değer üretimi Sürekli iyileştirme

Bir Sprint’in Yolculuğu

Efor ve Tahminleme

Efor Nedir?

  • Efor, bir işin tamamlanabilmesi için gereken çaba, zaman ve kaynakları ifade eder.
  • Scrum’da, efor genellikle bir işin zorluk derecesi veya karmaşıklığı ile ilişkilendirilir ve bir görev için ne kadar zaman veya kaynak gerektiğini ölçmeye yönelik tahminler yapılır.
  • Efor, genellikle “Story Points” gibi soyut birimlerle ölçülür ve işin büyüklüğünü değerlendirmek için ekip tarafından belirlenir.

Scrum’da Eforun Kullanımı

  • Scrum çerçevesinde, efor, işleri tahmin etmek, önceliklendirmek ve planlamak için kullanılır.
  • Bu sayede, ekipler Sprint’lerinde hangi işlerin tamamlanabileceğini daha doğru bir şekilde öngörebilir.
  • Efor, işlerin karmaşıklığını ve tamamlanma süresini tahmin etmek için kullanılırken, aynı zamanda işlerin sprint süresi içinde yönetilmesini sağlar.

Efor ölçü birimleri

  • Efor ölçü birimleri bir işi tamamlamak için gereken çabayı, karmaşıklığı ve belirsizliği ifade etmek için kullanılan çeşitli yollardır.
  • Temel amaç, ekiplerin işin ne kadar işi büyüklüğünü ve derinliğini anlamasına yardımcı olarak planlamayı kolaylaştırmaktır.

Efor ölçü birim türleri

  • Efor ölçü birimleri iki ana kategoriye ayrılabilir.
    • Soyut ölçüler: Bu ölçüler, mutlak bir zaman veya kaynak kullanımı yerine işin göreceli büyüklüğünü ve karmaşıklığını ifade eder.
      • Story Point (Hikaye Puanı)
      • T-Shirt Size (Tişört Bedenleri)
    • Somut ölçüler: Bu ölçüler, işin ne kadar zaman alacağını veya ne kadar kaynak gerektireceğini doğrudan ifade eder.
      • Ideal Days/Hours (İdeal Günler/Saatler)
      • Person Days (Kişi Gün)

Story Point (Hikaye Puanı)

En yaygın kullanılan soyut efor ölçü birimidir. Bir iş öğesinin (user story) karmaşıklığını, belirsizliğini, riskini ve genel eforunu temsil eder. Zaman ile doğrudan ilişkisi yoktur.

Story Point (Fibonacci)

T-Shirt Size (Tişört Bedenleri)

Daha kabaca bir tahmin yöntemi olup, iş öğelerini tişört bedenleri (XS, S, M, L, XL, XXL…) gibi kategorilere ayırarak eforu ifade eder.

  • Daha hızlı ve daha az detaylı tahmin gerektiren durumlarda kullanılır.
  • Bir işin diğerlerine göre “daha büyük” veya “daha küçük” olduğunu ifade eder.
  • Detaylı tahminlere zaman harcamak istenmeyen durumlar için uygundur.

T-Shirt Size

Ideal Days (İdeal Günler)

Bir işin, herhangi bir kesinti, engel veya dış etken olmaksızın, “ideal” koşullarda ne kadar gün süreceğini ifade eder.

  • Gün gibi bir zaman birimi kullanır.
  • “İdeal” koşulları varsayar, ki bu pratikte pek mümkün değildir.
  • Anlaşılması kolay ve somut bir yöntemdir.
  • Daha küçük ve daha net görevler için kullanışlıdır.

Ideal Hours (İdeal Saatler)

İdeal günlere benzer şekilde, bir işin “ideal” koşullarda ne kadar saat süreceğini ifade eder.

  • Saat gibi daha küçük bir zaman birimi kullanır.
  • “İdeal” koşulları varsayar.
  • Daha küçük ve kısa süreli görevler için uygundur.

Person Days (Kişi-Gün)

Bir işin bir kişi tarafından bir günde tamamlanması gereken iş miktarı.

  • Kişi ve zaman birimi (gün) içerir.
  • Kaç kişinin bir işi ne kadar sürede bitirebileceğini tahmin eder.
  • Kişilerin farklı hızlarda ve yeteneklerde çalışabileceğini dikkate almayabilir.
  • Kaynak planlama ve bütçelendirmede sıkça kullanılır.

Karşılaştırma

Özellik Story P. T-Shirt Ideal Hrs P. Days
Soyutluk Yüksek Orta Düşük Düşük
Görecelik Yüksek Orta Düşük Düşük
Somutluk Düşük Orta Yüksek Yüksek
Zaman İlişkisi Dolaylı Dolaylı Doğrudan Doğrudan
Karmaşıklık İyi Orta Yetersiz (belirsizliği yansıtmaz) Yetersiz (belirsizliği yansıtmaz)

Karşılaştırma (Devam)

Özellik Story P. T-Shirt Ideal Hrs P. Days
Ekip Hızı Çok İyi (Velocity ölçümü için) Orta Düşük (tutarlı değildir) Düşük
Detay Düzeyi Orta Düşük Yüksek (somut ama varsayımlı) Orta
Esneklik Yüksek Orta Düşük Düşük

Hangi Ölçü Birimi Kullanılmalı?

  • Story point: Karmaşıklık ve belirsizliğin yüksek olduğu ve ekip hızının ölçülmesinin önemli olduğu durumlarda genellikle en iyi seçenektir. Agile ekiplerin çoğunluğu tarafından kullanılır.
  • T-Shirt Size: Hızlı ve kabaca tahminler yapmak ve büyük backlog’ları önceliklendirmek için uygundur.
  • Ideal days/hours: Daha somut bir zaman tahmini gerektiğinde ve basit, net görevler için kullanışlıdır.
  • Person days: Proje kaynaklarını planlamak ve bütçelendirmek için daha çok kullanılır, ancak efor tahmini için diğer yöntemler daha iyi sonuç verebilir.

Efor Tahminlemek

  • Efor tahminleme teknikleri, projelerde yer alan işlerin büyüklüğünü, karmaşıklığını ve tahmini süresini değerlendirmek için kullanılan yöntemlerdir.
  • Bu teknikler, ekiplerin daha gerçekçi planlar yapmasına, kaynakları daha iyi yönetmesine ve proje risklerini azaltmasına yardımcı olur.

Planlama Pokeri (Planning Poker)

Ekiplerin işbirliği içinde efor tahminleri yapmasını sağlayan, interaktif ve eğlenceli bir tekniktir.

  • Tahmin edilecek iş öğesi belirlenir.
  • Her ekip üyesi, üzerinde efor ölçü birimleri (story point vb.) olan bir dizi karttan, kendi tahmini olan kartı gizlice seçer.
  • Tüm ekip üyeleri aynı anda kartlarını açar.
  • Tahminlerde farklılıklar varsa, ekip üyeleri farklı düşüncelerini tartışır.
  • Tahminler bir uzlaşıya varana kadar bu döngü tekrar edilir.

Planning Poker: Bir Tur

Tahminler pratikte ne kadar doğru?

  • Scrum efor tahminleri, pratikte çeşitli faktörler nedeniyle doğruluk açısından değişiklik gösterebilir.
  • Önemli bir faktör, tahmin sürecine katılan ekip üyelerinin deneyim ve uzmanlık düzeyi.
  • Ekipler projenin karmaşıklıklarına daha aşina hale geldikçe tahminler zamanla iyileşme eğilimindedir.

Tahminler pratikte ne kadar doğru? (devam)

  • Ek olarak, önceki projelerden elde edilen geçmiş verileri dahil etmek ve harcanan gerçek eforu takip etmek doğruluğu artırabilir.
  • Yapılan bir çalışma, çevik ekiplerin %60 ila %83 arasında değişen tahmin doğruluğuna ulaştıklarını gösteriyor. Bu da scrum efor tahminlerinin hem potansiyelini hem de sınırlamalarını ortaya koyuyor.
  • Ekip büyüklüğü, sprint süresi, proje deneyimi etkendir.

Özetle

  • Metodoloji Değil Çerçevedir: Scrum, adım adım ne yapılacağını söyleyen katı bir metodoloji değil; şeffaflık, gözlem ve adaptasyon (ampirik süreç kontrolü) temellerine dayanan, karmaşık işlerin yönetimi için kullanılan çevik bir çerçevedir.
  • Rollerin İş Birliği: Sürecin başarısı; ürün vizyonunu ve öncelikleri belirleyen Product Owner, süreci yöneten hizmetkâr lider Scrum Master ve kalite standartlarına (DoD) uygun çalışan ürün artışını (Increment) üreten Geliştiricilerin uyumlu çalışmasına bağlıdır.
  • Değerler Bütünü: Scrum’ın mekanik bir işlemden öteye geçip verimli olabilmesi için ekibin Cesaret, Odak, Taahhüt, Saygı ve Açıklık olmak üzere 5 temel değeri benimsemesi zorunludur.
  • Sürekli İyileştirme Döngüsü: Belirli zaman aralıklarından oluşan Sprint’ler boyunca yapılan Planlama, Daily Scrum, Review ve Retrospektif toplantıları sayesinde ürün ve çalışma süreci sürekli olarak denetlenir, geri bildirim alınır ve iyileştirilir.
  • Planlama ve Tahminleme: İşler, Product Backlog ve Sprint Backlog üzerinden takip edilirken; efor tahminlerinde mutlak zaman yerine genellikle Story Point gibi işin karmaşıklığını ve büyüklüğünü ifade eden soyut ölçü birimleri kullanılır