Scrum Guide

Scrum Tanımı

Scrum, insanların, takımların ve organizasyonların karmaşık problemler için adapte edilebilir çözümler aracılığıyla değer üretmesine yardımcı olan basit bir çerçevedir. Kısaca,

1. Bir Product Owner’ın karmaşık bir sorun için Product Backlog’daki işleri sıraladığı,
2. Scrum Team’in, seçilen işleri Sprint boyunca bir değer Increment’ine çevirdiği,
3. Scrum Team ve paydaşların sonuçları inceleyip ve bir sonraki Sprint için düzeltme yaptığı,
4. Ve bunları tekrarladığı

bir ortamı yaşatmak için bir Scrum Master gereklidir.

Scrum basittir. Olduğu gibi deneyin ve felsefesinin, teorisinin ve yapısının hedeflere ulaşmaya ve değer yaratmaya yardımcı olup olmadığını belirleyin. Scrum çerçevesi bilinçli olarak eksik bırakılmıştır, yalnızca Scrum teorisini uygulamak için gerekli kısımlar tanımlanmıştır. Scrum, onu kullanan insanların ortak zekası üzerine inşa edilmiştir. Scrum'ın kuralları insanlara ayrıntılı yönergeler vermek yerine onların ilişkilerine ve etkileşimlerine rehberlik eder.

Çerçeve dahilinde çeşitli süreçler, teknikler ve yöntemler kullanılabilir. Scrum, mevcut uygulamaları toparlar veya bazılarını gereksiz görüp dışarıda bırakır. Scrum, mevcut yönetimin, ortamın ve çalışma tekniklerinin göreceli etkililiğini görünür kılar. Bu sayede iyileştirmeler yapılabilir.

Scrum Teorisi

Scrum, deneysellik ve yalın düşünce üzerine kurulmuştur. Deneysellik, bilginin deneyimden ve gözleme dayalı karar vermekten geldiğini ileri sürer. Yalın düşünce israfı azaltır ve temel unsurlara odaklanır.

Scrum, öngörülebilirliği en iyi seviyeye çıkarmak ve riski kontrol etmek için yinelemeli (iterative) ve artımlı (incremental) bir yaklaşım kullanır. Scrum, işi yapmak ve gerekli becerileri paylaşmak veya edinmek için toplam olarak tüm becerilere ve uzmanlığa sahip insan gruplarını bir araya getirir.

Scrum, kapsayıcı bir etkinlik olan Sprint içinde gözlem ve adaptasyon için 4 resmi etkinliği bir araya getirir. Bu etkinlikler, Scrum’ın deneyselliğinin taşıyıcı kolonları olan şeffaflık, gözlem ve adaptasyonu uyguladığı için işe yarar.

Şeffaflık

Ortaya çıkan süreç ve iş, işi yapanların yanı sıra işten yararlananlara da görünür olmalıdır. Scrum’da önemli kararlar, Scrum’ın üç önemli eserinin algılanan durumuna dayanır. Düşük şeffaflığa sahip eserler, değeri azaltan ve riski artıran kararlara yol açabilir.

Şeffaflık gözlemi mümkün kılar. Şeffaflık olmadığı durumda yapılan gözlem yanıltıcıdır ve israfa yol açar.

Gözlem

Scrum eserleri ve üzerinde anlaşılan hedeflere yönelik ilerleme, potansiyel olarak istenmeyen sapmalar veya sorunları tespit etmek için sık sık ve özenle incelenmelidir. Gözleme yardımcı olmak için, Scrum, önerdiği beş etkinliği ile bir ritim oluşturur.

Gözlem adaptasyonu mümkün kılar. Adaptasyon olmadan yapılan gözlem anlamsız kabul edilir. Scrum etkinlikleri değişimi körüklemek için tasarlanmıştır.

Adaptasyon

Bir sürecin herhangi bir yönü, kabul edilebilir sınırların dışına çıkarsa veya sürecin sonunda çıkan ürün kabul edilemez ise, uygulanan süreç veya üretilmekte olan şeyler düzeltilmelidir. Düzeltme daha fazla sapmaya izin vermeden mümkün olan en yakın kısa sürede yapılmalıdır.

