30 saniyelik özet

Backlog Refinement, ürün için düşünülen işleri daha anlaşılır ve değerlendirmeye uygun hale getiren sürekli çalışmadır. Product Backlog, ürünün geliştirilmesi için gereken işlerin sıralı listesidir. Refinement sırasında maddeler bölünebilir, açıklamalar netleştirilebilir ve büyüklükleri değerlendirilebilir. Amaç bütün listeyi ayrıntılı bir şartnameye çevirmek değildir. Yakında ele alınabilecek işlerde karar vermeye yetecek ortak anlayış oluşturmak daha kullanışlıdır. Bir maddeye tahmin yazılması, problemin anlaşıldığını tek başına göstermez. Kullanıcı ihtiyacı, kapsam sınırı ve önemli belirsizlikler konuşulmadan verilen tahmin, anlaşmazlığı rakamın arkasında saklayabilir.

Neden önemli?

“Kullanıcıları toplu aktaralım” talebi ilk bakışta açıktır. Ancak kimlerin aktarılacağı, hatalı kayıtların nasıl ele alınacağı ve mevcut kullanıcılarla eşleşmenin nasıl yapılacağı bilinmiyorsa ekip üyeleri farklı işler düşünüyor olabilir. Tasarımcı bir dosya yükleme ekranını, geliştirici veri eşleştirmeyi, destek uzmanı başarısız kayıtları düzeltme sürecini dikkate alır.

Bu farklar geliştirme başladıktan sonra ortaya çıktığında sorun yalnızca eksik açıklama değildir. İş yeniden tasarlanabilir, başka bir ekibe bağımlılık anlaşılabilir veya kullanıcının beklediği davranış hiç ele alınmamış olabilir. Önceden konuşulabilecek bir karar, teslimat sırasında engel haline gelir.

Refinement, belirsizliği çalışma başlamadan görünür kılmaya yardımcı olur. Her soruyu kesin cevaplamak gerekmez. Hangi sorunun mevcut bilgiyle cevaplanabileceğini, hangisi için kullanıcı araştırması gerektiğini ve hangi teknik varsayımın sınanacağını ayırmak gerekir. Böylece ekip neyi bildiğini ve neyi henüz bilmediğini açıkça ifade edebilir.

Yönetici açısından bu çalışma, kapasitenin gerekçesiz taleplere bağlanmasını önleyebilir. Satış görüşmesinden gelen bir isteğin arkasında yaygın bir ihtiyaç mı, belirli bir müşteriye verilen söz mü, yoksa henüz doğrulanmamış bir çözüm fikri mi var? Bu ayrım, işin sırasını ve kapsamını etkiler.

İyi hazırlanmış bir madde, belirsizliği yok olmuş gibi göstermez. Önemli varsayımları ve çözülmemiş kararları taşır. Bu nedenle yöneticinin yalnızca “Kaç madde hazır?” sorusuyla yetinmemesi gerekir. “Hangi riskleri görünür hale getirdik ve sıradaki karar için ne öğrenmeliyiz?” sorusu daha yararlı bir konuşma açar.

Terim nedir?

2020 Scrum Guide, Product Backlog refinement faaliyetini iş maddelerini daha küçük ve daha kesin maddelere ayırma ve ayrıntılandırma olarak tanımlar. Açıklama, sıralama ve büyüklük gibi bilgiler eklenir. Kullanılan özellikler işin bağlamına göre değişebilir.

Scrum, karmaşık ürün çalışmalarını yönetmeye yardımcı olan bir çerçevedir. Bu çerçevede refinement sürekli bir faaliyettir; ayrı bir resmî etkinlik değildir. İşin büyüklüğünü değerlendirmek, işi yapacak Developers’ın, yani geliştiricilerin sorumluluğundadır. Product Owner, yani ürün sahibi, işlerin anlaşılması ve sıralanması dahil etkin backlog yönetiminden hesap verir. Bu çalışmayı başkalarıyla yürütebilir.

Çerçeve kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020.

Refinement için toplantı düzenlemek pratik bir tercih olabilir. Fakat hazırlık yalnızca toplantıda yapılmaz. Kullanıcı görüşmesinden edinilen bilgi, teknik inceleme veya destek kayıtlarının değerlendirilmesi de bir maddeyi netleştirebilir. Her konuyu bütün ekibin aynı anda tartışması gerekmeyebilir; sonucu ilgili kişilerle paylaşmak gerekir.

Sprint Planning, yani Sprint planlama, yaklaşan çalışma döngüsünün amacını ve yapılabilecek işleri ele alır. Refinement bu kararı destekler, fakat bir işin ayrıntılandırılması onun sıradaki döngüde mutlaka yapılacağı anlamına gelmez. Yeni kanıt veya değişen öncelik, iyi açıklanmış bir maddenin ertelenmesini de gerektirebilir.

Gerçek vaka: Atlassian’da planlama öncesi hazırlık

Dan Radigan’ın Atlassian’da yayımlanan 7 Nisan 2019 tarihli yazısı, şirket ekiplerinin planlama öncesindeki yaklaşımını anlatıyor. Yazıda eski kullanım olan backlog grooming ifadesi geçiyor; burada iş listesini gözden geçirme ve netleştirme çalışması kastediliyor.

Radigan, Atlassian’da ürün sahibi ve Scrum Master’ın katıldığı ayrı bir hazırlık toplantısını yararlı bulduklarını belirtiyor. Scrum Master, ekibin Scrum’ı anlamasına ve etkili çalışmasına yardımcı olan sorumluluktur. Geliştirme ekibinin tamamının bu hazırlığa katılımı, anlatılan uygulamada isteğe bağlı tutuluyor.

