30 saniyelik özet

Product Backlog, ürünü geliştirmek için gereken işlerin sıralı ve değişen listesidir. Product Owner, yani ürün sahibi, listenin etkili yönetiminden hesap verir. Bir işin listede bulunması, belirli tarihte teslim edileceğine dair söz değildir. Listenin değeri, ekip ve paydaşların sıradaki işlerin neden önemli olduğunu anlayabilmesidir. Yeni özelliklerin yanında mevcut sorunları gideren ve ürünün sürdürülebilirliğini destekleyen çalışmalar da değerlendirilmelidir. Müşteri geri bildirimi listeyi besler; öncelik kararının yerini almaz. İyi yönetilen bir backlog, taleplerin kaynağını, beklenen faydayı ve açık belirsizlikleri görünür kılar. Yeni bilgi geldikçe sıralama ve içerik yeniden incelenir.

Neden önemli?

Satış ekibi bir müşterinin rapor talebini, destek ekibi sık yaşanan hatayı, geliştiriciler ise bakım ihtiyacını gündeme getiriyor. Hepsi farklı kanallarda tutuluyorsa kapasitenin nereye ayrılacağına ilişkin karar eksik bilgiyle verilebilir. Müşteriye görünen özellikler konuşulurken ürünü işletmek için gereken işler arka planda kalır.

Ortak ve anlaşılır bir liste, bu işleri birlikte değerlendirmeyi kolaylaştırır. Ancak görünürlük tek başına yeterli değildir. Bir maddeye “yüksek öncelik” yazılması, başka bir yüksek öncelikli işe göre neden önce ele alınacağını açıklamaz. Sıralama, ekip için gerçek bir seçim anlamına gelmelidir.

Yönetici açısından backlog, kaynak tahsisi kararlarının izlenebildiği bir çalışma alanıdır. Hangi ihtiyaç öne alındı? Bunun bedeli olarak hangi iş bekliyor? Kararı hangi bilgi değiştirebilir? Bu sorular cevaplanabiliyorsa liste, toplantıların ardından unutulan taleplerden daha fazlasını sunar.

Liste büyüdükçe bakım maliyeti de artar. İhtiyacı artık geçerli olmayan maddeleri sürekli tartışmak zaman tüketir. Buna karşılık eski bir talebi sırf uzun süredir beklediği için silmek de önemli bağlamı kaybettirebilir. Düzenli incelemede maddenin yaşıyla birlikte kanıtı, stratejik ilişkisi ve yeniden değerlendirilme nedeni ele alınmalıdır.

Terim nedir?

Scrum Guide, Product Backlog’u ürünü iyileştirmek için gerekenlerin gelişen ve sıralı listesi olarak tanımlar. Scrum Team’in yürüttüğü işlerin tek kaynağıdır. Product Goal, yani ürün hedefi, bu listenin içinde bulunur; diğer maddeler hedefe ulaşmak için gereken işleri zamanla ortaya koyar.

Product Owner’ın sorumluluğu maddelerin oluşturulması ve açıkça iletilmesini, sıralanmasını, listenin görünür ve anlaşılır olmasını kapsar. Bu çalışmaları başkalarına yaptırabilir; hesap verebilirlik kendisinde kalır. Geliştiriciler yapacakları işin büyüklüğünü değerlendirmekten sorumludur.

Backlog Refinement, maddelerin bölünmesi ve daha ayrıntılı tanımlanması faaliyetidir. Türkçede backlog iyileştirme veya detaylandırma olarak ifade edilebilir. Scrum Guide bunu sürekli bir çalışma olarak açıklar. Sprint Backlog ise kısa çalışma dönemi olan Sprint’in hedefi, seçilen işleri ve bunları gerçekleştirme planını içerir. Product Backlog ile aynı liste değildir.

Tanım kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020; Product Owner, Product Backlog ve Sprint Backlog bölümleri.

Uygulamada yakın zamanda ele alınması beklenen maddeler için daha ayrıntılı bilgi hazırlamak yararlıdır. Uzak ihtimallerin bütün çözüm ayrıntılarını önceden yazmak, değişecek bilgiler üzerinde gereksiz çalışma yaratabilir. Bu bir planlama tercihidir; bütün maddelerin aynı belge uzunluğunda tutulması gerekmez.

Bir maddeyi anlaşılır kılan şey başlığının yanında gerekçesidir. “Rapor ekranı” yerine hangi kullanıcının hangi kararı veremediğini açıklamak, farklı çözüm seçeneklerini değerlendirmeye alan açar. Kullanılan araç bu düşünme işini kendiliğinden yapmaz. Düzenli kartlar, zayıf ihtiyaç tanımını telafi etmez.

Gerçek vaka: Atlassian’da geri bildirimden backlog’a

Atlassian’ın 4 Aralık 2015 tarihli yazısında Jira Software ürün yöneticisi Jason Wong, müşteri geri bildirimlerini nasıl topladığını ve değerlendirdiğini anlatıyor. Ürün içindeki geri bildirim bağlantısı ile kullanıcıların talep ve hataları iletip destekleyebildiği jira.atlassian.com kanalı, kullanılan kaynaklar arasında bulunuyor.

Wong, belirli bir özellik hakkındaki geri bildirimleri görüşme ve talep bağlantılarıyla birlikte Confluence sayfasında topladıklarını belirtiyor. Ardından geri bildirimler kullanıcı hikâyeleri biçiminde backlog’a aktarılıyor. Kullanıcı hikâyesi, ihtiyacı kullanıcı açısından ifade eden bir iş maddesi biçimidir. Maddeler diğer işlerle birlikte önceliklendiriliyor ve tahmin ediliyor.

