Agile Ekipler İçin Ücretsiz Proje Durum Raporu Sunum Şablonu

Yararlı bir Agile proje durum raporu, paydaşların dört soruyu hızlıca yanıtlayabilmesini sağlamalıdır: Ürün hedefine doğru ilerliyor muyuz? Hangi kullanılabilir değer teslim edildi? Bir sonraki sonucu riske atan ne var? Şu anda hangi karar veya yardım gerekiyor? Bir sunum bu soruları birkaç dakika içinde yanıtlayamıyorsa, daha fazla grafik eklemek genellikle onu daha iyi değil, daha uzun hale getirir.

Çoğu Agile ekip için yedi slaytlık bir durum sunumu yeterlidir: genel durum, hedef ve sonuçlar, ilerleme, riskler ve engeller, kapsam ve değişiklikler, kalite/sürüm hazırlığı ve sonraki eylemler veya kararlar. Aşağıdaki şablon bilinçli olarak kompakt tutulmuştur. Amacı paydaşlar için şeffaflığı artırmaktır; Sprint İncelemesi, Günlük Scrum, ürün backlog'u veya diğer çalışma artefaktlarının yerini almak değildir.

11 Eylül 2026 itibarıyla, mevcut resmi Scrum Kılavuzu Kasım 2020 baskısı olmaya devam etmektedir. Kılavuz, şeffaflığı, kararlaştırılan hedeflere yönelik ilerlemenin sık sık incelenmesini ve sonuçlar veya koşullar değiştiğinde uyum sağlamayı vurgular. Ayrıca Sprint İncelemesinin, Scrum Ekibi ve paydaşların sonuçları incelediği ve ne yapılacağına karar verdiği, yalnızca bir sunum olmayan bir çalışma oturumu olduğunu belirtir. Resmi Scrum Kılavuzu'na bakın.

Yüksek kaliteli bir durum sunumu ne başarmalıdır?

Sunum, insanların gerçekliğe dair ortak bir görüş ve az sayıda net eylemle ayrılması durumunda başarılıdır. Sadece her slaytın dolu olması onu başarılı kılmaz.

Bu, çalışan yazılımın ilerlemenin birincil ölçüsü olduğu Agile Manifestosu ilkesiyle uyumludur. Yazılım dışında bir şey üreten ekipler için aynı temel fikri kullanın: Yalnızca etkinliği değil, kullanılabilir, doğrulanabilir bir artışı veya sonucu vurgulayın. Agile Manifestosu'nun Arkasındaki İlkeler'e bakın.

Ücretsiz Agile proje durum raporu şablonu: 7 slaytlık yapı

Slayt 1: Genel bakışta proje durumu

Meşgul bir paydaşın her şeyden önce ihtiyaç duyduğu bilgiyle başlayın:

• Ürün veya proje adı
• Raporlama dönemi veya Sprint numarası
• Ürün Hedefi veya ana amaç
• Sprint Hedefi
• Kısa bir açıklamayla genel durum
• En önemli bir ila üç risk
• Önceki rapordan bu yana ne değiştiğine dair bir cümle

Kırmızı/amber/yeşil durum kullanıyorsanız, anlamını tanımlayın. “Amber”, Sprint Hedefinin hala ulaşılabilir olduğunu ancak bir bağımlılığın zamanlamayı önemli ölçüde etkileyebileceği anlamına gelebilir. Kriterleri olmayan bir renk öznel hale gelir ve durum iyimserliğini teşvik edebilir.

Kalite kontrolü: Yalnızca bu slaytı okuyan bir paydaş, mevcut yönü ve en önemli endişeyi anlamalıdır.

Slayt 2: Hedef, müşteri sonucu ve teslim edilen değer

Ekipin neyi başarmaya çalıştığını ve kullanıcılar, müşteriler veya iş için neyin değiştiğini gösterin. Bu slayt, uzun bir “tamamlanan görevler” listesinden daha değerlidir.

Basit bir yapı şudur:

Scrum'da bir Artış kullanılabilir olmalı ve Artışın bir parçası olarak kabul edilmeden önce “Bitti Tanımı”nı karşılamalıdır. Bu, kısmen tamamlanmış backlog öğelerini eşit değer teslim etmiş gibi saymaktan daha iyi bir durum çıpasıdır. Scrum Kılavuzu, Bitti Tanımı'nı, Artışın ürünün gerekli kalite ölçütlerini karşıladığındaki durumun resmi tanımı olarak tanımlar.