İlgili kişiler yetkilendirilmediğinde veya kendi kendini yönetmediğinde adaptasyon daha zor hale gelir. Bir Scrum Team’in gözlem aracılığıyla yeni bir şey öğrendiği anda adapte olması beklenir.

Scrum Değerleri

Scrum’ın başarıyla uygulanması insanların aşağıdaki beş değeri ustalıkla yaşatma becerisine bağlıdır: Taahhüt, Odak, Açıklık, Saygı ve Cesaret

Scrum Team, hedeflerine ulaşmayı ve birbirini desteklemeyi taahhüt eder. Scrum Team’in birincil odak noktası, hedeflerine doğru mümkün olan en iyi ilerlemeyi sağlamak için o Sprint'te aldıkları işlerdir. Scrum Team ve paydaşları yapılacak işler ve bu işleri yaparken karşılaşılan zorluklar hakkında açıktır. Scrum Team’in her bir üyesi diğer üyelere yetkin ve bağımsız insanlar olarak saygı duyar ve çalıştıkları insanlar tarafından da bu şekilde saygı görür. Scrum Team’in üyeleri, doğru olanı yapma, zor problemler üzerinde çalışma cesaretine sahiptir.

Bu değerler Scrum Team’e çalışmaları, eylemleri ve davranışları ile ilgili yön verir. Alınan kararlar, atılan adımlar ve Scrum'ın kullanılma biçimi bu değerleri azaltmamalı veya zayıflatmamalı, güçlendirmelidir. Scrum Team üyeleri, Scrum etkinlikleri ve eserleri ile çalışırken bu değerleri öğrenir ve keşfeder. Bu değerler Scrum Takımı ve birlikte çalıştıkları kişiler tarafından içselleştirildiğinde, Scrum’ın deneyselliğinin taşıyıcı kolonları olan şeffaflık, gözlem ve adaptasyon canlanarak herkes için güven oluşturur.

Scrum Team

Scrum Team, Scrum'ın küçük bir gruptan oluşan en temel birimidir. Scrum Team, bir Scrum Master, bir Product Owner ve Developers'dan oluşur. Scrum Team'de alt takımlar veya hiyerarşiler yoktur. Her seferinde tek bir hedefe, Ürün Hedefi’ne (Product Goal) odaklanan kaynaşmış profesyonellerden oluşan bir birimdir.

Scrum Teamler çapraz fonksiyoneldir, yani üyeler her Sprint'te değer yaratmak için gerekli tüm becerilere sahiptir. Aynı zamanda kendi kendilerini yönetirler, yani kimin neyi, ne zaman ve nasıl yapacağına kendileri karar verirler.

Scrum Team, hızlı davranabilecek kadar küçük ve bir Sprint içinde anlamlı bir işi tamamlayacak kadar büyüktür, tipik olarak 10 veya daha az kişidir. Genel olarak, daha küçük takımların daha iyi iletişim kurduğunu ve daha üretken olduğunu gördük. Scrum Teamler çok büyürse, her biri aynı ürüne odaklanan birden fazla kaynaşmış Scrum Team olarak yeniden düzenlenmeyi düşünmelidirler. Bu nedenle, aynı Ürün Hedefi’ni, Product Backlog'u ve Product Owner'ı paylaşmaları gerekir.

Scrum Team, paydaşlarla iş birliği, doğrulama, bakım, çalıştırma, deney, araştırma ve geliştirme ve gerekli olabilecek diğer şeyler gibi ürünle ilgili tüm faaliyetlerden sorumludur. Kendi işlerini yönetmek için organizasyon tarafından kurulan ve yetkilendirilen takımlardır. Sprintler halinde sürdürülebilir bir hızda çalışmak Scrum Team'in odaklanmasını ve tutarlılığını geliştirir.

Tüm Scrum Team, her Sprint'te değerli ve faydalı bir Increment oluşturmaktan sorumludur. Scrum, Scrum Team içinde üç özel sorumluluk tanımlar: Developers, Product Owner ve Scrum Master.

Developers

Developers, Scrum Team'de her Sprint'te kullanılabilir bir Increment'in herhangi bir kısmını oluşturmayı taahhüt etmiş kişilerdir.

