Jira’da Epic, Hikâye ve Alt Görev Hiyerarşisi Nasıl Kurulur?

Jira’nın varsayılan hiyerarşisi

Jira’nın yerleşik yapısında en üstte epic bulunur. Onun altında, epic’in hedeflerini destekleyen görev, hikâye ve hata gibi standart iş öğeleri yer alır. En altta ise standart iş öğelerinin daha ayrıntılı adımlarını temsil eden alt görevler durur.

Atlassian’ın tanımlarına göre epic daha büyük bir iş grubudur ve çoğu zaman birçok iş öğesinden oluşur. Görev, diğer türlerin iyi tarif etmediği işler için genel bir türdür. Hikâye, bir gereksinimin kullanıcı gözünden anlatımıdır. Hata, düzeltilmesi gereken bir sorundur. Alt görev ise standart bir iş öğesinin daha ince bir kırılımıdır ve her iş türünün alt görevi olabilir.

Terim notu: Atlassian belgelerinde iş öğeleri artık work item, iş türleri work type adıyla geçer; eskiden bunlara issue ve issue type deniyordu. Aynı kayıt türünü anlatırlar, bu yüzden eski eğitimlerdeki adlar yeni arayüzde farklı karşınıza çıkabilir.

Epic, hikâye, görev ve hata: hangisi ne zaman?

Seçim işin niteliğine bağlıdır, büyüklüğüne değil. Birkaç sprintte tamamlanacak ve içinde birçok iş barındıran bir hedefi epic yapın; örneğin ‘müşteri portalı’ ya da ‘ödeme akışının yenilenmesi’. Kullanıcıya görünen bir gereksinimi hikâye olarak yazın: ‘kullanıcı olarak şunu yapabilmek istiyorum’. Kullanıcıya doğrudan bir değer taşımayan teknik ya da idari işleri görev yapın. Çalışmayan bir şeyi onarmak için hata açın.

Çoğu kafa karışıklığı bu türlerin birbirinin altına girdiğini sanmaktan gelir. Hikâye, görev ve hata varsayılan yapıda aynı seviyededir; bir görev normalde hikâyenin altında durmaz. Hikâye ile görevi aynı epic’e bağlayabilirsiniz, ama hiyerarşik olarak biri diğerinin çocuğu değildir. ‘Epic, hikâye, görev, alt görev’ diye çok katmanlı bir zincir kurmaya çalışmak varsayılan yapıya aykırıdır.

Bir hikâyenin altında daha küçük iş parçalarına ihtiyaç duyduğunuzda çözüm alt görevdir. Alt görev, hikâyeyi geliştiricilere dağıtılabilir adımlara böler; hikâyenin kendisi sprintte tek birim olarak izlenir.

Alt görevler ve raporlama

Alt görev, üst iş öğesinin çocuğudur ve üst öğe oluşturulduktan sonra da eklenebilir. Her iş türü alt görev alabilir. Alt görev eklemek, işin kim tarafından ve hangi adımlarla yapılacağını görünür kılar.

Raporlamada alt görevin kendine özgü bir davranışı vardır: sprint raporunda, burndown ve velocity grafiklerinde alt görevlerin tahminleri dışlanır; yalnız üst iş öğelerinin tahmini sayılır. Bu yüzden tahminleri alt görevlere dağıtırsanız raporlar eksik toplam gösterebilir. Tahmini üst öğede tutmak, alt görevlerde ise yapılacak adımları ve sorumlu kişiyi izlemek güvenli yoldur.

Bir diğer pratik: alt görevi uzun ömürlü iş için kullanmayın. Günler ya da haftalar süren bir alt görev, kendi başına bir iş öğesi olmayı hak eder. Alt görev, üst öğeyle birlikte kapanmaya yakın küçük adımlar içindir.

Epic’in üstüne seviye eklemek

Büyük ürünlerde epic’lerin de bir üst gruba bağlanması gerekir: girişim, tema ya da program gibi. Jira bunun için yöneticinin iş türü hiyerarşisini yapılandırmasına izin verir.

