Tag: Proje Yönetimi

Çevik Ekiplerde Bilgi Panolarının Kullanımının Temel Faydası

Giriş

Günümüz iş dünyası giderek daha çevik (Agile) ve sanal hale geliyor. Özellikle yazılım ve teknoloji sektörlerinde, coğrafi olarak dağınık ekiplerin projelerde iş birliği yapması artık oldukça yaygın. Bu yeni yapıda, bilgi akışının kesintisiz olması, projelerin şeffaf bir şekilde yönetilmesi ve sürekli iyileşme kültürünün geliştirilmesi her zamankinden daha kritik hale gelmiştir. Çevik ortamlarda bu ihtiyaçlara cevap veren en etkili araçlardan biri de bilgi panolarıdır (information radiators). Bu panolar, görünürlüğü ve iletişimi artırarak ekip verimliliğine doğrudan katkı sağlar.

Bu yazıda, bilgi panolarının ne olduğu, çevik sanal ekiplerde nasıl kullanıldıkları ve özellikle şeffaflık, kritik bilgilere hızlı erişim ve sürekli iyileştirme açısından temel faydaları ele alınacaktır.

Bilgi Panosu Nedir?

“Information Radiator” terimi, Alistair Cockburn tarafından ortaya atılmıştır ve projeyle ilgili bilgilerin herkesin kolayca erişebileceği şekilde açık bir şekilde gösterildiği her türlü görsel sunumu ifade eder. Fiziksel olarak bir arada çalışan ekiplerde bu, duvardaki bir Kanban panosu olabilirken; sanal ekiplerde genellikle dijital panolar, görev yönetim yazılımları ya da bulut tabanlı proje takip araçları şeklinde olur.

Bir bilgi panosunda genellikle şu içerikler yer alır:

  • Sprint ilerlemesi (örneğin burndown grafikleri)
  • Mevcut engeller
  • Görev durumları (Yapılacaklar, Devam Edenler, Tamamlananlar)
  • Ekip kapasitesi ve hızı (velocity)
  • Geri bildirimler ve kullanıcı hikayeleri

Neden Bilgi Panosu Kullanılır?

Çevik metodolojide bilgiye gerçek zamanlı erişim ve şeffaflık temel değerlerdir. Scrum ya da Kanban gibi çerçevelerde ekiplerin kendi kendini organize etmesi beklenir ve bu ancak bilgiye erişimin mümkün olmasıyla gerçekleşebilir. Bilgi panoları, görünürlük ve netlik sağlayarak bu ihtiyacı karşılar.

Sanal ekiplerde yüz yüze iletişim eksikliği, bilgi eşitsizliğine yol açabilir. Yani bazı ekip üyeleri önemli bilgilere zamanında ulaşamazken, bazıları daha güncel verilere sahip olabilir. Bu dengesizlik ekip verimliliğini düşürür. Bilgi panoları, hayati öneme sahip gerçek zamanlı bilgileri tüm ekip üyelerine eşit şekilde sunarak bu sorunu çözer.

Temel Faydası: Şeffaflığı Artırmak ve Kritik Bilgilere Hızlı Erişim Sağlamak

1. Güven ve Açıklık Kültürü Oluşturur

Güven, çevik ekiplerin temel yapı taşlarından biridir. Proje ilerleyişinin, görev dağılımının ve engellerin herkes tarafından görülebilir olması, şeffaflığı ve karşılıklı sorumluluğu teşvik eder. Hiçbir bilgi saklı kalmaz — her şey açıkça paylaşılır.

2. Kendi Kendini Yöneten Ekipleri Güçlendirir

Çevik ekiplerin işi planlaması ve uygulaması kendi inisiyatiflerine bırakılır. Bu otonomi, doğru bilgiye doğru zamanda erişim gerektirir. Bilgi panoları, ekiplerin yönetici onayı beklemeden karar alabilmesini sağlar.

