Sprint Planning (Planlama) Pratikleri Nelerdir?

Bu yazımızda Sprint Planning (planlama) toplantılarında tecrübe ettiğimiz iyi pratikler ve hatalı uygulamalardan bahsedeceğiz.

Buna geçmeden önce kısaca Sprint Planning (Planlama)’dan bahsedelim. Öncelikle Sprint Planlama toplantılarında hepinizin merak ettiği “Ne Yapacağız” ve “Nasıl Yapacağız” sorularına birlikte cevap verelim.

Planlama toplantılarında önceki sprint’in çıktıları,metrikleri,ayrılan bufferlar değerlendirilir. Definition of Done (DoD ) a uygun tamamlanmayan product backlog itemlar yeni sprinte dahil edilecekse tekrar re-size edilir ve takımın önündeki sprint için takımın toplam gücü hesaplanır.  Detaylandırılmamış öncelikli product backlog itemlar Development Team tarafından Fibonnacci serisi baz alınarak tahminlenir.  Development Team üyeleri takımca tahminleme yaparak Product Backlog Item (PBI)ların büyüklük tahminini tamamlar.

Product Owner (PO) ile Development Team,Sprint Golleri ve sprint sonunda kabul kriterleri ve DoD’a göre teslim edilecek olan Product Backlog Item’lar üzerinde el sıkışırlar. Development team taahhüt ettiği PBI ‘ları teslim edebilmek için detaylı analiz ,tasarım  yapar ve PBI ları tasklara bölerek o sprintte yapılması gereken aktivitelerileri belirler. Tasklar en fazla 8 saat olacak şekilde kırılmaya bölümlenmeye çalışılmalıdır. Product Backlog Item(PBI) ın Definition of Done (DoD) a ve Kabul kriterlerine uygun tamamlanabilmesi için gerekli olan tasklar çıkarılmalıdır. Sprint sırasında Development Team ‘in yapacağı aktivitelerin(taskların) sprint backlogda yer almasına çalışılır.

Development team product backlog itemları tasklara bölerken aynı zamanda gerekli analiz ve tasarımıda takım olarak yapar. Sonrasında Development Team tasklar için efor tahmini yaparak sprint sırasında takibini yapacağı Burn-Down Chart’ın başlangıç halini hazır hale getirmiş olur.

Gelelim Sprint Planlamadaki İyi Pratiklere;

  • Developmet Team taskları max. 8 saat olarak bölmeye çalışmalıdır.
  • Planlama toplantılarının başında takımın metriklerini inceleyerek o Sprint’in performansını ve çıktılarını diğer sprintlerle karşılaştırmalıdır.
  • Son retrospective toplantısında konuşulan aksiyon adımlarının Sprint Planlama sırasında dikkate alınmalıdır.
  • Planlama toplantılarının  görseller kullanılması (Fiziksel Board, Tahta vb.)
  • Planlama toplantısına girmeden önce Product Backlog Refinement için backlog’un detaylandırılmış olması gereklidir.
  • Takımın hızının (Velocity) doğru hesaplanması için sprint içerisinde planlanmayan ancak sprint içinde ACİL yapılan işlerin Sprint sonlarında ya da Daily sonlarında size edilmelidir.
  • Planlama toplantısı sonrasında takımın şeffaflığı artırmak için, taahhüt ettiği Product Backlog(PBI)’ların listesini paydaşlarla paylaşılmalıdır.

Planlama’da Karşılaşılan Hatalı Uygulamalar ise;

  • Procut Owner(PO) Ların toplantılarda Development Team’i fazla taahhüte zorlaması yada taskların nasıl yapılacağına karışması
  • Toplantıların geç başlaması, geç bitmesi ,tarihlerinin değiştirilmesi
  • Product Owner(PO)’ların detaylandırılmamış ve planlamaya hazır olmayan Product Backlog ile toplantıya katılmaları
  • Scrum Masterların yada Product Owner(PO)’ların proje yöneticisi gibi davranıp takım üyelerine task atamaya çalışması
  • Büyüklük Tahmini ile tasklara verilen saat efor arasında lineer bir ilişki kurulmaya çalışılması
  • Development Team in toplantıda tasarım ve plan yapmaması ve bu aktiviteleri Sprint’in diğer günlerine bırakması
  • Product Backlog Item(PBI) ların öncelik sırası olmaması ,kabul kriterlerinin olmaması ,Büyüklük tahminlerinin yapılmamış olması ,Çok büyük ve genel yazılmış olması

Bir sonraki yazımızda görüşmek üzere;

Bir Yorum Yazın