Kalite kontrolü: “Bitti”, “devam ediyor” ve “planlandı” arasında net bir ayrım yapın. Ekipin Bitti Tanımı'nı karşılamadıysa, işi teslim edilmiş olarak tanımlamayın.

Slayt 3: Sprint ilerlemesi ve tahmin

Bir veya iki ilerleme görselini yalnızca bir karara yardımcı oluyorlarsa kullanın. Scrum Kılavuzu, burn-down, burn-up ve kümülatif akış gibi uygulamaları faydalı tahmin teknikleri olarak tanır ve bunların deneyselliğin yerini almadığını açıkça belirtir.

Faydalı seçimler şunları içerir:

• Burn-up grafiği: Kapsam değiştiğinde ve tamamlanan işi toplam kapsama karşı göstermek istediğinizde faydalıdır.
• Burn-down grafiği: Sınırlı bir Sprint veya sürüm tahmini içinde kalan işi görselleştirmek için faydalıdır.
• Kümülatif akış: Artan iş yükünü (WIP) veya bir iş akışı darboğazını ortaya çıkarmak gerektiğinde faydalıdır.
• Basit sonuç tablosu: Küçük ekipler veya yönetici kitleleri için genellikle bir grafikten daha iyidir.

Agile sunumların bir grafik içermesi beklendiği için sırf hız (velocity) eklemekten kaçının. Scrum Kılavuzu, hızı zorunlu bir Scrum metriği olarak tanımlamaz. Ekibiniz bunu tahmin için kullanıyorsa, rakamın neyi temsil ettiğini açıklayın ve onu evrensel bir verimlilik skoru olarak ele almak yerine ekibin kendi geçmişiyle karşılaştırın.

Kalite kontrolü: Grafik bir soruyu yanıtlamalıdır. Onu kaldırmak kimsenin anlayışını veya kararını değiştirmeyecekse, kaldırın.

Slayt 4: Riskler, engeller ve bağımlılıklar

Bu genellikle en karar verici slayttır. Üç kavramı ayırın:

• Risk: Bir sorun yaratabilecek gelecekteki bir olay veya durum.
• Engel: Şu anda ilerlemeyi engelleyen bir şey.
• Bağımlılık: Başka bir ekipten, tedarikçiden, sistemden veya karar vericiden gereken iş, bilgi veya yetenek.

Şu gibi sütunlar kullanın:

Scrum, iş ve zorluklar konusunda açıklığı açıkça değerli bulur ve Scrum Master, ekibin ilerlemesini engelleyen engellerin kaldırılmasına yardımcı olmaktan sorumludur. Rahatsız edici riskleri gizleyen bir durum sunumu, faydalı inceleme için gereken şeffaflığa aykırıdır.

Kalite kontrolü: Her önemli engelleyicinin bir sahibi veya açık bir yükseltme talebi olmalıdır. “Ekip izliyor” kritik bir bağımlılık için nadiren yeterlidir.

Slayt 5: Kapsam değişiklikleri ve ekibin öğrendikleri

Agile durum raporlaması, orijinal planın kutsal olduğu anlamına gelmemelidir. Scrum Kılavuzu, Sprint Hedefi tehlikeye atılmadığı sürece, daha fazla şey öğrenildikçe kapsamın Ürün Sahibi ile netleştirilebileceğini ve yeniden müzakere edilebileceğini söyler.

Paydaş beklentilerini önemli ölçüde etkileyen değişiklikleri gösterin:

• Keşfedilen yeni gereksinim
• Artık yeterli değer katmadığı için kaldırılan backlog öğesi
• Çürütülen teknik varsayım
• Değişen bağımlılık
• Yeniden önceliklendirmeye neden olan müşteri geri bildirimi

Kısa bir “Değişen / Neden / Etki” tablosu kullanın. Bu, izleyicinin iki backlog anlık görüntüsünü manuel olarak karşılaştırmaya zorlamadan uyumu görünür kılar.

Kalite kontrolü: Bir değişikliğin hedefi, tahmini, maliyeti, kaliteyi mi yoksa yalnızca uygulama yaklaşımını mı etkilediğini açıklayın.

Slayt 6: Kalite ve sürüm hazırlığı

