Backlog Refinement ve AI: gerçekte ne değişiyor

AI'nın Backlog Refinement'ı nasıl değiştirdiğine dair pratik bir inceleme: ne hızlanıyor, riskler nerede ortaya çıkıyor, ekibin zamanı nasıl yeniden dağıtılıyor ve nelerin manuel olarak kontrol edilmesi gerekiyor.

26 Mar 2026 · 06:54 UTC20 dk okuma

Telegram Orijinal

Bu, AI'nın çapraz fonksiyonel geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin ilk makalesi. Aşağıda Backlog Refinement, ile başlayacağım ve sonraki materyallerde Planning, Daily, Review, Retrospective konularını ayrı ayrı ele alıp ardından her şeyi nihai bir genel bakış makalesinde toplayacağım.

Hemen çerçeveyi netleştireyim: aşağıda refinement'tan, backlog item'larının netleştirilmesine yönelik düzenli bir ekip oturumu ve pratiği olarak bahsediyorum, illa ki ayrı bir resmi Scrum etkinliği olarak değil. Bu, terimlerin doğruluğu açısından önemli: Scrum Guide 2020 (RU PDF) içinde refinement, bağımsız bir event değil, ongoing activity olarak tanımlanıyor. Scrum Guide 2020'in Rusça versiyonunda bu düşünce doğrudan şöyle ifade ediliyor: Product Backlog'un netleştirilmesi, detay, sıralama ve boyut eklemeye yönelik sürekli bir faaliyettir.

Backlog Refinement, AI'nın ekibe oldukça somut fayda sağlamaya başladığı ilk yerlerden biri. Bağlamı daha hızlı toplamaya, bir tanım taslağı hazırlamaya, kabul kriterleri taslağını hızla üretmeye, benzer vakaları bulmaya ve açık sorular listesini formüle etmeye yardımcı oluyor. Bu tez, daha uygulamalı çalışmalarla da destekleniyor: örneğin LLM-Assisted Requirements Engineering in Agile MDD çalışmasında kabul kriterleri üretimi ayrıca doğrulanmış, Acceptance Test Generation with Large Language Models endüstriyel vaka çalışmasında ise kullanıcılar AI senaryolarının daha önce gözden kaçan durumları fark etmeye yardımcı olduğunu belirtmişler. Ama tam da bu yüzden burada tuzağa düşmek özellikle kolay: iyi biçimlendirilmiş bir taslağı gerçekten anlaşılır bir görevle karıştırmak.

Bence AI, refinement'ı ekibin artık daha az düşünmesi gerektiği anlamında basitleştirmiyor. Daha çok, onun etrafındaki en pahalı manuel işi ucuzlatıyor — arama, özetleme, paketleme ve ilk ayrıştırma. Bu da ekip tartışmasının değerinin kaybolmadığı, yer değiştirdiği anlamına geliyor: kaostan göreve benzeyen bir şey çıkarmak için daha az, bunun genel olarak işe alınıp alınamayacağını anlamak için daha çok zaman harcanıyor.

“AI ekibin anlaşmasını değil, ona hazırlanacak materyali hızlandırır”

Değişimler neden özellikle Backlog Refinement'ta hissediliyor

Agile pratiğindeki alışılmış ekip ritüellerine ve toplantılarına bakıldığında, refinement AI'nın ortaya çıkışına en duyarlı olanlardan biri olarak öne çıkıyor. Nedeni oldukça basit: refinement çevresinde tarihsel olarak çok fazla manuel entelektüel rutin vardı. Belgelerden, eski ticket'lardan, yazışmalardan ve insanların hafızasından dağınık bağlamı toplamak gerekiyordu. Ham bir iş fikrini anlaşılır bir backlog item'a dönüştürmek gerekiyordu. İş problemini, senaryoyu, kabul kriterlerini, kısıtları, açık soruları, bağımlılıkları ve olası sınır durumlarını formüle etmek gerekiyordu.

AI tam da bu katmana özellikle iyi nüfuz ediyor. Bu, LLM'lerin requirements engineering'de kullanımının bugün nasıl tartışıldığıyla da iyi örtüşüyor: modeller özetleme, gereksinimlerin ilk yapılandırılması, taslak üretimi ve analitik hazırlık desteğinde güçlü, ancak alan doğruluğu, izlenebilirlik ve nihai kararların sorumluluğunun gerektiği yerlerde daha zayıf. Bu anlamda refinement gerçekten de AI'nın faydasının hızla hissedildiği ve güvenilirlik sınırlarının neredeyse anında ortaya çıktığı ilk süreçlerden biri haline geliyor. Bu konu Challenges in applying large language models to requirements engineering tasks, incelemesinde, yeni sistematik derleme Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, ve daha uygulamalı çalışma LLM-Assisted Requirements Engineering in Agile MDD, içinde iyi bir şekilde ele alınıyor.

Ekip, AI ve Agile artefaktları yardımıyla bir backlog item'ı analiz ediyor — AI, refinement'a hazırlığı iyi hızlandırır, ancak anlamın kolektif olarak doğrulanmasının yerini almaz.

AI öncesinde refinement nasıldı