Yol şöyledir: Settings menüsünden Work items’a, soldaki sütunda Work type hierarchy’ye gidin. Epic seviyesine yeni iş türleri eklemek için Epic seviyesindeki Jira work types alanından türü seçip kaydedin. Epic’in üstüne seviye eklemek için listenin altındaki Create level’a tıklayın; yeni seviye hiyerarşinin en üstünde görünür. Seviyeye ad verin, Jira work types listesinden bu seviyeye hangi türlerin ait olacağını seçin ve kaydedin.

Koşullar ve riskler Atlassian’ın belgesinde açıktır. Epic seviyesine tür eklemek ve özel seviye oluşturmak Jira Cloud Premium ya da Enterprise gerektirir. Hiyerarşi değişiklikleri sitedeki tüm şirket tarafından yönetilen alanlara uygulanır. Jira yapısal değişikliğin etkisini hesaplar ve onay ister; belge, hiyerarşiyi değiştirmenin mevcut üst-alt ilişkilerini bozacağını ve yapısal değişikliklerin geri alınamayacağını açıkça belirtir. Eklediğiniz özel bir seviyeyi kaldırırsanız o seviyedeki türler hikâye seviyesine döner.

Yapı kararı: ne zaman seviye eklemeli?

Her organizasyonun ekstra bir seviyeye ihtiyacı yoktur. Varsayılan yapı çoğu tek ekip için yeterlidir. Ek bir seviye şu durumlarda anlamlıdır: birden fazla ekip aynı hedef için epic üretiyorsa, yönetim epic’lerin üstünde bir portföy görünümü istiyorsa ya da epic’ler tek başına izlenmeyecek kadar çoksa.

Kararı vermeden önce şu soruları cevaplayın. Üst seviyedeki kayıt kimin için, hangi toplantıda kullanılacak? Her ekip bu yapıyı aynı biçimde kullanacak mı? Mevcut iş öğeleri yeni yapıya nasıl taşınacak? Bu cevaplar yoksa yeni seviye eklemek yalnız admin yükünü artırır ve ilişkileri bozma riskini taşır.

Site genelinde değiştiği için hiyerarşi kararını tek ekip adına vermeyin. Jira yöneticisi, ürün yönetimi ve ilgili ekip liderleri birlikte karar versin; ardından önce küçük bir kapsamda kullanmayı deneyin. Adımları ve beklenen sonucu önceden yazmak, geri dönüşü olmayan bir değişiklikte güvence sağlar.

Sık yapılan hatalar

• Epic’i sprintlik iş yapmak: Bir sprintte biten bir iş epic olmaz, görev ya da hikâyedir.
• Hikâyenin altına görev koymaya çalışmak: Standart türler aynı seviyededir; ilişkiyi epic bağlantısı ya da alt görevle kurun.
• Tahmini alt görevlere dağıtmak: Raporlar alt görev tahminlerini dışlar.
• Hiyerarşiyi canlı sistemde denemek: Yapısal değişiklik geri alınamaz ve mevcut ilişkileri bozar.
• Gereksiz seviye eklemek: Kullanılmayan bir seviye listeyi karmaşıklaştırır.
• Terimleri karıştırmak: Eski ‘issue’ ile yeni ‘work item’ aynı şeydir; ekip içinde tek bir ad üzerinde anlaşın.

Kavramsal olarak epic ile kullanıcı hikâyesi arasındaki fark ayrı bir konudur; burada önemli olan bunların Jira’da hangi seviyeye yerleştirileceğidir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Jira Eğitimi: Temel ve İleri Uygulama programındaki Proje Kurulumu ve Yapılandırma modülü, iş yapısının kurulduğu bölümdür; Terminoloji ve Durum Geçişleri modülü ise iş öğesi kavramlarını çalıştırır. Jira ile Proje Yönetimi Eğitimi’ndeki Jira’ya Giriş ve Temel Kavramlar modülü başlangıç düzeyi için uygundur.