Yazıda sıralamanın, müşteri deneyimiyle ilişkili bir hedefi etkileme kapasitesine dayandığı açıklanıyor. Teknik temel çalışmaların bazen kullanıcıya doğrudan görünen özelliklerden önce yapılması gerektiği de vurgulanıyor.

Bu anlatım, şirketin o dönemdeki uygulamasına örnektir; bütün geri bildirimlerin teslim edildiğini veya kullanılan yaklaşımın belirli bir ticari artış yarattığını kanıtlamaz. Vakadan çıkarılabilecek ders, talebin kaydedilmesi ile uygulanmasına karar verilmesi arasında değerlendirme bulunduğudur. Bağımlılıklar da bu kararın parçasıdır.

Kaynak: Atlassian, Examples of capturing customer feedback for agile development, 4 Aralık 2015; Jason Wong’un anlatımı.

Varsayımsal örnek: Abonelik ürününde çakışan talepler

Kurumsal abonelik yazılımı geliştiren bir ekip düşünelim. Satış ekibi müşteriye özel rapor istiyor. Destek ekibi ödeme hatalarının daha anlaşılır gösterilmesini talep ediyor. Geliştiriciler ise işlem kayıtlarının eksikliği nedeniyle sorunları araştırmakta zorlandıklarını belirtiyor.

Product Owner, maddeleri sadece geldikleri sıraya göre ele almıyor. Özel raporun hangi müşteri kararını desteklediğini, ödeme hatalarının kullanıcıları nasıl etkilediğini ve eksik kayıtların hangi sorunların çözümünü geciktirdiğini araştırıyor. Ekip, teknik ihtiyacın kullanıcı sonucuyla ilişkisini açıklıyor.

İncelemede ödeme sorunlarını doğru sınıflandırmak için önce işlem kayıtlarının geliştirilmesi gerektiği anlaşılıyor. Böylece teknik çalışma ile hata mesajları arasındaki bağımlılık görünür oluyor. Teknik madde, “müşteri istemedi” gerekçesiyle geri plana atılmıyor. Beklenen katkısı ve sınırı kaydediliyor.

Özel rapor talebi de listede tutuluyor; ancak müşteriye teslim tarihi verilmiyor. Gerekli verilerin mevcut olup olmadığı ve raporun başka müşteriler için anlamı araştırılacak. Talebi ileten satış temsilcisine, değerlendirmeyi değiştirebilecek bilgiler açıklanıyor.

Yakındaki işler ekipçe detaylandırılıyor. Eski raporlama maddeleri incelendiğinde bazı ihtiyaçların mevcut ürünle karşılandığı görülürse karar gerekçesiyle kapatılıyor. İhtiyacı geçerli fakat çözümü belirsiz maddeler için araştırma adımı belirleniyor. Liste, bütün fikirleri geliştirme sözüne dönüştürmeden ürün kararlarını destekliyor.

Yaygın üç hata

  1. Backlog’a eklemeyi teslimat sözü gibi sunmak

Paydaş, talebi listede görünce sıranın kendisine geleceğini varsayabilir. Kaydetme, araştırma ve teslimat beklentilerini açıkça konuşun. Tarih veya kapsam taahhüdü varsa bunu ayrıca görünür tutun; liste konumunu sessiz bir sözleşmeye dönüştürmeyin.

  1. Sıralamayı yalnızca talep sayısına bağlamak

Tekrarlanan talepler önemli bir sinyaldir; ancak etkiyi ve bağımlılıkları tek başına açıklamaz. Kullanıcı sorununu, beklemenin bedelini, belirsizliği ve gereken çalışmayı birlikte inceleyin. Talep sayısının arkasında aynı kişinin tekrarları bulunup bulunmadığını kontrol edin.

  1. Her maddeyi aynı ayrıntıda hazırlamak

Uzak işler için kesin çözüm tasarlamak, değişecek kararların maliyetini artırabilir. Yaklaşan işler için gerekli açıklığı sağlayın. Belirsiz maddelerin eksik bilgisini kaydedin; boşlukları tahmin edilmiş ayrıntılarla doldurmayın.

Mini uygulama / şablon

Listenin üst bölümündeki maddeleri seçin. Her biri için aşağıdaki alanları gözden geçirin.

Madde kimliği ve açıklaması
—
İhtiyacın kaynağı
—
Etkilenen kullanıcı veya süreç
—
Problem ve mevcut kanıt
—
Ürün hedefiyle ilişkisi
—
Beklenen fayda veya azaltılacak risk
—
Sıralama gerekçesi
—
Bağımlı olduğu işler
—
Açık sorular ve belirsizlikler
—
Gerekli araştırma veya değerlendirme
—
Tamamlandığının nasıl anlaşılacağı
—
Sonucun nasıl izleneceği
—
Yeniden değerlendirme koşulu
—

Ardından listeyi bütün olarak inceleyin. Ekip sıradaki işlerin neden seçildiğini açıklayabiliyor mu? Teknik ihtiyaçlar ve mevcut ürün sorunları görünür mü? Çelişen beklentiler konuşulmuş mu? Cevaplanamayan sorular için detaylandırma çalışması planlayın. Liste uzunluğunu azaltmak yerine karar vermeyi kolaylaştırmayı hedefleyin.

İlgili terimler

Product Owner, Product Goal, Sprint Goal, Sprint Backlog, Backlog Refinement, User Story, Acceptance Criteria, Technical Debt, Prioritization ve RICE, MoSCoW Prioritization, Product Roadmap, Outcome ve Output