Agile & Lean

Retrospective

by mlap
written by mlap

Sprint Retrospective, Scrum Guide’da sprintin son etkinliği olarak tanımlanır. Bu etkinlik, Scrum takımının Kaizen kültürünü yani sürekli iyileşme yaklaşımını kazandığı en önemli aşamadır.

Retrospective sırasında takım; ilişkiler, iletişim, araçlar, süreçler, uygulamalar ve çalışma ortamını değerlendirir. Amaç, daha iyiye götürecek iyileştirme aksiyonlarını belirlemektir. Sadece gelişim noktalarının değil, birbirini takdir etmeninde önemli bir parça olduğunu unutmamak gerekir.
Scrum Guide, 2 haftalık bir sprint için bu etkinliğin en fazla 1,5 saat sürmesini önermektedir.

Retrospective’in Amacı

  • Hangi pratik uygulanırsa uygulansın, takip edilebilir aksiyonların çıkması ana hedeftir.

  • Aksiyon üretmeyen bir retrospective, amacına ulaşmış sayılmaz.

  • Etkinliğin verimli geçmesi için Scrum Master’ın hazırlık yapması ve uygun fasilitasyon tekniklerini seçmesi kritik önemdedir.

Güvenli Ortam ve Fasilitasyon

  • Retrospective’in fayda sağlaması için güvenli, şeffaf ve açık iletişime dayalı bir ortam gerekir.

  • Scrum Master, etkinliği herkesin katılımını sağlayacak şekilde fasilite etmelidir.

  • Doğru fasilitasyon teknikleri, hem katılımı artırır hem de kaliteli çıktılar sağlar.

Lider Katılımı

  • Eğer liderlerin varlığı güveni ve şeffaflığı zedeleyecekse, katılmamaları tavsiye edilir.

  • Aksi halde özellikle bireysel konular dile getirilemez ve etkinlik amacını kaybeder.

  • Ancak, liderlerin katılmaması durumunda bile, bireysel olmayan çıktılar ve takımın çözemediği konular mutlaka onlarla paylaşılmalı, destek istenmelidir.

Etki Alanına Odaklanmak

  • Takım, sadece etki alanındaki konulara odaklanmalıdır.

  • Etki alanı dışında kalan konuların konuşulması, sadece “dertleşme” seviyesinde kalır ve aksiyon üretilemez.

  • Zaman zaman duygusal bir retrospective yaşanabilir, bu doğaldır. Ancak asıl amacın iyileştirme olduğu unutulmamalıdır.

Retrospective’in Önemi

Woody Zuill’in sözü bu etkinliğin değerini çok güzel özetler:
“If you adopt only one agile practice, let it be retrospectives. Everything else will follow.”

Yani, yalnızca bir çevik pratik benimsenecekse, bu kesinlikle retrospective olmalıdır. Çünkü takip edilebilir aksiyonlarile sürekli iyileşmenin kapısını aralar.

Retrospective, sadece bir değerlendirme değil; takımın kültürünü, iletişimini ve verimliliğini sürekli geliştiren en güçlü araçtır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Review

by mlap
written by mlap

Sprint Review, sprint’in son gününde gerçekleştirilen, sprint boyunca geliştirilen işlerin paydaşlara sunulduğu ve geri bildirimlerin alındığı etkinliktir. Takımın ürettiği değeri sergilediği, adeta “şov sahnesi”dir. Tüm paydaşların ve merak eden herkesin katılımına açıktır. 4 haftalık bir sprint için süresi en fazla 4 saattir.

Katılımın Önemi

Etkinliğin temel amacı geri bildirim almak olduğundan, katılımcı sayısının mümkün olduğunca fazla olması önemlidir.

  • Product Owner, etkinlik öncesinde ana paydaşlarla iletişim kurarak katılımlarını teşvik etmelidir.

Hazırlık Süreci

Review, takımın ve ürünün imajı açısından kritik öneme sahiptir.

  • Etkinlik öncesinde (maksimum 1 saatlik) bir hazırlık yapılmalıdır.

  • Gösterilecek veriler hazırlanmalı, ortamın sorunsuz çalışacağı garanti edilmelidir.

  • Aksi takdirde kaliteli bir ürün bile olumsuz bir izlenim yaratabilir.

Demo Sunumu