3. Günlük Stand-up Toplantılarını Tamamlayıcıdır

Bazıları bilgi panolarının günlük stand-up toplantılarının yerine geçtiğini düşünebilir; fakat bu bir yanılgıdır. Bu araçlar, bilgi paylaşımı ihtiyacını ortadan kaldırarak toplantıların koordinasyon, problem çözme ve karar alma odaklı olmasına katkıda bulunur.

4. Geri Bildirim Yoluyla Sürekli İyileştirmeyi Destekler

Çevik yaklaşımın temel değerlerinden biri sürekli iyileşmedir. Bilgi panoları, ekiplerin sprint retrospektiflerinde gerçek verilere dayanarak eğilimleri analiz etmelerini sağlar (örneğin sık tekrarlanan engeller ya da görevlerdeki gecikmeler gibi).

Sanal Ekiplerde Bilgi Panosu Kullanımı: Zorluklar ve Çözümler

Sanal ekiplerde bilgi panosu kullanımı bazı özel zorluklar içerir. Ancak bu zorluklar uygun uygulamalarla aşılabilir.

Yaygın Zorluklar:

  • Farklı zaman dilimlerinde çalışılması, güncellemelerin eş zamanlı olmasını zorlaştırabilir.
  • Dijital araçlarda teknik sınırlamalar veya uyumsuzluklar yaşanabilir.
  • Çok karmaşık panolar, bilgi netliği sağlamaktan ziyade bilgi karmaşasına yol açabilir.

Önerilen Çözümler:

  • Bilgi panoları basit, görsel ve sezgisel olmalıdır.
  • Her sprintin başında panonun güncellenmesinden sorumlu kişiler net şekilde belirlenmelidir.
  • Pano kullanımı, kısa ve düzenli check-in toplantılarıyla desteklenmelidir.
  • Erişilebilirlik ön planda tutulmalı, pano tüm cihaz ve platformlardan görüntülenebilir olmalıdır.

Araçlar ve En İyi Uygulamalar

Sanal bilgi panoları için yaygın olarak kullanılan dijital araçlar şunlardır:

  • Jira + Confluence
  • Trello
  • Azure DevOps Boards
  • Monday.com
  • ClickUp

Bilgi panolarında sık kullanılan bileşenler:

  • Burndown ve Burnup Grafikler
  • Kümülatif Akış Diyagramları
  • Sprint Backlog Görünümleri
  • Engel Takip Panoları

En iyi uygulamalar şunları içerir:

  • Entegrasyonlarla otomatik güncellemeler sağlayarak gerçek zamanlı veri akışı oluşturmak
  • Panodaki verileri düzenli olarak retrospektif toplantılarda analiz etmek
  • Ekip geri bildirimleriyle bilgi panosunu sürekli geliştirmek

Sonuç

Çevik sanal ekiplerde bilgi panolarının en büyük katkısı, şeffaflığı artırmaları, önemli verilere hızlı erişim sağlamaları ve güven, otonomi ve sürekli iyileştirme kültürünü teşvik etmeleridir.

Bilgi panoları sadece birer proje izleme aracı değildir; aynı zamanda ekip kültürünün dijital yansımasıdır. Doğru kullanıldıklarında, ekip performansını ve proje başarısını stratejik olarak destekleyen araçlara dönüşürler.

Çevik dünyada başarı, yalnızca çerçeveleri uygulamakla değil, aynı zamanda bilgi panoları gibi araçları etkili bir şekilde kullanmakla mümkündür. Tamamen uzaktan çalışan ekipler bile, bu güçlü görselleştirme araçları sayesinde şeffaf, uyumlu ve yanıt verebilir bir kültür oluşturabilir.

PMI® Onaylı – Proje Yönetimi Uzmanlığı Sertifika Programı

Eğitim Tarihleri: 13 – 15 – 20 – 22 – 27 – 29 Mayıs – 12 – 17 – 19 – 24 – 26 Haziran – 1 Temmuz 2025Salı ve Perşembe / 19:30 – 22:30 (Akşam Programı/Zoom)

