Definition of Done: Scrum’da örnek, kontrol listesi ve workshop

Geçen gün bir meslektaşımla birlikte bir atölye çalışması hazırladık. İçerik konusunda hemen anlaştık, tek eksik uygun bir PowerPoint sunumuydu. Sunum üzerinde mümkün olduğunca verimli çalışabilmek için konuyu tematik olarak ayırdık. Daha sonra bitmiş taslağı tartışmak için oturduğumuzda, büyük bir sorun ortaya çıktı: “bitmiş bir taslağı” gerçekten neyin karakterize ettiği konusunda çok farklı fikirlerimiz vardı. 

Bu sorun çevik Scrum ekiplerinde de ortaya çıkabilir. İki hafta sonra, ekip sprintin sonuna ulaşır, ancak ürün artışının zaten bitmiş olup olmadığı ve “devam ediyor” dan “bitti” ye taşınabileceği konusunda anlaşmazlık vardır. Bu anlaşmazlık tartışmalara yol açar ve bu da ekipteki iklimi olumsuz etkiler. Bu tartışmaları önlemek ve etkili takım çalışmasını korumak için Scrum dünyasında “Bitti Tanımı” (DoD) adı verilen bir eser vardır. 

Scrum’da Definition of Done nedir?

Definition of Done, bir Scrum ekibinin ortak kalite anlaşmasıdır. Bir artışın tamamlanmış ve kullanılabilir sayılabilmesi için hangi koşulların sağlanması gerektiğini tanımlar. Kişisel bir görev listesi ya da tek bir rol tarafından yapılan ek bir onay değildir; tüm ekip için şeffaf bir standarttır.

Kelimenin tam anlamıyla, Definition of Done “bitmişliğin tanımı” anlamına gelir. Bu, ekibin bir özelliğin bitmiş olarak kabul edilmesi için ne yapılması gerektiği konusunda hemfikir olduğu anlamına gelir. Pratik anlamda, Bitti Tanımı, sprint sırasında ve özellikle de sonunda belirli tamamlanma kriterlerinin karşılanıp karşılanmadığını kontrol etmek için kullanılan bir tür kontrol listesi olarak gösterilebilir. Yazılım geliştirme ekipleri için bu kriterler örneğin aşağıdaki gibi olabilir: 

Scrum ekipleri için Definition of Done örneği: kontrol listesi

Uygulanabilir bir Definition of Done, bir yazılım ürünü için örneğin şu kriterleri içerebilir:

• Kabul kriterleri ve işlevsel gereksinimler karşılanmıştır.
• Dokümantasyon hazırlanmıştır.
• Kod tamamen uygulanmış ve yorumlanmıştır.
• Bir kod incelemesi gerçekleştirilmiştir.
• Otomatik testler başarıyla çalışır; ilgili hatalar ve güvenlik riskleri ele alınmıştır.
• Değişiklik entegre edilmiştir ve üretime yakın bir ortamda doğrulanabilir.
• Monitoring, logging ve gerekiyorsa release notları dikkate alınmıştır.
• Artış kullanılabilir durumdadır ve ürünün kalite standardını karşılar.
• …

Bu liste bir örnektir, evrensel bir şablon değildir. İyi bir DoD kaliteyi korur, ekibin her sprintte uygulayabileceği şekilde kalır ve ürün, riskler veya teknik koşullar değiştiğinde güncellenir.

Definition of Done, ürün etkisi ile aynı şey değildir

Bir Definition of Done önemli bir soruyu yanıtlar: Artış, üzerinde anlaşılan kalite standardını karşılıyor mu ve kullanılabilir mi? Ancak değişikliğin pazarda ya da müşteride istenen etkiyi yaratıp yaratmadığını otomatik olarak yanıtlamaz.

Bu nedenle pratikte üç seviye arasında bir ayrım yapmak faydalıdır:

