Jira'da Board ve Workflow Tasarımı: Status'ler, Transition'lar, Kolonlar ve WIP Limit

Sürüm notu: Bu yazı Jira Cloud'un 2026-11 itibarıyla güncel hâlini (space ve work item terminolojisi) esas alır ve company-managed bir software space üzerinden anlatır; team-managed farkları yeri geldikçe belirtilmiştir. Bu yazıda resmî belgelerden yararlanılmıştır (Atlassian Support, 15 Kasım 2026'da kontrol edildi).

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) ekibi Jira'ya geçtikten sonraki ilk sprint'i bitiriyor. Board'da her şey yolunda görünüyor: Done kolonunda 14 kart var, Sprint Report da 14 item'ı tamamlanmış sayıyor. Ertesi gün kurumsal satıştan Hakan şikâyet ediyor: kendisi için kaydedilen "açık kurumsal bug'lar" filter'ı, yani resolution = Unresolved koşulu olan filter, geçen hafta kapattığınız beş bug'ı hâlâ açık gösteriyor. Dashboard'daki Created vs Resolved grafiği de sprint boyunca sıfır çözülmüş item çiziyor.

Board mı yalan söylüyor, filter mı? Tahmin et: iki taraf da kendi tanımına göre doğru. Board ve Sprint Report bir item'ın bitip bitmediğine en sağdaki kolona bakarak karar veriyor; filter ve Created vs Resolved raporu ise resolution alanına bakıyor. Ekip workflow'u kurarken Done'a giren transition'a resolution'ı set eden kuralı eklemeyi unuttu. Bu yazının konusu tam olarak bu: status, transition, kolon ve resolution'ın birbirine nasıl bağlandığı.

Workflow'u Definition of Workflow'dan Türetmek

Jira'da workflow, bir work item'ın yaşamı boyunca geçtiği status'ler ve aralarındaki transition'lar demek. Jira'nın varsayılan workflow'u bir başlangıç noktası; ama ekibin akışını Jira'nın template'inden değil, ekibin kendi tanımından türetmek gerekiyor. Kanban serisinin 2. yazısında konuştuğumuz Definition of Workflow tam bu tanım: işin ne zaman başlamış ve ne zaman bitmiş sayılacağı, aradaki state'ler ve item'ların nasıl hareket edeceğine dair açık kurallar. Jira workflow'u bu kararların araçtaki yansımasıdır, kararın kendisi değil.

Atlassian'ın workflow için en iyi uygulamalar sayfası da aynı yöne bakıyor: workflow'u ekipteki her rolden biriyle birlikte kurmak, tek bir kalıbı bütün ekiplere kopyalamamak, sıfırdan ekibin gerçek adımlarını yazmak ve status ile transition sayısını gerçekten gerekenle sınırlamak. Belgenin gerekçesi basit: her status ve her transition, workflow'u kullanan herkes için ek karmaşıklık.