Eğitim Tarihleri: 24 – 25 – 31 Mayıs – 1 – 14 – 15 – 21 – 22 – 28 Haziran 2025Cumartesi ve Pazar / 09:30 – 13:30 (Zoom)

Scrum for Project Managers E-Book (PDF) 1.0

Are you tired of managing projects that seem to drag on forever? Do you feel like you’re constantly putting out fires instead of making real progress? It’s time to try a new approach.

Introducing Scrum for Project Managers, the e-book that will revolutionize the way you approach project management. Our comprehensive guide will teach you everything you need to know about Scrum, an agile project management framework that has been proven to increase productivity, improve communication, and deliver results.

In this e-book, you’ll learn the basics of Scrum, including how to create and manage a product backlog, how to conduct sprint planning and review meetings, and how to effectively communicate with your team. You’ll also discover advanced techniques for improving team collaboration, managing stakeholder expectations, and delivering high-quality products on time and within budget.

Whether you’re a seasoned project manager or just starting out, Scrum for Project Managers is the must-have resource for anyone looking to improve their project management skills. And with our easy-to-read format and practical advice, you’ll be able to start implementing Scrum in your projects right away.

Chapter 1- Scrum Approach

  • The Agile Manifesto and the Birth of Scrum. 10
  • Overview of Scrum Framework 12
  • Scrum Artifacts 14
  • Organizational Goals in Scrum 16
  • What is the Backlog? 19

Chapter 2 – Product Backlog

  • Product Backlog in Scrum 23
  • An Example of Scrum Practice 25
  • User Stories 27
  • Refining and Estimating Product Backlog 30

Chapter 3 – Sprint Backlog

  • Sprint Backlog 35
  • Sprint Scope and Sprint Goal 37

Chapter 4 – Definition of Done

  • Increment and Definition of Done 42
  • More Details of “Definition of Done” 45
  • When should the DoD be Prepared? 48
  • Definition of Done vs. Acceptance Criteria 50

Chapter 5- Scrum Events

  • What are Scrum Events? 53
  • What is a Time Box? 55
  • More Details About The Sprint 57
  • Sprint Planning Event 59
  • Why is the Sprint Valuable? 61
  • What can be Done in the Sprint? 63
  • How will Things Be Done in the Sprint? 66
  • Who Attends the Sprint Planning Meeting? 68
  • Coherency of Sprint Backlog Items 70
  • Daily Scrum 72
  • Sprint Review Meeting 74
  • Sprint Retrospective Meeting 76
  • Understanding Epics 80
  • Special Sprints 83
  • Canceling a Sprint 85

Chapter 6 – The Scrum Team

  • Scrum Team 88
  • Scrum Team Size 90
  • Product Owner 92
  • What is Value 94
  • How is the Product Backlog Ordered? 96
  • The Developers 98
  • The Scrum Master 100
  • How does the Scrum Master serve to the Scrum Team 102
  • What is an Impediment in Scrum? 104
  • How does the Scrum Master serve to the Product Owner? 106
  • How does the Scrum Master serve to the Organization 108
  • Other Titles in Scrum 110

Chapter 7 – Scaling Scrum

  • Introduction To Scaling Scrum 115
  • What happens when multiple Scrum Teams work on the same Product? 117
  • Impact on velocity when scaling Scrum 118
  • Integrated Product Increments 120
  • The Definition of Done when multiple teams work on the same Product 122
  • Must the Sprints be aligned? (same length, same start/end) 124
  • How many Product Owners are there? 126
  • Feature teams vs Component teams 128
  • The importance of creating an integrated Increment 130

Chapter 8 – Terms and Tools Used in Scrum

  • The Velocity of the Scrum Team 134
  • Technical debt 136
  • Functional and non-functional requirements 138
  • The process of emergence in Scrum 140
  • Burn-down charts 142
  • Burn-up charts 144
  • The “cone of uncertainty” 146