• Done: Artış Definition of Done’ı karşılar ve kullanılabilir.
• Done-Done: Değişiklik entegre edilmiştir, teslim edilmiştir ve işletimde gözlemlenebilir.
• Ürün etkisi: Gerçek müşteri geri bildirimi, değişikliğin ilgili bir sorunu çözüp çözmediğini ve ürün değerini artırıp artırmadığını gösterir.

John Cutler bu nedenle yazılımı sürekli geliştirilen bir hizmet sistemi olarak tanımlar: Özellikler nihai yapılar değil, müşteri faydası üretmek için geçici araçlardır. Bakış açısını burada okuyabilirsin The Work Is Never Done.

Gil Zilberfeld ayrıca “Done” kavramının farklı anlamlarını birbirinden ayırır — örneğin geliştirme, testler, teslimat veya müşteri geri bildirimi her biri farklı bir tamamlama düzeyini işaret ettiğinde. Değerlendirmesini burada bulabilirsin The Definition of Done, Done-Done and Really Done.

Önemli: “Ürün etkisi” basitçe ek bir DoD kriteri olarak formüle edilmemelidir. Bir Scrum ekibi kullanılabilir bir artış teslim etmelidir; bunun istenen etkiyi yaratıp yaratmadığı ise Sprint Review, kullanım ve diğer öğrenme döngüleriyle sonradan görünür olur. Tam da bu ayrım, Definition of Done’ın ulaşılması imkânsız bir toplama listesine dönüşmesini engeller.

Definition of Done’ın diğer etkili Scrum uygulamalarıyla nasıl etkileştiğini yazımızda gösteriyoruz Scrum En İyi Uygulamaları 2026.

Yapıldı Tanımı neden önemlidir?

Hedef belirlemenin performans açısından büyük önem taşıdığı yeni bir görüş değildir. Hedef belirleme psikolojide çok araştırılan bir konudur (bkz. Locke & Latham, 2006). Hedefler ulaşılamaz görünmeden mümkün olduğunca spesifik ve zorlayıcı olduğunda performansın en yüksek olduğu gösterilmiştir. Bununla birlikte, Yapılacakların Tanımı bir hedef belirleme yöntemi değildir (ancak kullanılacaksa, bir hedef belirleme yöntemidir). Hedef belirleme konusunda destek Yardıma ihtiyacınız olursa, size yardımcı olmaktan memnuniyet duyarız); bu daha ziyade hedefe ulaşmak için yerine getirilmesi gereken kriterlerle ilgili bir sorudur. 

Bu kriterler ekipte ortak bir anlayış oluşturmak için önemlidir. Ortak hedefe ulaşmak için her bir ekip üyesinin neyi başarması gerektiğine dair bir anlayış. Yani sonuçta bir ekip performansına dönüşen bireysel performanslarla ilgilidir.

DoD konusuna ürün sahibinin bakış açısından bakarsak, tamamen farklı sorunlar ortaya çıkar. Bir ürün artışının ne zaman bitmiş sayılacağı açıkça tanımlanmazsa, ürün müşteriye sunulduğunda müşteriyle anlaşmazlıklara yol açabilir. Bu gerçekleşir ve bitmemiş bir ürün sunulursa, müşteriden geri bildirim alma olasılığı engellenir. 

Sürekli iyileştirme

Bitti Tanımı statik bir kavram olmadığından ve sürekli gelişip değişebileceğinden ve değişmesi gerektiğinden, ekibe öğrenme fırsatı da sunar. Bir sprintin sonunda ekip, Bitti Tanımının kriterlerini karşılayamadığını fark ederse, ekip üyeleri ya Bitti Tanımını gerçek performansı karşılayacak şekilde ayarlayabilir ya da ekip bir sonraki sprint için sonuçlar çıkarır ve kendi çalışma şeklini değiştirir.

Echometer’yi şimdi ücretsiz deneyin ve retrospektifleriniz için yeni ilhamlar alın!