Developers’ın ihtiyaç duyduğu belirli beceriler genellikle geniştir ve çalışma alanına göre değişiklik gösterir.

Bununla birlikte aşağıdaki sorumluluklar her zaman Developers’tadır:

• Sprint Backlog, yani Sprint için bir plan oluşturmak;
• Bir Bitti Tanımı’na bağlı kalarak kaliteyi aşılamak;
• Planlarını her gün Sprint Hedefi’ne göre adapte etmek;
• Birbirlerini profesyoneller olarak sorumlu tutmak.

Product Owner

Product Owner, Scrum Team'in çalışması sonucu oluşan ürünün değerini en üst seviyeye çıkarmaktan sorumludur. Bunun nasıl yapılacağı ise organizasyonlar, Scrum Teamler ve bireyler arasında farklılık gösterebilir.

Product Owner, aynı zamanda Product Backlog'u etkili bir şekilde yönetmekle sorumludur, şunları içerir:

• Ürün Hedefi'ni oluşturmak ve açıkça iletişimini yapmak;
• Product Backlog maddelerini oluşturmak ve açıkça iletişimini yapmak;
• Product Backlog maddelerini sıralamak;
• Product Backlog'un görünür, şeffaf ve anlaşılır olmasını sağlamak

Product Owner, yukarıdaki işleri kendisi yapabilir veya bu yükümlülüğü başkalarına devredebilir. Ancak sorumluluk her zaman Product Owner’dadır.

Product Owner'ın başarılı olabilmesi için kararlarının organizasyondaki herkesten saygı görmesi esastır. Product Owner'ın kararları, Product Backlog'un içeriği, sıralaması ve Sprint Review'da sunulan gözlemlenebilir Increment aracılığıyla görünürdür.

Product Owner bir kişidir; bir komite olamaz. Product Owner, birçok paydaşın ihtiyaçlarını Product Backlog'a yansıtabilir. Product Backlog'u değiştirmek isteyenler bunu Product Owner'ı ikna etmeye çalışarak yapabilirler.

Scrum Master

Scrum Master, Scrum Kılavuzu’nda tanımlandığı gibi Scrum'ın benimsenmesinden sorumludur. Bunu hem Scrum Team hem de organizasyon içindeki herkesin Scrum teorisini ve pratiklerini anlamasına yardımcı olarak yapar.

Scrum Master, Scrum Team’in etkililiğinden sorumludur. Bunu, Scrum Team’in pratiklerini Scrum çerçevesi dahilinde iyileştirmesini sağlayarak yaparlar.

Scrum Masterlar, Scrum Team’e ve organizasyonun bütününe hizmet eden gerçek liderlerdir.

Scrum Master, Scrum Team’e aşağıdaki hususları içerecek şekilde farklı yollarla hizmet eder:

• Takım üyelerine kendini yönetme ve çapraz fonksiyonluluk konularında koçluk yapmak;
• Scrum Team'in Bitti Tanımı’na uyan yüksek değerli Incrementler oluşturmaya odaklanmasına yardımcı olmak;
• Scrum Team’in ilerlemesinin önündeki engellerin kaldırılmasını sağlamak ve,
• Tüm Scrum etkinliklerinin gerçekleşmesini ve bunların pozitif, üretken olmasını ve zaman sınırları içinde tutulmasını sağlamak.

Scrum Master, Product Owner’a aşağıdaki hususları içerecek şekilde farklı yollarla hizmet eder:

• Etkili Ürün Hedefi tanımı ve Product Backlog yönetimi için teknikler bulmaya yardımcı olmak;
• Scrum Team'in anlaşılır ve kısa Product Backlog maddelerine olan ihtiyacı anlamasına yardımcı olmak;
• Karmaşık bir ortamda deneysel ürün planlaması yapmaya yardımcı olmak ve,
• İstenildiğinde veya gerektiğinde paydaş iş birliğini kolaylaştırmak.

Scrum Master, organizasyona aşağıdaki hususları içerecek şekilde farklı yollarla hizmet eder:

