Scrum'da yapılan işin temel parçacıkları olan Product Backlog Item (PBI) veya Türkçe adı ile Ürün Gereksinim Maddesi; büyük bir proje veya işi ufak parçalara bölerek işin tümünün bitmesini kolaylaştıracak iş parçacıklarına denir.
Product Owner Proje ve Epics olan büyük işleri PBI olarak görünebilir parçalara bölüp Product Backlog'a ekler. Burada en önemli nokta PBI'ların bir Sprint bazında yapılabilirliği mümkün olması ve işin iyi parçalara bölünmüş PBI'lar dan oluşmasıdır. Gereğinden fazla büyük PBI'lar Sprint Planlamada takıma zorluk çıkartabilir ve işlerin yetişmesini engelleyebilir.
Bir PBI'ın Size değeri yani büyüklüğünü ise Development Team belirler. Takım ilk kurulduğunda PBI Size verme işlemi biraz uzun sürebilir ve Scrum Team, Sprint içinde Product Backlog Refinement yaparak PBI bazlı Size verme ve iş planlaması yaparak bir sonraki Sprint'ler için planlama işlerini kolaylaştırır. Product Backlog Refinement toplantısında öncelik PBI belirlemektir. Estimate başta verilmez fakat takım zaman kazanmak ve Size büyüklüğü verme becerisini geliştirmek için Estimate verme işlemini toplantının kalan kısmında verebilir. Product Backlog Refinement toplantısına genelde Product Owner ihtiyaç duyar. Amacı takımın önünü görmek ve ilerleyen Sprint'ler de işleri daha iyi planlamak içindir.
PBI'lar için en önemli kriterler Size büyüklüğü, Öncelikliği ve PBI tipidir. Size büyüklüğü genelde 0, 1, 2, 3, 5, 8, 13 ve 21 olarak belirlenir. Takımlar genelde 13'den fazla Size değeri alan bir PBI'ı ikiye böler. Amaç o PBI'ı daha şeffaf hale getirmek ve üzerinde bir belirsizlik veya kritik durum kalmasın diyedir. Bir diğer kriter ise Öncelik(Priority) sırasıdır. Öncelik sırasına göre PBI'lar Product Backlog'da dizilir ve takım bu önceliğe göre işleri alıp almamak üzerine planlama yapar. Kapasitesinden fazla PBI aldıysa önceliği en az olandan çıkarmaya başlar. Sprint içinde pek tavsiye edilmese de planlamada olmayan bir PBI Emerged edilebilir, fakat bu Sprint Goal'ü etkileyecek bir ekleme olmamalıdır.
PBI Tiplerinden bahsedecek olursak;
Development(Geliştirme)
Test Request(Test Desteği veya Test Gerekliliği)
Spike(Kapsam belirleme, Analiz, Araştırma, Gereksinimler, Toplantı, Gelişim Süreci)
Maintenance/Support(Bakım ve Destek)
Product Defects(Ürün ortamı hataları veya problemleri)
Spike olan PBI'ların Size değerleri genelde düşük olur hatta sıfır "0" bile olabilir. Çünkü Sprint içinde zaten yapılması gereken işler olduğu için bunlar Increment sağlayacak çalışmalar değildir. Sadece Increment'a giden yolda bizi geliştirecek işlerdir. Size büyüklüğü sıfır bile olsa Spike'ların Scrum Board'da olmasını öneririm.
Kaizen Action ve Task'lar Nasıl Belirlenir
Task'lar genelde Saat maliyeti verilen ve PBI'ların iş görevlerini belirten maddelerdir. Bir kişi üzerine Assign edilebilir veya birkaç kişide aynı Task üzerinde çalışabilir. Takım eğer PBI Size verme işlemini ve eritebileceği size kapasitesini çok iyi biliyorsa, PBI'ları Task etme işlemini Sprint içinde yapabilir ve saat maliyeti vermeyebilir. Bunun yerine Task için Başlangıç(In Progress) ve Bitiş(Done) zamanlarını tutarak bir Task'ı 3 günden fazla Scrum Board'daki In Progress kolonunda bekletmeyip onu bitirmeye odaklanır.
PBI'ları Task'lara bölme işlemi genelde Sprint Planning kısmında olur. Planlama toplantısının ikinci kısmında Development Team, PBI'ları Task'lara bölerek işi nasıl yapacağını konuşur. Task tipleri genelde; Development, Test, Analiz, Teknik Analiz, Backend, Services gibi konulara ayrılabilir. Task'lar için önemli kriterler; saat maliyeti, Task tipi, Assign edilen kişi veya kişiler ve PBI numarasıdır. Task'larda saat maliyeti artırılabilir, ne kadar çalıştığın değil ne kadar saat işin kaldığı yazılır.
Kaizen Action; Sprint Retrospective Toplantısından çıkan aksiyon maddeleridir. Kaizen maddelerini hem Scrum Board'daki Kaizen(Time to Improve) kısmında hemde Kaizen Backlog(Excel)'da tutabilirsiniz. Bu aksiyonlardan kalıcı Kaizen maddeleri çıkabilir. Kalıcı olan aksiyon maddelerini Scrum Board'a asabilirsiniz. Bu sayede takım bu maddeleri unutmaz. Kaizen Action'lar PBI olarak Product Backlog'a eklenebilir.
Örnek Kalıcı Kaizen Action Maddeleri;
* Bir PBI'a birden fazla kişi odaklanacak ve In Progress'de maksimum 3 veya 4 PBI olacak.
* Bir kişi üzerinde veya iş de İmpediments varsa herkes oraya odaklanarak engel aşılacak.
* PBI'lar Daily Scrum'da takımca planlanacak.
* Task değil PBI üzerinden koşularak durum belirlenecek.
Burak AVCI
Hiç yorum yok:
Yorum Gönder
Makaleye Yorum ve Sorularınızı Bırakabilirsiniz.