Kalite kötüleşiyorsa “zamanında” olmak yeterli değildir. Ürün için önemli olan birkaç kalite sinyali ekleyin. Ekipa bağlı olarak bunlar şunları içerebilir:

• Bitti Tanımı uyumu
• Açık kritik hatalar
• Otomatik test sağlığı
• Güvenlik veya erişilebilirlik kontrolleri
• Üretim olay trendi
• Sürüm engelleyicileri
• Operasyonel hazırlık

Slaytı mevcut her mühendislik metriğiyle doldurmayın. Artışın kullanılabilir olup olmadığına ve paydaşların sürüm kararına makul şekilde güvenip güvenemeyeceğine bağlı kanıtları seçin.

Kalite kontrolü: Sunum “yeşil” derken bir sürüm engelleyici hata çözülmemişse, durum modelinin değişmesi gerekir.

Slayt 7: Kararlar, sonraki adımlar ve sahipler

Jenerik bir “Teşekkürler” slaytıyla değil, eylemle bitirin. Basit bir tablo işe yarar:

Kalite kontrolü: Sunumdan sonra, bir sonraki dışa dönük eylemin kime ait olduğu konusunda hiçbir belirsizlik olmamalıdır.

Agile durum sunumunda hangi metrikler yer almalıdır?

Metrikleri yalnızca inceleme ve uyumu desteklediklerinde kullanın. Pratik bir seçim çerçevesi şudur:

Sunumu bir gösteriş metrikleri skor kartına dönüştürmeyin. Tamamlanan hikaye puanları, kapatılan ticket sayısı veya kullanım oranı belirli bir bağlamda geçerli dahili sinyaller olabilir, ancak bunlar kullanılabilir sonuçların yerini tutmaz. Agile Manifestosu'nun çalışan yazılımı ilerlemenin birincil ölçüsü olarak vurgulaması burada faydalı bir koruma rayıdır.

Sunumun yanlış araç olduğu zamanlar

Bir sunum, izleyicinin özlü, periyodik bir senteze ihtiyaç duyduğunda faydalıdır. Yaklaşımı şu durumlarda değiştirin:

• Paydaşlar gerçek zamanlı operasyonel verilere ihtiyaç duyuyorsa; canlı bir gösterge paneli kullanın.
• Ekip bugünün işini koordine etmesi gerekiyorsa; Günlük Scrum ve mevcut Sprint Backlog'u kullanın.
• İzleyicinin gerçek Artışı incelemesi gerekiyorsa; slaytlarda tarif etmek yerine onu gösterin.
• Ekip sürecinin neden başarısız olduğunu tartışıyor ise; Sprint Retrospektifini kullanın.
• Detaylı backlog sıralaması gerekiyorsa; doğrudan backlog veya ürün yönetimi sisteminde çalışın.

Scrum Kılavuzu, Sprint İncelemesinin bir sunumla sınırlı kalmaması gerektiği konusunda özellikle açıktır. Bir proje durum sunumu paydaşları hazırlayabilir ve bağlamı özetleyebilir, ancak ürünün işbirlikçi incelemesinin ve ne yapılacağına dair tartışmanın yerini almamalıdır.

Sunumu ne sıklıkla güncellemelisiniz?

Raporlama ritmini, izleyicinin alması gereken kararlara göre ayarlayın. Birçok ekip durumu her Sprint'te bir kez güncellerken, önemli bağımlılıkları olan programlar daha kısa haftalık özetlere ihtiyaç duyabilir. Sunum yalnızca dünkü verileri tekrarlıyorsa, daha sık raporlama otomatik olarak daha şeffaf değildir.

Faydalı bir kural şudur: Bilgi bir paydaş kararını, tahminini veya risk yanıtını değiştirebilecekse güncelleyin. Canlı olmayan her metrikte kaynak tarihini görünür tutun.

Okunabilirliği artıran tasarım kuralları

PowerPoint, boş bir sunumun yanı sıra hazırlanmış bir şablondan başlatmayı da destekler ve Microsoft, düzen, yazı tipleri, renkler ve efektlerde tutarlı bir düzen istediğinizde şablonları önerir. Microsoft'un PowerPoint sunum rehberine bakın.

Bir durum sunumu için:

• Slayt başına bir mesaj kullanın.
• Yoğun paragraflar yerine kısa tabloları ve doğrudan etiketleri tercih edin.
• Raporlama dönemini ve veri tarihini gösterin.
• Durum renklerini tutarlı tutun ve tanımlayın.
• Toplantı odasında okunabilir kalan büyük metin kullanın.
• Riski iletmek için yalnızca renge güvenmeyin; metin veya simge ekleyin.
• Daha derin detay faydalı olduğunda kaynak sisteme bağlantı verin.

Sunumu yeniden kullanmak istiyorsanız, Microsoft ayrıca özelleştirilmiş bir sunumu PowerPoint şablonu (.potx) olarak kaydetmeyi destekler; böylece aynı yapı gelecekteki raporlar için kullanılabilir. Microsoft'un şablon oluşturma rehberine bakın.

Şablonun değişmesi gerektiğini nasıl anlarsınız?

Sunum markalı olduğu için aynı slaytları sonsuza dek kullanmayın. Şablonun bilgisi artık alınan kararları desteklemediğinde şablonu değiştirin.

Sinyaller şunları içerir:

• Paydaşlar tekrar tekrar aynı eksik bilgiyi istiyor.
• Slaytlar birkaç Sprint boyunca değiştirilmeden ileriye kopyalanıyor.
• Ekipler risk veya sonuçları tartışmaktan çok biçimlendirmeye zaman harcıyor.
• Metrikler, değer yerine ticket sayısını optimize etmek gibi faydasız davranışları teşvik ediyor.
• Risk maddeleri sahip veya eylem olmadan kırmızı kalıyor.
• Sunum, yorum eklemeden canlı bir gösterge panelini tekrarlıyor.
• Toplantı, inceleme ve uyum yerine tek yönlü bir sunuma dönüşüyor.

Faydalı bir şablon, zamanla raporlama çabasını azaltmalıdır; elle bakılması gereken ikinci bir proje yönetim sistemi yaratmamalıdır.

Bu ücretsiz durum raporu şablonunun sınırları

Bu yapı, küçük bir Agile ekip, tek bir ürün akışı veya daha büyük bir girişimin yönetici özeti için iyi çalışır. Bir program birçok ürün, düzenlenmiş aşama kapıları, sözleşmeye dayalı kazanılmış değer raporlaması, karmaşık portföy finansı veya düzinelerce ekip arası bağımlılık içerdiğinde daha az uygundur. Bu durumlarda, yedi slaytlık sunum yönetici özeti olarak kalabilir, ancak ayrıntılı yönetişim uygun kaynak sistemlerde ve program kontrollerinde yer almalıdır.

Ayrıca evrensel bir Agile metrik seti de öngörmez. Scrum bilinçli olarak hafiftir ve Scrum Kılavuzu, tekniklerin ve taktiklerin bağlama göre büyük ölçüde değişebileceğini belirtir. İşin gerçek durumunu iyi kararlar için yeterince görünür kılan en küçük kanıt setini seçin.

Son kalite kontrol listesi

• Ürün Hedefi ve Sprint Hedefi görünürdür.
• Teslim edilen değer, devam eden işten ayrılmıştır.
• Durum, yalnızca renkle değil, kanıtla desteklenmiştir.
• Tahmin grafiklerinin net bir amacı vardır.
• Riskler, engeller ve bağımlılıklar ayrıştırılmıştır.
• Kapsam veya varsayımlardaki önemli değişiklikler açıklanmıştır.
• İlgili olduğunda kalite ve sürüm hazırlığı kanıtları dahil edilmiştir.
• Her istenen karar veya yükseltmenin bir sahibi ve tarihi vardır.
• Sunum, yüksek sesle okunmak yerine tartışılacak kadar özlüdür.
• Sunum, ekibin Scrum etkinliklerini ve canlı artefaktlarını tamamlar—yerine almaz.

Güçlü bir Agile proje durum sunumu nihayetinde bir karar yardımcısıdır. Ekibin mevcut gerçekliğini görünür kılar, ilerlemeyi hedeflere ve kullanılabilir sonuçlara bağlar, riski harekete geçmek için yeterince erken ortaya çıkarır ve net sonraki adımlarla biter. Sunum bunu yedi slayt yerine beş slaytla yapıyorsa, beşini kullanın. Canlı bir gösterge paneli bir slaytı gereksiz kılıyorsa, onu kaldırın. Şablon, şeffaflığa ve uyuma hizmet etmelidir—ekibin beslemek zorunda kaldığı başka bir törene dönüşmemelidir.