Scrum Kılavuzu | 34. Scrum'da Hız – Geliştirme Takımının Hızı

Yayınlanan: 2022-07-06

Scrum'daki Hız, Scrum Takımının görevleri tamamlama hızını belirlemenize yardımcı olur. Bir Sprint'te tamamlanan ortalama Story Point sayısı olarak tanımlayabiliriz. Velocity, halihazırda tamamlanmış olan iş ilerlemesine dayalı olarak bir projenin süresini de tahmin edebilir. Ancak bu, yalnızca dengeli ve istikrarlı bir hızda çalışan olgun bir ekip için anlamlıdır. Velocity'nin ne olduğuna ve sizin için en iyi şekilde nasıl çalışacağına bir göz atın!

Scrum'da Velocity – içindekiler tablosu:

  1. Scrum'da Hız – Giriş
  2. Gerçek ve planlanan hız
  3. Scrum'da Velocity ile ilişkili zorluklar ve riskler
  4. Özet

Scrum'da Hız – Giriş

Hız, bir Scrum Takımının hızını ölçmek için isteğe bağlı ancak popüler bir yöntemdir. Bunun nedeni , doğru bir şekilde tahmin edilen Hızın, bir projeyi tamamlamak için gereken süreyi makul bir ölçüde tahmin etmeyi sağlamasıdır. Ancak, yalnızca kendisine “değer verdiği” görevleri, örneğin Öykü Puanları gibi tanıdık bir birim kullanarak gerçekleştirecek olan belirli bir Geliştirme Ekibine uygulanabilecek bir ölçüdür.

Geliştirme Takımının Hızı genellikle bir Hız Tablosu şeklinde sunulur. X ekseninde ardışık Sprintler işaretlenir. Y ekseninde ise, belirli bir Sprint'te tamamlanan Öykü Puanlarının veya diğer karşılık gelen birimlerin sayısını bulacağız. Hız Tablosu ile Scrum Takımı, çalışmalarının hızındaki değişiklikleri net bir şekilde görür. Grafikte işaretlenen çizgi yükseliyorsa, Takım verimliliğini optimize ediyor veya Öykü Puanlarının değerini düşürüyor demektir. Bu nedenle hem Scrum Master hem de Ürün Sahibi, Takımın Hızını gösteren çizgiyi dikkatle izlemelidir.

velocity in scrum - speed of the development team

Gerçek ve planlanan hız

Geliştirme Takımının gerçek Hızı , tamamlanan Sprint'teki işin hızını tanımlar ve her Sprint'in sonunda hesaplanır. Tamamlanan tüm Kullanıcı Hikayeleri için Hikaye Puanlarının toplamının değerini alır. Geliştirme Ekibinin Gerçek Hızı, gelecekteki görevlerin hızını bir olasılıkla planlamanıza ve tahmin etmenize olanak tanır.

Planlanan Hız ise gerçek Hızın ortalama değerine dayalı olarak tahmin edilir. Geliştirme Takımında herhangi bir değişiklik olmayacağı varsayımını gerektirir. Geliştirme Ekibi için önemli bir dahili araçtır ve buna dayanarak Ekip içindeki işbirliğinin iyi gidip gitmediğini ve çalışma hızının korunup korunmadığını değerlendirebilir.

Planlanan Hız ayrıca Ürün Sahibinin sonraki Sprint'lerde yürütülmesi planlanan iyi tanımlanmış Kullanıcı Hikayelerinin yürütme süresini tahmin etmesini sağlar. Bu, bu makalede hakkında yazdığımız Ürün İş Listesinin daha verimli beslenmesini sağlar. Ancak, proje sürelerini tahmin etmek için planlanan Hızın uygulanması o kadar basit değildir.

Scrum'da Velocity ile ilişkili zorluklar ve riskler

Scrum'da hıza genellikle aşağıdaki faktörler dikkate alınmadan çok fazla önem verilir:

  • daha büyük bütünleri veya tüm projeyi tahmin etme – Geliştirme Ekibi belirli bir göreve atanacak Öykü Noktalarının sayısını doğru bir şekilde tahmin edebilirken, bu birimlerde gelecekte uygulanmak üzere daha büyük bütünleri tanımlamak çok zor veya imkansızdır
  • projedeki değişiklikler – projedeki herhangi bir değişiklik potansiyel olarak Ürün Hedefine ulaşmak için gereken Öykü Puanlarının sayısında bir değişiklik anlamına gelir. Halihazırda tamamlanmış görevlerin değiştirilmesi veya Ürünün son sürümünde kullanılmaması gerekebilir.
  • öngörülemeyen olaylar – halihazırda tamamlanmış olanlara dayalı olarak gelecekteki projelerin hızını tahmin etmek, yani gerçek Hızı Planlanan Hıza çevirmek, doğru tahminlerle sonuçlanabilir. Bununla birlikte, her projenin kendine has özellikleri vardır ve tarihe dayalı doğru bir tahmin genellikle imkansızdır.