Basitleştirirsek, AI öncesinde refinement çoğu zaman manuel bir anlayış inşası süreciydi. Backlog'a hazır bir görev değil, daha çok bir iş niyeti giriyordu: onboarding'i iyileştirmek, hatırlatıcılar eklemek, yöneticiye yeni bir rapor vermek, gecikmiş başvuru sayısını azaltmak. Ardından Ürün Sahibi, analist veya liderlerden biri bağlamı manuel olarak toplamaya başlıyordu: eski müşteri başvuruları, benzer özellikler, mevcut mimarinin kısıtları, geçerli durumlar, mevcut bildirimler, UI desenleri ve tartışma sırasında aniden ortaya çıkabilecek diğer her şey gözden geçiriliyordu.

Daha sonra aynı kişi veya birkaç kişi, toplananları ilk taslağa dönüştürmeye elle çalıştı: iş sorununu formüle etmek, senaryoyu tanımlamak, kabul kriterlerini yazmak, açık soruları ortaya çıkarmak ve olası kısıtları belirtmek. Ancak böyle bir taslak zaten var olsa bile, toplantı çoğu zaman bağlamı tüm ekibin kafasına yerleştirmekle geçiyordu. Ürün sahibi işin ne istediğini yeniden anlatıyor, analist şimdiye kadar neyin ortaya çıkarıldığını anlatıyor, geliştiriciler mimari kısıtları gündeme getiriyor, QA sınır senaryolarını çıkarıyor, tasarımcı ve frontend ayrı bir ekranın gerekip gerekmediğini ve nerede yer alacağını tartışıyordu.

Aynı vaka: AI olmadan ve AI ile

Genel formüller düzeyinde kalmamak için somut bir vaka ele alacağım. Ürün — kurumsal eğitim için bir B2B LMS platformu. Büyük müşteriler çalışanlarına uyum, güvenlik ve iç düzenlemelerle ilgili zorunlu kurslar atıyor. İş tarafından bir talep geliyor: zorunlu kursu son tarihe kadar tamamlamayan çalışanlara otomatik e-posta hatırlatmaları eklenmesi gerekiyor.

İlk bakışta bu, e-posta göndermeyle ilgili basit bir görev gibi görünüyor. Ancak ilk adımlarda bile burada aslında pek çok çatallanma olduğu anlaşılıyor: kimin kursu tamamlamamış sayılacağı, hatırlatmaların ne zaman gönderileceği, gönderimlerin nasıl tekilleştirileceği, bunun müşteri tarafından nasıl yapılandırılacağı, gönderim günlüğünün gerekip gerekmediği, saat dilimiyle ne yapılacağı, e-postanın hangi dilde olacağı ve arşivlenmiş ve devre dışı bırakılmış kullanıcıların hariç tutulup tutulmayacağı.

AI olmayan modda ekip bu sorulara çoğunlukla uzun elle hazırlık ve toplantının kendisinde kapsamlı bir konuşma yoluyla ulaşıyordu. Önce Ürün sahibi müşteri bağlamını ortaya koyuyordu. Ardından analist elle iç materyalleri gözden geçiriyordu: eski benzer talepleri arıyor, bildirim servisine bakıyor, mevcut atama durumlarını, zamanlayıcı görevlerinin varlığını, dil ayarı ve saat dilimi alanlarını kontrol ediyordu. Bu aşamada bile gerçek kısıtlar ortaya çıkıyordu: sistemde e-posta şablonları var ama yalnızca işlemsel e-postalar için; saat dilimi kullanıcı düzeyinde değil müşteri düzeyinde saklanıyor; gönderim günlükleri yok; üründe ayrı bir hatırlatma modeli de yok.

Bundan sonra analist ilk gereksinim taslağını elle hazırlıyordu, ama taslak yine de olgunlaşmamış kalıyordu. Örneğin, hatırlatma gönderilmesi gereken kesin durumlar, tekilleştirme mantığı, UI için minimum iş kapsamı, dil için yedek seçenek veya ilk sürümün sınırları taslakta yer almamış olabiliyordu. Refinement sırasında ekip görevi doğrudan konuşma esnasında tamamlıyordu. Tam orada, hatırlatmaların yalnızca zorunlu kurslar için gerektiği, not_started ve in_progress durumlarının uygun olduğu, expired durumunun ise ilk sürüme alınmamasının daha iyi olacağı, gönderim günlüğü olmadan destek ve müşteri destek ekibinin hızla sorular içinde boğulacağı ve ayrı bir koruma olmadan zamanlayıcı görevlerinin yeniden çalıştırılmasında tekrarların oluşacağı ortaya çıkıyordu.

AI ile modda aynı vaka farklı görünüyor. Ürün sahibi, müşteri destek ekibinden gelen kısa bir özeti, son müşteri başvurularını ve ham ilk talebi AI'ya yüklüyor. AI müşteri sıkıntılarını hızla gruplandırıyor, tekrarlayan beklentileri öne çıkarıyor ve sorun ifadesini biçimlendirmeye yardımcı oluyor. Analist AI'dan bildirim akışları, atama durumları, zamanlayıcı görevleri, dil ayarı, saat dilimi ve Jira'daki benzer görevlerle ilgili her şeyi ortaya çıkarmasını istiyor. Backend, mevcut bildirim mimarisinin açıklamasını önceden AI üzerinden geçirip teknik bir yaklaşım önermesini istiyor. Frontend ve tasarımcı, ayarların ve gönderim geçmişinin nereye yerleştirilmesinin daha mantıklı olacağını hızla kontrol ediyor. QA başlangıç niteliğinde bir sınır durumları ve zamanlama riskleri listesi çıkarıyor.