• Organizasyona Scrum'ın benimsenmesinde liderlik etmek, koçluk yapmak ve organizasyonu eğitmek;
• Organizasyon içinde Scrum uygulamalarını tavsiye etmek ve planlamak;
• Çalışanların ve paydaşların karmaşık işler için deneysel bir yaklaşımı anlamasına ve uygulamaya koymasına yardımcı olmak ve,
• Paydaşlar ve Scrum Teamler arasındaki bariyerleri kaldırmak.

Scrum Etkinlikleri

Sprint, diğer tüm etkinlikleri içinde barındıran bir etkinliktir. Scrum’daki her etkinlik Scrum eserleri üzerinde gözlem ve adaptasyon yapmak için resmî birer fırsattır. Bu etkinlikler, gerekli olan şeffaflığı mümkün kılmak için özel olarak tasarlanmıştır. Bu etkinliklerin herhangi birini bile işletmede başarısız olmak, gözlem ve adaptasyon için fırsatların kaybedilmesine neden olur. Scrum’da kullanılan etkinlikler, düzenlilik sağlamak ve Scrum’da tanımlı olmayan toplantı ihtiyacını asgari seviyeye düşürmek için kullanılır. İdealde, tüm etkinlikler karmaşıklığı azaltmak için hep aynı yer ve zamanda düzenlenir.

Sprint

Sprintler, fikirlerin değere dönüştürüldüğü Scrum’ın kalp atışı olan etkinliklerdir.

Tutarlılık yaratmak üzere Sprintler sabit sürelidir, bu süre bir ay ya da daha az olabilir. Önceki Sprint biter bitmez yeni Sprint başlar.

Sprint Planning, Daily Scrumlar, Sprint Review ve Sprint Retrospective de dahil olmak üzere Ürün Hedefi’ni yakalamak için gerekli olan tüm işler, Sprintler içinde gerçekleşir.

Sprint boyunca:

• Sprint Hedefi’ni tehlikeye sokacak hiçbir değişiklik yapılmaz;
• Kalite hedefleri düşmez;
• Product Backlog gerektikçe iyileştirilir (refinement); ve
• Daha fazla bilgi edindikçe Product Owner ile kapsam netleştirilebilir ve yeniden müzakere edilebilir.

Sprintler, en azından her takvim ayında bir, Ürün Hedefine doğru ilerleyişi gözlemlemeyi ve adapte etmeyi temin ederek öngörülebilirliği mümkün kılar. Sprintin süresi çok uzun olursa Sprint Hedefi geçersiz hale gelebilir, karmaşıklık ve risk artabilir. Daha fazla öğrenim döngüsü elde etmek, maliyet riskini ve eforunu daha kısa bir zaman dilimiyle limitlemek amacıyla daha kısa süreli Sprintler kullanılabilir. Her Sprint’e kısa bir proje gözüyle bakılabilir.

İlerleyişi öngörmek için aşağı‐tüketim (burn‐down), yukarı‐tüketim (burn‐up) veya kümülatif akış (cumulative flow) gibi çeşitli pratikler bulunmaktadır. Bu pratiklerin faydası kanıtlanmış olsa da bunlar deneyselliğin öneminin yerine geçemezler. Karmaşık ortamlarda, ne olacağı bilinemez. Sadece geçmişte ne olduğu bilgisi ileriye dönük kararlar almada kullanılabilir.

Bir Sprint, Sprint Hedefi anlamını kaybettiğinde iptal edilebilir. Sadece Product Owner Sprint’i iptal etme yetkisine sahiptir.

Sprint Planning

Sprint Planning, o Sprint içinde yapılacak işin planlandığı, Sprint’i başlatan aktivitedir. Bu plan, tüm Scrum Team’in iş birliği ile hazırlanır.

Product Owner, katılımcıların en önemli Product Backlog maddelerini ve onların Ürün Hedefi ile ilişkisini tartışmaya hazırlanmış olarak geldiğinden emin olur. Scrum Team, tavsiye alabilmek amacıyla Sprint Planning’e başka kişileri de davet edebilir.

Sprint Planning şu konuları adresler:

Birinci Konu: Bu Sprint Neden Değerlidir?