Hazırlıklar tamamlandıktan sonra sıra, geliştirilen ürünün/hizmetin demo sunumuna gelir.

  • Sadece “ideal” senaryolar değil, farklı kullanım senaryoları da gösterilmelidir. Bu, yapılan işe duyulan güveni yansıtır.

  • Eğer mobil bir ürün geliştiriliyorsa, katılımcılara cihaz verilerek denemeleri sağlanabilir. Bu, güvenin en yüksek seviyesini gösterir.

Geri Bildirimlerin Alınması

Review’un en önemli çıktısı geri bildirimlerdir.

  • Katılımcılardan yorum gelmiyorsa, Product Owner teşvik etmelidir.

  • Alınan geri bildirimler ürünün gelişimi için fırsat olarak görülmeli, gerekli olanlar Product Backlog’a eklenmelidir.

  • Yorumların atlanmaması için Product Owner not tutmalı; ek olarak bir takım üyesi de not alarak sonrasında birleştirilmesi iyi bir pratiktir.

Takip ve Güven

Bir sonraki Review toplantısında Product Owner, önceki toplantıda alınan geri bildirimlerle ilgili yapılan aksiyonları özetleyebilir.

  • Bu, hem katılımcıları memnun eder hem de takımın/projenin imajını güçlendirir.

  • Paydaşların güvenini artırır.

Sprint Review, yalnızca bir sunum değil; ürünün geleceğini şekillendiren, geri bildirim odaklı bir işbirliği etkinliğidir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Daily Scrum’un Verimli Geçirilmesi

by mlap
written by mlap

Daily Scrum, her gün düzenli yapılan ve en fazla 15 dakika süren bir etkinliktir. Etkin bir fasilitasyon olmadığında kısa sürmesi gereken bu toplantı gereksiz yere uzayabilir.

Daily’nin verimli olabilmesi için dikkat edilebilecek noktalar:

1. Sprint Backlog / Taskboard Kullanımı

  • İşlerin ve akışın görselleştirilmesi Daily’nin en kritik noktasıdır.

  • Jira, Azure, Excel gibi dijital araçlar ya da fiziksel bir taskboard kullanılabilir.

  • Görselleştirme sayesinde herkes aynı noktada hizalanır.

2. Ortak Ekran Paylaşımı

  • Online ortamda Daily yapılırken Sprint Backlog mutlaka bir ekip üyesi tarafından ekrana yansıtılmalıdır.

  • Böylece herkesin backlog odaklı kalması sağlanır.

  • Serbest formatta konuşmak, süreyi uzattığından kaçınılmalıdır.

3. Sıra ile Bilgi Paylaşımı

  • Herkesin sırayla konuşması etkinliği daha düzenli hale getirir.

  • İlerleme alfabetik sırayla ya da birbirine söz verilerek yapılabilir.

  • Eğer gecikmeler yaşanıyorsa, alfabetik sıra en garantili yöntemdir.

4. Backlog’un Düzenli Gözden Geçirilmesi

  • Daily’lerde genelde üzerinde çalışılan PBI’lar konuşulur, bu yüzden bazı işlerin gözden kaçma riski vardır.

  • Haftada 1–2 defa tüm backlog veya öncelikli PBI’lar üzerinden geçmek, açıkta iş kalmasını engeller.

5. Sprint Goal’un Görünür Olması

  • Sprint Goal, takımın ortak hedefini temsil eder.

  • Her Daily’de görünür halde olmalı ve gerektiğinde gözden geçirilmelidir.

  • Uygulama içinde, taskboard’da veya Daily sonrası hatırlatma ile görünürlük artırılabilir.

6. Burn (Down/Up) Chart Değerlendirmesi

  • Daily sonrası, takımın ilerleyişini görmek için burndown veya burnup chart’lar kontrol edilmelidir.

  • Bu grafikler sprint planına göre ilerleyişi gösterir, gerekli kararların alınmasına yardımcı olur.

  • Dijital araçlar kullanılıyorsa bu grafikler otomatik üretildiğinden operasyon yükü azalır.

7. Detaylı Konuları Daily Sonrasına Bırakmak

  • Günlük toplantıda detaylı tartışmalar yapılmamalıdır.

  • Konu derinlemesine ele alınacaksa, Daily sonrası “park edilen konular” listesi üzerinden sadece ilgili kişilerin katılımıyla devam edilmelidir.

✅ Tüm bu adımlar, Daily Scrum’un kısa, odaklı ve verimli geçmesini sağlar.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Daily Scrum Kontrol Listesi

by mlap
written by mlap