Chapter 9 – Agile Framework and Practices

  • Agile Framework Overview 150
  • Kanban 152
  • Extreme Programming (XP) 155
  • Test-driven development (TDD) 157
  • Behavior-driven development (BDD) 159
  • DevOps 161

Chapter 10 – FAQ about Scrum

  • Is Documentation Mandatory in Scrum? 165
  • What happens with incomplete Sprint Backlog items? 167
  • Who creates the Definition of Done? 168
  • How to change scope without affecting the Sprint Goal? 170
  • What happens if there is no Increment and/or the Sprint Goal is not reached? 171
  • The difference between Product Backlog Refinement and Sprint Planning 173
  • What is the difference between creating an Increment and Releasing it? 175

About The Author

Gökrem Tekir graduated from Anadolu University in 1997 as an Industrial Engineer.

He worked as a project engineer in different companies in the production and service sector. He earned the PMP Certificate in 2004.

After receiving the PMP Certificate, he continued his career as a Project Management Trainer and Consultant.

Among the trainings he gave, there are topics such as Fundamentals of Project Management, Agile Project Management, Scrum Approach, Project Planning and Follow-up with Microsoft Project, PMP Exam Preparation.

The consultancy services offered by Gökrem Tekir are the Establishment and Integration of Project Management Offices, Microsoft Project Server and Sharepoint Integration, Development of Enterprise-Specific Project Management Methods, Planning and Reporting of Projects Between Buyer and Sellers, Creation and Follow-up of Project Plans of Institutions, Projects of Employees. It is listed as Adapting to Management Methods.

Gökrem Tekir is the author of the first Turkish-language Project Management book in 2006. In 2017, a much more comprehensive work titled “Our Life is the Project – Project Manager’s Handbook” was also published.

Gökrem Tekir continues to share information on social networks such as Youtube, Linkedin, Twitter and Instagram in order to spread his knowledge on project management.

https://buy.stripe.com/6oE4jv5Fo8K7fNC5kx

  • Download link will be active after payment site.
  • When the new version is published, it will be sent to the email of the buyer.

Buy on ETSY.com

Buy on Kindle

17- Zaman Kutusu Nedir?

Scrum’da, zaman kutusu bir etkinliğin maksimum süresini ifade eder.

Örneğin, sprint planlama toplantısını ele alalım. Bu etkinlik, bir aylık sprint için 8 saate kadar zamanlanmış bir kutudur.

Scrum takımı, sprinti planlamak için tam olarak 8 saati kullanabilir. Eğer Scrum takımı toplantının amacına 6 saatte ulaşabilirse, bu çok daha iyi bir şeydir.

Hedeflenen sonuca ulaşılır ulaşılmaz sprint planalama etkinliği sona erer. Bekleyerek zaman kaybetmek için hiçbir sebep yoktur. Scrum, zaman ve kaynak israfını azaltmayı hedefler.

Scrum ekibinin zaman kutusunu aşmasına izin verilmez. Scrum ustası, Scrum Takımına zaman kutularının neden önemli olduğu ve zamanlarının nasıl daha iyi yönetileceği konusunda koçluk yapmalıdır.

Zaman kutuları neden önemlidir? Bunu bir örnekle açıklamaya çalışalım. Kısa süreliğine şehir dışına yolculuğa çıkacağınızı varsayın. 1 veya 2 gün için yapacağınız yolculuk için, hazırlık sürenizi düşünün. 1 günlük yolculuk için yanınıza alacağınız çanta küçüktür ve onu hazırlamak için yarım saat yeterli olacaktır. Buna karşılık, 1 haftalık şehir dışı yolculuğu için, bir valiz hazırlarken daha fazla zaman ayırırsınız. Çok daha uzun yolculuklar içinse bir kaç valiz hazırlamanız gerekeceğinden, hazırlık süreniz daha fazla olacaktır.

