Backlog item
DevAtlas
Kavram yükleniyor.CON-005Ekip ve iş planlama
Refinement
Refinement (Product Backlog Refinement)
Kısa tanım
Refinement, Scrum'da Product Backlog item'larını ihtiyaç oldukça daha küçük ve daha precise hâle getiren devam eden activity'dir. Amaç her şeyi baştan ayrıntılı planlamak değil, yakın ve değerli item'lar hakkında doğru karar verecek kadar shared understanding oluşturmaktır.
Stajİlk işGünlük ekipPlanlamaİşbirliği
Temsili kavram şemasıCON-005
Süreç şeması
Hazırlık akışı
İş, planlamadan önce konuşulabilir hâle gelir.
01 · İş adayıAç
Ekip seçilen işi ve bilinmeyenleri birlikte görür.
- Başlangıç beklentisi
- AçıklaDevAtlas önerisi; evrensel sektör standardı değildir.
- Tahmini okuma
- 7 dakika
Görsel anlatım · Planlama konuşması
Refinement, işi Sprint'e taşımadan netleştirir.
Belirsiz bir Backlog item'ı hangi sorularla ortak anlaşılır hâle gelir ve neden bu, Sprint sözü anlamına gelmez?
Refinement
Fikir var, ortak anlayış yok
Ana mesajProduct Backlog’a yeni giren bir item önce bir fikirdir; herkesin kafasındaki resim aynı değildir.
Yeni bir Backlog item genelde tek satırlık bir istek olarak başlar. Beklenen sonuç, kapsam, riskler, bağımlılıklar ve ortaya çıkacak çıktı henüz net olmayabilir. Bu, başta doğal bir durumdur; asıl sorun belirsizliğin var olması değil, item’ın bu hâliyle doğrudan geliştirmeye verilmesidir.
Sık karıştırılan noktaTicket açıldıysa iş anlaşılmış demektir.
DoğrusuTicket yalnızca bir kayıttır. Ortak anlayış, item üzerinde konuşuldukça oluşur; yazılı olması anlaşılmış olması anlamına gelmez.
ÇıkarımBelirsizlik başta bir kusur değil; üzerinde çalışılacak malzemedir.
- Beklenen sonuç?Kullanıcı için ne değişecek?
- Kapsam?Nereye kadar, nereden sonrası hariç?
- Acceptance Criteria?Bittiğini nasıl anlarız?
- Bağımlılıklar?Başka ekip veya sistem gerekiyor mu?
- Riskler?Nerede sürpriz çıkabilir?
Sahne 1 / 5
Refinement nedir?
Ana mesajRefinement; Product Backlog item’larını ihtiyaç oldukça daha küçük ve daha precise hâle getiren ongoing activity’dir.
Süreklilik taşıyan bir çalışma biçimidir: bazen kısa bir konuşma, bazen birkaç kişinin bir item üzerinde birlikte çalışması. Sabit bir gün, sabit bir süre veya tek doğru bir biçim tanımlanmış değildir. Ayrıca bütün Product Backlog aynı ayrıntı düzeyinde hazırlanmaz; yakın ve değerli item’lar daha precise olur, uzaktaki item’lar kaba kalabilir.
Sık karıştırılan noktaRefinement, takvimde sabit duran zorunlu bir haftalık toplantıdır.
DoğrusuRefinement bir event değil, süregelen bir activity’dir. Kimin, hangi sıklıkla ve hangi biçimde çalışacağına ekip kendi bağlamına göre karar verir.
ÇıkarımÖlçüt toplantı formatı değil; item’ın karar verilebilir hâle gelmesidir.
Zaman içinde akan çalışma
- Sprint n
- Sprint n+1
- Sprint n+2
- Yakın item’larDaha precise: sonuç, kapsam ve riskler konuşulmuş.
- Orta vadeli item’larKısmen net: ana hatlar var, ayrıntı bekliyor.
- Uzaktaki item’larKaba kalabilir: henüz ayrıntılı çalışmaya gerek yok.
Sahne 2 / 5
Hangi sorular konuşulur?
Ana mesajRefinement’ta item’ı netleştiren sorular konuşulur; zorunlu tek bir soru listesi yoktur.
Sık konuşulan başlıklar: beklenen sonuç, kapsam, Acceptance Criteria, bağımlılıklar, riskler, belirsizlikler ve gerektiğinde size. Hangi başlığın gerektiği item’a göre değişir. Size tahmini işi yapacak Developers’a aittir; Product Owner tek başına belirlemez. Bazı ekipler Definition of Ready gibi kendi anlaşmalarını kullanır; bu, Scrum’ın zorunlu bir artifact’ı değildir.
Sık karıştırılan noktaRefinement, item’lara story point vermekten ibarettir.
DoğrusuEstimation, konuşulan başlıklardan yalnızca biridir ve her zaman gerekmez. Asıl iş; beklenen sonucu, kapsamı ve riskleri anlaşılır hâle getirmektir.
ÇıkarımSoru listesi bir şablon değil; item’ın ihtiyacı kadar konuşulur.
Duruma göre konuşulan başlıklar
- Beklenen sonuçNe değişecek, kimin için?
- Kapsamİçinde ne var, dışında ne kalıyor?
- Acceptance CriteriaKabul ölçütü ne?
- BağımlılıklarNeyi beklemek gerekiyor?
- RisklerNe ters gidebilir?
- BelirsizliklerHangi bilgi eksik?
- SizeGerekiyorsa: büyüklük fikri.
Hepsi her item için gerekli değil · sıra ve biçim ekibe göre değişir
Sahne 3 / 5
Büyük ve muğlak iş nasıl netleşir?
Ana mesajMuğlak bir item, sorularla hem daha küçük parçalara ayrılır hem de riskleri görünür hâle gelir.
Temsilî bir örnek: “Ödeme modülündeki Technical Debt’i temizle.” Bu item bu hâliyle doğrudan geliştirmeye verilmez; önce ne olduğu konuşulur. Refinement belirsizliği tamamen yok etmez, onu görünür ve yönetilebilir hâle getirir. Ayrıca Refinement, bütün product discovery veya solution design sürecinin tamamı değildir; yakın karar için gereken açıklığı hedefler.
Sık karıştırılan noktaRefinement bittiğinde item’da hiç belirsizlik kalmaz.
DoğrusuBelirsizlik kalabilir. Fark şu: artık adı konmuştur, maliyeti görünürdür ve karar bilinçli verilir.
ÇıkarımNetleşme demek: daha küçük parçalar + adı konmuş riskler.
Önceki hâli
Ödeme modülündeki Technical Debt’i temizle
Kapsam, beklenen iyileşme ve bitiş ölçütü belirsiz.
Netleştiren sorular
- Hangi kod veya akış sorunlu?
- Bugün hangi değişiklikleri yavaşlatıyor?
- Beklenen iyileşme ne?
- Scope dışında ne kalıyor?
- Ertelemenin maliyeti veya riski ne?
- Gerekirse item nasıl daha küçük parçalara ayrılır?
Sonraki hâli
- Ödeme hatası loglarını tek yerde toplamaBeklenen iyileşme: hata nedenini bulma süresi kısalır.
- Tekrar eden doğrulama kodunu tek akışa indirmeBeklenen iyileşme: yeni ödeme yöntemi eklemek kolaylaşır.
- Eski ödeme adımındaki geçici çözümü kaldırmaScope dışı: yeni sağlayıcı entegrasyonu.
Belirsizliğin durumuGizli ve dağınıkGörünür ve yönetilebilir
Sahne 4 / 5
Hazırlık, Sprint sözü değildir
Ana mesajRefinement daha iyi karar kanıtı üretir; item’ın bir sonraki Sprint’e gireceği sözünü vermez.
Refinement sonunda item hakkında daha sağlam bilgi olur: beklenen sonuç, kapsam, riskler, bağımlılıklar ve gerekiyorsa bir size fikri. Bu bilgi karar vermeyi kolaylaştırır. Ancak hangi item’ın Sprint’e alınacağı Sprint Planning sırasında, Sprint hedefi ve o günün bağlamıyla belirlenir.
Sık karıştırılan noktaRefine edilen item kesin olarak bir sonraki Sprint’e girer.
DoğrusuRefine edilmiş olmak öncelik garantisi değildir. Seçim Sprint Planning’de yapılır; hedef, kapasite ve o anki bağlam belirleyicidir.
ÇıkarımHazır olmak seçilmek değildir; seçim hedefe göre yapılır.
Refine edilmiş item’lar
- Ödeme hatası loglarını tek yerde toplamaKarar kanıtı: net
- Doğrulama kodunu tek akışa indirmeKarar kanıtı: net
- Geçici çözümü kaldırmaBağımlılık: başka ekip
Sprint Planning
- Sprint hedefi
- Mevcut bağlam ve kapasite
- Güncel order
Olası sonuçlar
- Sprint’e alınırSprint hedefine doğrudan katkı sağlıyor.
- Product Backlog’da beklerHazır ama bu Sprint hedefine hizmet etmiyor.
- Order değişir veya yeniden konuşulurBağlam değişmiş; yeni bilgi gelmiş olabilir.
Sahne 5 / 5
Klavye: sol/sağ ok tuşları sahne değiştirir, Home ilk sahneye, End son sahneye gider.
Editoryal beta2 kaynak · Son güncelleme 20 Temmuz 2026
İnceleme ayrıntılarıBu sayfadaKısa tanım01 / 09Bölümler
Kişisel mercekBu kavram sana nerede dokunur?İlk okumayı bitirince kendi bağlamına göre aç.
Seçimine göre içerik
Mesleki merceğin
İçerik merceğin hazırlanıyor.
Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
İlk okuma
Refinement; büyük veya muğlak işi bölmeye, beklenen sonucu netleştirmeye, bağımlılıkları görmeye ve order kararını güncellemeye yardım eder.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Her item'ı aynı şablona zorlamak yerine o domain ve yakın karar için gerekli açıklığı hedefler. Belirsizliği tamamen yok etmez; görünür ve yönetilebilir hâle getirir.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
İlk okuma
SCN-006'da “ödeme modülündeki Technical Debt'i temizle” adlı bir Backlog item'ı var. Ekip önce hangi development artifact'ının sorunlu olduğunu, bugün hangi değişiklikleri yavaşlattığını, ertelemenin olası maliyetini, beklenen iyileşmeyi ve scope dışını konuşuyor.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Gerekirse item'ı daha küçük parçalara ayırıyor ve Acceptance Criteria'yı netleştiriyor. Toplantı sonunda otomatik olarak Sprint'e alma sözü vermiyor; Backlog order kararı için daha iyi kanıt üretiyor.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
İlk okuma
Temsili ekip konuşması: “Bu debt item'ı solution adıyla yazılmış. Önce hangi değişiklikte bizi yavaşlattığını, beklenen sonucu ve scope dışını netleştirip gerekirse iki item'a bölelim.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
01TanıTemel02AçıklaHedef03UygulaSonra
- Tanı: Refinement, Product Backlog item, Acceptance Criteria, size ve order konuşmalarını ayırt edebilmelisin.
- Açıkla: Refinement'ın neden ongoing activity olduğunu ve neden yalnız meeting veya estimation olmadığını anlatabilmelisin.
- Uygula: Muğlak bir item için kullanıcı/iş sonucu, scope, belirsizlik, bağımlılık, risk ve doğrulama soruları sorabilmelisin.
- Şimdilik bilmesi gerekmeyen: Organizasyon çapında refinement policy'si, estimation sistemi veya Product Owner coaching modeli tasarlamak.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
İlk okuma
Scrum ekipleri Sprint Planning'de yakın item'ları daha iyi anlayabilmek ve Product Backlog transparency'sini artırmak için refinement yapabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Bazı ekipler ayrı çalışma oturumu planlar, bazıları konuşmaları Sprint içindeki başka anlara dağıtır. Scrum.org bu activity'yi prescribed event saymaz; sıklık, katılım ve format self-managing team'in ihtiyacına göre değişir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
İlk okuma
Yetersiz Refinement, Sprint Planning'i belirsizlik çözme oturumuna çevirebilir; çok erken ve aşırı ayrıntı ise öğrenme geldikçe boşa gider.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Her item için aynı süre, kişi listesi veya doküman derinliği doğru değildir. Yakın zamanda seçilme olasılığı, risk ve belirsizlik uygun derinliği etkiler. Refinement kararın kendisi değil, daha iyi karar için hazırlıktır.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Refinement Scrum'ın zorunlu haftalık event'idir.” Yanlış; ongoing activity'dir ve prescribed formal event değildir.
- “Refinement yalnız story point vermektir.” Yanlış; description, order ve size yanında shared understanding ve item breakdown da ele alınabilir.
- “Product Owner item'ı anlatır, Developers dinler.” Eksik; sizing'i işi yapacak Developers üstlenir ve refinement ortak anlayış gerektirir.
- “Refine edilen item kesin bir sonraki Sprint'e girer.” Yanlış; seçim Sprint Planning'de goal ve mevcut bağlamla yapılır.
- “Bütün Backlog'u ayrıntılı refine etmek gerekir.” Yanlış; değişen bilgi uzak item'lar için erken ayrıntıyı değersizleştirebilir.
Gerilim ve çözüm1. bölüm
Keşfe devam et
İlgili kavramlar
Bağlantılar benzerlik listesi değildir; her biri bu kavramla neden birlikte düşünülmesi gerektiğini açıklar.
Şu an baktığın kavramRefinementCON-005 · 5 editoryal bağlantı
Bağlantı 05 / 05
Birlikte kullanılırTechnical Debt
Bu bağlantı neden var?
Technical Debt item'ının etkisi, scope'u ve erteleme trade-off'u Refinement sırasında görünür hâle getirilebilir.
Neden şimdi?
Refinement sorularının yalnız feature item'larına değil, etkisi ve maliyeti belirsiz Technical Debt item'larına nasıl uygulandığını görmek planlama trade-off'unu derinleştirir.
İş bağlamında gör
Bu kavramın geçtiği senaryolar
Kendi cümlenle düşün
Anlama kontrolü
Bu sorular puanlanmaz ve cevap metnin kaydedilmez. Amaç tanımı ezberlemek değil, kavramı iş bağlamında açıklayabilmektir.
“Refinement toplantısında herkes her Ticket'a story point vermeli” önerisinde Scrum'ın hangi activity/event ve sizing sınırları karıştırılıyor?
“Eski ödeme kodunu refactor et” item'ını order etmeye hazır hâle getirmek için solution tartışmasından önce hangi dört bağlamı netleştirirsin?
Anlama durumun yükleniyor…
“Anladım” bir öz değerlendirmedir; sınav, yetkinlik, işe hazırlık, sertifika, puan veya rozet anlamına gelmez.
Kanıt yüzeyi
Kaynaklar
Kaynak türü ve desteklediği bölümler görünür tutulur. Tek bir şirket pratiği evrensel sektör standardı olarak sunulmaz.
- REF-01The Scrum Guide — 2020
- Tür
- Birincil metodoloji rehberi
- Desteklediği bölümler
- Ongoing activity · detail/order/size · readiness · sizing accountability · Sprint içindeki kullanım
- Erişim
- 20 Temmuz 2026
- Tür
- Resmî metodoloji açıklaması
- Desteklediği bölümler
- Prescribed event olmaması · shared understanding · çalışma biçimi ve sıklık bağlamı
- Erişim
- 20 Temmuz 2026
Şeffaflık
İnceleme bilgisi
Kaynak temelli editoryal beta — uzman incelemesi bulunmuyor.
- İçerik durumu
- Taslak
- Kaynak durumu
- Kaynaklar tamamlandı
- İnceleme durumu
- Editoryal beta
- Son güncelleme
- 20 Temmuz 2026