Organizasyonların Scrum’ı bünyelerinde hayata geçirmesinin ardından, Scrum Guide’da ve sertifikalandırma sınavlarında bulunmaya bazı hususlar kafalarda karışıklığa neden olup, Scrum takımları içerisinde ortak dilin oluşmasını engelleyebilmekte ve iletişim konusunu sekteye uğratabilmektedir. Öncelikli olarak, bu kavram tanımlamalarının esas amacının, takımların kendi içinde anlaşmaları olduğunu unutmamak gerekir. Bu sebeple, eğer organizasyonunuzda bu kavramlar için kullandığınız başka terimler varsa ve bu terimler herkes için aynı anlamda kullanılıyorsa, bu şekilde kalmasında hiçbir sorun yok. Ben bu yazımda kavramların genel kabul gören tanımlamalarını paylaşacağım.
Üç esas tanıma geçmeden önce bu tanımlar içerisinde geçecek iki kavramı öğrenelim;
Görev (Task) & Özellik (Feature)
Gerçek hayattaki Scrum döngüsünde, Ürün Sahibi (Product Owner), Ürün İş Listesi’ni (Product Backlog) oluştururken, tüm paydaşlara proje için “NE” gerekli olduğu sorusunu sorarak isterleri toplar. Bu “NE” sorusuna gelen her bir cevabı “Özellik” olarak ele alarak birbirleri ile ilişkilendirmeye başlar. İlişkilendirilen bu Özellik’ler paketlenerek İstek Listesi’ni (Wish List) oluşturur.
Paydaşlardan gelen bu istek cümlelerine “Nasıl” sorusunu sorarak ise, hikayelerin içerisindeki Görev’ler çıkartılmış olur. Bu kapsamda Görev’lerin; projenin geliştirilme, kabul ve teslim basamaklarındaki “DONE” kriterlerini oluşturan en küçük yapı taşı olduğunu söyleyebiliriz. Dan Chuparkof, Jira ve Proje Yönetimi üzerine yaptığı bir sunumunda, bir Görev’in 30 dakika ile 3 gün arasında iş yükü doğuracak kapsamda olduğunu belirtir.
“Rapor uzmanı olarak, verileri kolaylıkla bulabilmek için, listeler içerisinde arama fonksiyonuna ihtiyacım var.” şeklinde gelen istek için; basit/gelişmiş arama, filtreleme, sıralama gibi maddeler Özellik olarak değerlendirilebilir. Bu Özelliklerin hayata nasıl geçirilebileceğinin cevabı olarak; back-end tasarımı, front-end tasarımı, arama API’sinin yazılması, sonuç sayfasının tasarlanması, test senaryolarının çıkartılmasını ise ayrı ayrı Görevler olarak değerlendirebiliriz.
Kullanıcı Hikayesi (User Story)
Kullanıcı Hikayesi, paydaşların projeden fonksiyonel beklentilerini anlatan metindir. Son kullanıcının ihtiyaç ve beklentileri, Kullanıcı Hikayeleri içerisinde, olabildiğince basit cümleler ile belirtilir.
Kullanıcı hikayeleri, PMI’ın Proje Yönetim döngüsündeki Kullanım Senaryosu (Use Case) ile ilişkilendirebilirsiniz. Aralarında nüanslar bulunmasına rağmen, temelde ikisi de paydaşların ihtiyaçlarının toplanıp, projeye girdi olarak sunulması amacına hizmet eder. Use Case bu işi, Aktor ve roller yardımı ile UML üzerinden yaparken; Kullanıcı Hikayeleri, işini cümleler üzerinden yapmayı tercih eder.
Kullanıcı Hikayeleri istenilen her formatta oluşturulabilir. Product Owner’ın PBI ları rahatça çıkarabilmesi amacı ile tercih edilen kabul görmüş aşağıdaki şablon, Sprint Planlama Toplantısına da eksiksiz girdi sağlamaya yardımcı olacaktır.
“[Kullanıcı Tipi] olarak, [neden/sebep] yapabileceğim bir sisteme [istek/ihtiyaç] duyuyorum.”
Örnek olarak, “Ben Satış Yöneticisi olarak, operasyonel yükün azalması için, aylık satış raporlarının otomatik olarak mailime düşmesini istiyorum.” Kullanıcı Hikayesini incelenebilir. Burada kullanıcı tipinin belirtilmesindeki amaç, unvana göre işin ele alınması değil; gereksinimin, sistemi kullanacak hangi kullanıcı tipine hizmet edeceğini görebilmektir. “iş takipçisi”, “son onaycı”, “destek personeli” gibi rolün yapacağı işi belirten kullanıcı tipleri, işin doğru şekilde ele alınmasında fayda sağlayacaktır.
Destan (Epic)
Destan kavramını, Kullanıcı Hikayelerinin bir araya gelmesi ile oluşan bir paket olarak değerlendirebiliriz. Ancak Destan kavramı için illa birden fazla hikayenin bir araya gelmesi gerekmez. Genel olarak büyük Kullanıcı Hikayeleri de Epic olarak adlandırılır. Buradaki “büyük” kavramının herhangi bir tanımı bulunmamakta; Scrum yapısı oturdukça, organizasyonun kendi içerisindeki büyük kavramı netlik kazanmaktadır. “Destan olarak adlandırmak için yeterince büyük mü?” sorusunun cevabını ben; “direkt Task basamağına kadar bölemiyorsam, Destan’dır” şeklinde veriyorum.
Destan kavramının kapsamı tabi ki değişkenler ve yöntem doğrultusunda farklılık gösterecektir; ancak bir Destan genel olarak en az iki sprint de tamamlanabilecek büyüklükte bir iş puanlamasına sahiptir.
Konu (Theme)
Temalar, kullanıcı hikayeleri gruplarına verilen isimlerdir. Projenin yapılmasının temel amacını yansıtır. Sprint Planlama Toplantısını, Theme parçalama toplantısı olarak da adlandırılabilir. Konular, projenin genel çerçevesini anlatacak cümle yapılarıdır. Herhangi bir formatta olabilmekle beraber; iş akışı, neden ihtiyaç duyulduğu ya da sorumlusu gibi bilgileri içermesi beklenmez. “Raporlama Ekranının Oluşturulması” şeklinde ihtiyacın hangi amaca hizmet edeceğinin belirtilmesi yeterli olacaktır.
Sonuç olarak, organizasyonlar içerisinde ortak dil kullanmak, iletişimi güçlendirerek hem süreci hızlandıracak, hem de oluşabilecek hataları minimize edecektir. Bu sebeple kullanımında karışıklığa sebep olan bu şekildeki kavramlar üzerine fırsat buldukça derinlemesine yazmaya çalışacağım. Her türlü soru ve önerinizi yorumlar üzerinden yönlendirebilirsiniz.
Yazar : Ali SARAÇOĞLU
