Sprint planlama toplantısında mümkün olduğunca tüm işler planlansa da, takıma gelen acil ve öngörülemeyen işlerolabilir. Özellikle ürünün sürekliliğini sağlamak için ortaya çıkan problem ve bakım gibi anlık işler, bu duruma tipik örneklerdir. Bu nedenle takımlar, sprint boyunca bu tip plansız işlere yer açabilmek için %15–20 oranında bir bufferayırmalıdır.
Buffer’ı, sprint süresince doldurulacak bir havuz gibi düşünebiliriz. Takım bu havuzu sprint boyunca kullanır; kullanımın az ya da fazla olması, sonraki sprintler için deneyimsel veri oluşturur. Böylece takım zamanla ihtiyacı olan ideal buffer miktarını belirleyebilir.
Buffer Yönetiminde Dikkat Edilecekler
-
Buffer sınırsız değildir. Sonsuz bir kuyu gibi düşünülmemelidir. Product Owner, sprint ortasında takıma getireceği işleri önce aciliyet açısından sorgulamalıdır. Gerçekten sprint içinde yapılması gerekiyorsa getirilmelidir.
-
Takıma gelen her iş için büyüklük/efor tahmini yapılmalıdır. Böylece buffer’ın hangi noktada olduğu netleşir. Bu tahmin, genellikle daily scrum sonrasında yapılabilir.
-
Eğer buffer’ın kullanımı beklenenden az kalırsa, takım sprint içinde ek bir iş alabilir.
-
Eğer buffer dolmasına rağmen acil işler gelmeye devam ederse, Product Owner düşük öncelikli ve başlanmamış işlerin sprint backlog’dan çıkarılmasını talep edebilir.
-
Eğer bu da yeterli olmaz ve sprint hedefinde yer alan işler çıkarılmak zorunda kalırsa, sprint hedefi geçerliliğini yitirmiştir. Bu durumda Product Owner sprinti iptal ederek yeni bir planlama yapılmasını sağlayabilir.
Retrospective’de Değerlendirme
Buffer kullanımı, sprintin gidişatını zorlayabilecek bir durumdur. Bu yüzden:
-
Product Owner, bu tip işlerin aciliyetini gerçekten sorgulamalı ve mümkünse sonraki sprintlere taşınmasını sağlamalıdır.
-
Takım ise bu acil ve plansız işleri retrospective’de değerlendirerek azaltılması için aksiyonlar almalıdır.