Scrum çerçevesiyle çalışmaya başlayan her takımın edinmesi gereken ilk alışkanlıklardan biri, ritüellerin düzenli uygulanmasıdır. Her gün yapılan Daily Scrum, en fazla 15 dakikalık bir timebox’a sahiptir. Bu sürenin verimli kullanılmaması, toplantıların uzamasına ve sıkça duyulan “Scrum çok fazla toplantıya sebep oluyor” şikâyetine yol açabilir.

Verimli Bir Daily Scrum İçin Kontrol Noktaları

  • Etkinlik zamanında başladı mı?

  • Tüm developer’lar zamanında katıldı mı?

  • Her developer, dünkü çalışmalarını ve bugün yapacaklarını paylaştı mı?

  • Engeller varsa açıkça dile getirildi mi?

  • Etkinlik sırasında, sürenin uzamasına sebep olacak detay konulara girildi mi?

  • Söylenemeyen engeller varsa Scrum Master proaktif davranarak görünür kıldı mı?

  • Etkinlik sonunda burndown chart kontrol edilip yorumlandı mı?

  • Sprint hedefi doğrultusunda öncelikli işler dikkate alındı mı?

  • Taahhüt edilen işlerin tamamlanabilmesi için gerekli kararlar alınıp aksiyonlar belirlendi mi?

  • Developer olmayan katılımcılar, soru ve geri bildirimlerini Daily sonrası dile getirdi mi?

Olası Uygulama Bozuklukları

Scrum Master’ların dikkat etmesi gereken yaygın bozulmalar:

  • Detay konuların Daily sırasında tartışılması: Bu durumda 15 dakika yetmez. Konular Daily sonrasına bırakılmalıdır. Scrum Master araya girerek süreyi korumalıdır.

  • Developer olmayan katılımcıların araya girmesi: Daily sırasında soru sormak veya geri bildirim vermek yerine, bu konular Daily sonrasına yönlendirilmelidir.

Scrum Master’ın Rolü

Tüm bu maddelerin sağlıklı şekilde uygulanması Scrum Master’ın sorumluluğundadır. Alışkanlık kazanılana kadar Scrum Master, bu kontrol listesini madde bazlı takip etmelidir.

📌 Kontrol listesinin çıktısını alabileceğiniz bir doküman da hazırlanmıştır. Ulaşmak için [tıklayınız].

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Daily Scrum

by mlap
written by mlap

Takım, sprint hedefine doğru ilerlerken her gün bir araya gelerek Sprint Backlog’un ilerleyişini gözden geçirir, gerekli düzenlemeleri yapar ve adaptasyonu sağlar.

Süre ve Düzen

  • Her gün yapılır.

  • Maksimum 15 dakika sürmelidir (Scrum Guide önerisi).

  • Karmaşıklığı azaltmak ve düzen sağlamak için her zaman aynı yerde ve aynı saatte yapılması faydalıdır.

  • Scrum Master, etkinliğin verimli geçmesini ve 15 dakika içinde tamamlanmasını kolaylaştırır.

Katılımcılar

  • Developer rolündeki herkesin katılımı zorunludur.

  • Product Owner ve Scrum Master, aynı zamanda developer rolüne sahipse katılmalıdır.

  • Etkinlik herkese açık olsa da developer olmayanlar bitene kadar sessiz kalmalıdır.

  • Sorular, ek bilgiler veya detaylı tartışmalar Daily Scrum sonrasına bırakılmalıdır.

İçerik

Her takım üyesi şu sorulara yanıt verir:

  1. Son 24 saatte ne yaptım?

  2. Önümüzdeki 24 saatte ne yapacağım?

  3. Önümde bir engel var mı?

Amaç, takım üyeleri arasında hizalanma sağlamaktır.

Katkıları

  • Tüm takımın aynı noktada olmasını sağlar.

  • İletişimi güçlendirir, karar almayı kolaylaştırır.

  • Etkinlik sonrası grafikler ve metrikler incelenerek sprint ilerleyişi hakkında kararlar alınabilir.

Board Kullanımı

  • Board, yalnızca Daily Scrum sırasında değil, gün içinde de güncellenebilir.

  • Ancak yapılan değişiklikler ertesi günkü Daily Scrum’da mutlaka takımla paylaşılmalıdır.

Daily Scrum, takımın hizalanmasını, engellerin görünür olmasını ve sprint hedefi doğrultusunda ilerlemesini sağlayan en önemli etkinliklerden biridir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Planlamada Kapasite Hesaplama

by mlap
written by mlap

Scrum’ın temelinde deneysellik vardır. Geçmiş deneyimlerden öğrenilir, bu deneyimlere göre daha iyiye götürecek aksiyonlar belirlenir ve gelişimin sürekliliği sağlanır.