Yaklaşan işlerde ayrıntı veya bağlam eksikliği fark edilirse bunlar planlama öncesinde tamamlanabiliyor. Yazının sunduğu gerekçe, planlama sırasında seçenekleri değerlendirmeye daha fazla alan bırakmak. Kaynak, bu yöntemin teslimat süresini ne kadar değiştirdiğini gösteren bir karşılaştırma sunmuyor.

Bu vaka bir kurumun çalışma biçimidir; bütün ekipler için zorunlu toplantı düzeni olarak alınmamalıdır. Buradan çıkarılabilecek ders, karar toplantısına gerekli bilgiyi önceden taşımaktır. Teknik belirsizlik baskınsa hazırlıkta ilgili geliştiricilerin katkısına ihtiyaç olabilir. Katılımcılar, ele alınan sorulara göre belirlenmelidir.

Kaynak: Atlassian, 4 best practices for sprint planning meetings, Dan Radigan, 7 Nisan 2019.

Varsayımsal örnek: Toplu kullanıcı aktarımını netleştirmek

Bir kurumsal yazılım ekibine “Müşteri kullanıcılarını toplu yükleyebilmeli” talebi geliyor. Ürün sahibi, destek kayıtları ve müşteri görüşmelerinden hareketle ilk ihtiyacı daraltıyor: Yeni müşterinin yöneticisi, yetkili olduğu hesaba çalışanlarını eklemek istiyor.

İş analisti mevcut süreci inceliyor. Dosyaların sütun adları değişebiliyor; bazı e-posta adresleri hatalı, bazı kişiler zaten sistemde bulunuyor. Tasarımcı, yükleme sonrasında hangi kayıtların kabul edildiğinin anlaşılması gerektiğini söylüyor. Geliştirici, aynı dosyanın tekrar yüklenmesinin yinelenen kullanıcı üretmemesi konusunu gündeme getiriyor.

Ekip, ilk kapsamı desteklenen dosya biçiminde doğrulama ve aktarım sonucunu gösterme üzerinden kuruyor. Büyük dosyaların arka planda işlenmesi ayrı bir ihtiyaç olarak kaydediliyor. Bölme işlemi yalnızca ekran, veri tabanı ve test işleri şeklinde yapılmıyor; ilk parça kullanıcının sınırlı koşullarda da olsa anlamlı bir işi tamamlamasını hedefliyor.

Acceptance Criteria, yani kabul kriterleri, beklenen davranışın değerlendirilmesine yarayan koşullardır. Bu örnekte geçersiz kayıtların gösterilmesi, mevcut kullanıcıların tekrar oluşturulmaması ve yetkisiz hesaba aktarım yapılmaması konuşuluyor. Ayrıntılar, geliştirme ekibinin uygulama seçeneklerini gereksiz yere kısıtlamadan açıklanıyor.

Dosya büyüklüğü konusunda yeterli teknik bilgi olmadığı anlaşılıyor. Kısa bir inceleme için sorumlu, cevaplanacak soru ve karar zamanı belirleniyor. Maddeye kesinmiş gibi tahmin yazmak yerine bu belirsizlik görünür tutuluyor. İnceleme sonrasında kapsam ve sıralama yeniden değerlendiriliyor.

Yaygın üç hata

  1. Refinement’ı tahmin toplama toplantısına çevirmek

Aynı madde için farklı büyüklükler söylenmesi ortak anlayış eksikliğine işaret edebilir. Ortalamayı alıp geçmek yerine varsayımları konuşun. İnsanlar farklı kullanıcıları, hata koşullarını veya teknik sınırları düşünüyor olabilir.

  1. Uzak gelecekteki bütün işleri ayrıntılandırmak

Henüz önceliği belli olmayan işler için kapsamlı açıklamalar üretmek, değişecek bilgiye emek bağlar. Yakındaki kararları destekleyecek ayrıntıyı öne alın. Daha sonraki işlerde problem, gerekçe ve önemli belirsizlikleri korumak yeterli olabilir.

  1. Eksik bilgiyi kabul kriterleriyle örtmek

Çözüm davranışını uzun uzun yazmak, ihtiyacın doğrulandığını göstermez. “Bu özellik neden gerekli?” sorusunun cevabı yoksa araştırma ihtiyacını kaydedin. Ayrıntılı metni kullanıcı kanıtının yerine koymayın.

Mini uygulama / şablon

Yaklaşan bir iş maddesi için aşağıdaki alanları doldurun.

Problem ve etkilenen kullanıcı
—
Talebin kaynağı ve ihtiyaç kanıtı
—
Beklenen kullanıcı veya iş sonucu
—
Mevcut davranış ve önerilen değişiklik
—
Kapsama dahil olanlar
—
Kapsam dışında kalanlar
—
Kabul kriterleri ve önemli istisnalar
—
Teknik ve operasyonel bağımlılıklar
—
Bölünebilecek anlamlı parçalar
—
Açık sorular ve varsayımlar
—
Bilgiyi sağlayacak kişi ve karar zamanı
—
Sıralama gerekçesi
—

Son olarak maddeyi farklı uzmanlıklardan kişilere kendi cümleleriyle anlattırın. Anlatımlar uyuşmuyorsa hangi varsayımın farklı olduğunu bulun. Çalışma başladıktan sonra ortaya çıkan kritik soruları da kaydedin. Bunların hangilerinin makul bir hazırlıkla fark edilebileceğini incelemek, refinement yaklaşımını geliştirmeye yardımcı olur. Amaç soru çıkmasını cezalandırmak değil, tekrarlayan bilgi boşluklarını azaltmaktır.

İlgili terimler

Product Backlog, Product Owner, Sprint Planning, Sprint Goal, User Story, Acceptance Criteria, Story Points, Relative Estimation, Definition of Ready, Definition of Done, Dependency Management, Product Discovery, Technical Spike, Prioritization