Echometer’yi ücretsiz test edin

Yapıldı Tanımına ilişkin bu yansımalar retrospektif sırasında ekip tarafından yapılmalıdır. Mümkün Echometer ÖğeleriHazırlık aşamasında sorulabilecek sorular şunlardır 

İhtiyaçlarımız için net Yapıldı Tanımlarımız var.

Genellikle ortak hedeflerimize ulaşma konusunda nerede durduğumuzu bilirim.

Hedefler: Hedeflerim meslektaşlarımın hedefleriyle uyumludur.

Ekip, hedefimize ulaşmak için ihtiyaç duyduğumuz tüm becerileri kapsıyor.

Sadece ekipte bir Görev Tanımı olup olmadığını değil, aynı zamanda ekipte şeffaflık, özerklik ve rol netliğinin ne kadar olduğunu da sorgularlar.

Ürün havuzunun tamamını şurada bulabilirsiniz Retro araç.

Ekibimiz yapılanı nasıl tanımlayabilir? Bir atölye çalışması örneği

Size Bitti Tanımının ne olduğunu ve Scrum ekiplerinde etkili işbirliği için neden önemli olduğunu gösterdik. Ancak ekibiniz henüz bir DoD oluşturmadıysa, muhtemelen nasıl çalıştığını merak ediyorsunuzdur. 

Prensip olarak, ekibin belgeyi hazırlarken zaman ayırması önemlidir. Sonunda, her ekip üyesinin özdeşleşebileceği ve sadece gerekli bir kötülük olarak görülmeyen bir belge ortaya çıkmalıdır. Bu nedenle, Scrum Master’ın moderatör olduğu çalıştay benzeri bir format öneriyoruz. Her ekip üyesi ürünün tamamlanması için hangi kriterlerin önemli olduğunu düşünmeli ve ekip daha sonra bu düşünceleri özetleyebilir. Benzer şekilde, hedef belirleme için de bir atölye formatı geliştirdik. Bir göz atınDefinition of Done atölye çalışmanız için fikir edinmek için! 

Tamamlanan DoD, geriye dönük incelemelerde, örneğin Bitti Tanımı trafik ışığı şeklinde kullanılabilir:  

1. Yapıldı Tanımı için kriterlerinizi alt alta yazınız.
2. Her birinin yanına bir kırmızı, bir sarı ve bir yeşil kare çizin.
3. Bitti Tanımındaki her bir madde için, her ekip üyesi son sprintte iyi, orta derecede iyi veya kötü uygulanıp uygulanmadığını işaretler. 
4. Kırmızı alanda en sık bahsi geçen üçünü tartışın.
5. Gerekirse Bitti Tanımınızı ayarlayın.

Sonuç - Bitti mi?

Sonuç olarak birkaç söz: Çevik ortamda nihai olarak “bitti” diye bir şey yoktur. Bitti yalnızca bir şeyin geçici olarak tamamlandığı anlamına gelir, ancak daha fazla ayarlama ve iyileştirme her zaman yapılabilir ve yapılmalıdır. Bu, çevik çalışmanın birçok güzel yönünden biridir: sürekli iyileştirme. 

Özellikle heyecan verici: Bazen müşteri ortaya çıkıp tüm çözümü sorgulayana ve böylece müşterinin ihtiyaçları hakkındaki varsayımlarınızın temelini sarsana kadar noktalar “tamamlanmış” sayılır. Bu gibi durumlarda, ekibin müşteri faydalarını bilet sistemindeki ilerlemeden daha öncelikli tutup tutmadığı netleşir.

Yapılacakların net bir şekilde tanımlanması çatışmaları önleyebilir ve performansınızı artırabilir. Bu hedefe ulaşmak için daha fazla yolla ilgileniyorsanız, makalemize de göz atmalısınız çevi̇k zi̇hni̇yeti̇n arkasindaki̇ şaşirtici gerçek üzeri̇ne bakın. Ya da psikolojideki en son bilimsel bulguları dikkate alarak geçmişe bakışınızı zenginleştirin.