Burada genellikle doğal bir soru ortaya çıkar: ya AI bir şeyi atladıysa? Özellikle kaynak tabanı büyük olduğunda böyle bir kısa özete ne kadar güvenilebilir? Araştırmalar ve pratik vakalar burada oldukça ayık bir tablo sunuyor: LLM'ler gerçekten de kullanıcı hikâyeleri, kabul kriteri taslakları ve ilk gereksinim belgeleri üretimini hızlandırabilir, ancak sonucun kalitesi büyük ölçüde girdi bağlamına, alana ve ardından gelen insan kontrolüne bağlıdır. Bu nedenle AI-Generated User Stories: Are They Good Enough? ve LLM-Assisted Requirements Engineering in Agile MDD: gibi daha uygulamalı çalışmaları da akılda tutmak faydalıdır; bunlar güçlü bir taslak üretmenin ve geliştirmeye hazır olmanın aynı şey olmadığını iyi gösteriyor.

Cursor ile çalışma deneyimime göre, uygulama senaryolarında modelin büyük bir kaynak havuzu üzerinde gerekli ilk geçişi oluşturabileceğinden oldukça nadir şüphe duyarım. Daha önemli olan başka bir şey: görevi ne kadar iyi formüle ettiğim, hangi kısıtlamaları belirlediğim, hangi açıklayıcı soruları eklemeyi başardığım ve sonucu tam olarak nasıl organize ettiğim. Bir şüphe duyduğumda, bunu "AI'ya inanıyor muyum, inanmıyor muyum" sorusuyla çözmeye çalışmam — sadece isteği daha da netleştirir, kaynakları ayrıca göstermesini ister, tartışmalı noktaları ayırmasını, gerçekler ile varsayımları ayırmasını veya yanıtı farklı bir çerçeveyle yeniden oluşturmasını isterim. Bu anlamda AI ile çalışmak koçluğa çok benzer: sadece üretimi başlatan değil, modelin düşüncesini doğru yöne yönlendiren kesin sorular sorma becerisi faydalıdır.

Bu elbette benim kişisel deneyimim, evrensel bir kural değil. Belki AI'ya güven, açıklayıcı soruların kalitesi ve sonucun kontrollü doğrulanması üzerine ayrıca bir materyal daha yazarım. Refinement için bu özellikle önemlidir: kaynak havuzu ne kadar büyükse ve kısa özet ne kadar ikna ediciyse, güçlü bir hazırlığı zaten doğrulanmış bir anlayışla karıştırma riski o kadar yüksektir.

"Kaynak havuzu ne kadar büyükse ve kısa özet ne kadar ikna ediciyse, güçlü bir hazırlığı zaten doğrulanmış bir anlayışla karıştırma riski o kadar yüksektir"

Sonuç olarak ekip refinement'a artık ham bir fikirle değil, oldukça güçlü bir taslakla gelir: kullanıcı hikâyesi taslağı, kabul kriterleri taslağı, açık sorular, risk listesi, ön teknik yaklaşım ve UI önerisi vardır. Bu nedenle toplantının kendisi daha kısa ve daha somut hale gelir. Ekip artık temel bağlamı ortaya çıkarmaya o kadar zaman harcamaz ve esas olarak tartışmalı noktaları tartışır: expired, kullanıcı başına ayrı bir saat dilimi yapılmalı mı, ilk sürümde gönderim günlüğü gerekli mi, sabit tetikleyicilerle sınırlı kalınmalı mı, yinelenenlere karşı nasıl korunulmalı ve ilk sürümün sınırları ne olarak kabul edilmeli.

Ekibin ilerlemesi ne anlama geliyor?

Bir ekip AI'yı kullanmaya yeni başladığında, AI çoğunlukla hızlı bir ilk taslak üreticisi olarak çalışır. Ancak olgunluk arttıkça bir sonraki mantıklı adım, yalnızca genel modelle çalışmayı bırakıp daha önce yalnızca insanların hafızasında yaşayan şeyleri kademeli olarak ekibin yönetilen bağlamına taşımaya başlamaktır. Bunlar ürün ilkeleri, kabul kriterleri şablonları, refinement'ta görevin sık reddedilme nedenleri, tipik sınır durumları, mimari kısıtlamalar, tipik açıklayıcı sorular kümesi, kuruluşun iç düzenlemeleri, kuruluş ve ekip düzeyinde Definition of Ready ve Definition of Done ile benzer vakalara ilişkin iyi çözüm örnekleri olabilir.

O zaman ilk taslağın kalitesi gerçekten artmaya başlar. Model aniden "alanı kendi başına anladığı" için değil, ekip kendi düşünme kalıplarını, iç kısıtlamalarını ve doğrulama kurallarını sistematik olarak ona aktarmayı öğrendiği için. Ve burada refinement yalnızca görevin doğrulandığı yer değil, aynı zamanda ekibin kendi AI katmanını kademeli olarak eğittiği yer haline gelir.

