Scrum basit, anlaması kolay ama uygulaması zordur. Her ne kadar Scrum Guide bize bir çerçeve çizse de karşılaştığımız durumlarda bu çerçeve içinde nasıl kalacağımız konusu kafamızda soru işaretleri doğurabilir. Takımların en çok karşılaştıkları durumlardan biri sprint bittiğinde planlanan işler in bitmemesidir. Bu ve buna bezer diğer durumlarda takım nasıl davranmalı hadi biraz tartışalım.
Sprint bitti ama hala bitmeyen planlanan işler varsa
Sprint Planlama etkinliklerinde takım önündeki sprint hedefine göre neler yapacaklarını planlar. Sprint süresi bittiğinde de kimi zaman bu planlanan işlerin tamamı bitmeyebilir. Peki bu durumda takımın kalan işler için yapabileceği alternatifler neler olabilir?
Takımların aklına ilk gelen alternatif yetişmeyen işlerin hemen bir sonraki sprinte devredilmesidir. Ama durun hemen buna karar vermeyin. Başka alternatifler de olabilir.
Öncelikle yetişmeyen işler Review etkinliklerinde belirtilmelidir. Takım sprint hedefine ulaşabildi mi, hangi işleri tamamladı, hangilerini tamamlayamadı, paydaşlarıyla paylaşmalıdır. Paydaşlardan geri bildirim alarak yetişmeyen işler product board ile birlikte düşünülerek tekrardan tartışılabilir. Bunu tartışmanın sonucunda;
1- Yetişmeyen işler paydaşlar için hala öncelikli ise Product Board’da üst sıralara alınabilir. Bu bir sonraki veya yakın bir sprintte tekrar yapılmak üzere planlanacak anlamındadır.
2- Tekrar değerlendirme sonucu yetişmeyen işler önceliğini artık kaybetmişse, Product Board’dan kalkabilir veya öncelik sırasında daha aşağılara alınabilir.
Takımlar genellikle birinci alternatifle ilerler. İkinci alternatif göz ardı edilendir. Ama çevik çalışmanın sebeplerinden biri de önceliklerin hızlı değişkenlik göstermesidir. 1 sprint bile geçmiş olsa öncelikleri sürekli değerlendirmek gerekir. Bu değerlendirmeyi yapmazsak sırf önceki sprintten kaldı diye, önceliğini yitirmiş bir işi yapmış olacağız. İsraf israf israf.
İşlerin neden yetişmediği konusunu da mutlaka değerlendirmek gerekir. Retrospective etkinlikleri de bunun için var zaten. Sprinti takımca değerlendirmek, neleri yanlış yapıyoruz diye tartışmak gerekir. Varsa iyileştirme yöntemlerine karar verilir.
Sprintte planlanan işlerin bitmemesinin en çok karşılaşılan nedeni planlamanın yanlış yapılmasıdır. Yeni olumuş takımlar için bu çok doğaldır, hatta yaşanması gereken bir süreçtir. Takım hızını öğrenmesi için birkaç sprint tecrübe etmeye ihtiyacı vardır. Bu sürede takım birçok yöntem denemelidir. Kendileri için en iyi yöntemi bu deneysellik ile bulacaktır.
Sprint bitmeden planlanan işler biterse
Oldu ya planladığımız işler sprintten önce bitti. Kalan sprint günlerine ne olacak, ne yapacağız?
❌ İşler erken bitti diye sprint de bitti diyemeyiz. Sprint süresini bu şekilde esnetmemiz doğru değildir. Bu konuda anlaşalım ve sakince diğer güzel alternatiflere odaklanalım.
1- Product Backlog’tan yeni iş çekmek: Developers, Product Owner ile birlikte Product Board’a odaklanır. Takımın kalan sprint günlerinde tamamlayabileceği ve öncelikli işler sprinte dahil edilebilir.
2- Kaliteye odaklanmak: Bu süre takımın kaliteyi arttırması için bir fırsattır. Teknik borçlar eritilebilir, yapılan işlerin kalitesi arttırılabilir.
3- Kişisel gelişime odaklanmak: İşlerin erken bitmesi kişisel gelişime biraz daha zaman ayırma fırsatını sunabilir. Takım üyelerinin kişisel gelişimine vakit ayırabilmesi, daha sağlıklı sprintler anlamına gelir. Sadece işlerin erken bittiği zamanlarda değil, takım sprint planlarında kişisel gelişim için de pay bırakmalıdır.
Sprintin ortasında planlanan işlerin bitmeyeceği farkedilirse
Eyvah işler yetişmeyecek!
Panik yok. 🤗 Olabilir, işler yetişmeyebilir ama akla ilk gelen o yöntemlere başvurmayın. Yani;
❌ Sprintten madde çıkartmayın.
❌ Sadece o sprint için takımı genişletmeyin. Yani “kaynak” yığmayın.
Planladığınız işleri yapmaya devam edin. Sprint’in sonunda neleri tamamladınız neleri yapamadınız Review’da paydaşlarla paylaşırsınız, Retrospective’de takımca sprinti değerlendirirsiniz.
Madem önceden farkettik, sprint süresince çeviklik becerilerimizi konuşturalım.
- Sprint hedefi bizim pusulamız. Ona hizmet eden işlerimiz daima önceliklidir. In Progress’e madde çekerken buna dikkat edebiliriz.
- Bitmeye en yakın işleri de öncelikli görebiliriz. Bu yüzden board okumaya hep sağdan başalarız ya. Aynı mantık. 😉
- Tüm maddeleri yetiştirmek için kaliteden ödün vermeyin, her işi hakkını vererek yapmaya devam edin.
- Definition of Done için de aynı şey geçerli. DOD’den ödün vermek yok.
Retrospective Tekniği : Improve Your Definition Of Done (DOD)
Son Söz ve Tavsiyeler
Sprintlerde karşılaştığımız durumlarda aldığımız kararlar bizim ne kadar çevik olduğumuzu gösterir. Evet Scrum Guide bize bir sınır çiziyor ama yine de o sınırda nasıl davranacağımızı bize bırakır. Burada da Agile Manifesto ve diğer çevik değerler pusulamız olsun. Çevik yapmak güzel ama çevik olmak daha güzel.
İlkim Dilara KADAKALOĞLU
d.
İlk Yorumu Siz Yapın