Product Owner, ürünün değeri ve kullanılabilirliğinin bu Sprint’te nasıl artırılabileceğine ilişkin önerilerini sunar. Devamında tüm Scrum Team iş birliği içerisinde bu Sprint’in paydaşlar için neden değerli olduğunu ifade eden bir Sprint Hedefi oluştururlar. Sprint Hedefi, Sprint Planlama bitmeden önce kesinleşmelidir.

İkinci Konu: Bu Sprint’te ne tamamlanabilir?

Developers, Product Owner ile görüşerek Product Backlog’dan bu Sprint’e dahil edebilecekleri maddeleri seçer. Scrum Team, bu sırada anlaşılırlığı ve netliği artırmak için bu maddelerde iyileştirmeler yapabilir (refinement).

Bir Sprint’te ne kadar iş tamamlanabileceğini belirlemek zorlayıcı olabilir. Fakat Developers, geçmiş performansı, mevcut kapasitesi ve Bitti Tanımı hakkında daha fazla bilgiye sahip oldukça Sprint tahminlemeleri konusunda daha emin hale gelecektir.

Üçüncü Konu: Seçilen iş nasıl yapılacak?

Bitti Tanımı’na uygun bir Increment yaratabilmek için, Developers seçilen her bir Product Backlog maddesi için yapılması gereken işi planlar. Bunu yaparken Product Backlog maddeleri çoğu zaman bir gün veya daha kısa sürecek parçalara bölünür. Bunun nasıl yapılacağı yalnız Developers’ın takdirine kalmıştır. Hiç kimse, Developers’a Product Backlog’u değer yaratacak Incrementlere nasıl dönüştüreceğini söyleyemez.

Sprint Hedefi, Sprint’e seçilen Product Backlog maddeleri ve bu maddeleri teslim etme planı hep birlikte Sprint Backlog olarak anılır.

Sprint Planning, bir aylık Sprint için maksimum 8 saatle sınırlıdır. Daha kısa Sprintler için, etkinlik genellikle daha kısadır.

Daily Scrum

Daily Scrum’ın amacı Sprint Hedefi’ne doğru ilerlemeyi gözden geçirmek ve planlanmış işleri gereken şekilde düzenleyerek Sprint Backlog’da adaptasyon yapmaktır.

Daily Scrum, Scrum Team’deki Developers için olan 15 dakikalık bir etkinliktir. Karmaşıklığı azaltmak için Sprint boyunca her çalışma gününde aynı yer ve zamanda düzenlenir. Eğer Product Owner veya Scrum Master, Sprint Backlog üzerindeki maddeler üzerinde aktif olarak çalışıyorlarsa onlar da Developers olarak dahil olurlar.

Daily Scrum Sprint Hedefi’ne doğru ilerleyişe odaklandığı ve önlerindeki gün için hayata geçirilebilecek bir plan üretebildiği sürece, Developers bu etkinlik için istediği yapı ve tekniği seçebilir. Bu, odaklanma yaratır ve kendi kendini yönetmeyi geliştirir.

Daily Scrumlar iletişimi geliştirir, engelleri saptar, hızlı karar almayı geliştirir ve sonuç olarak başka toplantılara olan ihtiyacı ortadan kaldırır.

Daily Scrum, Developers’a planlarını güncellemesi için izin verilen tek zaman dilimi değildir. Genellikle, planlarını uyarlamak ya da Sprint’in geri kalanını yeniden planlamak üzere gün içerisinde daha detaylı görüşmeler için bir araya gelebilirler.

Sprint Review

Sprint Review’ın amacı Sprint’in çıktısını gözden geçirmek ve gelecek adaptasyonları belirlemektir. Scrum Team yaptıkları işin sonuçlarını tüm paydaşlara sunar ve Ürün Hedefi’ne doğru ilerleme durumu görüşülür.

Bu etkinlik sırasında Scrum Team ve paydaşlar bu Sprint’te yapılanları ve ortamlarında nelerin değiştiğini gözden geçirir. Bu bilgiye dayanarak katılımcılar, sonraki adımda ne yapılacağı üzerinde birlikte çalışırlar. Product Backlog da yeni fırsatları karşılayabilecek şekilde uyarlanabilir. Sprint Review bir çalışma seansıdır ve Scrum Team bunu bir sunuma indirgemekten kaçınmalıdır.

