Ana sayfa → Bölüm 18
Product Owner: Ticket Yazıcı Değil, Hayır Diyen Kişi
Pazartesi, 29 Eylül 2025, 09:40, sprint planning. PO’muz Gizem ekranı açtı: “Bu sprint’in öncelikleri” başlığının altında 7 madde vardı, yedisi de P1. “Hangisi önce?” diye sordum. “Hepsi,” dedi. “Üç ayrı kişi söz verdi.”
- PO’nun asıl yetkisi sıralama. Ticket yazmak, talep toplamak, toplantıya girmek bu işin yan ürünleri. Sırayı başkası koyuyorsa PO yoktur, kâtip vardır.
- Herkese evet diyen PO, aslında hayır diyemeyen PO’dur. Gizem’in hayırları başının üstünden çözülüyordu. Altı sprint’te sprint’e giren 45 story’nin 30’u başka kanallardan geldi.
- Yetki yazılı olmalı. 45 dakikalık bir toplantı ve tek paragraflık bir e-posta: “Sırayı Gizem koyar. Sırayı değiştirmek isteyen ona gelir.” Oran %67’den %9’a indi.
- Vekil sırayı değiştirmez. Gizem izindeyken vekil bendim ve sprint’in %45’ini teknik işle doldurdum. Review’da müşterinin göreceği şey kalmamıştı.
- PO “ne ve hangi sırayla”, teknik lider “nasıl ve ne kadar”. Teknik iş ayrı listeye değil, aynı sıraya girer; gerekçesi rakamla gelir.
Sahadan: yedi P1 ve üç ayrı söz
Gizem ekibe iki yıl önce iş analisti olarak gelmişti. Bir yıl sonra unvanı Product Owner oldu. Unvanla birlikte gelmeyen tek şey yetkiydi. Müşterinin operasyon direktörü istediğini ona değil, bizim genel müdüre söylüyordu. Satış tarafı yeni sözleşme görüşmelerinde tarih veriyordu. Müşterinin muhasebe ekibi doğrudan geliştiricilere yazıyordu. Gizem bunların hepsini ticket’a çeviriyor ve hepsine P1 yazıyordu.
Bunun sebebi zayıflık değildi. Gizem iki kez hayır demeyi denemişti. İkisinde de talep sahibi bir üst kata çıkmış, genel müdürden “bunu araya alın” mesajı gelmişti. Üçüncüsünde artık denemedi. Hayırı başının üstünden çözülen bir PO, evet demeyi öğrenir.
Hatanın bir kısmı da benimdi. Gizem’den iyi ticket istiyordum: kabul kriterleri, ekran görüntüleri, uç durumlar. Onu ticket kalitesiyle ölçüyordum. Satış müdürü bana doğrudan geldiğinde de onu Gizem’e yönlendirmek yerine “bakarız” diyordum. Yani ben de onun sırasını atlayanlardan biriydim.
O planning’den sonra son altı sprint’e baktım. Temmuz–Eylül arasında sprint’e 45 story girmişti. Bunların 30’u, yani %67’si, Gizem’in kendi sıralamasından değil, “yukarıdan” gelen bir istekle girmişti. Backlog’da 212 madde vardı ve 64’ü P1 etiketliydi. Her üç P1’den biri bir yıldan eskiydi.
Vekil olduğum üç hafta
Bu tablonun en kötü satırı benim yazdığım satırdı. 11–29 Ağustos arasında Gizem izindeydi ve vekil olarak ben kaldım. Teknik lider olarak aylardır ertelenen işler aklımdaydı: log düzenlemesi, eski bir raporlama modülünün temizliği, test ortamının otomasyonu. 18 Ağustos planning’inde sprint’e 9 madde aldık. 4’ü teknik işti ve 33 adam-günün 15’ini tutuyordu; sprint’in %45’i.
29 Ağustos’taki review’da müşteri tarafına gösterecek dört küçük değişiklik vardı. Operasyon direktörü ekrana baktı ve sordu: “İki haftada bizim için çıkan bu mu?” Teknik işlerin hepsi gerekliydi. Ama sıralama kararı benim değildi. Vekilliği, kendi listemi öne almak için bir fırsat olarak kullanmıştım.
PO ne işe yarıyor?
Scrum Guide PO’yu tek bir hesap verebilirlikle tanımlar: ürünün değerini en üst düzeye çıkarmak. Bunun elle tutulur hâli backlog’un sırasıdır. Ekip bir sonraki işi sıradan çeker; sırayı koyan, ekibin önümüzdeki haftalarda ne üreteceğine karar verir.
Diğer her şey bu kararın etrafında döner. Backlog Refinement yazısında elemenin ürün tarafının işi olduğunu, Grooming yazısında da PO’nun işinin “ne” değil “neden” olduğunu yazmıştım. İkisi de doğru, ama ikisi de bir ön koşula dayanıyor: PO’nun eleme ve sıralama kararının gerçekten geçerli olması. Kararı başkası bozabiliyorsa elemenin de, bağlam aktarmanın da anlamı kalmaz.
Scrum Guide bunu da açıkça söyler: PO bir kişidir, bir komite değildir. Sırayı değiştirmek isteyen, PO’yu ikna etmeye çalışır. Organizasyon da PO’nun kararlarına saygı duymalıdır. Bizde bu son cümle eksikti.
Nasıl olmalı?
1. Yetkiyi yazılı yap
9 Ekim’de Gizem, operasyon direktörü, bizim genel müdür ve ben 45 dakikalık bir toplantı yaptık. Önce 30/45 rakamını gösterdim. Sonra tek bir öneri getirdim. Toplantıdan tek paragraflık bir e-posta çıktı:
“Backlog’un sırasını Gizem koyar. Sırayı değiştirmek isteyen, ekibe ya da genel müdüre değil, Gizem’e gelir. Operasyon direktörü ile Gizem her Perşembe 30 dakika sırayı birlikte gözden geçirir. Gizem’in kararına itiraz edilecekse bu toplantıda edilir; toplantı dışında sıra değişmez.”
Genel müdürün bu e-postaya “onaylıyorum” yazması, bütün sürecin en önemli adımıydı. İlk itiraz ona gelecekti ve geldi.
2. P1 etiketini kaldır, sıra numarası koy
Öncelik etiketi yarışmayı gizler: yedi P1 aynı rütbede görünür. Sıra numarası yarışmayı açık eder: 1 ile 2 aynı yerde duramaz. Etiketleri kaldırdık ve backlog’un ilk 30 maddesini 1’den 30’a sıraladık. Gerisi “sırasız” kaldı; sırasız madde sprint’e girmez.
Kasım sonuna kadar 212 maddelik backlog 87’ye indi. Gizem 125 maddeyi “yapmayacağız” notuyla kapattı. Sonraki üç ayda bunlardan 4’ü geri geldi. Yani kapatılan her 31 maddeden sadece biri gerçekten istenen bir işti.
3. Hayırın biçimi
Stratejik düzeyde neye hayır dendiğini Teknik Strateji yazısındaki hayır listesinde anlatmıştım; o yılda bir yazılan bir seçim. PO’nun hayırı ise günlük: tek tek taleplere verilen cevap. Gizem’le bunun için dört cevap kalıbı yazdık:
| Cevap | Ne zaman | Örnek cümle |
|---|---|---|
| Evet, şu sırada | Talep değerli ve sıraya girebilir | “Evet, 6. sırada. Yaklaşık üç hafta sonra başlar.” |
| Evet, ama karşılığında | Talep sıranın başına geçmek istiyor | “Öne alabilirim; o zaman 2. sıradaki iş iki hafta kayar. Hangisini seçersiniz?” |
| Şimdi değil | Değerli ama sıradaki işlerden daha az | “Sırasız listeye aldım. Mart’taki gözden geçirmede yeniden bakacağız.” |
| Hayır | Ürünün yönüyle uyuşmuyor | “Bunu yapmayacağız, çünkü…” ve tek cümlelik gerekçe |
İkinci satır en çok kullanılanı oldu. “Hangisini seçersiniz?” sorusu kararı talep sahibine geri veriyor ve çoğu zaman talep sahibi kendi isteğini geri çekiyor. İlk ay Gizem 23 talebe “şimdi değil” ya da “hayır” dedi. Bunlardan 2’si Perşembe toplantısına itiraz olarak geldi. Direktör birinde sırayı değiştirdi, diğerinde Gizem’in yanında durdu. İtirazın kanalı değişmişti; artık genel müdürün kapısı değil, bir takvim davetiydi.
PO ile teknik lider: sınır nerede?
Vekillik hatam bu sınırı çizmem gerektiğini gösterdi. Teknik lider teknik işin önemini en iyi bilen kişidir; ama sıranın sahibi değildir. PO ise değeri en iyi bilen kişidir; ama işin nasıl yapılacağına karar vermez. Karışıklık, ikisi birbirinin alanına girdiğinde başlıyor.
| Karar | Karar veren | Danışılan |
|---|---|---|
| Backlog’un sırası | PO | Teknik lider, paydaşlar |
| Teknik işin sıraya girmesi | PO | Teknik lider gerekçeyi rakamla getirir |
| İşin nasıl yapılacağı | Ekip (teknik lider kolaylaştırır) | PO, yalnızca kısıt varsa |
| Ne kadar süreceği, sprint’e ne sığacağı | Ekip | PO |
| İşin kabulü | PO | QA |
| Sprint iptali | PO | Ekip |
İkinci satır pratikte en çok tartışılan satır. Teknik iş için ayrı bir liste tutmuyoruz; aynı sıraya giriyor. Benim işim Gizem’e “bu önemli” demek değil, rakam getirmek: “Eski raporlama modülüne dokunan her story ortalama 1,5 gün fazladan test istiyor. Son altı sprint’te 9 kez dokunduk.” Bu cümleyle raporlama temizliği sıranın 4. maddesi oldu. “Bu teknik borç, yapmamız lazım” cümlesiyle aylarca sırasız kalmıştı.
Vekil kuralı da buradan çıktı: vekil sırayı uygular, değiştirmez. Sıradaki işin anlaşılmasına yardım eder, kabul kararlarını erteler ya da sıradaki basit kararları verir. Yeni sıra kararlarını PO dönünce PO verir.
- Sıralama yetkisini yazılı yap, bir üst yöneticiye onaylat
- Öncelik etiketi yerine sıra numarası kullan
- İtiraz için tek bir kanal ve düzenli bir toplantı koy
- Teknik işi aynı sıraya rakamlı gerekçeyle sok
- Sana doğrudan gelen talebi PO’ya yönlendir; kendin de
- PO’yu ticket kalitesiyle ölçmek
- PO’nun hayırını bir üst katta bozmak
- Backlog’da her şeyi saklamak; kapatılan madde geri gelebilir
- Vekilliği kendi listeni öne almak için kullanmak
- Sırayı bir komiteye bırakmak
4. PO’nun takvimini değiştir
Yetki kâğıtta verilince iş bitmedi; Gizem’in haftası da değişmek zorundaydı. Ekim başında takvimine birlikte baktık. Haftasının yaklaşık 20 saati ticket yazmaya ve talep toplamaya gidiyordu. Sıralamaya, yani asıl işine ayırdığı düzenli bir zaman yoktu; sıra, planning’den önceki akşam veriliyordu.
İki şeyi değiştirdik. Birincisi, ticket’ın detayı artık Gizem’in tek başına yazdığı bir belge değil. Kabul kriterlerini grooming’de ekiple birlikte yazıyorlar; Gizem “neden”i ve sınırları getiriyor. İkincisi, Salı ve Perşembe sabahları birer saat “sıra saati” oldu: yeni talepleri okuyor, dört cevap kalıbından birini seçiyor ve cevabı aynı gün yazıyor. Ticket’a giden süre haftada 8 saate indi. Açığa çıkan zamanın çoğu, müşterinin işi gerçekte nasıl yaptığını izlemeye gitti.
Nasıl bozuluyor?
| Biçim | Belirti | Karşılığı |
|---|---|---|
| Ticket yazıcı PO | Ticket’lar mükemmel, sıra başkasının | Sıralama yetkisini yazılı ver |
| Komite PO | Her sıra kararı bir toplantı bekliyor | Tek karar verici, danışılanlar ayrı |
| Aracı PO | Asıl karar verici hiç odada değil | Karar vericiyi haftalık sıra toplantısına al |
| Vekil PO | İzin döneminde sıra değişiyor | Vekil sırayı uygular, değiştirmez |
| Her şeye evet diyen PO | Backlog büyüyor, P1 sayısı artıyor | Hayırın bir üst katta bozulup bozulmadığına bak |
Ne değişti?
| Ölçü | Temmuz–Eylül (6 sprint) | Kasım–Ocak (6 sprint) |
|---|---|---|
| Sprint’e giren story | 45 | 46 |
| PO’nun sırası dışından gelen | 30 (%67) | 4 (%9) |
| Backlog büyüklüğü | 212 madde, 64 P1 | 87 madde, ilk 30’u sıralı |
| Kapatılıp geri gelen madde | — | 125’te 4 |
Kasım–Ocak arasındaki 4 story de sıradışı değildi aslında; Perşembe toplantısında direktörle Gizem’in birlikte öne aldığı işlerdi. Fark şurada: artık bir istisnaydılar ve kimin kararı olduğu biliniyordu.
Kontrol listesi
- Son altı sprint’te sprint’e giren işin kaçını PO’nun sırası belirledi?
- PO’nun son hayırı bir üst katta bozuldu mu?
- Sıralama yetkisi yazılı mı, bir üst yönetici onayladı mı?
- Backlog’da kaç tane P1 var, sıra numarası var mı?
- İtirazın gideceği tek bir kanal var mı?
- Bana doğrudan gelen son talebi PO’ya yönlendirdim mi?
- Teknik iş aynı sıraya rakamlı gerekçeyle mi giriyor?
- PO izne çıkınca vekilin neyi değiştirmeyeceği yazılı mı?
Sonuç
29 Eylül sabahı Gizem’in ekranındaki yedi P1, bir PO’nun değil, üç ayrı kişinin sıralamasıydı. Gizem’in eksiği beceri değildi. Eksik olan, onun kararının geçerli olduğunu söyleyen tek paragraftı.
O paragrafı yazmak 45 dakika sürdü. Zor olan, sonrasında ona uymaktı: satış müdürünü Gizem’e yönlendirmek, vekilken sırayı değiştirmemek, teknik işi rica ederek değil rakamla savunmak. İlk uymayan bendim.
Ticket yazmayı herkes öğrenebilir. PO’yu PO yapan, hayırının geçerli olmasıdır.
PO’nun tek kişi olması, backlog sırasından hesap verebilir olması ve kararlarına organizasyonun saygı duyması gerektiği Scrum Guide’dan (Schwaber & Sutherland, 2020). Dört cevap kalıbı, vekil kuralı ve teknik işin rakamlı gerekçeyle aynı sıraya girmesi kendi sahamdan.