Rollere göre neler değişiyor

Aşağıda rolleri yalnızca soyut işlevler olarak değil, zorunlu kurslar için hatırlatmalar içeren simüle edilmiş vakadaki somut eylemler olarak da görmek faydalıdır. AI'sız ve AI'lı mod arasındaki fark gerçekten ancak böyle belirgin hale gelir.

Rol	AI'sız	AI'lı
Ürün Sahibi	Müşteri bağlamını manuel olarak ortaya çıkarır, müşteri destek ekibinin taleplerini bir araya getirir, iş sorununu toplantıda yeniden açıklar.	Anonimleştirilmiş bir girdi hazırlar, AI'dan müşteri acılarını gruplamasını ister, toplantıya sorunun ifadesinin taslağını ve tartışmalı ürün kararlarının listesini getirir.
İş Analisti	Benzer vakaları arar, durumları, kısıtlamaları, bağımlılıkları manuel olarak toplar ve sonra hepsini ilk gereksinim taslağına yeniden yazar.	AI'ya kaynaklara dayalı bir istek düzenler, kısa özeti kaynaklarla karşılaştırır, kabul kriterlerini düzenler, açık soruları ve modelin gözden kaçırmış olabileceklerini kaydeder.
Backend Geliştirici	Genellikle soruna ilk kez refinement'ta derinlemesine dalar, bildirim servisinin kısıtlamalarını ve yinelenme risklerini tartışma sırasında ortaya çıkarır.	Toplantıdan önce teknik seçenekler üzerine ilk geçişi alır, tekilleştirmeyi, zamanlayıcı görevlerini, audit trail'i ve ilk sürümün sınırlarını önceden kontrol eder.
Frontend Geliştirici	Toplantıda tasarımcıyla birlikte ayrı bir ekranın gerekli olup olmadığını, ayarların nerede yaşayacağını ve minimal UI'ya gerçekte nelerin dahil olduğunu anlamaya çalışır.	Toplantıdan önce AI'nın UI entegrasyonu taslağına bakar, ayarlar, durumlar ve arayüz kısıtlamaları konusundaki tartışmalı noktaları önceden işaretler.
Kalite Mühendisi / QA Mühendisi	Esas olarak toplantıda devreye girer, negatif senaryoları, durum çakışmalarını ve zamansal riskleri genel konuşma sırasında ortaya çıkarır.	Toplantıdan önce başlangıç niteliğinde bir sınır durumları listesi alır, AI'nın yinelenenleri, saat dilimlerini, dil fallback senaryolarını ve kullanıcı durumlarına ilişkin istisnaları atlamadığını kontrol eder.
UX/UI Tasarımcısı	Görevi tartışma sırasında anlar ve yerinde yeni bir ekranın, ayarlar bloğunun veya gönderim geçmişinin gerekli olup olmadığını tahmin eder.	Frontend ile birlikte birkaç UI yaklaşımı varyantını hızlıca test eder ve sıfırdan değil, anlamlı bir öneriyle gelir.
Scrum Master	Katılımcıları bir araya getirir, zamanlamayı tutar, kaotik bağlam toplama sürecinde kaybolmamaya yardımcı olur ve tartışma dağıldığında ekibi öze döndürür.	Organizasyonel mekaniğe ve temel bağlamı hizalamaya daha az zaman harcar, tartışmalı kararların kolaylaştırılmasına, açık soruların kaydedilmesine ve tartışma kalitesinin kontrolüne daha fazla zaman ayırır.

Artılar, riskler ve serbest kalan zaman

AI'ın refinement sürecindeki faydası oldukça belirgin. Bağlam daha hızlı toplanıyor, görev taslağı daha hızlı ortaya çıkıyor, tartışma daha kolay başlıyor ve sonuçlar daha iyi paketleniyor. Ancak AI riskleri de tam olarak refinement sürecinde çok erken ortaya çıkıyor. En belirgin risk yanlış netliktir. AI, görsel ve yapısal olarak iyi görünen düzgün backlog item'ları üretebiliyor. Bu nedenle ekip, görevde hâlâ ürün ve teknik boşluklar varken, görevin zaten anlaşıldığı hissine kapılarak kendini kolayca kandırabiliyor.

Burada bazı şeyleri adıyla anmak faydalı olur. Birincisi, otomasyon önyargısı ve aşırı bağımlılık — sistemin önerisini fazla isteyerek kabul etme ve aktif doğrulamadan daha pasif izlemeye geçme eğilimi. NIST'in üretken yapay zekâ profili nde bu doğrudan AI sistemlerine aşırı güven olarak tanımlanıyor ve Automation Bias in AI-Decision Support: Results from an Empirical Study adlı ampirik çalışmada, sistemin algılanan yüksek faydasının hatalarına yönelik yanlış onayı artırabileceği, kullanıcı eğitiminin kalitesinin ise bu etkinin olasılığını azalttığı gösteriliyor. İkincisi, model halüsinasyonu — kaynaklarla doğrulanmamış, inandırıcı ama uydurma bir çıkarım. Refinement için bu özellikle kritik, çünkü AI neredeyse her zaman belgeleri, ticket'ları ve yazışmaları özetleyerek çalışır; bu da riskin yalnızca “güzel ama uydurma kabul kriterleri taslağı” değil, aynı zamanda kaynak bağlamın sessizce çarpıtılması olduğu anlamına gelir. Bu nedenle refinement sürecinde AI daha çok metin üslubunda değil, bağlam gerçeklerinde hata yapar — ve bu risk On Faithfulness and Factuality in Abstractive Summarizationçalışmasında iyi bir şekilde açıklanmıştır. Buradaki pratik panzehir oldukça basittir: modelden gerçekleri hipotezlerden ayırmasını istemek, kaynak referansları talep etmek ve kısa özeti belgelere, ticket'lara ve ekip kararlarına hızla geri çözülebilecek şekilde oluşturmak.