Tam da bu vaatle retro aracımız Echometer’yi geliştirdik. Echometer’nin nasıl çalıştığını (ve çalışıp çalışmadığını) merak ediyorsanız, lütfen Holger’in aracımızla ilgili deneyim raporunu okuyun:

Ekibinizi yeni bir performans seviyesine mi taşımak istiyorsunuz? Retro Aracımız bunu yapmanıza yardımcı olabilir. İşte Holger’in bu araçla ilgili deneyimleri:

Holger’in Remote Retro Tool hakkındaki deneyim raporu

Definition of Done ile ilgili sık sorulan sorular

Definition of Done’a neler girer?

Bir Definition of Done’a, bir artışın kullanılabilir olması için karşılaması gereken tüm kalite kriterleri girer. Tipik örnekler arasında karşılanmış kabul kriterleri, code review, testler, güvenlik kontrolü, dokümantasyon ve teslimat için teknik uygunluk yer alır. Hangi maddelerin geçerli olduğuna ekip, ürün bağlamına göre karar verir.

Scrum’da Definition of Done’ı kim oluşturur?

Scrum ekibi Definition of Done’ı birlikte geliştirir ve sürdürür. Tek bir rol tarafından bir kontrol listesi olarak dayatılmamalıdır. Kuruluşlar asgari standartlar belirleyebilir, ancak ekip bunları anlamalı ve günlük çalışmada uygulayabilmelidir.

Definition of Done ile Definition of Ready arasındaki fark nedir?

Definition of Done, bir artımın ne zaman tamamlanmış ve kullanılabilir olduğunu tanımlar. Buna karşılık bir Definition of Ready, bir iş öğesinin hazırlığı için kriterler içerebilir; ancak resmi bir Scrum artefaktı değildir ve sorumluluğu ya da geri bildirim döngülerini başka bir zamana itmek için kullanılamaz.

Uygulamadan örnek: Echometer’deki dahili Definition of Done’umuz

Bir Definition of Done yalnızca kod ve testlerle sınırlı olmak zorunda değildir. Echometer, dahili olarak işlevselliğin yanı sıra UX’i, sürdürülebilirliği, gözlemlenebilirliği ve sürümün hazırlığını da dikkate alan daha kapsamlı bir standart kullanır. Aşağıdaki örnek, bir ekibin kendi kalite kriterlerini nasıl somut ve doğrulanabilir hâle getirebileceğini gösterir:

Alan	Örnek kriterler
İşlevsellik	Belirtilen fonksiyon çalışır, tipik edge case’ler kontrol edilmiştir, bilinen hata yoktur, tamamlanmamış fonksiyonlar bir feature flag ile korunur ve ilgili kullanım verileri toplanır.
UX	Boş durumlar, yükleme durumları, yetkiler, hata yönetimi, yerelleştirme ve duyarlı tasarım dikkate alınmıştır.
Sürdürülebilirlik	Coding Guidelines ve ilgili kurallara uyulmuştur, gereksiz kod ve bilerek bırakılan teknik borçlardan kaçınılmıştır ve izleme ile hata ayıklama için önemli bilgiler mevcuttur.
Dağıtım	Değişiklik prod ortamına alınmıştır veya bilinçli olarak bir feature flag ile hazırlanmıştır, Release Notes eklenmiştir ve etkilenen paydaşlar gerektiğinde bilgilendirilir.

Bu örnek elbette genel geçer bir şablon değildir. Ancak bunu temel olarak kullanabilir, kendi tanımlarınızla zenginleştirebilir, düzenli olarak gözden geçirebilir ve yaşayan bir doküman olarak geliştirmeye devam edebilirsiniz.

Kaynaklar

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x