Agile ekipler genellikle aynı iletişim sorunuyla karşı karşıya kalır: Ekip zaten bir backlog'a, panoya, Sprint Hedefine, incelemelere ve çalışan yazılıma sahiptir; ancak paydaşlar hâlâ özlü bir proje durum sunumu talep eder. Hata genellikle sunumu hazırlamak değildir. Hata, sunumun ikinci bir doğruluk kaynağına, Sprint İncelemesinin yerine geçen bir araca veya kesin görünen ancak kimsenin karar vermesine yardımcı olmayan yüzde koleksiyonuna dönüşmesine izin vermektir.
Bu ücretsiz proje durum raporu sunum şablonu, PowerPoint veya Google Slides'a kopyalayabileceğiniz slayt slayt bir içerik taslağıdır. Her ekibin aynı metrikleri veya raporlama sıklığını kullandığını iddia etmeden kısa bir paydaş güncellemesine ihtiyaç duyan Scrum ve diğer Agile ekipler için tasarlanmıştır. Vurgu, doğrulanmış gerçekler, bağlama bağlı göstergeler, açık kararlar ve somut sonraki eylemler üzerinedir.
Doğrulanmış: Scrum, haftalık durum raporu slayt sunumunu öngörmez. Güncel resmi Scrum Rehberi; Ürün Backlog'unu, Sprint Backlog'unu, Artırmayı, bunların taahhütlerini ve Scrum etkinliklerini tanımlar; proje durum sunumu bu zorunlu artefaktlardan veya etkinliklerden biri değildir. Rehber ayrıca, Sprint İncelemesinin Sprint çıktısını incelemek ve gelecekteki uyumlamalara karar vermek için çalışan bir oturum olduğunu ve ekibin bunu bir sunumla sınırlamaktan kaçınması gerektiğini belirtir. Bunu resmi Scrum Rehberi'nden doğrulayabilirsiniz.
Faydalı eylem: Sunumu paralel bir yönetim sistemi olarak değil, bir iletişim katmanı olarak ele alın. Gerçekleri ekibin mevcut kaynaklarından—Ürün Backlog'u, Sprint Backlog'u, Artırma, sürüm verileri, hata verileri, risk günlüğü ve kararlar—çekin; ikinci bir sayı setini manuel olarak uydurmak yerine.
Bağlama bağlı: Bazı organizasyonlar haftalık yönetici güncellemesine ihtiyaç duyar; diğerleri yalnızca sürüm düzeyinde bir özet veya aylık portföy raporu ister. Scrum'ın kendisi bu sıklığı öngörmez. Düzenlenmiş bir program, müşteri sözleşmesi, PMO veya çoklu ekip girişimi, Scrum'ın ötesinde ek raporlamaya makul şekilde ihtiyaç duyabilir.
Faydalı eylem: Raporlama sıklığını hedef kitlenin karar döngüsüne göre seçin. Liderler haftalık olarak finansman veya bağımlılık kararları alıyorsa, haftalık özet faydalı olabilir. İki haftalık Sprintler arasında anlamlı bir şey değişmiyorsa, aynı sunumu birkaç günde bir tekrarlamak, şeffaflığı artırmadan raporlama yükü oluşturur.
Aşağıdaki sekiz slaytlık yapı kasıtlı olarak kompakttır. Küçük bir ürün ekibi için yalnızca 1, 2, 4, 6 ve 8. slaytlara ihtiyacınız olabilir. Harici bağımlılıkları olan bir program için tüm sekizini kullanın. Her örnek yer tutucuyu gerçek ekibinizden verilerle değiştirin.
| Slayt | Amaç | İçerilecekler |
|---|---|---|
| 1. Başlık ve raporlama aralığı | Hedef kitleyi yönlendirin | Ürün veya proje adı, Sprint/sürüm, raporlama tarihi, sahibi |
| 2. Yönetici durumu | 30 saniyede önemli olanı gösterin | Hedef, genel durum, büyük değişiklik, en büyük risk, gereken karar |
| 3. Hedef ve sonuç ilerlemesi | Etkinliği değerle ilişkilendirin | Ürün Hedefi veya sürüm amacı, Sprint Hedefi, sonuç kanıtları |
| 4. Tamamlanan ve kabul edilen işler | Doğrulanmış ilerlemeyi gösterin | Tamamlanmış artırmalar, sürümler, müşteriye yönelik değişiklikler, kanıtlar |
| 5. Akış veya tahmin metrikleri | Hareketi ve belirsizliği ortaya koyun | Burn-up, burn-down, döngü süresi, iş hacmi, tahmin aralığı—yalnızca faydalıysa |
| 6. Riskler, engeller, bağımlılıklar | Yönetim dikkatini odaklayın | Etki, sahibi, hafifletme, tarih/tetikleyici, gereken yardım |
| 7. Kararlar ve değişiklikler | Belirsizliği önleyin | Alınan kararlar, kapsam değişiklikleri, geçersiz kılınan varsayımlar, bekleyen seçimler |
| 8. Sonraki adımlar | Eylemle bitirin | Sonraki hedef, ana işler, sahibi, kilometre taşı, paydaş eylemi |
Açılış slaytını işlevsel tutun. Faydalı bir başlık “Proje Durum Raporu — Ödeme Modernizasyonu — Sprint 14” olabilir, ardından raporlama tarihi ve ekip adı gelir. Sunum on dakikalık bir operasyonel inceleme için tasarlandıysa, sloganlara veya dekoratif içeriğe tam bir slayt ayırmaktan kaçının.
Faydalı eylem: “Sprint 14: 1–14 Eylül 2026” gibi kesin raporlama aralığını ekleyin. Bu, sonraki slaytlardaki her sayının yorumlanmasını kolaylaştırır ve insanların farklı dönemlerden metrikleri karşılaştırmasını önler.
Basit bir yönetici slaytı, Yolda (On Track), Risk Altında (At Risk) veya Yoldan Çıktı (Off Track) gibi genel bir durum içerebilir, ancak etiketin belirtilmiş bir nedeni olmalıdır. “Ödeme sağlayıcısı sertifikasyonu 16 Eylül'den 23 Eylül'e ertelendiği için Risk Altında” ifadesi eyleme dönüştürülebilir. Açıklamasız kırmızı bir durum değildir.
Yaygın yanlış anlama: “%80 tamamlandı” çubuğu otomatik olarak Agile bir ilerleme ölçütü değildir. Resmi Scrum Rehberi, ampirizmi vurgular ve burn-down, burn-up ve kümülatif akışlar gibi uygulamaların faydalı tahminler olabileceğini, ancak gerçekte olanların yerini tutmadığını belirtir. Ayrıca, karmaşık ortamlarda ileriye dönük karar alma için yalnızca zaten olanların kullanılabileceğini ifade eder. Resmi Scrum Rehberi'nin Sprint bölümüne bakın.
Faydalı eylem: Bir tamamlanma yüzdesi gösteriyorsanız, paydayı tanımlayın. “Planlanan 50 göç görevinden 39'u tamamlandı” ifadesi, “Müşteri değerinin %78'i sunuldu” ifadesinden farklıdır ve hiçbiri diğerini ima etmemelidir.
Scrum'da Sprint Hedefi, Sprint için tek amaçtır; Ürün Hedefi ise Scrum Ekibinin üzerinde çalıştığı daha uzun vadeli amaçtır. Sprint Backlog'u, Sprint Hedefini, seçilen Ürün Backlog öğelerini ve uygulanabilir teslimat planını içerir. Bu, durum raporuna “yapılan görevler ile kalan görevler”den daha iyi bir organizasyon ilkesi sağlar.
İyi bir slayt şunları söyleyebilir:
Faydalı eylem: Slayt başlığını “Sprint ilerleme güncellemesi” yerine “Yetkilendirme akışı tamamlandı; iade doğrulaması hâlâ engelli” gibi bir sonuç ifadesi olarak yazın. Bir paydaş, detayları okumadan durumu anlamalıdır.
Scrum burada faydalı bir sınır sunar: Bir iş, Tanımlanmış Tamamlanma Kriterini karşılamadığı sürece bir Artırmanın parçası değildir. Tanımlanmış Tamamlanma Kriteri, tamamlanmış iş için gereken kalite durumu hakkında ortak bir anlayış yaratır. Bu, durum sunumunun “bitti”, “tamamlandı” veya “teslim edildi” gibi etiketlerde dikkatli olması gerektiği anlamına gelir.
Faydalı eylem: Önemli olduğunda üç durumu ayırın: “uygulandı”, “Tanımlanmış Tamamlanma Kriterini karşılıyor” ve “kullanıcılara sürüldü”. Bunlar farklı zamanlarda gerçekleşebilir. Bu, paydaşların “bitti” duyup özelliğin zaten canlıda olduğunu varsaymasını önler.
Kompakt bir tamamlanan iş slaytı üç sütun kullanabilir: Tamamlanmış Artırma, Kanıt ve Kullanıcı/İş Etkisi. Örneğin: “İade API entegrasyonu — otomatik sözleşme testleri geçti — sonraki pilot için manuel iade işlemini ortadan kaldırıyor.”
Tek bir zorunlu “Agile grafiği” yoktur. Scrum Rehberi, tahmin için faydalı olabilecek uygulamalar olarak burn-down, burn-up ve kümülatif akışlardan açıkça bahseder; bunlardan birini zorunlu kılmaz. Hız (Velocity) da zorunlu bir Scrum metriği olarak tanımlanmaz.
Faydalı eylem: Hedef kitlenin sorusunu yanıtlayan en küçük metrik setini seçin:
| Soru şu ise… | Göstermeyi düşünün… | Dikkat edilmesi gereken… |
|---|---|---|
| Sprint Hedefini bitirme ihtimalimiz var mı? | Sprint Hedefi kanıtı artı kalan iş veya burn-down | Grafiği bir performans hedefine dönüştürmek |
| Bu sürüm kapsamı ne zaman bitebilir? | Burn-up, iş hacmi geçmişi, tahmin aralığı | Tahmini garanti edilmiş bir tarih gibi sunmak |
| İş daha hızlı mı akıyor? | Döngü süresi veya iş hacmi trendi | Farklı iş öğelerini karşılaştırmak |
| Kalite iyileşiyor mu? | Sızan hatalar, olay trendi, kurtarma verileri, kabul kanıtları | Hikaye puanlarını kalite ölçütü olarak kullanmak |
| Değer kullanıcılara ulaşıyor mu? | Kullanım, benimseme, dönüşüm, görev başarısı, gelir veya diğer ürün sonuçları | Çıktı hacmini sonuçla eşitlemek |
Ölçene kadar bilinmeyen: Daha yüksek bir hız, tek başına ekibin daha verimli hale geldiğini veya daha fazla müşteri değeri sunduğunu kanıtlamaz. Hikaye puanı ölçekleri ekibe özgüdür, tahmin uygulamaları değişir ve iş karışımı değişir.
Faydalı eylem: Hızı gösterirken, bunu o ekip için bir planlama sinyali olarak etiketleyin ve paydaşların gerçekten önemsediği bir sonuçla eşleştirin.
Bir risk listesi, hedef kitleye ne olabileceğini ve hangi yanıtın gerektiğini söylediğinde faydalı hale gelir. “API sorunu” çok belirsizdir. “Sağlayıcı hız sınırı, 18 Eylül'e kadar yük testinin tamamlanmasını engelleyebilir; platform lideri önbellekleme test ediyor; sağlayıcı kota artışı talep edildi; yanıt yoksa Cuma gününe kadar yönetici yükseltmesi gerekiyor” ifadesi eylemi destekler.
Faydalı eylem: Her büyük riske beş alan verin: risk, etki, sahibi, hafifletme ve karar/tetikleyici tarihi. Sunumu, bir hedefi, tarihi, maliyeti, kapsamı, kalite seviyesini veya bağımlılığı değiştirebilecek risklerle sınırlayın.
Agile planların, daha fazla şey öğrenildikçe uyum sağlaması beklenir. Scrum Rehberi, Sprint Hedefi tehlikeye atılmadığı sürece kapsamın Sprint sırasında Ürün Sahibi ile netleştirilebileceğini ve yeniden müzakere edilebileceğini söyler. Bu nedenle, değişen bir plan otomatik olarak kötü icranın kanıtı değildir.
Faydalı eylem: Değişiklikleri açıkça belirtin. Kapsamı sessizce değiştirip paydaşların ne olduğunu tahmin etmesini bırakmak yerine, “Müşteri testi sonrası isteğe bağlı dışa aktarma formatı kaldırıldı; kapasite erişilebilirlik hatalarına kaydırıldı” yazın.
Slayttaki küçük bir karar günlüğü şunları içerebilir: tarih, karar, neden, sahibi ve sonuç. Bu, aynı sunumun çalışma oturumlarında bulunmayan yöneticiler tarafından incelendiğinde özellikle faydalıdır.
En güçlü kapanış slaytı, hedef kitleye ne olacağını ve bir şey yapmaları gerekip gerekmediğini söyler. Bir sonraki Sprint veya sürüm hedefini, bir ila üç yakın vadeli kilometre taşını ve gereken herhangi bir paydaş kararını dahil edin.
Faydalı eylem: Eyleme dönüştürülebilen bir cümleyle bitirin: “Ekim pilot penceresini korumak için 15 Eylül'e kadar ek test ortamını onaylayın.” Eğer paydaş eylemi gerekmiyorsa, bunu belirtin: “Yükseltme talep edilmiyor; ekip mevcut Sprint Hedefi doğrultusunda devam edecek.”
Hayır. Bu, korunması gereken en önemli ayrılıklardan biridir. Scrum Rehberi, Sprint İncelemesinin Sprint çıktısını incelemek, Ürün Hedefine doğru ilerlemeyi tartışmak, ortamdaki değişiklikleri göz önünde bulundurmak ve bundan sonra ne yapılacağı konusunda işbirliği yapmak için var olduğunu söyler. Sprint İncelemesini özellikle çalışan bir oturum olarak tanımlar ve Scrum Ekibinin bunu bir sunumla sınırlamaktan kaçınması gerektiğini belirtir.
Faydalı eylem: Kısa bir yönetim özeti değerli olduğunda durum sunumunu Sprint İncelemesinden önce veya sonra kullanın. İnceleme sırasında, slaytları yüksek sesle okumak yerine gerçek Artırmaya, paydaş tartışmasına, kanıtlara ve uyumlamaya öncelik verin.
Her ikisi de bu yapıyı destekleyebilir, ancak “şablon” PowerPoint'te belirli bir ürün anlamına gelir. Microsoft, yeniden kullanılabilir bir PowerPoint şablonunun .potx dosyası olarak kaydedilebileceğini ve bir slayt anası ve düzenleri içerebileceğini belgeler. Microsoft ayrıca, PowerPoint şablonu oluşturmanın web sürümü yerine masaüstü sürümünü gerektirdiğini belirtir. Microsoft'un resmi PowerPoint şablonu talimatlarına bakın.
Faydalı eylem: Organizasyonunuz masaüstü PowerPoint kullanıyorsa, tekrarlayan slayt yapılarını—yönetici özeti, risk tablosu, metrik paneli, karar günlüğü—Slayt Anası düzenlerine dönüştürün, ardından bitmiş tasarımı bir .potx dosyası olarak kaydedin.
Google, bir Slides şablonunu temaları, düzenleri, arka planları, yazı tiplerini, renkleri ve yer tutucu içeriği birleştirebilen önceden tasarlanmış bir koleksiyon olarak tanımlar. Google Slides ayrıca kullanıcıların düzenleri değiştirmesine ve tarayıcıda işbirliği içinde çalışmasına olanak tanır. Google'ın resmi Slides şablonu ve düzen belgelerine bakın.
Faydalı eylem: Gerçek zamanlı işbirliği yerel bir .potx dosyasından daha önemliyse, sekiz slaytlık yapıyı Google Slides'ta yeniden oluşturun, paylaşılan bir konumda temiz bir ana kopya tutun ve her raporlama dönemi için bunu çoğaltın.
Seciz slayt fazlaysa, bu yoğunlaştırılmış düzeni kullanın:
Faydalı eylem: Bir durum toplantısı, netleştirmesi gereken işten düzenli olarak daha uzun sürüyorsa, bir sonraki raporlama döngüsü için tek slaytlık versiyonu deneyin. Detayları bağlantılara veya ek slaytlara taşıyın ve canlı tartışmayı kararlar, riskler ve değişen varsayımlar üzerinde odaklı tutun.
Bir Agile proje durum raporunu yayınlamadan önce, her ifadeyi kaynağına karşı doğrulayın. Basit bir kontrol listesi yeterlidir:
İyi bir Agile durum sunumu, her şeyin yeşil olduğunu kanıtlamaya çalışmaz. Görevi, gerçeği incelenmesi kolay hale getirmektir: Ekibin hangi hedefi kovaladığı, gerçekte neyin tamamlandığı, hangi kanıtların mevcut olduğu, planı neyin değiştirebileceği ve sıradaki kararın ne olduğu. Bu ücretsiz şablonu başlangıç yapısı olarak kullanın, ardından hedef kitlenizin ilerlemeyi incelemesine veya daha iyi bir karar vermesine yardımcı olmayan herhangi bir slaytı kaldırın.
ABD serbest çalışma işleri için IRS uyumlu kategoriler, makbuz kayıtları, 2026 kilometre ücretleri ve vergi inceleme bayrakları içeren bir bağımsız yüklenici gider takip sistemi oluşturun.
Saat hesaplayıcı, gece vardiyası formülleri, haftalık toplamlar, kalite kontrolleri ve net sınırlar içeren ücretsiz bir Excel çalışan vardiya programı oluşturun.
Tablolar, açılır listeler, takip uyarıları ve basit bir satış hunisi özeti içeren pratik bir Excel potansiyel müşteri takipçisi oluşturun; ayrıca bir CRM'e geçme zamanının geldiğine dair net işaretler.
Servis geçmişi, son tarihler, duruş süreleri, maliyetler, denetim kayıtları ve net güvenlik sınırları içeren atölye varlıkları için pratik bir Excel ekipman bakım kaydı oluşturun.
LM Studio ile Windows 11'de DeepSeek'i yerel olarak çalıştırın. Normal bir PC için uygun modeli öğrenin, indirip yükleyin, çevrimdışı kullanımı doğrulayın ve yaygın sorunları giderin.
Dört pratik istem sıkıştırma tekniği, önbellek dostu düzenler, yapılandırılmış çıktılar ve kalite koruyucu bir değerlendirme planı ile LLM API maliyetlerini düşürün.
Yapılandırılmış çıktıları, inceleme kapılarını ve gerçekçi API maliyet rehberliğini içeren, kendi sunucunuzda barındırılan n8n ve Claude ile ücretsiz barındırılabilir bir AI içerik dönüştürme hattı kurun.
Zaman çizelgeleri, tedarikçi takibi, tahmini ve gerçek maliyetler, ödemeler ve etkinlik günü görevleri içeren, Word için pratik bir yazdırılabilir etkinlik planlama kontrol listesi ve bütçe şablonu kullanın.
Yerel AI sohbeti ve kasa farkındalıklı PKM için Ollama'yı Obsidian'a bağlayın. Kurulum, kalite kontrolleri, yerel gömme işlemleri, gizlilik sınırları ve modellerin ne zaman değiştirileceğini öğrenin.
AI ajanları, web araması, kanıta dayalı değişiklik tespiti, GitHub Actions zamanlaması ve insan incelemesi ile haftalık rakip izleme iş akışını oluşturun.