Bookstore ekibinin kararları şöyle. İş, bir geliştirici item'ı Ready'den çektiğinde başlıyor. Bitiş, PR (pull request; değişikliğin ana branch'e alınması için açılan istek) main branch'e merge edildiğinde; çünkü ekibin CI/CD pipeline'ı main'e giren her değişikliği production'a çıkarıyor ve test, merge'den önce PR'ın kendi test ortamında yapılıyor. Arada üç state var: In Progress (kod yazılıyor), In Review (PR okunuyor) ve Testing (PR ortamında senaryolar deneniyor). Toplam beş status: Ready, In Progress, In Review, Testing, Done.

Jira her status'ü üç kategoriden birine bağlar: To Do, In Progress ve Done. Kategoriler status'lerin renklerini ve bazı hesapları belirler; JQL (Jira Query Language; Jira'nın arama sorgu dili) içinde statusCategory alanıyla da sorgulanabilirler. Ready To Do kategorisinde, ortadaki üçü In Progress'te, Done ise Done kategorisinde.

Transition'lar: Hareketin Adı ve Kuralı

Status'ler işin nerede olduğunu, transition'lar nasıl hareket ettiğini söyler. Bookstore'un transition'ları ileri yönde Start Work, Request Review, Approve ve Pass Test; geri yönde Request Changes (review'dan koda dönüş), Fail Test (test'ten koda dönüş) ve Reopen (Done'dan tekrar açılış).

Transition'lara isim vermek ilk bakışta tören gibi görünebilir, ama bu isimler başka yerlerde de kullanılıyor. 04. yazıda göreceğimiz smart commits, commit mesajındaki #approve gibi bir komutu transition adıyla eşleştiriyor ve adın yalnız ilk kelimesine bakıyor. Request Review ve Request Changes aynı kelimeyle başladığı için commit mesajında #request belirsiz kalıyor; bu ikisi için tam ad tireyle yazılmalı: #request-review. İsimleri seçerken bunu bilmek sonradan bir transition'ı yeniden adlandırmaktan kolay.

Transition'lara kural da eklenebilir: kimin yapabileceğini sınırlayan koşullar, bir alanın dolu olmasını isteyen doğrulamalar ve geçişten sonra bir alanı güncelleyen işlemler. Team-managed space'lerde bir workflow'a 200'e kadar transition eklenebiliyor; belge "Any status"tan başlamayan transition'ların board'da kart sürüklerken beklenmedik davranışa yol açabileceği konusunda da uyarıyor. Bookstore ekibi tek bir kural ekledi, o da aşağıda: resolution.

Company-managed bir software space board ile açıldığında varsayılan olarak simplified workflow kullanıyor; bu modda space ya da board admin'i board ayarlarından doğrudan status ekleyebiliyor. Space Jira workflow'u kullandığında bu düğme kayboluyor; status'leri Jira admin'leri workflow editöründe yönetiyor. Bookstore ekibi isimli transition'lar ve resolution kuralı istediği için Jira workflow'u kullanıyor.

Resolution: Raporların Gizli Anahtarı

Resolution, bir work item'ın neden Done'a taşındığını anlatan alan: Done, Won't Do, Cannot Reproduce gibi. Atlassian'ın belgesi Done'daki item'ların resolution'ı olmak zorunda olmadığını, ama olmasını güçlü biçimde önerdiğini yazıyor ve gerekçesini üç yerde gösteriyor. Board'larda resolution'ı dolu item'lar üstü çizili görünüyor; resolution yanlış set edilirse In Progress'teki bir kart bile üstü çizili çıkabiliyor. Created vs Resolved raporu resolution'a dayanıyor. Ve Open work items filter'ı resolution'ı boş olan item'ları gösteriyor; Hakan'ın filter'ının yaptığı tam olarak buydu.

Belge iki yol öneriyor. Birincisi, Done'a giden transition'a resolution alanını sabit bir değerle güncelleyen bir kural eklemek. İkincisi, transition'da Resolution alanı olan bir ekran gösterip kişiye seçtirmek. Bookstore ekibi ilkini seçti: Pass Test transition'ı resolution'ı Done yapıyor. Won't Do gibi ikinci bir bitiş durumu gerekirse, o status'e giden transition da kendi resolution değerini set edecek. Bir de ters yön var: belge, resolved bir status'ten çıkan transition'ların da yapılandırılması gerektiğini söylüyor. Reopen transition'ı resolution'ı temizlemezse yeniden açılan bir bug hem In Progress'te hem üstü çizili hem de filter'larda kapalı görünür.

Bir ayrıntı daha: Jira resolution boştan bir değere geçtiği anda resolved tarihini otomatik set ediyor. JQL'deki resolved alanı ve resolution'a dayanan raporların tarihleri bu andan geliyor. Resolution belgesi company-managed space'ler için yazılmış; team-managed tarafında JQL fields sayfası service türündeki team-managed space'lerde resolution alanı olmadığını ve orada statusCategory = Done kullanılması gerektiğini söylüyor.

Status ile Board Kolonu Eşlemesi

Board'daki kolon, item'ın o anki status'ünü gösterir; bir kolona birden fazla status eşlenebilir. Scrum board'un varsayılan kolonları To Do, In Progress ve Done; Kanban board'unkiler Backlog, Selected for Development, In Progress ve Done. Bu eşleme göründüğünden daha önemli, çünkü raporlar kolona bakıyor. Velocity chart, cumulative flow diagram ve Sprint Report belgeleri aynı kuralı tekrarlıyor: en soldaki kolona eşlenen status'teki item To Do sayılır, en sağdaki kolona eşlenen status'teki item Done sayılır. Sprint'i tamamlama belgesi de bir item'ın tamamlanmış sayılması için board'un son kolonuna taşınmış olması gerektiğini söylüyor.

Bunun sonucu şu: en sağdaki kolona ne koyarsan sprint'in "tamamlanan" listesine o girer. Won't Do status'ünü Done kolonuna eşlersen vazgeçilen item'ların story point'leri de velocity'de tamamlanmış iş olarak görünür. Bir status'ü hiçbir kolona eşlemezsen o status'teki item'lar board'da hiç görünmez; belgenin "board'da görünmeyen item'lar" sorun giderme bölümünün ilk şüphelisi de board filter'ı ile eşlenmemiş status'ler. Bookstore ekibi beş status'ü beş kolona birebir eşledi; Done kolonunda yalnız Done var.

Scrum Board: Backlog, Sprint ve Sprint Goal

Bookstore ekibi Scrum ile çalışıyor, bu yüzden board'u bir Scrum board. Backlog ekranında Selin sıralı Product Backlog'u yönetiyor, ekip Sprint Planning'de bir sprint'i doldurup başlatıyor. Sprint'i başlatırken açılan pencerede isteğe bağlı bir goal alanı var; yazılan sprint goal Sprint Report'ta ve Burndown Chart'ta da görünüyor. Scrum serisinin 4. yazısında konuştuğumuz gibi sprint goal sprint'in neden var olduğunu söyler; Jira'da boş bırakılabilmesi, boş bırakılması gerektiği anlamına gelmiyor.

Birkaç davranış bilmeye değer. Sprint'ler space'e değil board'a bağlıdır; item'lar başka bir space'e taşındığında sprint verisi onlarla gitmez. Sprint'i tamamlamak için bütün subtask'ların Done olması gerekir; bitmemiş parent item'lar backlog'a ya da sonraki sprint'e aktarılır. Aynı backlog'dan çalışan iki ekip için parallel sprints özelliği var, ama belge bunun velocity'yi ekip başına göstermediğini ve iki ekibin aynı şekilde tahmin yaptığını varsaydığını açıkça yazıyor.

Kanban Board: WIP Limit, Swimlane ve Custom Filter

Jira'da WIP (devam eden, henüz bitmemiş iş) limit'inin adı column constraint. Board ayarlarında her kolona minimum ve maksimum değer yazılabiliyor; maksimum aşılınca kolon başlığı kırmızıya, minimum karşılanmayınca sarıya dönüyor. Belgenin iki notu önemli: constraint değerleri kolonda gösterilen item sayısını değiştirmiyor, yani Jira kartın kolona girmesini engellemiyor; limit'e uymak ekibin politikası. Ayrıca constraint, quick filter ile gizlenmiş item'lar dahil kolondaki toplam item'ı sayıyor. Sayım "Work item count" ya da "Work item count, excluding subtasks" olarak seçilebiliyor; belge Scrum ekiplerine subtask'ları hariç tutmayı öneriyor. WIP limit'in neden işe yaradığını Kanban serisinin 3. yazısında Little's Law ile konuştuk; burada yalnız aracın nasıl uyguladığına bakıyoruz.

Swimlane'ler kartları yatay olarak gruplar. Seçenekler: her biri bir JQL sorgusu olan query swimlane'leri, story'ye göre, assignee'ye göre, epic'e göre, space'e göre ya da hiç swimlane olmadan. Query modunda varsayılan olarak priority = Blocker sorgulu bir Expedite şeridi ve silinemeyen bir Everything Else şeridi geliyor. Quick filter'lar ise board'u JQL ile süzen düğmeler; varsayılanlar Only My Work items (assignee = currentUser()) ve Recently Updated. Company-managed space'lere gelen yeni board görünümünde quick filter'ların adı custom filter oldu.

Bookstore ekibi Scrum board'unda Kanban'dan iki şey aldı (Kanban serisinin 7. yazısındaki Scrumban fikri): In Progress için maksimum 4, In Review için maksimum 3 column constraint, subtask'lar hariç. Swimlane olarak query kullanıyorlar: Expedite şeridinin sorgusunu labels = expedite yaptılar, gerisi Everything Else. Custom filter olarak da Only My Work items'ın yanına Kurumsal Sipariş epic'i için parent = BOOK-120 ve type = Bug ekledi. PR açıldığında item'ı In Review'a, merge olduğunda Done'a taşıyan otomasyonu 04. yazıda kuracağız.

Üretimde Dikkat

Company-managed space'te workflow bir workflow scheme ile space'e bağlanıyor; aynı scheme'i kullanan bütün space'ler workflow değişikliğinden birlikte etkileniyor. Bir status'ü kaldırırken o status'teki item'ların yeni bir status'e taşınması gerekiyor; Jira bunu workflow'u güncellerken soruyor. Atlassian'ın önerisi, yeni workflow'u önce ayrı bir test space'inde örnek item'larla baştan sona yürütmek ve item'ların takıldığı bir adım olup olmadığına bakmak. Bu iş, yayından sonra ekibin board'unda keşfedilecek bir kilitlenmeden çok daha ucuz.

Board'un 5.000 item sınırı Kanban board'larda daha çabuk dolar, çünkü Done kolonu sürekli büyür. Board filter'ına bitmiş ve eskimiş item'ları dışarıda bırakan bir koşul eklemek ya da team-managed'da Done item'ları board'dan temizlemek bu sınıra gelmeden yapılmalı.

Sık Düşülen Tuzaklar

Birinci tuzak baştaki hikâye: resolution boş kaldığı için Done'daki item'lar filter'larda ve Created vs Resolved raporunda açık görünüyor. Tersi de var: resolution'ı Done olmayan bir status'te set eden ya da Reopen'da temizlemeyen workflow, çalışılan kartları üstü çizili gösteriyor. Her iki durumda da çözüm aynı yerde: bitiş status'lerine giren ve onlardan çıkan transition'lar.

İkinci tuzak, ekibin gerçek akışını yansıtmayan kolonlar: "In Review 2", "Ready for Test", "Test Approved Waiting Deploy" gibi, her biri bir zamanlar tek bir sorunu çözmek için eklenmiş status'ler. Kanban serisinin 2. yazısındaki kural burada da geçerli: bir status'ü ancak ölçmek istediğin bir bekleme ya da iş varsa ayrı tut. Üçüncü tuzak, onay adımlarını workflow'a gömmek: "Müdür Onayı" status'ü ve yalnız tek bir kişinin yapabildiği bir transition. O kişi izne çıktığında bütün akış duruyor. Onay gerçekten gerekiyorsa, akışın kendisini kilitlemeyen bir kural olarak ve yetkisi bir role verilmiş biçimde kurulmalı. Dördüncüsü, en sağdaki kolona Won't Do gibi vazgeçilen işleri koyup velocity'yi şişirmek.

Küçük Bir Deneme

★☆☆ Ekibinin bugünkü board'undaki her kolon için tek cümle yaz: bu kolonda item'ı kim bekliyor ya da kim üzerinde çalışıyor? Cümlesi yazılamayan kolon kaldırılmaya adaydır.

★★☆ Bookstore workflow'una "Won't Do" bitiş status'ü ekle: hangi status'lerden ulaşılır, transition adı ne olur, hangi resolution set edilir ve board'da hangi kolona eşlenir? Kararının velocity'ye etkisini bir cümleyle açıkla.

★★★ Erişimin olan bir Jira sitesinde statusCategory = Done AND resolution = Unresolved ve statusCategory != Done AND resolution is not EMPTY sorgularını çalıştır. Dönen her item, workflow'da resolution kuralı eksik ya da yanlış olan bir transition'ı gösteriyor. Hangi transition olduğunu bul.

Board artık doğru şeyi gösteriyor; sıradaki soru bu veriden doğru soruları nasıl soracağımız. Bir sonraki yazıda JQL'in temellerini, kaydedilmiş filter'ları ve dashboard'ları ele alıyor, velocity, burndown, cumulative flow ve control chart'ın hangi soruya cevap verdiğini ve metriklerin kişi performansına dönüştüğü yeri konuşuyoruz.