Bir risk katmanı daha var — veri. Yukarıdaki vakada AI müşteri talepleri, sistemin iç açıklamaları ve kullanıcı sinyalleriyle çalışıyor. Bu nedenle ekibin önceden, modele neyin aktarılabileceği ve neyin aktarılamayacağı konusunda anlaşması önemlidir. Üretken AI için risk yalnızca prompt ile sınırlı değildir: kişisel veriler girdide, çıktıda ve hatta modelin memorization/regurgitation yoluyla ortaya çıkabilir. Bu nedenle, çalışmada kişisel veriler veya hassas müşteri bağlamı varsa, temel veri hijyeni ilkeleri zorunlu olmalıdır: prompt'lardaki veri hacmini en aza indirmek, mümkünse girdiyi anonimleştirmek, filtrelenmemiş ham dışa aktarımı modele taşımamak, işleme amacını açıkça anlamak ve sağlayıcının «kişisel verileri işlemiyoruz» veya «model anonim» gibi beyanlarını doğrulanabilir organizasyonel ve teknik kontroller olmadan kabul etmemek. Ayrıca işlemenin hukuki dayanağını, asgari gerekli alan setini, süreç içindeki rolleri ve sorumlulukları ve uygulanabilir olduğu yerlerde veri sahiplerinin bilgilendirilmesine ilişkin gereklilikleri önceden kaydetmek faydalıdır. Senaryo kişisel veriler içeriyorsa ve ölçek veya riskler belirginse, DPIA'nın gerekli olup olmadığını önceden değerlendirmek ve bu kararı ayrıca kaydetmek mantıklıdır. Avrupa bağlamında bu, hem GDPR Article 5ilkeleriyle hem de CNIL'in AI system developmentkonusundaki pratik önerileriyle, ayrıca EDPS guidance on Generative AI ve EDPB Opinion 28/2024ile iyi uyumludur.

Ve burada bir önemli soru daha ortaya çıkıyor: uzmanların serbest kalan zamanı nereye gidiyor. En basit seçenek, bu zamana daha fazla görev sıkıştırmaya çalışmaktır. Daha olgun olanı ise bu tasarrufu kararların kalitesine, teknik borcun azaltılmasına, iç şablonların geliştirilmesine, eğitime, dokümantasyona ve en azından ekibin dikkatinin daha iyi yönetilmesine yatırmaktır. Serinin final derleme makalesinde, AI'ın yalnızca süreci değil, ekip zamanının kullanım kültürünü de değiştirdiğini ayrıca anlatacağım.

Göz ardı edilmemesi gereken yeni gizli maliyetler

Verimlilik konuşması fazla pürüzsüz görünmesin diye, diğer tarafı da eklemek önemli: AI nadiren yeni iş türleri olmadan “saf tasarruf” sağlar. Zamanın bir kısmı artık veri hazırlamaya, kaynaklara erişim kurulumuna, prompt ve şablonların bakımına, kaynakların doğrulanmasına, kararların belgelenmesine ve insan kontrolüne gidiyor. Bu bakış açısı, üretken AI için risk yönetimi uygulamalarıyla da iyi uyumludur: örneğin, NIST'in üretken yapay zekâ profili sadece otomasyonun faydasına değil, aynı zamanda oversight, documentation ve yönetimsel kontrole duyulan ihtiyaca da vurgu yapıyor.

Bir Backlog Refinement için senaryo bazlı işgücü tahmini (senaryo)

Aşağıdakiler "piyasa ortalaması" değil, aynı yedi kişilik ekip için aynı Backlog Refinement'ın senaryo modelidir: PO, BA, backend, frontend, QA, designer ve Scrum Master. Bu, küçük ve iyi anlaşılmış bir story değil, tek bir büyük veya belirgin şekilde belirsiz backlog item için bir tahmindir. Bu sayıların değeri dakika hassasiyetinde değil, maliyet yapısının karşılaştırılmasındadır: zaman eskiden nereye gidiyordu ve şimdi nereye gidiyor.

Bundan sonrası, toplantının kendi süresi değil, tek bir büyük backlog item için insan-saatlerdir — hazırlık, tartışma ve toplantı sonrası kısa iyileştirme. Toplantının kendisi de genellikle kısalır, ancak işin bir kısmı asenkron hazırlığa, açıklayıcı çalıştırmalara ve zorunlu manuel kontrole kayar.

