Ana sayfa → Bölüm 07
Story Point: Süre Değil, Belirsizlik
12 Haziran 2025, Perşembe, yol haritası toplantısı. Direktör velocity grafiğimize baktı: “Ödeme ekibi sprint’te 81 puan kapatıyor, siz 58. Bir de şunu söyleyin: 1 puan kaç saat?” Telefonun hesap makinesini açtım ve cevap verdim: “Beş buçuk saat civarı.” O cümlenin bedelini üç ay ödedik.
- Puan süreyi değil, belirsizliği ölçer. Bizde 5 puanlık işler 1,5 ile 9 iş günü arasında sürdü. Puan büyüdükçe ortalama değil, aralık büyüyor.
- Saate çevrildiği an puan ölür. “1 puan = 5,5 saat” dediğim günden sonra oyların ayrıştığı tur oranı %31’den %8’e indi. Belirsizlik azalmamıştı; sadece konuşulmuyordu.
- Velocity kıyas aracı değildir. 81 ile 58 iki farklı cetvel. Kıyas başladıktan sonra aynı on işi kör olarak yeniden oyladık; yedisi daha yüksek puan aldı.
- #NoEstimates’i altı sprint denedik. Story saymak tahmini iyileştirdi, planning’i 95 dakikadan 55’e indirdi. Ama belirsizlik sinyali kayboldu; sprint ortası sürprizler 3’ten 7’ye çıktı.
- Kalan düzen: yukarıya story sayısı ve aralık gider, asla saat. Puan ekip odasından çıkmaz ve tek bir soruya hizmet eder: bu işte bilmediğimiz ne?
Puan ne işe yarıyor?
Planning poker’ın nasıl oynandığını ve neden hızlı bitmesi gerektiğini Sprint Planning bölümünde anlattım. Burada oyunun kendisine değil, masaya konan sayıya bakıyorum: o sayı neyi ölçer, neyi ölçmez?
Kitap tanımı şudur: story point bir işin büyüklüğünü efor, karmaşıklık ve belirsizlik birlikte düşünülerek, başka işlere göre göreli olarak söyler. Bu tanımda “saat” kelimesi yok ve bu bir unutkanlık değil. Puan göreli olduğu için ekibe aittir. “Bu iş, geçen ay yaptığımız rapor alanından biraz büyük” cümlesi sadece o raporu yapan ekip için bir anlam taşır.
Sahada puanın en değerli kısmı sayının kendisi değil, oylar arasındaki farktı. Biri 3, biri 13 gösterdiğinde masada bir bilgi farkı vardır. Birisi diğerinin bilmediği bir şeyi biliyordur: eski bir modül, belgesiz bir entegrasyon, geçen sefer yaşanan bir sürpriz. O fark konuşulduğunda belirsizlik planning’de yüzeye çıkar. Konuşulmadığında sprint’in ortasında çıkar.
Puanın ölçmediği şeyler de en az ölçtükleri kadar önemli. Puan kişinin hızını ölçmez: aynı 3 puanlık işi Mehmet bir günde, yeni gelen biri üç günde bitirir ve ikisi de doğru oylamıştır. Puan değeri ölçmez: 13 puanlık bir iş müşteriye hiçbir şey kazandırmayabilir, 1 puanlık bir düzeltme çağrı merkezinin günde bir saatini kurtarabilir. Puan süreyi de ölçmez, ama bu yazının geri kalanı zaten o yanlış anlamanın hikâyesi.
Puan ile süre arasındaki gerçek ilişki
Direktörün sorusundan sonra yapmam gereken şeyi, cevabı verdikten sonra yaptım. Ekim 2024 ile Mart 2025 arasındaki 12 sprint’te biten 62 maddenin puanını ve “Devam ediyor” sütununda geçirdiği süreyi Jira’dan çektim. Bir iş gününü 8 saat saydım.
| Puan | Madde | Medyan (iş günü) | En kısa – en uzun | Puan başına saat |
|---|---|---|---|---|
| 1 | 9 | 0,6 | 0,3 – 1,2 | 4,8 |
| 2 | 12 | 1,1 | 0,5 – 2,5 | 4,4 |
| 3 | 13 | 1,9 | 0,8 – 4 | 5,1 |
| 5 | 14 | 4,2 | 1,5 – 9 | 6,7 |
| 8 | 9 | 8,5 | 3 – 19 | 8,5 |
| 13 | 5 | 17 | 6 – 31 | 10,5 |
İki şey görünüyor. Birincisi, “1 puan kaç saat?” sorusunun tek bir cevabı yok. Küçük işlerde puan başına 4–5 saat, büyük işlerde 10 saatin üstü. Benim “beş buçuk” cevabım kapasite saatini velocity’ye bölmekten geliyordu: 5 kişi (altıncı kişi operasyon kolundaydı) × 10 gün × 6,5 verimli saat = 325 saat; 325 / 58 ≈ 5,6. Aritmetik doğruydu, soru yanlıştı.
İkincisi daha önemli: puan büyüdükçe süre değil, aralık büyüyor. 2 puanlık bir işte en kısa ile en uzun arasında iki gün var. 8 puanlık işte 16 gün, 13 puanlık işte 25 gün. 8 ve 13 puan “büyük iş” demek değil, “ne kadar süreceğini bilmiyoruz” demek. Backlog Refinement bölümündeki T-shirt ölçeğinin üssel olmasının sebebi de buydu: iş büyüdükçe artan şey sadece süre değil, belirsizlik.
Sahadan: saate çevrilen puan
1. Oyların ayrışması kayboldu
12 Haziran’dan sonra “5,5 saat” ekip kanalına, oradan yol haritası sunumuna geçti. Planning poker’da bir şey değişti ve ilk iki sprint fark etmedim. İnsanlar kartı göstermeden önce kafalarında saat hesaplamaya başladı. “İki günlük iş, 16 saat, 3 puan diyelim.” Herkes aynı hesabı yapınca herkes aynı kartı gösterdi.
Planning notlarımızdan saydım. O toplantıdan önceki altı sprint’te, en düşük ile en yüksek kart arasında en az iki kart fark olan turların oranı %31’di. Sonraki üç sprint’te %8. Belirsizlik azalmamıştı. Sadece artık masaya gelmiyordu.
2. 1,5 sprint denen iş 5 sprint sürdü
“Bildirim tercihleri” epic’i 89 puandı. Sunumda hesap şöyle yapıldı: 89 × 5,5 = 490 saat, sprint başına 325 saat, yani 1,5 sprint. 23 Haziran’da başladık, yol haritasına “Temmuz ortası” yazıldı. Epic 29 Ağustos’ta bitti.
Gecikmenin çoğu iki 13 puanlık maddeden geldi. Biri SMS sağlayıcısıyla yeni bir izin entegrasyonuydu. Oylamada Ayşe 21 göstermişti: “Sağlayıcının onay süreci belli değil.” Diğerleri 5 ve 8 göstermişti. Eskiden bu fark on dakikalık bir konuşma ve muhtemelen bir spike demekti. O gün “ortası 13 olsun” deyip geçtik, çünkü kafamızda 13 puan 71,5 saatti ve bu yeterince büyük görünüyordu. Madde 23 iş günü sürdü; sağlayıcının onayı tek başına 11 gün aldı.
3. Kıyas başlayınca puan şişti
“Ödeme ekibi 81, siz 58” cümlesi ekibe ulaştı. Kimse bilerek bir şey yapmadı ama oylamada “bu biraz daha zor aslında” demek kolaylaştı, “bence bu 3” diye itiraz etmek zorlaştı. Eylül’de bir test yaptım: bahar aylarında biten 10 maddeyi, eski puanlarını göstermeden ekibe yeniden oylattım. Yedisi eskisinden yüksek puan aldı, üçü aynı kaldı, hiçbiri düşmedi. Ortalama 3,2’den 4,6’ya çıktı.
Şişme böyle oluyor: yalan yok, anlaşma yok, sadece referans kayıyor. Ölçü birimi yavaşça küçülüyor ve aynı iş daha çok puan ediyor. Ödeme ekibinin 81’i ile bizim 58’imiz zaten iki farklı cetveldi. Kıyas, bizim cetvelimizi de bozdu.
#NoEstimates denemesi: altı sprint story saymak
Puanın bozulduğunu görünce onu tamamen bırakmayı denedik. 4 Ağustos ile 24 Ekim arasında, altı sprint boyunca kural şuydu:
1. Puan yok. Planning'de tek soru: "Bu story 3 gune sigar mi?"
2. Sigmiyorsa bolunur. Her parca kullaniciya gorunen bir degisiklik olmali.
3. Tahmin = son 6 sprint'in story sayisi, tek sayi degil aralik.
4. Yukariya giden rapor: kalan story sayisi / sprint basina story araligi.
# ornek: kalan 20 story, sprint basina 5-7 story
# 20 / 7 = 2,9 20 / 5 = 4,0 -> "3 ile 4 sprint arasi"
İkinci kuraldaki “kullanıcıya görünen” şartı ilk günden yoktu. Beşinci sprint’te story sayısı 13’e çıkacaktı. Baktım, story’lerin bir kısmı “backend” ve “frontend” diye ikiye bölünmüştü. Sayı artmış, gösterilecek iş artmamıştı. Puanın şişmesinden kaçarken sayının şişmesine yakalanmıştık. Şartı ekledik ve o sprint’i 9 saydık.
| Ölçü (6 sprint) | Puan (Mayıs – Temmuz) | Story sayma (Ağustos – Ekim) |
|---|---|---|
| Planning süresi (ortalama) | 95 dk | 55 dk |
| Taahhüt isabeti (biten / alınan) | %74 | %78 |
| Biten story / sprint | 6,8 | 6,0 (4–8) |
| 3 iş gününü aşan story / sprint | 2,3 | 1,5 |
| Belirsizliği sprint ortasında ortaya çıkan madde (toplam) | 3 | 7 |
Planning süresi, isabet ve büyük story sayısı denemeyi haklı çıkarıyordu. Bölme kuralı işleri küçülttü, küçük işin tahmini daha isabetli oldu, planning kısaldı. Biten story sayısının düşmesi denemeden gelmiyordu: aynı dönemde sprint’e girişi kısan 14 maddelik bir hazırlık listesi deniyorduk. Onu ayrı bir yazıda anlatacağım. Yukarıya giden “3 ile 4 sprint arası” cümlesi “490 saat”ten çok daha dürüsttü ve direktör aralığı sorun etmedi. Tek sayı yerine aralık vermeye hiç direnç görmedim; direnç bende, alışkanlıktaydı.
Son satır ise bedeldi. “3 güne sığar mı?” sorusuna herkes kolayca “evet” dedi. Puan varken ayrışan oylar “burada bir şey bilmiyoruz” diye bağırıyordu; evet/hayır sorusu bu sesi kıstı. Yedi maddenin ikisi büyük sürpriz oldu: MKK’dan gelen gün sonu dosyasının formatını okuyan bir iş 8 gün, eski komisyon modülüne dokunan bir iş 11 gün sürdü. İkisinde de ekipte konuyu bilen biri vardı ve ikisinde de kimse ona sormadı, çünkü sormayı gerektiren bir an yoktu.
Nasıl olmalı: kalan düzen
Denemeden sonra puanı geri getirdik, ama başka bir işe. Artık puan bir süre tahmini değil, belirsizliği yüzeye çıkaran bir araç. Tahmini story sayısı yapıyor.
- Oyları ayrışan her maddeyi konuş; iki karttan fazla fark varsa önce 1–2 günlük spike
- Yukarıya story sayısı ve aralık ver: “3 ile 4 sprint arası”
- Her story’yi 3 günden kısa ve kullanıcıya görünen parçalara böl
- Her çeyrek 10 referans maddeyi kör olarak yeniden oylat, kaymayı ölç
- “1 puan kaç saat?” sorusuna sayıyla cevap vermek
- İki ekibin velocity’sini aynı grafikte göstermek
- Farklı sprint sürelerindeki velocity’yi karşılaştırmak
- Oylar ayrışınca “ortası olsun” deyip geçmek
Oylar ayrıştığında ne yapıldığı da yazılı. Önce en düşük ve en yüksek kartı gösteren konuşur, ikişer dakika. Sonra bir kez daha oylanır. Fark hâlâ iki karttan fazlaysa madde bu sprint’e girmez; yerine bir ile iki günlük bir spike girer ve sorunun cevabı bir sonraki planning’e gelir. İlk iki sprint’te dört spike açıldı. Üçünde en yüksek kartı gösteren kişi haklı çıktı. Birinde iş sanıldığından kolaydı ve madde 2 puan olarak geri geldi. Dört spike toplam altı gün sürdü; “Bildirim tercihleri”ndeki SMS maddesinin tek başına 23 gün sürdüğünü düşününce bu ucuz bir sigorta.
Üçüncü yapılmayacak madde Sprint Süresi bölümünden geliyor: bir haftalık sprint’teki 20 puan iki haftalık sprint’teki 40 puan etmiyor. Aynı mantık ekipler arasında daha da sert işliyor. Direktöre kıyas yerine şunu önerdim: “İki ekibi kıyaslamak istiyorsanız teslim edilen işe ve talebin ne kadar beklediğine bakalım. Puana bakmayalım.” Kabul etti. O sayıları nasıl tuttuğumuz başka bir yazının konusu.
Referans yeniden oylamasının ilk sonucu şaşırtıcıydı. Referans listesini sıfırladık ve Ekim sonundaki planning’de sprint’e 36 puan aldık. Eski referansla aynı iş 58 civarı ederdi. Kimse daha yavaş çalışmıyor; cetvel yerine döndü.
Ne izlemeli?
- Oyların ayrıştığı tur oranı. Birden düşüyorsa ekip saat hesaplıyor ya da itiraz etmekten çekiniyor.
- Referans maddelerin kör yeniden oylamadaki kayması. Ortalama yükseliyorsa puan şişiyor.
- Puan başına süre aralığı. 8 ve 13 puanlık işler çoğalıyorsa bölme yapılmıyor.
- Sprint ortasında belirsizliği ortaya çıkan madde sayısı. Tahmin yönteminin asıl sınavı bu.
Kontrol listesi
- Puan ya da velocity, ekip dışına saat veya kıyas olarak gidiyor mu?
- Oyları iki karttan fazla ayrışan maddeleri konuştuk mu, yoksa ortalamaya mı yuvarladık?
- 13 puan ve üstü madde sprint’e bölünmeden mi girdi?
- Yukarıya verdiğim tahmin tek bir tarih mi, yoksa bir aralık mı?
- Referans maddeleri en son ne zaman kör olarak yeniden oylattık?
- Story’leri bölerken her parça kullanıcıya görünen bir değişiklik mi?
Sonuç
12 Haziran’da direktör bana makul bir soru sordu. Yol haritası yapması gerekiyordu ve elinde sadece puan vardı. Hata soruda değil, benim cevabımdaydı. “Beş buçuk saat” yerine “puan saat ölçmez, size story sayısı ve bir aralık verebilirim” deseydim “Bildirim tercihleri” yine 5 sprint sürerdi. Ama kimse 1,5 sprint beklemezdi ve Ayşe’nin 21’i konuşulurdu.
#NoEstimates bize tahmini puandan kurtarmanın mümkün olduğunu gösterdi. Aynı deneme, puanın tahminden başka bir işe yaradığını da gösterdi: masadaki bilgi farkını görünür kılmak.
Puan “ne kadar sürer?” sorusunun cevabı değil. “Ne kadar emin değiliz?” sorusunun cevabı.