scrum events time boxing
Scrum Etkinliklerine Giriş:
Daha önceki eğitimlerimizde Scrum'ı ve nasıl yapılandırıldığını tartışmıştık.
Ve önceki öğreticimiz hakkında her şeyi açıkladı Scrum Eserleri detayda.
Scrum Takımını kimin oluşturduğunu ve süreç boyunca hangi farklı eserlerin geliştirildiğini biliyoruz. Artık güçlü bir arka plan oluşturduk. Bu nedenle, Scrum'da bir adım öne geçelim ve Scrum Sürecini oluşturan önemli olayları / törenleri tartışalım.
Bu eğitimde, Scrum Etkinliğinin her birinin ne anlama geldiğini, temel özelliklerin neler olduğunu ve bunları ayrıntılı olarak nasıl organize ettiğimizi anlamaya çalışacağız.
Ne öğreneceksin:
- Genel Bakış
- Scrum Etkinlik Türleri
- Time Boxing nedir?
- Sprint Planlama
- Günlük Standup
- Sprint İncelemesi
- Sprint Retrospektifi
- Bekleme Listesi İyileştirme
- Sonuç
- Önerilen Kaynaklar
Genel Bakış
Scrum tabanlı bir proje üzerinde çalışırken, scrum ekibi bir dizi Scrum Seremonisinden geçer.
Bazıları onlara Scrum törenleri veya etkinlikleri diyebilir ve diğerleri onları ritüel veya toplantılar için çağırabilir. Burada kullanılan farklı terminolojilere bakılmaksızın, her Scrum etkinliğinin amacı aynı kalır. Scrum olaylarının her biri, özünde, Sprint çalışmasının gerçekleştirilmesine ve izlenmesine yardımcı olur.
Scrum Etkinlik Türleri
Her Scrum seremonisi, özel gruplar için Scrum Master tarafından düzenlenen yüz yüze bir olay / toplantıdır. Çekirdek ekibin dışında, bazı toplantılar paydaşları, teslimat yöneticilerini ve hatta müşterinin kendisini içerebilir. Bu toplantılar zaman sınırlıdır ve bu nedenle öngörülen zaman çerçevesi içinde tamamlanmalıdır.
Her toplantının amacı, katılımcıları bir araya getirmek ve onların eldeki işi tartışmalarına izin vermektir. Her katılımcının beklentisi odaklanmış, meşgul ve katılımcı kalmaktır.
Yapılan işin geri bildirimlerini sohbet etmek, incelemek ve geri almak için bir fırsat olarak değerlendirilir. Sıradan toplantıların aksine, Scrum etkinlikleri sonuç odaklıdır, zaman sınırlıdır, hedef kitleye dayalıdır ve her biri ile uyumlu belirli bir amaca sahiptir.
Time Boxing nedir?
Zaman sınırlama, her Scrum Etkinliğine eklenen temel özelliklerden biridir. Katılımcıların, olayların her birine ayrılan zamanın farkında ve saygılı olmaları beklenir. Olaylar uzatılamaz, ancak toplantının hedeflerine zaten ulaşılmışsa kısaltılabilir.
Aynı zamanda tüm Scrum Etkinliklerinin kolaylaştırıcısı olan Scrum Master, herkesin zaman sınırlamasının önemini anladığından emin olur ve aynı zamanda en iyi sonuçları elde etmek için toplantının amacına ve sapmalarla zaman içinde sonuçlara odaklanmalarını hatırlatmaya devam eder.
Bir etkinlik için Zaman Kutusu ideal olarak uzatılmamalıdır, ancak Scrum'ın kurallarla ilgili olmadığını bildiğimiz için, her katılımcının kabul etmesi halinde süre belirli bir süreye uzatılabilir.
Her Scrum etkinliği için zaman kutusuna nasıl karar veririz?
Scrum Etkinlikleri için zaman aralığı, Sprint'in uzunluğu ile doğru orantılıdır. Bununla birlikte, bu kuralın tek istisnası, Sprint Uzunluğuna bakılmaksızın 15 dakikalık sabit bir zaman çerçevesine sahip olan Günlük Standup'tır.
Sprint uzunluğuna göre her etkinlik için standart zaman dilimleri vardır. Yine de takım, gereksinimlerine göre bu etkinlikler için zaman dilimlerine karar verme özgürlüğüne sahiptir.
Her Scrum olayını ayrıntılı olarak tartışarak bu kavramları daha fazla anlayalım.
Sprint Planlama
Bu seremoninin bir ön koşulu olarak, Ürün Sahibi toplantıya gelmeden önce hazırlanmış kullanıcı hikayelerinden oluşan, önceliklendirilmiş istikrarlı bir Ürün İş Listesine sahip olmalıdır. Kullanıcı hikayeleri, ekibin anlayabileceği kadar iyi biçimlendirilmiş ve açık olmalıdır.
Ürün Sahibi, Ürün İş Listesini geliştirmek için Paydaşlar, Müşteri, Tasarımcı ve Scrum Master'dan yardım isteyebilir.
Bir Kullanıcı Hikayesinde Kabul Kriterlerine sahip olmak zorunludur. Ekip, Kabul kriterleri olmaksızın bir kullanıcı hikayesini reddetme yetkisine sahiptir.
Amaç
Sprint Planlama, bir Sprint başlatılırken yapılan ilk törendir. Sprint Planlama toplantısının amacı bir Sprint Hedefi oluşturmak, Ürün İş Listesinden Sprint İş Listesine kadar kullanıcı hikayelerini seçmek ve bunları ayrıntılı olarak tartışmaktır.
Takım, Ürün Sahibi ve Scrum Master ile birlikte bir toplantı odasında bir araya gelir ve burada Ürün Sahibi, bir sonraki sprint için seçilmesi gereken kullanıcı hikayelerini sunar.
Ekip, hikaye hakkında daha fazla bilgi edinmek istediği kadar çok soru sorabilir ve soruları ele almak Ürün Sahibi'nin sorumluluğundadır. Ekip ayrıca hikayenin eksiksizliği ve uygunluğu açısından da meydan okuyabilir.
Hikaye içinde ek bilgi gerekiyorsa veya tamamlanmamış bir bağımlılık varsa veya eksik bulunursa, ekibin bu hikayeyi reddetme gücü vardır.
Sonuçta, şüpheler giderildi ve ekip bir hikayeyi tamamlamak için yapılması gereken işin tam miktarını bilir, ardından ekip tahmin eder ve her bir Kullanıcı Hikayesine Hikaye Puanları verir.
Benzer şekilde, diğer hikayeler tartışılır ve tahmin edilir. Ekip şimdi, Geçmiş hızlarına göre Sprint'te taahhüt edip tamamlayabileceklerini düşündükleri, Öncelikli Ürün İş Listesinin en üstünden Sprint İş Listesi'ne Hikayeleri seçiyor.
Hız, ortalama bir sprintte tamamlanan toplam hikaye puanı sayısına göre belirlenir. Hız, geçmiş Sprintlere dayalı olarak ve bunların ortalaması alınarak hesaplanır. Ne kadar çok sprint tamamlarsak, bir takımın hızı o kadar sabittir.
Birçok takım Hikaye Tahmini için Planlama Poker kartlarını kullanır. En yaygın tahmin tekniği, Fibonacci serisini kullanan hikaye işaretlemedir. Fibonacci serisi, serideki her bir sonraki sayının önceki iki sayının toplanmasıyla oluşturulduğu bir sayı dizisidir.
Fibonacci Serisi - 1, 1, 2, 3, 5, 8, 13 vb.
13 hikaye puanının ötesinde tahmin edilen kullanıcı hikayeleri, tek bir sprintte tamamlanacak kadar büyük kabul edilir ve bu nedenle, ayrı ayrı tahmin edilebilecek daha küçük mantıksal kullanıcı hikayelerine ayrıştırılır.
Bir Sprint Planlama Toplantısı sırasında, ekip ayrıca Sprint için seçilmiş olan kullanıcı hikayeleri altında görevler oluşturacaktır. Takımın Sprint Planlama sırasında tüm kullanıcı hikayelerini görevlendirmesi beklenmez, ancak bunları başlatmak için yeterlidir. Görevin geri kalanı sprint sırasında yapılabilir.
Bir Sprint Planlama toplantısının temel sonucu, takımın tamamlamayı taahhüt ettiği kullanıcı hikayelerinden oluşan Sprint Hedefi ve Sprint İş Listesi'dir.
Kullanıcı Hikayelerinin yanı sıra, Sprint İş Listesinin bir parçası olabilecek başka tür öğeler de olabilir.
- Sivri uçlar
- Teknik Borçlar
- Hatalar
Sivri uçlar bir çözüm bulmak için araştırma görevleridir, yani ihtiyaç Kullanıcı Hikayesi tarafından tetiklenir. Bazı öyküler basit olmayabilir veya teknik yeterlilikte olmayabilir ve bu nedenle, bunlar etrafında daha fazla analiz ve araştırma gerektirebilir. Bu nedenle bir sivri uç yaratılır. İhtiyaç duyulması halinde bir POC de içerebilir.
Teknik Borçlar mevcut kodun yeniden düzenlenmesidir. Çoğu zaman, ekibin yeni gereksinimleri karşılamak için daha önce geliştirilen kod üzerinde yeniden çalışması gereken durumlar vardır.
Hatalar Scrum'da genellikle kabul edilen kullanıcı hikayelerinden çıkan, ancak mevcut çalışma öğeleriyle ilgili olan gözden kaçan veya yeni gereksinimlerdir. Bir gereklilik değilse, aslında önceki sprintler sırasında ortaya çıkarılan ancak bu sprintte sabitlenmemiş ve önceliklendirilmiş sistemdeki bir hata olabilir.
Katılımcılar
Scrum Takımındaki herkes Sprint Planlama toplantısının bir parçasıdır. Çekirdek ekip dışında hiç kimse toplantıya davet edilmez.
Sprint Planlama toplantısı Scrum Master tarafından organize edilir ve kolaylaştırılır, ancak Ürün Sahibi gösteriyi çalar.
Zaman kutusu
Sprint Planlama toplantısı, iki haftalık bir Sprint için yarım gün kadar uzun sürebilir. Bir Sprint Planlama toplantısının zaman kutusu doğrudan Sprint'in uzunluğuna bağlıdır. Kısa bir Sprint için daha kısa ve uzun bir Sprint için daha uzun.
Sprint Planlama toplantısı, tüm Scrum Mimarisinde çok önemli bir role sahiptir ve geliştirilmekte olan ürünü doğrudan etkiler. Bu nedenle ekip, tüm kullanıcı hikayelerini ayrıntılı olarak tartışmak için gerekli olduğunu düşündükleri kadar zaman harcamalı ve kendilerine uygun alternatif bir zaman çerçevesi önerebilmelidir.
Zaman çizelgesine karar verilip üzerinde mutabık kalınca, takımı hedefe odaklamak ve aynı zamanda zamanı takip etmek Scrum Master'ın sorumluluğundadır.
Günlük Standup
Amaç
Günlük Bekleme, Sprint’in genel sağlık durumunu gösterme fırsatı sunan bir toplantıdır. Aynı zamanda, diğer takım üyelerinin ne üzerinde çalıştığını ve Sprint’in hedefine ulaşmada durdurulan bir şey olup olmadığını tartışmak için bir platformdur.
Günlük bir standup toplantısı sırasında, her ekip üyesi, üzerinde çalıştıkları iş öğeleriyle ilgili ilerlemesinin durumunu paylaşır. Ayrıca, ilerlemelerini engelleyen herhangi bir engel varsa, diğer ekip üyelerini paylaşır ve onlardan yardım isterler.
Günlük bir standup toplantısı sırasında, masanın etrafındaki her ekip üyesi aşağıdaki üç önemli soruyu tek tek yanıtlar:
'Son Günlük Standup Toplantısından bu yana ne yaptınız?'
'Bugün ne yapmayı planlıyorsun?'
c ++ ile yazılmış yazılım
'Çalışmanızı engelleyen herhangi bir engel var mı?'
Diğer ekip üyelerinden biri durumu paylaşırken dikkat etmeleri ve ihtiyaç duyulması halinde yardım teklif etmeleri beklenir. Son ekip üyesi üç soruyu da yanıtladığında toplantı orada biter.
Günlük Standup toplantısı, şu anda üzerinde çalıştıkları yinelemenin mevcut ve genel tamamlanma durumunun ne olduğuna dair genel bir resim verir. Scrum Master, Günlük Standup toplantısının odaklanmış ve zaman sınırlı kalmasında çok önemli bir rol oynar. Ekibin Kullanıcı Hikayeleri ile ilerlemesini engelleyen engellerin çözülmesinden de sorumludur.
Scrum Master ayrıca çekirdek ekipten başka hiç kimsenin soru sormadığından ve durumu sunmadığından emin olmalıdır. Gerekirse kullanıcı hikayeleri etrafında hızlı tartışmalara izin verebilir, ancak her zaman farkında olması gerekir ve istediği zaman devreye girip ekip üyelerinden çevrimdışı bir tartışma yapmalarını isteyebilir.
Katılımcılar
Günlük Standup toplantısına herkes katılabilir. Ancak, çekirdek ekibin toplantıya katılması ve çalışmalarının durumunu sunması zorunludur.
Takımın dışından Sprint ilerlemesi hakkında bilgi sahibi olmakla ilgilenen herhangi biri bile Günlük Standup Toplantısına katılabilir, ancak işinin durumunu sunmasına veya Geliştirme Takımı üyelerine çalışmaları hakkında soru sormasına izin verilmez.
Yalnızca çekirdek ekip üyelerinin iş ilerlemelerini paylaşmalarına izin verilir ve diğer herkesin sessizce dinlemesi beklenir.
Tek bir ekip üyesi olsa bile Günlük Standup toplantısı yapılmalıdır.
Ekip, Günlük Standup Toplantısını kendi başına gerçekleştirebilir veya Scrum Master'dan bunu kendileri için kolaylaştırmasını isteyebilir.
Zaman kutusu
Adından da anlaşılacağı gibi, günlük bir standup toplantısı her gün gerçekleşir ve katılımcıların sadece 15 dakikalık kısa bir toplantı olduğu için ayakta kalmaları beklenir. Buradaki fikir gündeme sadık kalmak ve odaktan sapmamaktır, bu nedenle toplantı kısa tutulur. Toplantıya devam etmek, sadece 15 dakika gerektirdiğinden, insanların toplantıya kolayca bağlanmalarına da yardımcı olur.
Günlük Standup toplantısı da katılımcılar arasındaki karışıklığı azaltmak ve toplantı odalarını günlük olarak rezerve etmek için her gün aynı yerde ve aynı yerde tutulur. Toplantı sırasında dizüstü bilgisayarların, masaüstü bilgisayarların veya cep telefonlarının kullanılması kesinlikle önerilmez.
Ekipler Günlük Standup toplantısının ne zaman yapılacağına ve buna bağlı kalacağına karar verebilir. Ancak normal eğilim, toplantıları sabah ilk iş olarak tutmaktır. Farklı saat dilimlerinde çalışan ekipler için sabah çağrısı işe yaramayabilir ve bu nedenle öğleden sonra veya kendilerine en uygun olanı çağrıyı alabilirler.
Scrum Master, süre izin veriyorsa, ancak herhangi bir maliyetle toplantıyı uzatmasına izin verilmiyorsa, toplantı sonunda önemli haberleri veya güncellemeleri ekiple paylaşabilir.
Sprint İncelemesi
Amaç
Sprint İnceleme Toplantısı, yapılan işi göstermek ve geri bildirimleri toplamak ve katılımı sağlamakla ilgilidir. Bazı yerlerde, Sprint İnceleme toplantısı Sprint Demosu olarak da bilinir. Sprint Gözden Geçirme Toplantısı genellikle sprintin sonunda ancak Sprint Retrospektif toplantısından önce yapılır.
Takımdan seçilen temsilci (ler) mevcut sprint çalışma öğelerini gösterir. Genellikle, kullanıcı hikayesi üzerinde çalışan Geliştirici, çalışmayı gösterir ve izleyicilerden herhangi birinin sorduğu sorulara yanıt verir.
Bitti Tanımı'na göre yapılan kullanıcı hikayeleri, Sprint Gözden Geçirme Toplantısında gösterime aday olan tek adaydır.
Ürün Sahibi, Sprint Değerlendirme Toplantısı sırasında çok önemli bir rol oynar. Gösterilen kullanıcı hikayelerinin her birini kabul kriterlerine göre değerlendirmekten sorumludur ve hikayeyi kabul eder veya reddeder.
Kabul edilen hikayeler daha sonra potansiyel olarak gönderilebilir bir teslim edilebilir olan Bitmiş Ürün Parçası ile entegre edilir. Reddedilen veya tamamlanmamış bir öykünün nereye gideceği, Ürün Sahibi'nin çağrısıdır. Reddedilen hikayeler bir sonraki sprint'in bir parçası olabilir veya yeniden önceliklendirilecekleri Ürün İş Listesi'ne taşınabilir.
Sprint Gözden Geçirme toplantısının temel sonucu, Proje tamamlanma tarihinin genel bir resmidir. Ürün Sahibi hikayeyi kabul eder / reddeder ve kabul edilen hikayeler daha sonra Ürün Parçası ile (önceki sprintler sırasında oluşturulan) bir bütün olarak entegre edilerek tüm ürünü tamamlarken nerede durduğumuza dair daha iyi bir resim verir.
Sprint Gözden Geçirme toplantısının bir diğer önemli sonucu, takım üyelerinin tahmin hakkında bir şeyler öğrenmesidir. Kabul edilen kullanıcı hikayelerinin sayısı, bir sprintte elde edilen hikaye puanı sayısını belirler.
Böylelikle, sprint ile kademeli olarak sprint ile takım, doğru tahmin etme ve başarılması mümkün olan hikaye noktaları hakkında bilinçli bir karar verme yeteneğini geliştirebilir.
Bu tür toplantıların, eksik Kabul Kriterlerine veya `` ortaya çıkan yeni şartlara '' ışık tuttuğu sıklıkla görülmektedir. Bu durumdan kurtulmanın en iyi yolu, hikayeleri kapatmak ve Sprint Planlama Toplantısı sırasında başlangıçta üzerinde anlaşılan tüm Kabul Kriterlerini karşılıyorlarsa bunları tamamlandı olarak işaretlemektir.
Bunun dışında her şey yeni bir gereksinim olarak kabul edilecek ve Ürün Sahibi gelecekteki sprint için bu gereksinimlerden sorumludur.
Katılımcılar
Sprint İnceleme Toplantısına Scrum Master ve Ürün Sahibi dahil Takım Üyeleri katılır. Sprint İnceleme Toplantısındaki diğer katılımcılar, paydaşlar, teslimat yöneticileri, müşteriler / son kullanıcılar veya Sprint Review'un bir parçası olmakla ilgilenen kişilerdir.
Zaman kutusu
İki haftalık bir sprint için ideal bir senaryoda, Sprint Review toplantısında yaklaşık 2 saat geçiriyoruz. Bu, Sprint'in uzunluğuna göre değişebilir. Daha kısa bir sprint için daha kısa Sprint Review ve daha uzun bir sprint için daha uzun Sprint Review.
Diğer toplantılar gibi, Scrum Master da toplantının ivmesini korumaktan ve faaliyetlerin (hikayeleri gösterme, soruları yanıtlama, hikayeleri kabul etme, not edilen geri bildirimler vb.) Öngörülen zaman çerçevesine uyduğundan emin olmaktan sorumludur.
Sprint Retrospektifi
Amaç
Sprint Retrospektifi, Agile'ın söylediği şeyi somutlaştırmakla ilgilidir - ' Nasıl daha etkili olunacağına dair düzenli düşünceler ’. Sprint Retrospektifi, tüm takıma sprintin nasıl gittiğini ve süreçleri doğaçlama yapmak için ne yapılması gerektiğini düşünme ve düşünme fırsatı verir? Sprint Retrospektifi, her sprint sonunda yapılır.
Bir Sprint Retrospektif toplantısı sırasında, tüm ekip bir araya gelir ve henüz tamamlanan Sprint'i tartışır. Ekibin şeffaf olması ve dürüst fikirler vermesi bekleniyor ancak etrafta suçlama oyunu yok.
Toplantının amacının doğaçlama alanında bir adım öne geçmek ve üyeler arasındaki gerilimi artırarak ekibi tutmamak olduğunu hatırlayın.
Herkes içinde Takımın dört temel soruyu yanıtlaması bekleniyor:
Scrum Master, ekip üyelerinden her bir kadran için puanlarını yukarıda yapışkan notlarda gösterildiği gibi yazmalarını ister. Bazı yerlerde aletler aynı amaçla kullanılmaktadır.
Ne iyi gitti?
Takım üyeleri son Sprint'te neyin iyi gittiğine dair bir veya daha fazla puan verir. Bu bölüm, diğer ekip üyelerini iyi çalışmaları için takdir etmek ve takdir etmek için bir fırsat olarak da alınabilir.
Ne öğrendin?
Scrum, her sprintte yeni bir şey öğrenmek için bir fırsat olarak kabul edilir. Bir çeyreğin bu alanı, son Sprint'ten temel çıkarımları ve öğrenmeleri tartışmaktır.
Ne iyi gitmedi?
Takım, bu bölümde son sprint sırasında karşılaştıkları sorunları ve engelleri tartışır. İnsanlar diğerlerini rahatsız edebilecek sorunları gündeme getirebileceğinden, toplantının bu kısmı en kırılgan kısım olma eğilimindedir.
Gerektiğinde atmosferi sakinleştirmek ve insanlara kişisel saldırı turlarından geçmek yerine sorunlarını yapıcı bir şekilde gündeme getirmeyi öğretmek Scrum Master'ın sorumluluğundadır.
Üyelerden herhangi biri diğer takım arkadaşlarının önünde sorunlarla yüzleşmekten rahatsız olursa, daha sonra Scrum Master'a gidebilir ve konuları tartışabilir.
Daha iyi ne yapılabilir?
Toplantının bu bölümü, tüm ekip üyelerine daha önce ortaya konulan tüm sorunları tartışma ve bunları çözmenin yollarını bulma fırsatı verir. Ekipteki herkes, elindeki soruna çözümler önermekten memnuniyet duyar. Ekip daha sonra birlik içinde en uygun çözümlere karar verir.
Ekip ayrıca gelecekteki sprintler için iyi gidenler bölümünde tartışılan konulara bağlı kalmayı da düşünmelidir ve bu şeyler ileriye dönük olarak sürecin ayrılmaz bir parçası olarak eklenebilir.
Sprint Retrospektif toplantısının sonucu, gelecek sprint için süreci iyileştirmek için katılımcılar tarafından kabul edilen eylem maddelerinin bir listesidir.
Katılımcılar
Scrum Master ve Ürün Sahibi dahil tüm Scrum Takımı. Ancak günlük bir standup toplantısından farklı olarak, Scrum Master ve Ürün aynı zamanda kendi girdilerini ve geçmişe yönelik noktaları sağlamaya da katılır.
Günlük Standup toplantısı gibi, Sprint Retrospektif toplantısı da Scrum Master tarafından kolaylaştırılır. Scrum Master, kendisi de dahil olmak üzere takımdaki herkese hem pozitif hem de negatifleri açma ve konuşma fırsatı verilmesini sağlar.
Ekip dışındaki katılımcıların Sprint Retrospektif Toplantısına davet edilmediğini not edin. Sprint Retrospektifi, takım üyelerinin tereddüt etmeden açılmalarına ve son sprint sırasında karşılaştıkları sorunları tartışmalarına olanak tanıyan biraz kişisel ve duygusal bir ortam olarak kabul edilir.
Zaman kutusu
Haklı olarak, tüm Scrum Seremonilerinin zaman kutulu olduğu ve zaman çerçevesinin Sprint'in uzunluğuna bağlı olduğu söylenir. İki haftalık bir sprint için, 2 saatlik bir Sprint Retrospektif toplantısı yapmak ideal.
Windows 7 için ücretsiz sistem temizleyici
Bununla birlikte, Sprint Retrospektifi'ne iletişim kurmak, geçmişe bakmak ve gelişmeleri taahhüt etmek için bir fırsat olarak bakarsak, önemli görüş ve kavrayışları kaybetmekten kaçınmak için toplantıya yeterli zaman vermek çok haklı olacaktır.
Bu nedenle, toplantıya zaman ayırmak iyidir, ancak iletişim ve ilerleme pahasına yapılmamalıdır. Scrum'daki bir diğer önemli olay da İş Listesi İyileştirmedir. Biraz ışık tutalım.
Bekleme Listesi İyileştirme
Backlog geliştirme olarak da bilinen Backlog Refinement, bir sonraki Sprint'in bir parçası olabilecek Ürün İş Listesindeki kullanıcı hikayelerini tartışmak için bir toplantıdır. Bir birikim iyileştirme toplantısında, tüm ekip birlikte oturur ve kullanıcı hikayelerini tartışır ve böylece girdilerini sağlar.
Genel fikir, Ürün İş Listesini gelecek Sprint için hazırlamak ve kullanıcı hikayelerinin seçilmeye hazır olduğundan emin olmaktır. Backlog Refinement toplantısı, 'n' sprintte seçilecek öğelere hazırlanmak için 'n-1' sprint sırasında düzenlenir.
Sonuç
Bununla birlikte, okumamız gereken 'Scrum Etkinlikleri' hakkındaki bu eğitimin sonuna geldik. Scrum Etkinlikleri, Scrum Serisinin açık ara en önemli ve en önemli konusudur.
Bu eğiticide, beş Scrum Etkinliğinin tümünü ele aldık, yani Sprint, Sprint Planlama, Günlük Standup, Sprint İncelemesi ve Sprint Retrospektifi . Günlük standup dışındaki her bir olayın, sprint başına düzenli bir döngüsü vardır, yani her sprintte bir kez gerçekleştirilir.
Olaylar, görevlerin bir Scrum ortamında nasıl yerine getirildiğine dair bir fikir verir. Tüm Scrum etkinlikleri iyileştirme, adaptasyon ve denetim için fırsatlardır.
Sırada, mevcut Sprint'in tüm kusurlarının tartışıldığı ve önceliklendirildiği, yani önceliklendirildiği resmi bir toplantı olan 'Kusur Triaging' üzerine öğretici gelecek.
PREV Eğitimi | SONRAKİ Eğitici
Önerilen Kaynaklar
- Scrum Eserleri: Ürün İş Listesi, Sprint İş Listesi ve Ürün Artışları
- JIRA Scrum Board Eğitimi: Sprint'i Yönetmek İçin Jira ile Scrum Kullanımı
- Çevik Scrum Çevrimiçi Testi: Çevik Scrum Bilginizi Test Edin
- Çevik Scrum Süreci Kullanılarak Kısa Sürede Yüksek Değerli Yazılım Özellikleri Nasıl Sağlanır
- Scrum'da Hata Triaging: Bir Scrum Kurulumunda Nasıl Düzenlenir
- Selenium Uzmanları için Yarı Zamanlı Serbest Çalışma Fırsatı
- Scrum Takım Rolleri ve Sorumlulukları: Scrum Master ve Ürün Sahibi
- Çalışan Zaman Takibi İçin En İyi 10 Ücretsiz Zaman Saati Yazılımı