Velocity in Scrum

Özet

Geliştirme Takımının etkinliğini değerlendirmek için Hız'ı bir ölçü olarak kullanmak , onun güvenilirliğinin düşmesine neden olabilir. Ayrıca, bu makalede daha ayrıntılı olarak yazdığımız tahminlerin kalitesini de düşürebilir . Sonuçta, metriklerde mümkün olan en iyi sonuçları elde etmek için Geliştirme Ekibi, Hızı artırmak için görevlerin emek yoğunluğunu fazla tahmin edebilir. Bu, ekibin kendisi daha sonra iyileştirmeler yapmak ve görevlerini daha doğru planlamak için değerli bilgileri kaybettiği için zararlıdır.

Scrum'daki hız, öncelikle Geliştirme Takımı tarafından işin hızını değerlendirmek için kullanılan dahili bir ölçü olarak kullanışlıdır. Bunun nedeni, tek bir Sprint sırasında kaç görevi tamamlayabileceğini belirlemesine izin vermesidir.

Ürün Sahibinin elindeki hız, daha büyük görevler için son teslim tarihini tahmin etmek için kullanışlı bir araç haline gelir.

Bununla birlikte, en büyük riskler, Geliştirme Ekibini değerlendirmek için bir ölçü olarak Velocity'nin kullanılmasıyla ilişkilidir. Bunun nedeni, Scrum Takımının çalışmalarının dış değerlendirmesini iyileştirmek için güvenilirliğinin düşmesine ve hatta değerinin kasıtlı olarak fazla tahmin edilmesine yol açabilmesidir.

İçeriğimizi beğendiyseniz, Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest'teki meşgul arılar topluluğumuza katılın.

Scrum Guide | 34. Velocity in Scrum - Speed of the Development Team caroline becker avatar 1background

Yazar: Caroline Becker

Bir Proje Yöneticisi olarak Caroline, en iyi iş akışlarını tasarlamak ve süreçleri optimize etmek için yeni yöntemler bulma konusunda uzmandır. Organizasyonel becerileri ve zaman baskısı altında çalışabilme yeteneği, onu karmaşık projeleri gerçeğe dönüştürmek için en iyi kişi yapıyor.

Tüm gönderileri görüntüle

Scrum Kılavuzu:

  1. Temel terimler, roller ve kavramlar sözlüğü
  2. Scrum nedir?
  3. Scrum değerleri
  4. Şirketinizde Scrum nasıl uygulanır?
  5. Scrum Takımı - nedir ve nasıl çalışır?
  6. Ürün Sahibi kimdir?
  7. Ürün Sahibinin En Sık Yapılan Hataları
  8. Scrum Master kimdir?
  9. İyi bir Scrum Master'ın Özellikleri
  10. Scrum Master'ın en yaygın hataları
  11. Scrum Master hangi istatistikleri ve metrikleri izlemelidir?
  12. Ürün Sahibi ve Scrum Master Arasındaki İşbirliği
  13. Scrum'da Geliştirme Takımı
  14. Geliştiricilerin en yaygın hataları
  15. Scrum eserleri
  16. Scrum'ı Ölçeklendirme
  17. Sprint İş Listesi
  18. Ürün İş Listesi nedir?
  19. Kullanıcı Hikayeleri nedir?
  20. INVEST ile en iyi Kullanıcı Hikayesini Oluşturmak
  21. En yaygın Kullanıcı Hikayesi hataları
  22. Kullanıcı Hikayesi Kabul Kriterleri
  23. Scrum'da Tahmin ve Öykü Puanları
  24. Poker Planlama
  25. Takım Tahmin Oyunu
  26. Artış Tanımlama
  27. Scrum etkinlikleri
  28. Scrum'da Sprint nedir?
  29. Scrum Takımı Taahhütleri - Ürün Hedefi, Sprint Hedefi ve Tamamlamanın Tanımı
  30. Burndown Grafiği nedir?
  31. İş bitim grafiği nasıl oluşturulur ve yorumlanır?
  32. İş bitim grafiğinin avantajları ve dezavantajları
  33. Scrum ve Scrumban'da Kanban panoları
  34. Scrum'da Hız - Geliştirme Takımının Hızı
  35. Günlük Scrum
  36. Sprint Planlama
  37. Sprint İncelemesi
  38. Sprint Retrospektifi nedir?
  39. Sprint Retrospektifi sırasında yaygın hatalar
  40. Ürün İş Listesi beslemesi