Sprint Review, Sprint’teki sondan ikinci etkinliktir ve bir aylık Sprint için maksimum 4 saat ile sınırlıdır. Daha kısa Sprintler için, etkinlik genellikle daha kısadır.

Sprint Retrospective

Sprint Retrospective’in amacı kaliteyi ve etkililiği artırmanın yollarını planlamaktır.

Scrum Team geçen Sprint’i, bireyler, etkileşimler, süreçler, araçlar ve Bitti Tanımı açısından gözden geçirir. Gözden geçirilen unsurlar genellikle çalışma alanına göre değişir. Scrum Team’i hedeflerinden saptıran varsayımlar tespit edilir ve bunların kökenine inilir. Scrum Team bu Sprint’te nelerin iyi gittiğini, ne tip problemlerle karşılaştıklarını ve bu problemleri nasıl çözdüklerini (ya da çözemediklerini) tartışır.

Scrum Team, etkililiğini geliştirmesi için en çok yardımcı olacak değişiklikleri belirler. En çok etki yaratacak iyileştirmeler en kısa sürede hayata geçirilir. Hatta bu iyileştirmeler gelecek Sprint’in Sprint Backlog’una bile eklenebilir.

Sprint, Sprint Retrospective ile birlikte sona erer. Bir aylık Sprint için maksimum 3 saat ile sınırlıdır. Daha kısa Sprintler için, etkinlik genellikle daha kısadır.

Scrum Eserleri

Scrum’ın eserleri yapılan işi ya da üretilen değeri temsil eder. Kilit bilgilerin şeffaflığını en üst seviyeye yükseltecek şekilde tasarlanmıştır. Bu sayede onları gözden geçiren herkes, adaptasyon yapabilmek için aynı temele sahip olacaktır.

Her bir eser, ilerlemeyi ölçmek, şeffaflığı ve odaklanmayı artırdığından emin olmak için birer taahhüt içerir:

• Product Backlog için bu, Ürün Hedefi’dir.
• Sprint Backlog için bu, Sprint Hedefi’dir.
• Increment için bu, Bitti Tanımı’dır.

Bu taahhütler, Scrum Team ve paydaşlar için deneyselliği ve Scrum değerlerini güçlendirmek için mevcuttur.

Product Backlog

Product Backlog, ürünü geliştirmek için nelere ihtiyaç duyulduğunun sıralı ve yaşayan bir listesidir. Scrum takımı tarafından üstlenilen işlerin tek kaynağıdır.

Scrum Team tarafından bir Sprint içinde bitirilebilecek Product Backlog maddeleri, Sprint Planning etkinliğinde seçilmeye hazır kabul edilir. Genellikle iyileştirme aktiviteleri sonrasında bu derecede şeffaflık elde ederler. Product Backlog iyileştirme, Product Backlog maddelerini daha küçük, daha kesin parçalara ayırma ve detaylandırma aktivitesidir. Bu, açıklama, sıra ve büyüklük gibi detaylar eklemek için gerçekleştirilen sürekli bir aktivitedir. Bu bileşenler genellikle çalışma alanına göre değişkenlik gösterir.

İşi yapacak olan Developers işlerin büyüklüğünü belirlemekten sorumludur. Product Owner, detaylarda nelerin yapılıp nelerden vazgeçilebileceğini anlamalarına yardımcı olarak Developers’ı etkileyebilir.

Taahhüt: Ürün Hedefi

Ürün Hedefi, Scrum Team’in ulaşmayı planladığı, ürünün gelecekteki bir durumunu tanımlayan hedef olarak Scrum Team’e hizmet eder. Ürün Hedefi, Product Backlog içerisinde yer alır. Product Backlog’un geri kalanı, Ürün Hedefi’ni yerine getirmek için gerekli “ne” yapılacağını tanımlamak için ihtiyaç oldukça şekillenir.