Zaman kutuları böyle çalışır. Ne kadar uzak geleceği planlamanız gerekiyorsa, ayırmanız gereken zaman da artar. Buna karşılık, planlamayla fazla zaman kaybedip, işlerin ilerlemesine de engel olmamanız gerekir. Örneğin, valizleri hazırlamaya gereğinden fazla zaman ayırırsanız, bu sefer de uçağı kaçırırsınız.

Scrum’da farklı etkinlikler için zaman kutularının olduğunu ileriki videolarımızda göreceğiz.

Özetlemek gerekirse, bir zaman kutusu bir etkinliğin minimum süresini değil, maksimum süresini ifade eder.

Her türlü etkinlik, etkinliğin amacına ulaşıldığı sürece, zaman kutusu sona ermeden sonlandırılabilir. Fakat, etkinliğin zaman kutusunu aşmasına izin verilmez.

Bu durum, sprintin kendisi hariç, tüm etkinlikler için geçerlidir. Sprint, özel bir durumdur. Planlanan işi, sprintin süresi bitmeden tamamlasanız bile, sprint daha erken bitmez. Bunun sebebi, oluşturmaya çalıştığımız rutinin bozulmasını engellemektir. Fazladan zamanınız kalmışsa eğer, ürün birikim listesinden daha fazla iş alıp, sprinte devam edersiniz. Ancak bu durum, çok nadiren görülür.

14- “Tamamlandının Tanımı” Ne Zaman Hazırlanır?

Scrum Takımı, Tamamlandının Tanımını ne zaman hazırlamalıdır? Scrum Kılavuzu bununla ilgili herhangi bir bilgi vermez, sadece bunun var olması gerektiğini ifade eder.

Bunun nedeni, Scrum’ın bir çerçeve olmasıdır. Adım adım ne yapmanız gerektiğini açıklayan bir metodoloji değildir.

Peki, bu durumda, Tamamlandının Tanımı ne zaman oluşturulmalıdır? Cevap, ne zaman isterseniz.

Çoğu zaman, insanlar her şeyin Scrum etkinliklerinden birinde olması gerektiğini düşünür ve bu doğru değildir.

Scrum Takımı, kendi içinde belirsizlikleri giderecek şekilde farklı toplantılar yapabilir. Bu, Scrum tarafından yasaklanmış değildir.

Scrum Takımının, ilk Sprint başlamadan önce Tamamlandının Tanımının ilk versiyonunu hazırlanmasında hiçbir sakınca yoktur. İlk hali, mükemmel veya nihai olmak zorunda değildir.

Zamanla ihtiyaçlar şekillendikçe veya kalite sorunları yaşandıkça, tamamlandının tanımı da gelişir. Özellikle, Retrospektif toplantılarında ekip deneyimlerini paylaşarak, Tamamlandının Tanımını iyileştirmek için önerilerde bulunabilirler.

Pratik açıdan bakıldığında, zorunlu olmadıkça, sprintin ortasında Tamamlandının Tanımını değiştirmek çok tercih edilen bir yöntem değildir. Bunu bir oyunun kurallarını oyun başladıktan sonra değiştirmek gibi düşünebilirsiniz. Kurallar, oyun başlamadan önce belirlenir. Eğer istenmeyen bir sonuç ile karşılaşılırsa, kurallar, oyun tekrar başlamadan önce oyuncular tarafından konuşulur, anlaşmaya varılır ve oyun ondan sonra başlar.

Tamamlandının Tanımını Sprint’in ortasında değiştirmek tahmin değerlerini ve tamamlandığı düşünülen işleri olumsuz etkileyebilir.

Video için Youtube kanalımı ziyaret edebilirsiniz.

Eğitimlerimiz için İstanbul Kurumsal Gelişim’in Web Sitesini Ziyaret Edebilirsiniz.

Youtube Üzerindeki Videolu Eğitimleri Buradan İnceleyebilirsiniz.

UDEMY Eğitimlerim

13- “Tamamlandının Tanımı” Kavramına Detaylı Bakış

Bu derste, tamamlandının tanımı ifadesine biraz daha detaylı göz atacağız. Bir önceki videomuzda “Başlangıç Sayfası Oluşturma” öğesi için kabul kriterlerini tanımlamıştık.

Burada gördüğünüz ifadeler ise “Başlangıç Sayfası Oluşturma” adlı ürün birikim öğesi için daha detaylı hazırlanmış ve kriterleri gösteren bir örnektir. Yazılanların doğruluğu veya detay seviyesi önemli değildir. Bu örnek, yazılımla ilgili olduğu için, ekranda göreceğiniz ifadeler, bazılarınız için anlamsız olabilir. Bu ifadelerin sadece bir örnek olduğunu dersimiz boyunca unutmayınız.

Öncelikle, tamamlandının tanımı bir kontrol listesi gibi görünse de, Scrum literatürü içinde kontrol listesi ifadesi kullanılmaz. Bu durumu, doktorların veya avukatların kullandığı özel kelimeler gibi düşünebilirsiniz. Her disiplinin kendine özel kavramlarının olması normaldir. Önemli olan bu kavram yapısını bilmek ve diğer meslektaşlarla aynı dili konuşabilmektir.

Konumuza dönersek; bir ürün birikim öğesinin tamamlanmış olarak kabul edilmesi için aşağıdaki kriterlere uyması gerektiği gözükmektedir.

Bu listede ilk maddeye baktığımızda “Kabul Kriterlerinde belirtilen şartların sağlanması” ifadesi gözükmektedir. Bir önceki dersimizde, bu maddeler hakkında örnekler paylaşmıştık. Bu kriterler, genellikle ürünün nasıl gözükeceğini içeren özelliklerdir. Kabul kriterlerinin neler olduğunu görmek için 12.video olan Artırım ve Tamamlandının Tanımı adlı videoyu izlemenizi tavsiye ederiz.

Şu an ekranımızda ise ürünün etkin çalışabilmesi için uyulması gereken farklı kriterlerden de bahsedilmiştir. Bu kriterler, ürün sahibinin bilemeyeceği kriterler olabilir. Bu yüzden, bu kriterler, Scrum takımı tarafından hazırlanır.

Örneğin, hazırlanan kodun, uzman bir geliştirici tarafından gözden geçirilmesi kriteri, daha sonra oluşabilecek kusurları engelleyebilir ve deneyimsiz olan geliştirme ekibinin yeni şeyler öğrenmesini sağlayabilir.

Teknik dokümanın hazırlanmış olması ifadesi, ilgili sayfanın bilgi akışı veya süreç akışını gösteren içerikler olabilir. Bu bilgiler, baştan belgelenmediği takdirde, ve sistemin zamanla büyümesi durumunda, sistemin kontrolü imkansız hâle gelebilir.

Birim testinin geçmesi, hazırlanan fonksiyonun doğru çalışıp, çalışmadığını test etmek ve onaylamak iken, kabul testinden geçmek sistemin bir bütün olarak kabul edilebilir olmasıyla ilgili testlerdir.

Sistemin farklı web tarayıcıları üzerinden test edilmesi ve o tarayıcılarda da sorunsuz çalışması bir başka kriter olarak gözükmektedir. Benzer bir değerlendirme, mobil cihazlar için uygulanabilir. Oluşturduğumuz giriş sayfasının farklı cep telefonlarının ekranlarında nasıl gözüktüğü bir kabul kriteri olabilir.

Bütün bunlara ek olarak fonksiyonel olmayan gereksinimler altında performans, uygunluk ve güvenlik gibi kriterler tanımlanabilir ve üretilen birikim öğesinin bu kriterleri de sağlayıp, sağlamadığı denetlenmiş olur.

Bütün bu kriterlerin olumlu sonuç vermesi halinde, ilgili birikim öğesi “tamamlandı” olarak kabul edilmiş olacaktır.

Müşteri veya ürün sahibi, Sprint içinde geçen süreyi ve harcanan eforu sadece istenen ürünü üretmek olarak düşünmemelidir. Karmaşık bir projede, burada örnek olarak gözüken kabul kriterlerinin sayısı onlarca olabilir. Bu yüzden, Scrum ekipleri, ortaya çıkaracakları ürün birikim öğesinin bu kriterlere uyup uymadığını test etmek zorundadır. Bir projede, ekipleri acele ettirmek, diğer ifadeyle, az zamanda çok fazla şeyi talep etmek ve ekibe baskı kurmak, kalite kriterlerinin yeterince sağlanmadan ürünün teslim edilmesine sebep olur. Bu da, ortaya çıkan ürünün kalite sorunları yaşamasına, ve ekibin düzeltmeler yapmak için tekrar tekrar ürün üzerinde çalışmasına, neden olur.

12- Artırım ve Tamamlandının Tanımı

Artırım, ürünün yeni bir sürümüdür ve önceki tüm sprintlerden gelen artırımlara eklenir.

Bunu, tamamlanmış önceki tüm işlerin üzerine yerleştirilmiş bir yapı taşı gibi görebilirsiniz.

Geliştiriciler, her sprintte en az bir adet yeni ürün artırımı sağlamak için çalışır.

Her yeni artırım, ürünün geliştirilmiş ve kullanılabilir bir sürümüdür.

Artırımın, müşterinin kullanımına sunulma zamanına, yani yayınlanmasına, sadece ürün sahibi karar verir. Bununla birlikte, artırımın kendisi, test etme, belgeleme ve hatta diğer Scrum ekiplerinin yaptığı işlerle entegre etme gibi, herhangi bir ek çalışmaya ihtiyaç duymayacak şekilde, kullanılabilir olmalıdır.

Bir ürün birikim öğesi tamamlanmış olarak kabul edildiğinde, herkes tamamlanmış ifadesinin ne anlama geldiğini anlamalıdır.

Çoğunlukla “tamamlanmış” ifadesi için kalite yönetiminden bildiğimiz kabul kriterleri referans alınır.

Eğer 7. videoda başlattığımız örnekte, ilk ürün birikim öğemiz “Başlangıç sayfası oluşturmaktı. Sonraki bir videomuzda bu öğe için kullanıcı hikayesi yazmıştık. Bir başka videomuzda ise kabul kriterlerini tanımlamıştık.

  • Kurumun logosu sayfada gözükmeli.
  • Marketin bina görseli sayfad gözükmeli.
  • Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.

Yine bir başka videomuzda, ekibin yönlendirmesiyle, ürün sahibi, kabul kriterlerinin içine şu iki maddeyi eklemişti.

Logo dijital olarak çizilmiş olmalıdır.

Binanın fotoğrafları profesyonel olarak çekilmiş olmalıdır.

Tam bu noktada lütfen dikkat. Kabul kriterleri hiç bir zaman subjektif ifadeler içeremez. Dikkat ederseniz, “Profesyonel fotoğraf çekimi” ifadesi bile yoruma açıktır. Bu yüzden, çekilecek fotoğrafların çözünürlüğü sayısal verilerle ifade edilmelidir. Amaç, çıkan sonucun ki bu örnekte çekilen fotoğrafların çözünürlüğü, yoruma açık olmaksızın, test edilebilir ve doğrulanabilir olmalıdır.

Her sprint, kalite planlamayı ve kalite kontrolü kendi içinde barındırır. Scrum ekibi, sprint sonlarında yapacakları retrospektif toplantısında öğrendikleri derslerden yola çıkarak, kaliteyi sürekli artırmanın yollarını arayacaklardır.