📋 Scrum ve Kanban Panoları

Scrum ve Kanban Panoları: Bir restoran mutfağının sipariş panosunu düşün: siparişler soldan girer, hazırlık istasyonlarından geçer, sağdan servise çıkar.

Bir restoran mutfağının sipariş panosunu düşün: siparişler soldan girer, hazırlık istasyonlarından geçer, sağdan servise çıkar. Ocak sayısı sınırlıdır — aynı anda yalnızca dört tencere kaynatabilirsin. Bu sınır bir eksiklik değil, mutfağın gerçeğidir; sınırı görmezden gelip on siparişi birden başlatan mutfakta hiçbir tabak zamanında çıkmaz. Kanban'daki WIP limiti tam olarak bu ocak sayısıdır. Düşündürücü soru: panoya bir "QA" sütunu koymak testi görünür mü kılar, yoksa QA'i akışın en sonundaki bir şelale adımına mı hapseder? İki tarafın da güçlü argümanı vardır ve bu sayfa sana birini dayatmaz — ama kararın sonucunu ölçmenin yolunu gösterir. Karşılaştır: otomasyon koşumunda paralel worker sayısını sınırlarsın; çünkü sekiz çekirdekte on altı tarayıcı açmak toplam süreyi kısaltmaz, uzatır. WIP limiti insan ekibinde aynı fiziği uygular: eş zamanlı iş sayısı arttıkça her işin bitme süresi uzar. QA açısından pano bir teşhis aracıdır: "QA" sütununda biriken kartlar, ekibin test kapasitesinin geliştirme hızının gerisinde kaldığını gösterir. Bu birikme bir suçlama değil, ölçülebilir bir sinyaldir — ve sprint retrospektifinde tartışılacak en somut veridir.

🧭 Bu Sekmede Ne Öğreneceksin

Backlog → sprint → pano zincirini; Scrum ve Kanban panolarının farkını ve hangi ekibe hangisinin uyduğunu; sütun, swimlane ve hızlı filtre konfigürasyonunu; WIP limitinin darboğazı nasıl görünür kıldığını; ve sprint ritüellerinde (planlama, günlük toplantı, review, retrospektif) QA'in hangi veriyle masaya oturduğunu işleyeceğiz. Kavramları okuduktan sonra bunları yaşayarak denemek istersen, sitedeki sprint simülatörü aynı akışı bir Kanban panosu üzerinde canlandırıyor.

🎬 Bir İş Kaleminin Backlog'dan Panoya Yolculuğu

Sprint Review: Velocity

SHOP-118 "Kupon Kodu Uygulama", 200'den fazla öğenin bulunduğu backlog'da ham bir fikir olarak duruyor — henüz tahmin edilmemiş, kabul kriteri yazılmamış. Bu filmde bu ham fikrin panoya kadar giden yolunu izleyeceksin.

Adım 1 — Grooming (refinement): takım ve PO birlikte oturur, story point tahmini yapar (5 puan) ve kabul kriterini yazar: "Bir kupon sipariş başına bir kez uygulanır". Bu adım atlanırsa kartın panoda NE ZAMAN biteceği tahmin edilemez.

Adım 2 — Sprint Planning: takım kapasitesine (bu sprint için 30 puan) göre backlog'dan öğe seçer. SHOP-118'in 5 puanı kapasiteye sığar, sprint'e alınır. Tahmin edilmemiş bir öğe bu adımda seçilemez — kimse ne kadar süreceğini bilmez.

Adım 3 — Sprint başlar, SHOP-118 panoda bir kart olarak belirir. Kart sütunlar arasında ilerler: To Do → In Progress → Ready for QA → In QA → Done. Kabul kriteri sayesinde QA'in "bu bitti mi" sorusunun cevabı NETTİR.

Adım 4 — Sprint Review: kart Done sütununa ulaştı, 5 puan takımın velocity'sine eklendi. Bu sayı bir sonraki sprintin kapasitesini tahmin etmek için kullanılacak — tek bir kartın yolculuğu artık bir veri noktası.

Final (kontrast) — Grooming'i atlayıp doğrudan sprint'e alınan bir başka kart hayal et: kabul kriteri yok, kimse ne kadar süreceğini bilmiyor. Kart "In Progress" sütununda GÜNLERCE donar — developer neyin "bitti" sayılacağını bilmediği için ilerleyemez. Grooming atlanan bir adım değil, panonun akıcılığının ÖN KOŞULUDUR.

1️⃣ G1. Backlog → Sprint → Pano Zinciri

Grooming (refinement) adımı atlanıp bir öğe doğrudan sprint'e alınırsa en olası sonuç nedir?

Kart panoda daha hızlı ilerler