Ürün, değer teslimatı için bir araçtır. Net bir sınırı, bilinen paydaşları, iyi tanımlanmış kullanıcıları veya müşterileri vardır. Ürün, bir hizmet, fiziksel bir ürün veya daha soyut bir şey olabilir.

Ürün Hedefi, Scrum Team için uzun vadeli hedeftir. Scrum Team’in, bir sonraki hedefe yönelmeden önce, mevcut hedefi yerine getirmesi (veya terk etmesi) gerekir.

Sprint Backlog

Sprint Backlog, Sprint Hedefi (neden), Sprint için seçilen Product Backlog maddeleri (ne) ve Increment’i ortaya çıkarabilmek için eyleme geçirilebilir bir plandan (nasıl) oluşur.

Sprint Backlog, Developers tarafından, Developers için hazırlanan bir plandır. Sprint Hedefi’ne ulaşmak için Developers’ın Sprint sırasında başarmayı planladıkları işin son derece görünür, gerçek zamanlı bir resmidir. Sonuç olarak Sprint Backlog, daha fazla bilgi edindikçe Sprint boyunca güncellenir. Daily Scrum’da Developers’ın ilerlemeyi gözlemleyebilmesi için yeterli ayrıntıya sahip olmalıdır.

Taahhüt: Sprint Hedefi

Sprint Hedefi, Sprint için tek hedeftir. Sprint Goal, Developers’ın bir taahhüdü olmasına rağmen, bunu başarmak için gereken iş açısından esneklik sağlar. Sprint Hedefi, ayrıca kaynaşma ve odaklanma yaratarak, Scrum Team’i ayrı inisiyatifler yerine birlikte çalışmaya teşvik eder.

Sprint Hedefi, Sprint Planning etkinliği sırasında yaratılır ve ardından Sprint Backlog’a eklenir. Developers Sprint sırasında çalışırken, Sprint Hedefi’ni akıllarında tutarlar. İşler beklenenden farklı çıkarsa, Sprint Hedefi’ni etkilemeden Sprint Backlog’un kapsamını müzakere etmek için Product Owner ile iş birliği yaparlar.

Increment

Increment, Product Hedefi’ne doğru atılan somut bir adımdır. Her Increment, önceki Incrementlerin üzerine eklenir ve tüm Incrementlerin birlikte çalışmalarını temin edecek şekilde tamamen doğrulanır. Değer sağlamak için Increment kullanılabilir olmalıdır.

Bir Sprint içinde birden fazla Increment oluşturulabilir. Incrementlerin toplamı Sprint Review'da sunularak deneysellik desteklenir. Ancak bir Increment Sprint sona ermeden önce de paydaşlara teslim edilebilir. Sprint Review değerin teslim edilebilmesi için bir mekanizma gibi görülmemelidir.

Bitti Tanımı’na uymadığı sürece yapılan iş Increment’in parçası olarak kabul edilemez.

Taahhüt: Bitti Tanımı

Bitti Tanımı, Increment’in ürün için gerekli kalite gereksinimlerini sağladığı halinin resmi bir tanımıdır.

Bir Product Backlog maddesi Bitti Tanımı'nı karşıladığı anda Increment doğar.

Bitti Tanımı, Increment’in parçası olarak hangi işlerin tamamlandığına dair herkes için ortak bir anlayış sağlayarak şeffaflık yaratır. Bir Product Backlog maddesi Bitti Tanımı’nı karşılamıyorsa, kullanıma alınamaz ve hatta Sprint Review’da sunulamaz. Bunun yerine, ileride değerlendirilmek üzere Product Backlog’a geri döner.

Bir Increment için Bitti Tanımı organizasyonun standartlarının bir parçasıysa, tüm Scrum Teamleri asgari olarak buna uymalıdır. Organizasyonel bir standart değilse, Scrum Team ürüne uygun bir Bitti Tanımı oluşturmalıdır.

Developers’ın Bitti Tanımı'na uyması gerekir. Bir ürün üzerinde birlikte çalışan birden fazla Scrum Team varsa, bunlar karşılıklı olarak aynı Bitti Tanımı’nı tanımlamalı ve bunlara uymalıdır.

Kavram Sözlüğü

Kaynak:

https://scrumguides.org/download.html