Geçmiş Deneyimlerden Yararlanmak

  • Sprint planlamanın başında, takımın taahhüt edeceği iş miktarı belirlenirken geçmiş sprintler referans alınır.

  • Önceki sprintlerde tamamlanan işlerin ortalamasına göre, yeni sprintte alınacak büyüklük belirlenir.

  • Bu yaklaşım, sprint içindeki zamanın daha etkin kullanılmasını sağlar.

Kapasite Belirleme

  • Takım üyelerinin izin, eğitim gibi çalışamayacağı süreler sprint başında netleştirilir.

  • Bu süreler çıkarılarak sprint boyunca kullanılabilir toplam efor hesaplanır.

Tahminleme Yöntemleri

  • İş büyüklüğü için genellikle Fibonacci sayı dizisine dayalı, birimden bağımsız tahminleme yapılır.

  • Efor için ise saat cinsinden süre belirlenebilir.

  • Sprint başında bu iki tahminin yapılması, daha sağlıklı planlama ve verimli bir sprint geçirilmesini sağlar.

Pratik Araçlar

  • Son 5 sprintte tamamlanan PBI’lar incelenerek, takımın tamamlayabileceği ortalama büyüklük hesaplanabilir.

  • Ayrıca sprint bazlı izin ve eğitim süreleri girilerek, seçilen PBI’ların task eforlarını hesaplamayı kolaylaştıran şablonlar kullanılabilir.

Sprint planlama, geçmiş deneyimlere dayalı verilerle yapıldığında hem daha gerçekçi hem de daha verimli olur. Kapasitenin net hesaplanması, takımın taahhüt ettiği işleri başarıyla tamamlamasını destekler.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Planlama Kontrol Listesi

by mlap
written by mlap

Scrum çerçevesiyle çalışmaya başlayan her takımın ilk edinmesi gereken alışkanlıklardan biri, ritüellerin düzenli uygulanmasıdır. Her sprintin ilk ritüeli olan Sprint Planlama etkinliğinin verimli geçmesi için aşağıdaki noktalara dikkat edilebilir.

Etkinlik Öncesi Kontroller

  • Product Backlog’daki item’lar önceliklendirilmiş mi?

  • Item’lar refine edilmiş mi?

  • Item tanımları yeterince açık mı?

  • Kabul kriterleri net olarak belirtilmiş mi?

  • Bir önceki Review’den gelen geri bildirimler backlog’a yansıtıldı mı?

  • Bir önceki Retrospective’den backlog’a eklenmesi gereken maddeler eklendi mi?

  • Product Backlog, takımın yapacağı tüm aktiviteleri kapsıyor mu?

Etkinlik Sırasında Yapılacaklar

  • Etkinlik zamanında başladı mı?

  • Takım, geçmiş metriklerine göre kapasitesini belirledi mi?

  • Takım üyelerinin sprint boyunca çalışabileceği süre netleştirildi mi?

  • Önceki sprintten kalan işler için Product Owner yeni öncelikleri belirledi mi?

  • Product Owner, PBI’lardaki “NEDEN değerli?” sorusunu net olarak açıkladı mı?

  • Product Owner, PBI’lardaki “NE yapılacak?” sorusuna net cevap verdi mi?

  • Product Owner, tahminleme için yeterli bilgiyi sağladı mı?

  • Önceki sprintten kalan PBI’lar, kalan işe göre yeniden boyutlandırıldı mı?

  • Takım, büyüklükleri adam/gün yerine Story Point cinsinden tahminledi mi?

  • Takım, sprint boyunca yapacağı işleri netleştirdi mi?

  • Acil/plansız işler için buffer ayrıldı mı?

  • Task’lar 8–16 saatlik parçalara bölündü mü?

  • Herkesin hemfikir olduğu Sprint Goal belirlendi mi?

  • Burndown Chart’ın ilk hali çizildi mi?

Etkinlik Sonunda Genel Değerlendirme

  • Planlama, timebox’a uygun şekilde tamamlandı mı?

  • Tüm takım üyeleri aktif katılım sağladı mı?

  • Scrum Master, etkin bir fasilitasyon yapıp gerekli durumlarda müdahale etti mi?

  • İşlerin NASIL yapılacağı değerlendirilirken görselleştirme araçları kullanıldı mı?

    • Ofiste: flipchart, beyaz tahta

    • Uzaktan: Miro, Mural vb.

Olası Bozulmalar

