Home Tags Posts tagged with "dijital ürün"
Tag:

dijital ürün

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

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

Product Backlog’ta Yer Alması Gereken Temel Bilgiler

by mlap
written by mlap

Product Backlog’un etkin yönetilebilmesi için temel bilgilerin eksiksiz doldurulması gerekir. Bu alanlar, backlog’un şeffaf olmasını, tüm paydaşların aynı noktada buluşmasını ve etkin yönetimi sağlar.

  • PBI (Product Backlog Item):
    Backlog’daki her iş maddesidir. Yapılacak işi net, sade ve anlaşılır şekilde ifade etmelidir. User Story, Job Story gibi farklı formatlarda yazılabilir.

  • Kabul Kriteri:
    PBI’ın kullanıcı bakış açısıyla tamamlanmış sayılabilmesi için gerekli koşulları içerir. Takımla yapılan anlaşma niteliğindedir ve güncel tutulması şeffaflık için önemlidir.

  • Statü:
    PBI’ın mevcut durumunu gösterir. Örn. Waiting, In Progress, Done (ihtiyaca göre genişletilebilir).

  • Öncelik:
    Backlog’un olmazsa olmaz alanıdır. Product Owner, PBI’ları iş değerine göre önceliklendirmekten sorumludur.

  • Büyüklük:
    Takım, çeşitli tahminleme teknikleri kullanarak PBI’ın büyüklüğünü belirler. Bu bilgi backlog’da mutlaka yer almalıdır.

  • İş Değeri:
    Product Owner, PBI’ın sağlayacağı değeri belirlemeli ve backlog’da şeffaf şekilde paylaşmalıdır.

  • İş Tipi:
    PBI’ların türüne göre sınıflandırılması yönetim kolaylığı sağlar. (Örn. Yeni Özellik, Problem, Teknik Borç).

  • Giriş Sprinti:
    PBI’ın backlog’a ilk eklendiği zamanı gösterir.

  • Planlanan Sprint:
    PBI’ın ilk kez planlamaya dahil edildiği sprinttir.

  • Tamamlanan Sprint:
    PBI’ın tamamlandığı sprinttir.

Bu üç alan birlikte ele alındığında;

  • Değerin müşteriye ne kadar sürede ulaştığı,

  • PBI üzerinde ne kadar süre çalışıldığı gibi bilgiler analiz edilebilir. Bu da Product Owner için kıymetli içgörüler sağlar.

  • Talep Sahibi:
    PBI’ın kim tarafından talep edildiğini belirtir. Bu bilgi, iletişim sürecini kolaylaştırır.

Product Backlog’da bu alanların eksiksiz tutulması, sağlıklı metrikler ve raporlamalarla desteklenmesi, backlog’un etkin yönetimini sağlar.

👉 Yazının sonunda bahsettiğim “Product Backlog şablonu” linki, bu süreci uygulamalı olarak desteklemek için oldukça değerli bir kaynak olacaktır.

0 comments
0 FacebookTwitterPinterestEmail