İşgücü hesaplamasına not: tarihsel olarak Scrum Guide 2017 (RU PDF) içinde refinement aynı zamanda ongoing process olarak tanımlanıyordu ve genellikle geliştirme ekibinin mevcut kapasitesinin %10'undan fazlasını almaması gerektiğine dair bir referans vardı. Scrum Guide 2020 (RU PDF) içinde bu referans artık yok, bu nedenle aşağıdaki tablo bir norm olarak değil, iki çalışma modunu karşılaştırmak için senaryo modeli olarak okunmalıdır.

Ayrıca açıkça belirtmek gerekir: aşağıdaki «AI ile» sütunu, bu senaryonun onsuz çalışmadığı temel yeni işi zaten içerir — girdi verilerinin hazırlanması, açıklayıcı sorgular, kısa özetin ilk kontrolü, tartışmalı noktaların doğrulanması ve asgari insan kontrolü. Yani tablodaki nihai fayda, yeni maliyetler hesaba katılmadan önceki "kirli" tasarruf değil, bunların temel düzeyde dahil edilmesinden sonraki daha gerçekçi senaryo tahminidir.

Bu tahminin yeniden üretilebilir olması için basit bir şemayla hesaplanması uygundur: T_AI = T_base × ((1 − p) + p × s) + o; burada T_base — AI olmadan süre, p — hızlandırılan işin payı, s — bu kısımdaki hızlanma katsayısı ve o — veri hazırlama, açıklayıcı sorgular ve sonucu doğrulama için yeni iş.

Aşağıda tam olarak bu temel senaryoya yönelik kalibre edilmiş bir örnek var. Amacı evrensel bir norm kanıtlamak değil, aynı modelin belirli bir vaka için tablodaki sayıları nasıl yeniden üretebileceğini göstermektir. Gerçek bir ekipte bu parametrelerin son 3–5 Backlog Refinement'a göre kalibre edilmesi ve ardından kendi aralığınızı elde etmeniz daha iyidir.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Rol	AI olmadan	AI ile (yeni iş dahil)	Ne değişiyor
Ürün Sahibi	4.5 sa	2.5 sa	Müşteri bağlamını daha hızlı toplar, ancak zamanının bir kısmını girdi hazırlığına ve açıklayıcı sorgulara harcar
İş Analisti	10 sa	5 sa	Daha az manuel arama ve yeniden yazma, daha fazla doğrulama, düzenleme ve AI'ın önemli bir şeyi kaçırıp kaçırmadığının kontrolü
Backend Geliştirici	3.5 sa	2 sa	İlk teknik analizi daha hızlı alır, ancak mimari kısıtlamaları ve tekrar riskini ayrıca kontrol eder
Frontend Geliştirici	3 sa	1.5 sa	UI entegrasyonunu ve ayarları daha hızlı değerlendirir, aynı zamanda tartışmalı noktaların kontrolüne daha erken katılır
Kalite Mühendisi / QA Mühendisi	3 sa	2 sa	Sınır durumları ve geçici riskleri daha erken alır, ancak eksikliklerin ve negatif senaryoların kontrolüne daha fazla dahil olur
UX/UI Tasarımcısı	3 sa	2 sa	İlk UI yaklaşımını daha hızlı toplar ve gereksiz arayüz seçeneklerini önceden eler
Scrum Master	2.5 sa	1.5 sa	Bağlamın organizasyonel hizalanmasına daha az, kararların fasilitasyonuna ve açık soruların kaydedilmesine daha fazla zaman
Toplam	29.5 sa	16.5 sa	Senaryo faydası — temel yeni iş dahil edildikten sonra böyle bir Backlog Refinement'ta yaklaşık 13 insan-saat

Senaryo aralığı: fayda nasıl değişebilir

Senaryo	AI olmadan	AI ile	Net fayda	Ne zaman böyle olur
Temkinli	24–28 sa	18–21 sa	4–10 sa	Kaynaklar eksik, çok fazla manuel kontrol var, ekip AI ile çalışma şablonlarını yeni oluşturuyor.
Temel	28–32 sa	15–18 sa	10–15 sa	Modellenen vaka yaklaşık olarak böyle görünüyor: AI hazırlığı iyi hızlandırıyor, ancak doğrulama için yeni iş zaten hesaba katılmış.
Güçlü	30–36 sa	14–17 sa	13–19 sa	Ekibin iyi kaynakları, tekrarlanabilir şablonları ve net veri hijyeni ile manuel kontrol kuralları var.

AI senaryosunda hangi yeni iş zaten hesaba katıldı

Aşağıdaki tablo birincideki nihai faydayı geçersiz kılmaz. Sadece tasarruf edilen zamanın bir kısmının hangi yeni eylemler sayesinde sürece geri döndüğünü — ve bunun ardından bile net etkinin neden hâlâ belirgin kaldığını açıklar.