Scrum Master’ların özellikle dikkat etmesi gereken noktalar:

  • Product Owner, PBI’ların büyüklüklerine müdahale etti mi?

  • Product Owner, takıma daha fazla iş alması için baskı yaptı mı?

  • Product Owner, takım üyelerine iş/görev ataması yaptı mı?

Tüm bu maddelerin sağlıklı şekilde uygulanması, Scrum Master’ın sorumluluğundadır. Alışkanlıklar oturana kadar Scrum Master, bu kontrol listesini madde madde takip etmelidir.

📌 Kontrol listesinin doküman formatına ulaşmak için [buraya tıklayınız].

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Planlama Etkinliği

by mlap
written by mlap

Her sprint, Sprint Planlama etkinliği ile başlar. Bu etkinlik üç ana soruya yanıt arar:

  • NEDEN değerli?

  • NE yapılacak?

  • NASIL yapılacak?

Takım bu etkinlikte, sprint boyunca yapacakları işlerin neden değerli olduğunu öğrenir, hangi işleri yapacağına karar verir ve temel düzeyde nasıl yapacaklarını belirler.

Etkinlik Öncesi Hazırlık

  • Product Owner, backlog’u önceliklendirilmiş ve olgunlaştırılmış şekilde getirmelidir.

  • Gerektiğinde, ek görüşler sunmak için başka kişiler davet edilebilir. Ancak bu kişilerin, takımın kararlarına ve tahminlemelerine müdahale etmemesi gerekir.

Sprint Hedefi

Etkinlik sırasında tüm takımın ortak belirlediği Sprint Hedefi netleştirilmelidir. Bu hedef, sprint boyunca takımın odak noktasıdır.

Üç Adımda Sprint Planlama

  1. NEDEN değerli?

    • Product Owner, en öncelikli ve en değerli işleri takıma sunar.

    • İşlerin neden önemli olduğunu, ürün kapsamındaki etkilerini ve sağlayacağı değeri açıklar.

    • Bu bilgi, takımı motive eder. PO açıklamadığında, Developer’ların mutlaka sorgulaması tavsiye edilir.

  2. NE yapılacak?

    • Product Owner, önceliklendirdiği işlerin kapsamını ve kabul kriterlerini net şekilde aktarır.

    • Developer’lar tahminleme yapar, önceki sprintlerdeki hızlarını dikkate alarak yapabilecekleri işleri belirler ve sprint boyunca taahhüt eder.

  3. NASIL yapılacak?

    • Takım, işlerin temel düzeyde nasıl yapılacağını kararlaştırır ve task’ları yazar.

    • Task’lar, BİTTİ tanımına uygun olacak şekilde, 1–2 günde tamamlanabilecek küçük parçalar halinde planlanır.

    • Task’lar uzmanlık alanına bakılmaksızın tüm takım tarafından yazılmalıdır. Bu, işbirliğini ve kaliteyi artırır.

    • Belirsiz veya riskli konular, tüm takım tarafından değerlendirilir.

    • Görsellik iletişimi kolaylaştırır: Fiziksel ortamda flipchart veya tahta; dijital ortamda Miro, Mural gibi araçlar kullanılabilir.

Timebox

  • Scrum Guide’a göre, iki haftalık sprint için planlama toplantısı maksimum 4 saat sürmelidir.

  • Sürenin verimli kullanılabilmesi için, öncesinde yeterli refinement yapılmış olmalıdır.

Çıktılar

Sprint Planlama etkinliğinin sonunda:

  • Güncellenmiş Product Backlog,

  • Sprint Backlog,

  • Taskboard,

  • Net bir şekilde tanımlanmış Sprint Goal ortaya çıkar.

Sprint Planlama, sprintin çerçevesini belirler. Doğru hazırlanmış bir backlog, açık kabul kriterleri ve tüm takımın katılımıyla gerçekleşen etkinlik, sprint boyunca takımın verimliliğini ve odaklanmasını garanti altına alır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Süresi Nasıl Belirlenmeli?

by mlap
written by mlap

Agile dönüşüm yolculuğunda, Scrum çerçevesini uygulamayı tercih eden takımların ilk kararlarından biri sprint süresini belirlemek olur. Scrum Guide’a göre sprint süresi 1 ay veya daha kısa olabilir ve bu süre, takımın değişikliğe adaptasyon hızına göre belirlenir.

Sprint Süresini Belirlerken Dikkat Edilecek Noktalar

  • Amacı Hatırlamak:
    Takımlar sprint süresini belirlerken, dönüşüm yolculuğunu başlatan amaçları unutmamalıdır.

    • İşleri küçük parçalara bölmek,

    • Ürüne sık aralıklarla yeni özellikler kazandırmak,

    • Takımın verimliliğini ve iş birliğini artırmak, bu amaçların başında gelir.

  • İşleri Küçük Parçalara Bölmek:
    Takımların en çok zorlandığı noktalardan biri budur. Geleneksel yaklaşımda işler genellikle uzmanlık alanlarına göre sırayla yapılırken, küçük parçalara bölme alışkanlığı gelişmemiştir. Ancak bu zorluk aslında büyük bir kazanımdır. Çünkü:

    • Daha fazla bilgi paylaşımı yapılmasını,

    • Daha güçlü iş birliğini,

    • Planlama kaslarının gelişmesini sağlar.

  • Fonksiyonların Paralel Çalışması:
    Dönüşümün başında zorlayıcı bir diğer nokta, analiz, yazılım ve testin sırayla değil, paralel ilerlemesidir. 1 aylık sprint süresi belirlemek daha kolay görünebilir; ancak kısa sprintlerle başlamak takımı zorlayarak:

    • Verimliliği,

    • Çapraz fonksiyonlu çalışmayı,

    • Birlikte çözüm üretmeyi,

    • Yetkinliklerin gelişmesini hızlandırır.

Anket Sonuçları

  • En çok tercih edilen sprint süresi: 2 hafta

  • İkinci sırada: 3 hafta

Scrum Guide, sprint süresinin sprintten sprint’e değişmemesini önerir. Çünkü sabit süreler:

  • Karmaşıklığı azaltır,

  • Takımın ve ürünün gelişimini daha net gözlemlemeyi sağlar.

Önerim

Uygun ürün ve takım yapısı varsa, 2 haftalık sprintlerle başlamak, Agile prensiplerin daha hızlı içselleştirilmesini sağlar.

  • Kısa sprintler, takımı daha çok zorlar.

  • İşleri küçük parçalara bölme,

  • Paralel çalışma alışkanlıkları daha hızlı gelişir.

Doğru alışkanlıklar kazandıkça, sprint süresini yeniden şekillendirmek mümkün olabilir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Nedir?

by mlap
written by mlap

Sözlük anlamı “koşu” olan sprint, Scrum’da takımın tüm etkinliklerini gerçekleştirdiği, üretimin yapıldığı, adeta takımın kalbinin attığı yerdir. Scrum Guide’da da sprint, bir etkinlik olarak tanımlanır.

Sprint’in Süresi

  • Sprint süresi değişmemelidir. Tutarlılık için bir sprintin süresi diğer sprintlere göre farklılık göstermemelidir.

  • Süre en fazla 1 ay olabilir, daha kısa (örneğin 1-2 hafta) süreler de tercih edilebilir.

  • Sprint süresi, takımın ürün veya hizmetteki değişikliklere adaptasyon süresini de belirler.

Sprintte Dikkat Edilecek Noktalar

  • Sprint Hedefi:
    Her sprintte bir hedef belirlenir ve takım bu hedefe ulaşmayı amaçlar. Hedefi tehlikeye atacak değişikliklerden kaçınılmalıdır. Hedef geçerliliğini yitirirse sprint, yalnızca Product Owner tarafından iptal edilebilir.

  • Kalite Taahhüdü:
    Takım, sprint boyunca kaliteli iş çıkarmayı taahhüt eder. Kaliteyi düşürecek aktivitelerden uzak durmalıdır.

  • Etkinlikler:
    Sprint içinde şu etkinlikler mutlaka yapılır:

    • Sprint Planning

    • Daily Scrum

    • Sprint Review

    • Sprint Retrospective
      Ayrıca, zorunlu olmamakla birlikte oldukça faydalı olan Refinement etkinlikleri de sprint boyunca gerçekleştirilebilir.

  • İlerleyişin Takibi:
    Takım, ilerleyişi Burndown Chart, Burnup Chart gibi araçlarla takip eder ve gerektiğinde uygun kararlar alır.

Sprint Döngüsü

Bir sprint bittiğinde diğeri hemen başlar. Sprintler arasında boşluk veya ara etkinlik bulunmaz.

Sprint, Scrum takımının değer ürettiği ve hedefe odaklandığı en temel etkinliktir. Doğru yönetilen sprintler, hem ürünün gelişimini hem de takımın olgunluğunu sürekli ileri taşır.

0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts