Birazdan anlatacaklarım gerçek bir hikayeden alınmıştır demeyi çok isterdim ama daha gerçek bir iş çıktısı almak isterseniz bu yöntem tam size göre 🙂

User story mapping tabloları, daha çok bir müşterinin bir ürünle başından sonuna kadar yaptığı yolculuğun görselleştirilmesidir. Genellikle bu yolculuğun bir parçası olarak tamamlanacak adımları belirler.

User story mapping, tüm yöntemler içinde uygulanabilir. Özellikle karmaşık bir ürün üzerinde çalışılıyorsa tüm çevik ekipler için yararlı olacaktır.

Neden Story Mapping?

En basit hali ile backlogların uzun olduğu listede önce “hangisine başlarsak müşteriyi kazanırız” önceliğini belirlemede fayda sağlayacaktır. Aslında birikmiş ürün listelerinde çalışmalarımızı daha bütünsel, müşteri odaklı ve genel bir bakış açısı oluşturmasına katkı sağlar.

User Story Mapping Oluşturulurken Dikkat Edilmesi Gerekenler?

• Çalışma sonucu çıkan tablo her zaman müşteri gözü ile oluşturulmalı.
• Teknik olarak detay olan kalemler, basit ve tüm paydaşların sahip olduğu ortak dilde yazılmalı
• Planlanan ürün ile ilgili tüm akış dikkate alınmalıdır. Gri noktalar tablo üzerinde belirtilerek daha sonra detaylı bir analiz yapılmalı
• Story Mapping hiç bir zaman tek seferlik yapılmaz. Ürün geliştirme süreçleri devam ettikçe bu tablo yaşayan bir sistem gibi güncellenebilir.
• Proje ile ilgili tüm paydaşlarında bu çalışmaya dahil edilmesi beklenir.

User Story Mapping Oluşturma Adımları:

• Vizyon Tanımlama: Geliştirmesi yapılacak ürün/ürünlerin neye hizmet edeceği, hangi problemi ortadan kaldıracağı ile ilgili ortaya koyulan hedeftir.
• Ürün İskeletini Oluşturma: Geliştirilecek ürünler ile ilgili konu uzmanları ile bir araya gelinir ve müşterinin ürün içerisindeki yolculuğu referans alınarak basit bir dil ile akış çıkartılır. Bu aşamada derine inmeden yüzeysel ve genel hedeflere odaklanılır.

• Aktivitelerin Tasklara Bölünmesi: İşlem basamakları oluşturulduktan sonra bir alt adım olan daha detay kısımlara geçilir. Her bir task, altında bulunan aktivitenin gerçekleşmesi için gerekli olan iş parçasını temsil etmektedir.

• Story Mapping tablolarında olası boşluklar olabilir mi bununla alakalı birde dış göz olarak da arama yapılması gerekmektedir.
• Story Mapping ile Release yönetimi ile paydaşlar arasında mutabık kalınan ölçüt ile sıraladığınız iş parçalarınızı uygulama versiyonlarının kapsamın sınır bilgisini aktarmak için kullanılabilir.

User story mapping aslında geliştirilecek ürünün tüm paydaşlar tarafından zihinlerinde netleşmesini sağlayacak güzel bir yöntem ve dinamik bir tablo. Bunu hayatınızın her alanında kullanabilirsiniz. Daha fazla bilgi almak isterseniz aşağıdaki linkedin hesabıma yada mail adresime yazabilirsiniz.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Bir MVP Kolay Oluşturulmuyor yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Hayat bir sahne ve bizler de oyuncularız. Shakespeare’in bu ünlü sözünü duymayan yoktur. Peki ya projelerimiz? Onlar da birer sahne değil midir? Her bir ekip üyesi kendi rolünü oynarken, tüm parçalar birleşip büyük bir hikâye anlatır. İşte bu hikâyenin uyumlu ve akıcı olmasını sağlamak için RACI matrisi, sahne arkasındaki yönetmenimizdir.

RACI Matrisi Nedir?

RACI, bir projenin veya sürecin rollerini ve sorumluluklarını netleştiren bir modeldir. Açılımı şöyledir:

• R — Responsible (Sorumlu): Görevi fiilen yerine getiren kişi veya kişiler. O faaliyeti gerçekleştiren kişi, işin ana sorumlusu (A) Accountable olmayabilir; ancak bazı durumlarda işin niteliğine ve önem derecesine bağlı olarak Responsible (R) ve Accountable (A) rolü aynı kişiye atanabilir.
• A — Accountable (Hesap Verebilir): Belirli bir görev için nihai yetki ve sorumluluğu olan kişi ya da rolüdür. Herhangi bir görev için, sadece bir rol / kişi sorumludur. Bu rol, diğer kişi ya da kişilere delege olamaz.
• C — Consulted (Danışılan): Bir görevin yerine getirilebilmesi için bilgi alınması gereken ya da danışılması gereken kişi/kişiler olabilir. Bir görev için birden fazla © Consulted rolü atanması o işin tamamlanma sürecini n uzaması riskini doğurur.
• I — Informed (Bilgilendirilen): Sağlıklı bilgi akışını sağlamak için görev tamamlandıktan sonra bilgi aktarılması gereken kişiler tanımlanır. Bu rolün doğru belirlenmemesi yanlış iletişim ve gecikmelere yol açabilir.

Sanatın Dilinde RACI

Responsible (Sorumlu) — Başrol Oyuncusu

Sahnenin merkezindeki ışık, başrol oyuncusunun üzerindedir. Hikâyeyi taşıyan, duyguyu izleyiciye aktaran odur. Projede de sorumlu kişi, görevi yerine getiren, emeğini katan ve sonucu şekillendirendir.

Accountable (Hesap Verebilir) — Yönetmen

Yönetmen, oyunun veya filmin genel vizyonunu belirler. Başrol oyuncusunun performansını yönlendirir, sahnelerin uyumunu sağlar. Projede hesap verebilir kişi, son kararları alan, sorumluluğu üstlenen ve sonucun kalitesinden sorumlu olandır.

Consulted (Danışılan) — Senarist ve Danışmanlar

Bir hikâyenin derinliği, senaristin kaleminden ve danışmanların katkısından gelir. Karakterlerin geçmişi, diyalogların inceliği burada şekillenir. Projede danışılan kişiler, uzmanlıklarıyla göreve değer katan, bilgi ve deneyimlerini paylaşanlardır.

Informed (Bilgilendirilen) — İzleyiciler ve Yapımcılar

Perde açıldığında izleyiciler sahnedeki büyüyü deneyimler. Yapımcılar ise sürecin ilerleyişinden haberdar olup gerekli desteği sağlarlar. Projede bilgilendirilen kişiler, sürecin gidişatı hakkında bilgi sahibi olması gereken paydaşlardır.

Proje Yönetiminde Sanatsal Uyum

Bir senfoni orkestrasını düşünün. Her enstrüman kendi notalarını çalar, ancak şefin yönlendirmesiyle muhteşem bir uyum ortaya çıkar. Eğer bir enstrüman yanlış zamanda veya yanlış notayı çalarsa, tüm eser etkilenir. RACI matrisi, proje ekiplerinin bu orkestral uyumu yakalamasını sağlar.

Neden RACI Matrisi?

• Rol Karmaşasını Önler: Kim ne yapacak? Sorusunun cevabını netleştirir.
• İletişimi Güçlendirir: Doğru kişilerin doğru zamanda dahil olmasını sağlar.
• Verimliliği Artırır: Gereksiz tekrarları ve gecikmeleri önler.
• Sorumluluk Bilinci Oluşturur: Herkes görevlerinin farkında olur ve buna göre hareket eder.

RACI ile Projelerinize Sanat Katın

Bir ressamın tuvaline dokunuşları gibi, ekip üyelerinin projeye katkıları da bir bütün oluşturur. RACI matrisi, bu dokunuşların doğru yerde ve doğru zamanda olmasını sağlayarak, ortaya çıkan eserin kusursuz olmasına yardımcı olur.

Uygulamada RACI

1. Görevleri Belirleyin: Projenin tüm görevlerini ve süreçlerini listeleyin.
2. Rolleri Tanımlayın: Ekipteki tüm pozisyon ve kişileri belirleyin.
3. Matrisi Oluşturun: Görevlerin ve rollerin karşısında R, A, C veya I atamalarını yapın.
4. Paylaşın ve Onaylayın: Matrisi ekip ile paylaşarak herkesin aynı noktada olduğundan emin olun.
5. Güncel Tutun: Proje ilerledikçe matrisi güncelleyin ve değişiklikleri aktarabileceğiniz bir iletişim kurun.

Son Söz: Projelerinizde Sanatın Gücünü Kullanın

Her proje, anlatılmayı bekleyen bir hikâye, çizilmeyi bekleyen bir resim veya bestelenmeyi bekleyen bir melodidir. RACI matrisi ise bu sanat eserinin ortaya çıkmasında ekip üyelerinin uyumunu ve katkılarını organize eden gizli bir rehberdir.

Projelerinize sanatın estetiğini ve uyumunu katmak, hem ekip motivasyonunu artıracak hem de ortaya çıkan sonuçların kalitesini yükseltecektir. Unutmayın, büyük sanat eserleri, uyum içinde çalışan ekiplerin ve net bir vizyonun ürünüdür.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Bir Orkestra Gibi Proje Yönetimi: RACI Matrisine Sanatsal Bir Bakış yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Scrum Master olmak, birçok kişi için ekip liderliğinin en heyecan verici rollerinden biridir. Ancak işin içine biraz da zorluk girdiğinde, bu rol daha da karmaşık hale gelir. Farklı çalışma disiplinleri olan zorlayıcı bir ekiple karşı karşıya kalan bir Scrum Master olarak, sadece teknik çözüm sunmak yetmez; aynı zamanda ekip dinamiklerini anlamak ve duygusal zekâ ile yaklaşmak gerekir. Peki, bu nasıl yapılır? İşte zorlu ekiplerle başa çıkarken hem duygusal hem de teknik açıdan nasıl hareket edileceğine dair bazı ipuçları.

1. Ekip İçi İletişim Sorunları: “Herkes Birbirini Anlıyor mu?”
   Eğer ekipte iletişim sorunu varsa, işler doğal olarak sarpa sarar. Scrum Master olarak, ekibin birbirini gerçekten duyup duymadığını sorgulamak zorundasınız.
   • Duygusal Yaklaşım:
     İnsanların kendilerini ifade edemedikleri bir ortamda sorunlar büyür. Bu yüzden önce dinlemeye odaklanın. Empati, burada sizin en güçlü silahınız. Ekibin her bir üyesine kendini ifade etmesi için fırsat verin. Açık, samimi ve yargılayıcı olmayan bir ortam yaratın.
   • Teknik Yaklaşım:
     Bu noktada teknik olarak iletişim araçlarını ve süreçleri optimize etmelisiniz. Daily Scrum toplantılarında herkesin durumu net paylaşmasına dikkat edin ve geri bildirimleri yakalayın. Belki de Slack ya da Jira gibi araçlar üzerinden daha yapısal bir iletişim sağlayabilirsiniz.
2. Net Olmayan Roller ve Sorumluluklar: “Kim Ne Yapıyor?”
   Belirsizlik stres yaratır. Eğer ekip üyeleri rolleri ve sorumlulukları konusunda kafası karışıksa, performans düşer.
   • Duygusal Yaklaşım:
     Öncelikle herkesin beklentisini dinleyin. Herkesin kendi rolüne dair endişeleri olabilir, bu yüzden sabırlı olun. Samimi ve destekleyici bir şekilde “Senin bu rolde nasıl bir beklentin var?” sorusunu yöneltebilirsiniz. Böylece ekipte bir rahatlama sağlanır.
   • Teknik Yaklaşım:
     Rolleri ve sorumlulukları netleştirmek için RACI matrisleri gibi araçları kullanabilirsiniz. Böylece her bir ekip üyesinin ne yapması gerektiği netleşir. Sprint planlamalarında görevlerin doğru dağıtıldığından emin olun.
3. Sprint Hedeflerine Ulaşamama: “Başarısızlık mı? Yoksa Öğrenme Fırsatı mı?”
   Hedeflere ulaşamamak, ekip üzerinde ciddi bir baskı yaratır. Ancak bu durumu bir öğrenme fırsatına dönüştürebilirsiniz.
   • Duygusal Yaklaşım:
     Başarısızlık moral bozucu olabilir. Bu noktada ekibe yüklenmek yerine, başarısızlığı bir öğrenme fırsatı olarak sunun. “Bu sefer olmadı, ama bir dahaki sefere neleri daha iyi yapabiliriz?” şeklinde bir yaklaşım, ekibin güvenini kazanmanızı sağlar.
   • Teknik Yaklaşım:
     Sprint hedeflerinin neden gerçekleşmediğini anlamak için velocity (hız) verilerini analiz edin ve sprint planlamalarını daha gerçekçi hale getirin. Gerektiğinde backlog refinement toplantılarını kullanarak görevleri daha doğru tanımlayın.
4. Çatışmalar ve Gerilimler: “Herkes Aynı Tarafta mı?”
   Çatışmalar ve gerilimler, bir ekibi en çok yıpratan konulardandır. Ancak doğru yönetilirse, çatışmalar bile ilerleme sağlayabilir.
   • Duygusal Yaklaşım:
     Çatışmalar genellikle kişisel anlaşmazlıklardan doğar. Burada duygusal zekanızı kullanarak tarafsız bir tutum sergileyin. Empati kurun, her iki tarafı da dinleyin ve anlaşmazlıkları kişiselleştirmeden çözmeye çalışın.
   • Teknik Yaklaşım:
     Çatışmaların kaynaklarını retrospektiflerde açığa çıkarmak önemli. Takım etkinlikleri düzenleyerek ekip içi dinamikleri iyileştirebilir ve gerilimi azaltabilirsiniz.
5. Düşük Motivasyon: “Ekibi Nasıl Canlandırırsınız?”
   Motivasyon eksikliği genellikle ekip performansında belirgin düşüşe neden olur. Ancak doğru stratejilerle bu durumu tersine çevirebilirsiniz.
   • Duygusal Yaklaşım:
     Düşük motivasyon, kişisel ya da iş yükü kaynaklı olabilir. Ekibinizle birebir görüşmeler yaparak onların endişelerini anlamaya çalışın. Küçük başarıları kutlayarak ekip ruhunu yükseltin ve destekleyici bir liderlik gösterin.
   • Teknik Yaklaşım:
     Teknik olarak, motivasyonu artırmak için oyunlaştırma gibi yöntemler kullanabilirsiniz. Ayrıca, sprint sonunda başarıların vurgulandığı ve takdir edildiği bir ortam yaratmak önemli.
6. Geri Bildirim Eksikliği: “Nerede Hata Yapıyoruz?”
   Geri bildirim almak ve vermek, ekiplerin sürekli iyileşmesi için hayati önem taşır.
   • Duygusal Yaklaşım:
     Geri bildirim konusunda çekingen olan ekip üyelerini rahatlatın. Onlara geri bildirimin ekip gelişimi için ne kadar önemli olduğunu hatırlatın ve eleştirilerde yapıcı olun.
   • Teknik Yaklaşım:
     Geri bildirim süreçlerini güçlendirmek için “Start, Stop, Continue” gibi çerçeveleri kullanarak yapıcı geri bildirimleri teşvik edin. Veriye dayalı analizler ile (örneğin burndown charts) süreçlerin nasıl iyileştirilebileceğini gösterin.
7. Micromanagement: “Takımı Özgür Bırakın!”
   Micromanagement, ekibin bağımsız çalışma kabiliyetini zayıflatır ve moral bozar.
   • Duygusal Yaklaşım:
     Üst yönetim veya Product Owner’ın ekibi fazla kontrol ettiğini düşünüyorsanız, iki taraf arasında köprü kurun. Onlara güven inşa etmenin ve ekibi serbest bırakmanın önemini açıklayın.
   • Ekibin kendi kendini yönetmesi için Scrum’ın kendi çerçevelerine sadık kalın. Sprint planlamalarında ekip üyelerine daha fazla karar alma yetkisi vererek micromanagement’ı önleyin.
8. Ürün Sahibi ile Uyum Sorunları: “Herkes Aynı Yöne mi Bakıyor?”
   Product Owner ile ekip arasındaki uyumsuzluk büyük sorunlara yol açabilir.
   • Duygusal Yaklaşım:
     Uyumsuzluk durumunda iki tarafı da dinleyin. Samimi ve şeffaf bir diyalog kurarak iki tarafı ortak bir noktada buluşturun.
   • Teknik Yaklaşım:
     Backlog yönetimini iyileştirmek ve sprint review toplantılarında Product Owner’ın daha aktif rol almasını sağlamak için süreçleri gözden geçirin.
9. Değişime Direnç: “Alışkanlıkları Kırmak Zor mu?”
   Değişim her zaman kolay kabul edilmez. Ama doğru stratejilerle direnci kırabilirsiniz.
   • Duygusal Yaklaşım:
     Değişim yönetiminde sabırlı olun. Ekibin bu sürece duygusal olarak hazır olup olmadığını değerlendirin. Küçük adımlarla değişimi teşvik edin ve büyük dönüşüm baskısından kaçının.
   • Teknik Yaklaşım:
     Agile eğitimleri ve pilot projelerle değişimin faydalarını gösterin. Bu süreçte yavaş ama sağlam adımlar atarak ekibi daha ileri taşıyabilirsiniz.
10. Teknik Borç ve Yüksek İş Yoğunluğu: “İş Yükünü Dengede Tutmak”
    Teknik borç ve aşırı iş yükü, ekip üzerinde baskı oluşturur ve verimliliği düşürür.
    • Duygusal Yaklaşım:
      Ekip teknik borç altında eziliyorsa, onlara destek olun ve bu durumun bir süreç olduğunu hatırlatın. Sadece teknik bir sorun değil, aynı zamanda ekip üzerinde bir stres faktörü olduğunu da unutmayın.
    • Teknik Yaklaşım:
      Teknik borçları yönetmek için Sprint’lerde bu borçları temizlemeye yönelik çalışmalar yapın. İş yükünü doğru bir şekilde planlayarak ekibin yorulmadan çalışmasını sağlayın.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Scrum Master’ın Zorlu Ekiplerle Mücadele Sanatı: Duygusal ve Teknik Dengeyi Bulmak yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Agile, hızlı değişen pazar koşullarına uyum sağlamak için geliştirilen bir proje yönetimi yaklaşımıdır. Bu yaklaşım, yazılım geliştirme başta olmak üzere birçok sektörde benimsenmiştir. Profesyonel Agile liderlik, bu çerçevede ekiplere rehberlik ederek, onların verimliliğini ve adaptasyon yeteneklerini artırmayı hedefler. İşte bu konuda başarılı olabilmek için yapılması gereken ve dikkat edilmesi gereken noktaları gelin birlikte inceleyelim.

Profesyonel Agile Liderlik Nedir?

Profesyonel Agile liderlik, Agile prensiplerine dayalı olarak çalışan ekipleri yönlendiren ve destekleyen bir liderlik tarzıdır. Bu liderlik yaklaşımı, ekip üyelerinin bağımsız çalışmasını teşvik ederken aynı zamanda onları ortak hedeflere yönlendirmeyi amaçlar.

Hazırlık Süreci

1. Agile Prensiplerini ve Değerlerini Öğrenmek:

• Agile Manifesto ve onun 12 prensibini derinlemesine anlamak önemlidir.
• Scrum, Kanban gibi yaygın Agile metodolojilerini öğrenmek ve uygulamalarını kavramak gereklidir.

2. Agile Prensiplerini ve Değerlerini Öğrenmek:

• Ekip üyelerinin güçlü ve zayıf yönlerini, motivasyon kaynaklarını ve çalışma tarzlarını tanımak.
• Ekip içi iletişimi ve iş birliğini artırmak için stratejiler geliştirmek.

3. Liderlik ve İletişim Becerilerini Geliştirmek:

• Etkili iletişim, aktif dinleme ve empati gibi liderlik becerilerini güçlendirmek.
• Çatışma yönetimi ve problem çözme yeteneklerini geliştirmek.

Uygulama Aşamaları

1. Değişimi Yönetmek:

• Agile dönüşüm sürecinde ekibin adaptasyonunu kolaylaştırmak için değişim yönetimi stratejileri uygulamak.
• Ekip üyelerini Agile yöntemlerine alıştırmak için eğitim ve atölye çalışmaları düzenlemek.

2. Sürekli İyileştirme:

• Ekip performansını düzenli olarak değerlendirmek ve iyileştirme alanlarını belirlemek.
• Retrospektif toplantılar düzenleyerek ekip üyelerinin geri bildirimlerini almak ve aksiyon planları oluşturmak.

3. Engelleri Kaldırmak:

• Ekip üyelerinin işlerini engelleyen bariyerleri tespit etmek ve ortadan kaldırmak.
• Kaynakları ve desteği sağlamak için organizasyon içinde gerekli girişimlerde bulunmak.

Dikkat Edilmesi Gereken Noktalar

1. Şeffaflık ve Güven:

• Ekip içinde şeffaf bir iletişim ortamı oluşturmak ve güven inşa etmek.
• Hatalardan ders çıkarma kültürünü teşvik etmek.

2. Müşteri Odaklılık:

• Üretilen değerin sürekli olarak müşteri ihtiyaçlarına uygunluğunu sağlamak.
• Müşteriden düzenli geri bildirim alarak ürün geliştirme sürecini yönlendirmek.

3. Esneklik ve Adaptasyon:

• Değişen koşullara ve gereksinimlere hızlı bir şekilde uyum sağlayabilmek.
• Planları gerektiğinde revize ederek ekibi yeni hedeflere yönlendirmek.

Profesyonel Agile liderlik, modern iş dünyasında ekiplerin verimliliğini ve uyum yeteneğini artırmak için kritik bir rol oynar. Bu liderlik tarzını benimsemek ve başarılı bir şekilde uygulamak, hem ekiplerin hem de organizasyonların sürdürülebilir başarısı için gereklidir. Yukarıda belirtilen adımlar ve dikkat edilmesi gereken noktalar, bu yolda rehberlik edebilir.

Aynı zamanda Scrum.org da ki PAL I sınav içinde internetten aşağıdaki linklerden de hazırlanabilirsiniz.

Toplamda 36 soru ve 60 dakika olan bu sınavın ücreti 200 dolardır.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Profesyonel Agile Liderlik (PAL I): Nasıl Hazırlanmalı ve Nelere Dikkat Edilmeli? yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Yakın zamanda Scrum.org da girmiş olduğum sınavlar sonunda elde ettiğim başarı ile ilgili çok soru aldığım için bu yazıyı yazmak istedim. Herkese faydalı olması adına başlıyorum.

Sınav İçerik Bilgisi

• PSM I ve PSPO I sınavı 80 sorudan oluşmaktadır.
• Sınav süresi 60 dakikadır.
• Sınavı geçmek için soruların en az %85’ini doğru cevaplamanız gerekmektedir, yani en az 68 doğrunuz olmalıdır.
• Sınav onlinedır. İnternetin olduğu her yerde giriş yapabilirsiniz.
• Sınav ücreti 200 $ dır. (Bugünün kur bilgisini aşağıda paylaşıyorum geri dönüp baktığımda inşlh daha fazla üzülmem :))
• scrum.org üzerinden üye olup sınavı satın aldığınızda mailinize bir sınav giriş anahtarı gönderilecek, bu anahtarı sınavı aktif etmek için kullanacaksınız tek kullanımlıktır.

23 Ekim 2024 tarihli dolar kuru.
Güncel dolar kuru için: Dolar Kuru Bugün Ne Kadar? – Canlı Alış Satış TL Fiyatı ve Hesaplama (hurriyet.com.tr)

1. Temel Bilgileri Öğrenin: Scrum teorisini, uygulamalarını ve ilkelerini kapsayan Scrum Kılavuzu’nu okuyarak başlayın. Scrum Alliance veya Scrum.org gibi kuruluşların sağladığı materyalleri inceleyin. Ben şirketin sunmuş olduğu 5 haftalık eğitim ile başlamıştım sonrasında başta bahsettiğim sitelerden faydalandım.
2. Eğitim Kurslarına Katılın: Certified Scrum Product Owner (CSPO) gibi sertifikalı kurslara katılmak, bilginizi pekiştirebilir ve sınavda başarılı olmanıza yardımcı olabilir. Bu kurslar, deneyimli eğitmenler tarafından verilir ve interaktif öğrenme fırsatları sunar. Ayrıca Udemy de sınava girmiş olan kişilerin vermiş olduğu eğitimlerden de faydalanabilirsiniz.
3. Deneme Sınavları Çözün: Çevrimiçi bulabileceğiniz veya kurslar sırasında edinebileceğiniz deneme sınavları, gerçek sınav formatına aşina olmanızı sağlar. Bu sınavlar aynı zamanda zayıf yönlerinizi belirlemenize ve üzerinde daha fazla çalışmanız gereken alanları gösterir.
4. Grup Çalışması Yapın: Diğer adaylarla çalışma grupları oluşturarak bilgi alışverişinde bulunun ve birbirinizin bilgisini test edin. Grup içinde soru çözme ve tartışma, konuları daha iyi kavramanıza yardımcı olabilir. Bu noktada çalıştığınız kurumda sınava girecek arkadaşlar ile birlikte online ücretsiz sitedeki soruları birlikte çözerekde pratik yapabilirsiniz.
5. Günlük Pratik Yapın: Günlük olarak kısa çalışma oturumları düzenleyin. Bu, bilgileri sürekli taze tutmanıza ve sınav gününe kadar bilgi birikiminizi artırmanıza olanak tanır.Eğer fırsatınız varsa çalıştığınız kurumda Product Ownerlık veya Scrum Masterlık yaparakta pratiklik yapabilirsiniz.
6. Scrum Topluluğuna Katılın: Scrum topluluklarına katılarak tecrübelerden yararlanabilir ve farklı bakış açılarına erişebilirsiniz. Bu topluluklar, sorularınızı yanıtlamak ve sınavla ilgili ipuçları vermek için harika kaynaklardır. İş yerinizde Agile ekiplerinizle de bir araya gelerek tecrübelerinizi ve başarılı çözümlerinizi anlatarakda deneyim kazanabilirsiniz.

Ek olarak aşağıda linklerini paylaşacağım sitelerden de destek alabilirsiniz. Sınavda gelen soruları iyi okumak kritik çünkü her zaman best cevabı istiyor ve bu yüzden bazı maddeler birbirlerine çok yakın olduğu için ikileme düşülebiliniyor. Scrum team veya developer konularına dikkat etmekte fayda olabilir. Scrum ritüelleri en sık çıkan sorulardır. PO nun yapacakları takımın yapacakları ve işleyişde kimin önceliği var bunlara dikkat etmek gerekir.

Ek olarak şirketimde Agile Koçumuzunda sınav için hazırlanmam adına önerdiği siteleride paylaşıyorum. Faydalı olması dileği ile;

Scrum.org adresinden certification menusunde sinava giriş için gerekli bilgileri inceleyebilirsiniz.

https://www.scrum.org/professional-scrum-certifications

PSM-I sertifikasına hazırlık için öneriler;

• https://scrumguides.org/ adresindeki scrum guide türkçesini 1 defa okumak, ingilizcesini ara ara en az 3–4 defa okumak.
• https://www.scrum.org/open-assessments/scrum-open sayfasındaki soruları 100% doğru cevaplayana kadar tekrar tekrar çözmek, her açtığınızda farklı sorular gelir, birden çok kez çözmek gerekir.
• https://mlapshin.com/index.php/scrum-quizzes/ adresindeki soruları learning ve real modda 100% doğru yanıta ulaşıncaya kadar çözmek gerekir.
• Scrum: A pocket guide, Gunter Verheyen.
• https://www.scrum.org/resources/suggested-reading-professional-scrum-master

Bunların dışında sınav sonrasında bile olsa aşağıdaki iki kitabı da mutlaka okumanızı öneririm.

• Buzdağımız eriyor (our iceberg is melting), john kotter
• Scrum: twice work in half time, jeff sutherland

PSPO için ek olarak;

• https://www.scrum.org/open-assessments/product-owner-open

PSPO için mutlaka okunması gereken kitap :

• evidence based management guide
• agile product management, roman pichler

https://www.scrum.org/resources/suggested-reading-professional-scrum-product-owner

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>PSM I & PSPO I Sınavlarına Nasıl Hazırlanmalı? yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Evet yanlış duymadınız. Scrum takımlarında bir işin büyüklüğünü belirlemek için belirli saat/gün/hafta terimlerinin karşılığını belirlemek için fibonacci dizisinden faydalanır. Peki ya neden?

Bir agile takımın, daha iyi planlama yapabilmesi için yapılan için ölçeklendirilmesi gerekir. Böylelikle sprinte alınan işin ne kadar sürede teste/uat/prod a çıkacağını belirlemiş ve müşteriye teslim süremizde belirlenmiş olur.7

Bir şirkette Story Point belirlenirken ; yapılacak işin büyüklüğü, kompleksliği, barındırdığı riskler ve belirsizlikleri göz önünde bulundurarak geliştirme aşamasında harcanacak efor hakkında tahmini bir puanlama yapmanız gerekir.

Story Point = ƒ (Volume, Risk & Uncertainty, Complexity)

Volume; Sprinte yapılacak işin büyüklüğünü ifade eder. Örneğin, ekranda bir buton ekleyeceksiniz. Fakat bu butonun etki ettiği 2 tane daha aynı özelliklere sahip ekran var ve aynı butonu bu ekranlara da ekleyeceksiniz. İş aynı ve kompleks değil ama 3 farklı yere ekleme olacağından verilecek puanın 1 ekran için değilde diğer ekranlarıda düşünerek vermeniz gerekmektedir.

Risk & Uncertainty; Planlamaya gelen oylanacak madde net ancak bu maddenin nasıl yapılacağı tam belirlenemedi ya da bazı kısıtlamanız var veya hala araştırma yapılacak bir kaç fonksiyon olduğu görüldü. O zaman işin riski artacağı için puanın yaratacağı riskleri düşünerek yüksek verilmesi beklenir.

Complexity; Sprinte alınacak iş basit görünebilir ancak; bazı durumlarda işin yapılacağı yerin arkasında yer alan business çok karmaşık olabilir veya geliştirme yapacağınız ekranda o sprinte başka maddelerde olabilir. Bu durumda, hem geliştirme bakımından hem de test bakımından daha fazla uğraş gerektirdiği için verilecek puan yüksek olması beklenir.

Story pointlerin doğru belirlenmesi, Product Owner’ın proje kapsamınında kaynakları etkili bir şekilde yönetmesi ve ürün geliştirme sürecinde bilinçli kararlar almasına olanak tanır. Başarılı bir ürün yönetimi için story pointler hayati önem taşır. Product owner için şu faydaları sağlar;

1. Önceliklendirme ve Planlama
2. Kapasite Planlaması
3. İletişim ve Anlaşmazlıkları Çözme
4. Performans İzleme
5. Risk Yönetimi
6. Değer Oluşturma

gibi faydalar sağlayacaktır. Tabi sadece PO için değil Developers içinde faydaları şöyledir:

1. Göreceli Tahminler: Story point’ler, işlerin zamanla değil, karmaşıklık, çaba ve belirsizlikle ilgili göreceli tahminlerle değerlendirilmesini sağlar. Bu, takım üyelerinin farklı beceri düzeyleri ve çalışma hızlarına rağmen iş yükünü daha adil bir şekilde tahmin etmelerine olanak tanır.
2. Takım İçi Uyum ve Anlayış: Story point tahmin süreci, takım üyelerinin bir iş üzerinde tartışmaları ve fikir birliğine varmaları gerektiği anlamına gelir. Bu, görevlerin kapsamını ve zorluklarını derinlemesine anlamalarını sağlar ve takım içi iletişimi güçlendirir.
3. Kapasite Planlaması ve Hedef Belirleme: Takım, genellikle geçmiş performansına (örneğin, geçmiş sprintlerde tamamladığı toplam story point) dayanarak bir sprint içinde ne kadar iş tamamlayabileceğini tahmin edebilir. Bu, daha gerçekçi hedefler belirlemelerine ve aşırı yüklenmeyi önlemelerine yardımcı olur.
4. Üretkenlik ve Sürekli İyileştirme: Story point’lerle, takım sprint sonuçlarını değerlendirerek üretkenliğini ölçebilir ve sürekli iyileştirme için alanlar belirleyebilir. Bu, zamanla daha verimli hale gelmelerini sağlar.
5. Esneklik ve Adaptasyon: Story point’ler, takıma, değişen gereksinimlere ve önceliklere hızlı bir şekilde uyum sağlama esnekliği verir. İşlerin göreceli büyüklüğü ve zorluğu anlaşıldıkça, takım, en yüksek değeri sunacak işleri seçebilir.
6. Müşteri ve Paydaş Beklentilerinin Yönetimi: Story point tahminleri, takımın sprint ve proje teslimatları hakkında daha doğru beklentiler oluşturmasına olanak tanır. Bu, müşteriler ve diğer paydaşlarla daha etkili iletişim kurulmasını sağlar.
7. Önceliklendirme: Story point değerlendirmeleri, takımın önceliklendirme kararlarında daha bilinçli olmasına yardımcı olur. Takım, sınırlı zaman ve kaynakları en iyi şekilde nasıl kullanacağına karar verirken, işlerin göreceli önemini ve değerini daha iyi anlar.

Story point’lerin kullanımı, Scrum takımlarının iş yüklerini daha etkili bir şekilde yönetmelerine, hedeflere ulaşmalarına ve ürün geliştirme sürecinde daha uyumlu çalışmalarına olanak tanır. Bu süreç, takımın performansını artıran ve proje sonuçlarını iyileştiren bir dizi pozitif etkiye sahiptir.

Story point verme işlemini dilerseniz kendi miroda bir ortak alan oluşturup yapabilirsiniz veya aşağıdaki linklerden de faydalanarak puanlama işlemini gerçekleştirebilirsiniz.

• https://planningpokeronline.com/
• https://www.planningpoker.com/
• https://www.scrumpoker-online.org/en/room/77822338/scrum-poker/20

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Fibonacci Dizisinden Story Point Hesaplamasına yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Bir Scrum Master olarak görevinizi yerine getirirken takip edebileceğiniz bir kontrol listesi (checklist) olması kimin hoşuna gitmez ki 🙂

Durun durun hemen veriyorum o listeyi.

İşte hayatınızı kolaylaştıracak o liste aşağıda →

1. Takımın Hazır Olmasını Sağlama:
   • Scrum ekibi, sprint planlamasına ve diğer toplantılara hazır mı?
     Sprint planlama toplantısını düzenlemek ve yönetmek.
   • Ekip üyelerinin kabul edebileceği iş miktarını (sprint kapasitesi) belirlemek.
2. Sprint Planlaması:
   • Sprint planlama toplantısını düzenlemek ve yönetmek.
   • Sprint hedeflerini ve sprint sırasında yapılması gereken işleri belirlemek.
   • Ekip üyelerinin kabul edebileceği iş miktarını (sprint kapasitesi) belirlemek.
3. Günlük Daily Toplantıları:
   • Günlük Daily toplantılarını düzenlemek ve yönetmek.
   • Ekip üyelerinin ilerlemelerini ve karşılaştıkları engelleri paylaşmalarını sağlamak.
4. Engelleri Kaldırma:
   • Ekip üyelerinin karşılaştığı engelleri tanımlamak ve bunları çözmeye çalışmak.
   • Engelleri gidermek için gerekli kaynakları veya yardımı sağlamak.
5. Retrospektifler:
   • Retrospektif toplantılarını düzenlemek ve yönetmek.
   • Ekip üyelerinin sprint sonuçlarını değerlendirmelerini ve iyileştirme fırsatlarını tanımlamalarını teşvik etmek.
6. Görsel İzleme:
   • Kanban panoları,aktif backlog(jira üzerinde), iş tahtaları veya diğer görsel yönetim araçlarını güncellemek ve izlemek.
   • Metrikleri (örneğin, iş hızı, işlenmemiş iş miktarı) düzenli olarak takip etmek.
7. Eğitim ve Koçluk:
   • Yeni ekip üyelerine veya organizasyon içindekilerine Scrum süreçleri ve prensipleri hakkında eğitim vermek.
   • Ekip üyelerine ve Product Owner’a koçluk yapmak.
8. İletişim Yönetimi:
   • Ekip ile üst yönetim veya diğer paydaşlar arasındaki iletişimi düzenlemek ve gerektiğinde bilgi akışını sağlamak.
9. Risk Yönetimi:
   • Proje veya ekiple ilgili olası riskleri tanımak ve bu risklere karşı önlemler almak.
10. Kendini Geliştirme:
    • Kişisel ve profesyonel gelişiminizi sürdürmek, Scrum topluluğu ve literatürü ile ilgili güncel kalmak.

Bu checklist, Scrum Master’ın temel sorumluluklarını yerine getirmesine yardımcı olabilir. Ancak her organizasyonun ihtiyaçları farklıdır, bu nedenle bu liste üzerine eklemeler veya çıkarmalar yapabilirsiniz. Ayrıca, bu liste düzenli olarak güncellenmelidir, çünkü Scrum süreçleri ve ekibin ihtiyaçları zaman içinde değişebilir.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Check Ediyorum ! yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Her görevin olduğu gibi scrum masterın da takip etmesi, yapması yada yönlendirmesi gereken görevleri vardır. Bugün ki yazıda kısaca bu başlıklara değineceğiz. Tabi ki unutmamak gerekir ki her takım kendine özgüdür ve bu nedenle birebir aşağıda yazdıklarımın olması gerekmektedir.

Amaç Scrum takımımızın verimini arttırmak olmalı bu nedenle, takımın süreci yöneten ve ekibi destekleyen bir rolü vardır. Scrum Master’ın temel aktiviteleri olarakta aşağıdaki başlıklar bazında ilerleyebiliriz:

1. Ekip Yönetimi: Scrum Master, Scrum ekibini oluşturan bireyler arasındaki işbirliğini teşvik eder ve ekibi motive eder. Takımdaki en ufak mod düşüklüğünü algılar, kök nedene iner ve bunu oluşturan engellerin kaldırılmasını sağlar.
2. Scrum Süreç Yönetimi: Scrum süreçlerini anlayarak ve bu süreçlere uygun şekilde yöneterek ekibin etkinliğini artırır. Takıma yeni katılanların bu süreçleri öğrenmesini ve takıma ayak uydurmasını sağlar.
3. Engelleri Ortadan Kaldırma: Ekip üyelerinin karşılaştığı engelleri (örneğin, kaynak eksikliği, teknik sorunlar, iletişim problemleri) çözmek için çaba sarf eder.
4. Retrospektifler Düzenleme: Düzenli retrospektif toplantıları düzenleyerek ekibin sürekli olarak kendini geliştirmesini teşvik eder. ekip içerisinde sprinte yaşanan yaşanabilecek olan olayları takım anlaşmasını sağlayarak ekibi hizalar.
5. Görsel İzleme ve Metrik Analizi: Scrum Master, projenin ilerlemesini izler, Kanban panoları ve diğer görsel yönetim araçları kullanarak sürecin daha iyi anlaşılmasını sağlar. Ayrıca, metrikleri (örneğin, iş hızı, hata oranı) izler ve ekip performansını değerlendirir.
6. Scrum Eğitimi: Yeni ekip üyelerini veya organizasyon içindeki diğer kişileri Scrum süreçleri ve prensipleri hakkında eğitir.
7. İletişim: Ekip ile üst yönetim veya diğer paydaşlar arasındaki iletişimi kolaylaştırır ve gerektiğinde bilgi akışını düzenler.
8. Koçluk: Ekip üyelerine ve Product Owner’a (ürün sahibi) rehberlik yapar, Scrum süreçlerine ve uygulamalarına uyum sağlamalarına yardımcı olur.
9. Risk Yönetimi: Proje veya ekiple ilgili olası riskleri tanır ve bu risklere karşı önlemler alınmasına yardımcı olur. Düzenli aralıklarla Takıma ve Proje paydaşlarına scrum bültenini yayınlar.
10. Kendini Geliştirme: Scrum Master, kendi becerilerini ve bilgisini sürekli olarak geliştirir ve Scrum topluluğuyla iletişimde kalır. Yeni olanı inceler analiz eder ve takıma sunup takım içinde yaygınlaştırılmasını sağlar.

Bu listeyi temel bir aktivite örneği olarak baz alırsak daha da derinleştirerek ilerleyebiliriz. Yeni başlayanlar için yol gösterici olması dileği ile

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Scrum Master Aktiviteleri yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Her scrum takımının sprint sonrası abi biz ne yaşadık bu sprinte diye yaptığımız toplantıdır desem belki de agile yaklaşımına biraz sokak ağzı katmış olabilirim. Tabi ki teorisini aktarıcam ama bir de bizi yaşarken görün demek istiyorum. Ama önce tabi ki teoriye geçelim.

Nedir bu RETROSPEKTIVE?

Retrospektifler, Sprint ya da diğer adımların sonunda gerçekleştirilen düzenli toplantılardır. Ekip üyeleri, bu toplantılarda geçmiş süreci gözden geçirir, neyi iyi yaptıklarını ve neleri geliştirebileceklerini değerlendirirler. Bu değerlendirme, açık iletişim ve katılımcı bir ortamda gerçekleşir.

Retrospektiflerde genellikle “ne iyi gitti” ve “iyileştirme yapılabilir alanlar” başlıkları altında toplanır. Başarılar ve iyi uygulamalar kutlanırken, olumsuz durumlar açıkça ifade edilir ve çözümler üzerinde çalışılır. Aksiyon maddeleri oluşturulur ve sorumlular belirlenir. Bu şekilde, ekip, gelecekte benzer sorunlarla karşılaştığında daha hızlı ve etkili bir şekilde tepki verebilir.

Şimdi gerçek dünyada tabi ki profesyonel hayatta beklenen hemen 1 paragraf öncesi olması ama o yoğun ve zorlu sprinte bazen geliştirici takım ile PO nun istedikleri uyuşmamış olabilir. Özellikle sprintler bir KPI hedefe bağlandığında bu süreç daha yıpratıcı olabiliyor. Bu noktada geliştirici takım ile Po arasında açık iletişim konusunda profesyonel bir yaklaşıma gidilmesi gerekir. Bu noktada Scrum master a büyük bir görev düşüyor.

Sıcak sprint sonrası iki tarafta söz verdiği işleri yapamadığında koçluk yapması gereken Scrum master oluyor. Scrum masterın retrospektive de ki görevleride şunlar olmalı,

1. Toplantıyı Planlama
2. Retrospektif Formatını Seçme
3. Toplantıyı Yönetme
4. Geri Bildirim Toplama
5. Engelleri Belirleme
6. Eylem Planlarının Oluşturulmasını Destekleme
7. Gelişim Sürecini İzleme
8. Ekip İçi İletişimi ve İlişkileri Destekleme

ve tüm bunları görev olarak ilgili kişilere atama ve takibini yapma.

Eğer bir ekipte Scrum Master olarak görev alıyorsanız aşağıdaki retrospektive araçlarını kullanabilirsiniz.

1. Miro: Miro, sanal beyaz tahta olarak kullanılabilen işbirliği ve fikir paylaşımı platformudur. Retrospektiflerde, ekibin online olarak fikirleri toplamasına, aksiyon maddelerini takip etmesine ve görsel olarak verimliliği artırmasına yardımcı olabilir.
2. Trello: Trello, görev ve proje yönetimi için popüler bir araçtır. Retrospektiflerde, ekibin toplantı sonuçlarını takip etmek ve geliştirme süreçlerini organize etmek için kullanılabilir.
3. FunRetro (eskiden RetroTool): RetroTool, adından da anlaşılacağı gibi retrospektifler için tasarlanmış bir araçtır. Ekibin kolayca fikirlerini toplayabileceği ve oylayabileceği, aksiyon maddeleri oluşturabileceği ve sonuçları paylaşabileceği kullanıcı dostu bir platform sunar.
4. Retrium: Retrium, özellikle retrospektif toplantıları için tasarlanmış bir araçtır. Retro formatlarını kolayca uygulamanıza ve ekip üyelerinin anonim olarak geri bildirim vermesine imkan tanır.
5. Google Jamboard: Google Jamboard, çevrimiçi beyaz tahta olarak kullanılabilen ve ekip üyelerinin katkı sağlayabileceği bir araçtır. Ekip, retrospektiflerde fikirlerini post-it notları şeklinde ekleyebilir ve tartışabilir.
6. GroupMap: GroupMap, ekip içinde fikirleri toplamak ve oylamak için kullanışlı bir araçtır. Retro süreçlerini yönetmek için çeşitli şablonlar sunar.

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Retrospective-Yaşarken Hiç Komik değildi(!) yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Her sprint sonu bir z raporu arıyorsanız size muhteşem bir grafikten bahsedeceğim. Burndown Chart.

Burndown chartlar, ekibinizin çalışmalarını planlanan zamanda tamamlama olasılığını tahmin etmek için kullanılır. Ayrıca, product backlog da meydana gelebilecek kapsam değişiklikleri içinde ekibi haberdar etmek erken uyarıcıdır. Bu grafiklere jira uygulamanızdan raporlar sekmesinden ulaşabilirsiniz.

Burndown chart grafiğindeki başlıkları incelemek gerekirse;

• X Ekseni: Proje/yineleme zaman çizelgesi
• Y Ekseni: Proje için tamamlanması gereken işler. Kalan çalışma için süre veya hikaye noktası tahminleri bu eksen tarafından temsil edilecektir.
• Proje Başlangıç ​​Noktası: Grafiğin solundaki en uzak noktadır ve projenin/yinelemenin 0. gününde gerçekleşir.
• Proje Bitiş Noktası: Grafiğin en sağındaki noktadır ve projenin/yinelemenin tahmin edilen son gününde gerçekleşir.
• İdeal Çalışma Kalan Çizgi: Başlangıç ​​noktasını bitiş noktasına bağlayan düz bir çizgidir. Başlangıç ​​noktasında ideal çizgi, tamamlanması gereken tüm görevler (iş) için tahminlerin toplamını gösterir. Bitiş noktasında ideal çizgi x eksenini keser ve bu da tamamlanacak iş kalmadığını gösterir. Bu çizgi, tahminlere dayalı matematiksel bir hesaplamadır ve tahminlerin hatalı olma olasılığı eserden daha fazladır.
• Fiili Çalışma Kalan Çizgisi: Kalan fiili işi gösterir. Başlangıç ​​noktasında kalan fiili çalışma, kalan ideal çalışma ile aynıdır ancak zaman ilerledikçe, tahminler arasındaki bu eşitsizliğe ve ekibin ne kadar etkili olduğuna bağlı olarak fiili çalışma çizgisi ideal çizginin üstünde veya altında dalgalanır. Fiili çalışma çizgisi ideale göre üstte kalıyorsa bu sprintin sonunda diğer sprinte işlerin sarkacağını anlatır. Tam tersi olduğunda bu çizgi ideal çalışmanın altında kaldığında takımın performansından düşük işler aldığını ve sprint sonunda takımın boşa düşeceğini ifade eder. Bir birlerine yakın ve paralel bir çizgi halinde ilerlediklerinde ise takımın sprint sonunda tüm alınan işleri tamamlayacağını ifade eder.

Aşağıdaki grafik gerçek bir sprinttin ideal beklenen ile fiili çalışma çizgisinin durumunu göstermektedir.

Burndown Chart Grafikleri bizlere ne fısıldar merak ediyorsanız aşağıdaki grafikleri inceleyebilirsiniz 🙂

İdeal Takım Grafiği: Kapasiteyi doğru tahminleyip kendi kendine organize olan bir ekip

Mükemmel Takım Grafiği : Takım sprintin ilk yarısında geç kalmış olmasına rağmen ikinci yarısında kalan işleri doğru organizasyonla hızlıca tamamlayıp sprint planını zamanında tamamlamışlar. bu tip bir grafik ekibin deneyimli ve bir biri ile konuştuğunu gösterir.

“Otobüsü Kaçırdık” Grafiği: Takım alınan işler için geç kaldığı ve tamamlayamayacağı kadar iş aldığını gösterir.

“Gene Erken Geldik” Grafiği: Ekip performansının çok altında iş aldığını, elindeki işleri bitirmesine rağmen ek iş almadığını gösteren bir grafik.

“Yönetim Geliyor” Grafiği: Ekip muhtemelen bazı işler yapıyor ama belki de ilerlemesini buna göre güncellemiyor. Başka bir neden de, ürün sahibinin halihazırda tamamlanmış olan iş miktarını eklemeside çizginin düz olmasına neden olabilir.

Yukarıdaki örnekleri bir çok şekilde çoğaltarak ilerleyebiliriz. Önemli olan iyi bir PO geliştirici ekibinin performansınıda göz önüne alarak sprintte doğru bir kapasite planlaması yapmasıdır

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Z raporu=Burndown Chart yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.