Yeni çalışma alanı	AI ile ne ortaya çıkıyor	Bu neden gerekli
Girdi verilerinin hazırlanması	Temizleme, anonimleştirme, gerekli bağlamın özetlenmesi	Modeli çöple aşırı yüklememek ve gereksiz verileri çekmemek için
Açıklayıcı sorgular	Tekrarlanan çalıştırmalar, yanıt çerçevesinin netleştirilmesi, gerçekler ile varsayımların ayrılması talebi	İlk güzel yanıtı nihai anlayış olarak kabul etmemek için
Şablonların ayarlanması	Promptlar, tanım şablonları, sonuç formatı kuralları	AI'ın rastgele metin değil, yararlı ve tekrarlanabilir bir taslak üretmesi için
Gerçeklerin kontrolü	Kaynak bağlantılarının, terimlerin, durumların ve kısıtlamaların kontrolü	Toplantıdan önce modelin halüsinasyonlarını ve yanlış netliği yakalamak için
Güvenin belgelenmesi	Manuel olarak tam olarak neyin kontrol edildiğinin ve sonuca neden güvenilebileceğinin kaydı	Ekibin sorumluluğu güzel bir taslakla değiştirmemesi için

Aşamalara göre farklar

Aşama	AI olmadan	AI ile
Toplantı öncesi bağlam toplama	Belgelerde, ticket'larda ve insanların hafızasında uzun manuel arama	Kaynaklar üzerinden ilk geçiş ve kısa özet belirgin şekilde daha hızlı yapılıyor
İş tanımı taslağı	Manuel yazılıyor ve çoğu zaman ham kalıyor	Ekibin eleştirebileceği ve netleştirebileceği güçlü bir ön çalışma var
Backlog Refinement'in kendisi	Zamanın çoğu anlayışı hizalamakla geçiyor	Odak tartışmalı kararlara, bağımlılıklara ve ilk sürümün sınırlarına kayıyor
Toplantı sonrası iyileştirme	İş tanımını neredeyse baştan yazmak sık sık gerekiyor	Sonuçlar zaten iyi paketlenmiş ve daha az manuel iyileştirme gerektiriyor

Refinement'a AI hazırlığının kalite kontrol listesi

Önemli: bu Definition of Ready, Scrum Guide'ın bir parçası değil, ekibin iç pratiğidir. Burada yanlış netlik, eksiklikler ve AI hazırlığında belirsiz sorumluluklara karşı bir koruma olarak gereklidir.

AI taslağı için Definition of Ready

Olgular varsayımlardan ayrılmıştır: ekip neyin kaynaklardan alındığını, neyin model tarafından önerildiğini anlar.

Kilit ürün ve teknik iddialar için kaynaklara bağlantılar veya anlaşılır işaretler vardır.

Açık sorular düzgün metnin altında saklanmaz, açıkça ortaya konur.

Alan terimleri, durumlar, kısıtlamalar, roller ve bağımlılıklar kontrol edilmiştir.

Her kilit iddia için kanıt düzeyi anlaşılırdır: bu bir kaynaktan gelen olgu mu, çalışma hipotezi mi yoksa model varsayımı mı.

Sınır durumları, olumsuz senaryolar ve geçici riskler ayrıca kontrol edilmiştir.

Hangi verilerin modele aktarılamayacağı ve hangi veri hijyeni önlemlerinin uygulandığı anlaşılırdır.

İddia türlerine göre doğrulama sahipleri atanmıştır: iş mantığı, mimari uygulanabilirlik, test edilebilirlik ve veriyle çalışma.

Ekip, AI taslağının neredeyse hazır bir görev değil, tartışma için ham malzeme olduğu konusunda anlaşmıştır.

Bu kontrol listesinin fazla soyut kalmaması için, e-posta hatırlatmalarıyla ilgili vakamızda nasıl görüneceği aşağıda:

AI, not_started, in_progress ve expired durumlarının dahil edilmesini öneriyor — ekip, expired durumunun ilk sürüm için doğrulanmış bir kural değil, henüz bir hipotez olduğunu açıkça işaretliyor.
Kısa özette bildirimlerin kullanıcının saat dilimine göre gönderilmesi gerektiği söyleniyor — backend bunu kaynaklarla karşılaştırıyor ve mevcut sistemde saat diliminin yalnızca istemci düzeyinde saklandığını, saat dilimleri arası geçişlerin ve DST'nin ayrıca kontrol edilmesi gerektiğini doğruluyor.
AI, gönderim geçmişini çözümün "bariz" bir parçası olarak ekledi — Ürün Sahibi ve BA, burada ayrıca denetim ve destek yükü sorunu olduğu için bunun ilk sürümün zorunlu bir parçası mı yoksa bir sonraki sürümün iyileştirmesi mi olduğuna ayrıca karar veriyor.
QA yalnızca sınır durumları listesi değil, zamanlayıcı görevlerinin yeniden çalıştırılmasında tekrarları, dil fallback senaryolarını, archived ve devre dışı bırakılmış kullanıcılar için istisnaları ve son tarihler etrafındaki olumsuz senaryoları kontrol etmek için somut bir görev alıyor.
Backend, rate limit'leri, throttling'i, deliverability'yi ve sistemin yeniden gönderimlerde ve sağlayıcı hatalarında nasıl davranacağını ayrıca kontrol ediyor.
PO ve BA ayrıca bildirim politikasını doğruluyor: kime hatırlatma gönderilebilir, nerede opt-out veya müşteri istisnaları gerekir ve zorunlu kurslar için kabul edilebilir davranış nedir.

Böyle bir vaka için, genellikle üretime yakın aşamada ortaya çıkan iki pratik konuyu da ayrıca konuşmak faydalıdır: "e-posta neden ulaşmadı" konusunda düzgün bir teşhis yoksa deliverability hızla destek ve müşteri destek ekibine yük haline gelir; quiet hours ve takvim pencereleri ise çoğu zaman "ek bir seçenek" değil, müşterinin kurumsal bir gereksinimi olarak ortaya çıkar.

Kim neyi manuel olarak kontrol ediyor

Neyi kontrol ediyoruz	Sahibi kim	LMS vakasında örnek
Amaç ve ürün politikası	PO ve BA	Kime ve ne zaman hatırlatma gönderileceği, hangi istisnaların kabul edilebilir olduğu, ilk sürümün sınırlarının nerede olduğu.
Kuralların ve durumların doğruluğu	BA	Hangi durumların "tamamlamadı" sayıldığı, `expired` ile ne yapılacağı ve bunun kaynaklarla nerede doğrulandığı.
Mimari kısıtlamalar	Backend geliştirici	Tekilleştirme, zamanlayıcı görevleri, idempotentlik, denetim günlüğü, rate limit'ler ve yeniden gönderimlerde davranış.
İlk sürümün UI sınırları	Frontend geliştirici ve UX/UI tasarımcısı	Ayarların nerede olduğu, ayrı bir geçmiş ekranının gerekip gerekmediği ve hangi arayüz senaryolarının gerçekten ilk sürüme dahil olduğu.
Olumsuz ve zamansal senaryolar	Kalite mühendisi / QA mühendisi	DST, saat dilimleri, dil fallback senaryoları, archived ve devre dışı bırakılmış kullanıcılar için istisnalar ve zamanlayıcı görevlerinin yeniden çalıştırılmasında tekrarlar.
Kararların ve açık soruların kolaylaştırılması	Scrum Master	Neyin zaten kararlaştırıldığı, neyin tartışmalı kaldığı ve ekibin nerede bilinçli bir uzlaşma kabul etmesi gerektiği.
Veri hijyeni ve veri uygunluğu	PO/BA ve varsa Security veya DPO	Modele neyin aktarılabileceği, neyin anonimleştirilmesi gerektiği ve AI hazırlığı başlatılmadan önce hangi kontrollerin zorunlu olduğu.

Ekibe ne önerirdim

AI taslağını sırf iyi göründüğü için hazır bir görev saymamak.
Ekip toplantı öncesinde bağlamın hangi bölümlerini elle, hangilerini toplantı sırasında kontrol etmek zorunda olduğunu açıkça kararlaştırmalı.
Yalnızca genel sohbeti "olduğu gibi" kullanmakla kalmayıp, kendi ürün ve süreç kalıplarını kademeli olarak ekip AI katmanına taşımalı.
Hazırlık hızlandı diye refinement'ı mekanik olarak kısaltmamalı.
Serbest kalan zamanın nereye gideceğine bilinçli olarak karar vermeli: kaliteye, öğrenmeye, dokümantasyona, teknik borca veya ekibin dikkatini yenilemeye.

Bu senaryonun uygulanabilirlik sınırlarını ayrıca hatırlamak önemli. AI'nın etkisi dokümantasyonun olgunluğuna, iç kaynakların erişilebilirliğine, ürünün alan karmaşıklığına ve ekibin örtük bilgiyi tekrarlanabilir bağlama dönüştürme becerisine bağlı olarak çok farklı olacaktır. Kaynak verilerin zayıf olduğu yerlerde AI paketlemeyi hızlandırabilir, ancak kararların kalitesini mutlaka iyileştirmez.

Sonuç

Çok kısaca söylemek gerekirse, AI'nın refinement için ana etkisini şöyle ifade ederdim: AI ekibin anlaşmasını değil, o anlaşmaya yönelik malzemenin hazırlanmasını hızlandırır. Bu nedenle refinement girişte hızlanır: bağlam daha hızlı toplanır, taslak daha hızlı ortaya çıkar, temel sorular ve riskler daha hızlı belirlenir, sonuçlar daha hızlı paketlenir.

Ancak bu, refinement'ı otomatik olarak kolaylaştırmaz. Çünkü hazırlık maliyeti düştükçe, AI'nın henüz gerçekten iyi yapamadığı şeylerin değeri artar: alanı anlamak, gerçek kısıtları hissetmek, sahte netliği fark etmek, verilere özenle davranmak ve ekibin bilinçli ödünleşimler yapmasına yardımcı olmak.

Bu nedenle refinement'ta AI'ya bakmanın en iyi yolu şudur: pratiğin etrafındaki pahalı el emeğinin bir kısmını ortadan kaldırır, ancak anlamın insan tarafından doğrulanmasını daha da önemli hale getirir. Backlog öğeleri üretmek kolaylaştıkça, hangilerinin gerçekten tartışmaya hazır, hangilerinin ise sadece iyi göründüğünü anlamak daha önemli hale geldi. Serinin sonraki makalelerinde bu kaymanın yalnızca süreci değil, ekip zamanının kullanım kültürünü de nasıl etkilediğini görmek ilginç olacak.

Kaynaklar ve referanslar

← Tüm denemeler