İçeriğe geç

Sprint İçinde Gelen İşler Ne Olacak?

Bir Sprint Backlog düşünün sadece planlanmış işlerden oluşan. Ne kadar güzel geliyor kulağa değil mi? Sprint koşanlar bilir bunun ne kadar zor hatta imkansız olduğunu. Planladığımız işler olduğu gibi sprint içinde gelen işlerimizin olması da o kadar doğal bir durumdur. Çünkü bilinmezlik hayatımızın her yerinde vardır. Önemli olan bu durumu yönetebilmek ve hızlı kararlar alabilmektir. Peki sprint içinde gelen işleri nasıl yöneteceğiz?

Bu yazıda sprint içinde gelen işler için karşılaşılması en olası senaryoları ele aldım. Sizlerin önerileri, eklemek veya tartışmak istediğiniz konular varsa mutlaka yorumlarda buluşalım. Sonuçta olay ve durumlara deneysel yaklaşıyoruz.

Sprint içinde gelen işler ne olacak?

 

Sprint içinde gelen işler ne olacak?

PO’dan daha öncelikli bir iş gelirse

Sprinti planlarken, o sprintin hedefini de belirleriz. Bu hedef, sprint içinde alacağımız kararlar için yol göstericidir. Eğer PO sprint içinde daha öncelikli bir iş getiriyorsa bu işin sprint hedefine hizmet etmesini bekleriz.

Scrum Master bu durumda belki Sprint Hedefi’ni PO’ya hatırlatma ihtiyacı duyabilir. Takım olarak hedefe uygun olup olmadığı tartışılabilir. Sonuç olarak bir karar verilir. Bu karar Sprint Hedefini destekleyen ve onu riske atmayacak şekilde olmalıdır.

Bazen takımca ortak karar verebildiğimiz gibi bazen de karşılıklı birbirini ikna yöntemine giderek de kararlar alınabilir.

Başladığımız işin içinden iş çıkarsa

Sprint Planlama sırasında her şeyin çok net olduğunu düşünsek de işi yapmaya başladığımızda öngöremediğimiz durumlarla karşılaşabiliriz. Bu çok doğal bir süreçtir.

Bu durumda takım 2 şeyden endişelenir.

1- İşi bu sprintte tamamlayabilecek miyiz?

2- İşin büyüklüğünü sprintte nasıl göstermeliyiz?

Öncelikle Sprint Backlog’un güncellenmesini hatırlatmak istiyorum. Mutlaka sprint içindeki değişiklikler, ekleme ve çıkartmalar Sprint Backlog üzerinde gösterilmeli ve sürekli güncellenmelidir.

Birinci maddeden başlayalım. İşi tamamlamak için ekstra bir mesai veya takıma geçici olarak birini ekleme yöntemleri oldukça yanlıştır. Takım kendi kapasitesi ile devam etmesi gerekir. Geliştiriciler ve PO’nun bu durumda bir araya gelmesi ve Sprint Hedef’ine göre bir karar alması gerekebilir. Alınacak kararlar için bir genelleme yapmak çok zor, senaryo çok fazla ve farklı olabilir. Ama en basit ve olası karar; takımın sprinte devam etmesi ve işi tamamlayabildiği kadarıyla yapmasıdır. Sprint Review’da durumu paydaşlarla beraber değerlendirebilirler. Sprint Retrospective de ise neden böyle bir durumla karşılaştıklarını tartışıp iyileşme noktalarını keşfedebilirler.

İkinci madde ile devam edelim. Yine net reçetesi olmayan bir durum. Burada da birçok farklı yöntem izlenebilir. İşin, planlanan büyüklük (size) ve gerçekleşen büyüklük bilgileri ayrı ayrı tutulabilir. Veya işin büyüklüğü sprint sonunda gerçekleşen büyüklük ile güncellenebilir. Ne yapmak gerektiği takımın ihtiyacına veya göstermek istediğine göre değişmelidir.

Acil bir iş gelirse

Her işin acil gelme potansiyeli oldukça yüksektir. Peki gelen iş gerçekten “Acil” mi? İlk bu soruyu sorarak bu süreci yönetmemiz gerekiyor. Bu konuda anlaşalım. Eğer her iş acil geliyorsa, “Hayır” deme kültürünü yavaş yavaş ayağa kaldırma zamanı gelmiş demektir.

Eğer iş gerçekten acil değilse veya sonraki sprint planlamasına kadar bekleyebilecek bir işse, o işi Sprint’e almamak daha doğru bir karar olacaktır. PO paydaşlarla Product Backlog üzerinde tekrar bir önceliklendirme çalışması yapabilir.

Peki iş gerçekten acilse? O zaman sprinte dahil edilebilir. Karşılığında sprintten bir madde çıkarmak bence doğru değil. Sebebi de Sprint Hedefi’ni riske atmamak için ama yine de tartışmaya açığım. 🤗

Eğer her sprint “Gerçek Acil İş” geliyorsa, takım planlamalarında bu tarz işler için ufak bir buffer ayırabilir. Takım bir sprintte ne kadar bu tarz iş geldiğini ölçebilirse buffer’ın büyüklüğünü belirlemek o kadar kolay olacaktır.

Gelen işin sprint içinde “Plansız” geldiğini belirtmek, takıma ne kadar bu tarzda iş geldiğini görselleştirmelerine yardımcı olabilir.

Scrum Metrikleri

 

Son Söz ve Öneriler

Aslında her bir durum için çok farklı çözüm önerileri sayabiliriz. Ben en çok tercih edilen olanlar üzerinde durdum. Daha önce de dediğim gibi önemli olan takımın neye ihtiyaç duyduğu ve kararların ona göre verilmesi gerektiğidir.

Peki sizlerin önerileri neler? Yorumlara bekliyorum. 👇

 

İlkim Dilara KADAKALOĞLU
d.

Tarih:Sprint

İlk Yorumu Siz Yapın

    Bir cevap yazın

    E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

    %d blogcu bunu beğendi: