Ken Schwaber & Jeff Sutherland

Scrum Kılavuzu
Scrum’ın Tanımlayıcı Kılavuzu: Oyunun Kuralları

Kasım 2020

Scrum Kılavuzunun Amacı
Scrum’ı 1990'ların başında geliştirdik. Scrum Kılavuzu’nun ilk sürümünü, dünya genelindeki insanların
Scrum’ı anlamalarına yardımcı olmak için 2010 yılında yazdık. Kılavuzu o zamandan beri küçük, işlevsel
güncellemelerle geliştirdik ve arkasındayız.
Scrum Kılavuzu, Scrum’ın tanımını içerir. Çerçevenin her bir öğesi, Scrum ile gerçekleştirilen tüm değer vesonuçlar için gerekli olan belirli bir amaca hizmet eder. Scrum’ın temel tasarımını veya fikirlerinideğiştirmek, öğeleri dışarıda bırakmak veya Scrum kurallarına uymamak, sorunları örter ve Scrum’ın
faydalarını sınırlar, hatta potansiyel olarak yararsız hale getirir.
Sürekli büyüyen karmaşık bir dünyada Scrum'ın artan kullanımını takip ediyoruz. Scrum'ın köklerininolduğu yazılım ürünü geliştirmenin ötesinde, temelde karmaşık işler barındıran birçok alanda Scrum'ın
benimsendiğini görmekten onur duyuyoruz. Scrum’ın kullanımı yaygınlaştıkça geliştiriciler, araştırmacılar,analistler, bilim adamları ve diğer uzmanlar işi yapar. Scrum’da "developers" (geliştiriciler) kelimesini
belirli bir rolü adresleyerek diğerlerini dışlamak için değil, sadeleştirerek daha kapsayıcı hale getirmek içinkullanıyoruz. Scrum’dan bir değer elde ediyorsanız, kendinizi Developers içinde düşünebilirsiniz.
Scrum kullanılırken, bu dokümanda tanımlanan Scrum çerçevesine uyan kalıplar, süreçler ve iç görüler
bulunabilir, uygulanabilir ve tasarlanabilir. Bunların tanımları, Scrum Kılavuzu’nun amacının dışındadırçünkü bağlama göre değişebilir ve Scrum’ın kullanımları arasında büyük farklılıklar gösterir. Scrumçerçevesi içinde kullanılmaya yönelik bu tür taktikler çok çeşitlidir ve başka yerlerde tanımlanmaktadır. .

Ken Schwaber & Jeff Sutherland, Kasım 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share‐Alike license of Creative Commons,accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share‐Alike license of Creative Commons.

1

Scrum Kılavuzunun Amacı

1

Scrum Tanımı

3

Scrum Teorisi

3Şeffaflık

3

Gözlem4

Adaptasyon

4

Scrum Değerleri

4

Scrum Team

4

Developers

5

Product Owner

5

Scrum Master6

Scrum Etkinlikleri

7

Sprint7

Sprint Planning

8

Daily Scrum

9

Sprint Review

9

Sprint Retrospective

9

Scrum Eserleri

10

Product Backlog
Taahhüt: Ürün Hedefi

10
10

Sprint Backlog
Taahhüt: Sprint Hedefi

11
11Increment
Taahhüt: Bitti Tanımı

11
12

Son Not
Takdir ve TeşekkürKişiler
Scrum Kılavuzu TarihçesiÇeviri Teşekkür
2017 Scrum Kılavuzu ile 2020 Scrum Kılavuzu Arasındaki Değişiklikler

13
13
13
13
13
14

2

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.

3

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ünkabul edilemez ise, uygulanan süreç veya üretilmekte olan şeyler düzeltilmelidir. Düzeltme daha fazlasapmaya 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. Budeğ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.

4

Scrum Teamler çapraz fonksiyoneldir, yani üyeler her Sprint'te değer yaratmak için gerekli tüm becerileresahiptir. 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ünHedefi’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çinorganizasyon 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 çıkarmaktansorumludur. 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;5

●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ı ProductBacklog'a yansıtabilir. Product Backlog'u değiştirmek isteyenler bunu Product Owner'ı ikna etmeyeçalışarak yapabilirler.

Scrum MasterScrum 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ınayardı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:

6

●
●
●
●

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çinkullanılır. İdealde, tüm etkinlikler karmaşıklığı azaltmak için hep aynı yer ve zamanda düzenlenir.

SprintSprintler, 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’niyakalamak 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 halegelebilir, 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ısabir 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

7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şkisinitartış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 dahakı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.

8

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ırve 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. Dahakı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ıranvarsayı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.

9

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. Dahakı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çinaynı 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çinmevcuttur.

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 Planningetkinliğ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çalaraayırma ve detaylandırma aktivitesidir. Bu, açıklama, sıra ve büyüklük gibi detaylar eklemek içingerç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

10

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, bunubaş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.

11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 Teamvarsa, bunlar karşılıklı olarak aynı Bitti Tanımı’nı tanımlamalı ve bunlara uymalıdır.

12

Son Not
Scrum ücretsizdir ve bu Kılavuz'da sunulmaktadır. Scrum çerçevesi, burada ana hatlarıyla belirtildiği
gibidir, değiştirilemez. Scrum'ın yalnızca bazı kısımlarını uygulamak her ne kadar mümkün olsa da, sonuç
Scrum değildir. Scrum sadece bir bütün olarak vardır ve diğer teknikler, metodolojiler ve pratikler için iyi
bir hazne görevi görür.

Takdir ve TeşekkürKişiler
Scrum’a katkıda bulunan binlerce insan arasında, Scrum’ın başlangıçta yardımı dokunanları özellikle
saymalıyız. En başta Jeff McKenna ve John Scumniotales ile çalışan Jeff Sutherland ve Mike Smith ve Chris
Martin ile çalışan Ken Schwaber vardı. Ve bu kişilerin tamamı birlikte çalıştılar. Sonraki yıllarda çok dahafazla insan katkı sağladı. Onların yardımı olmasa Scrum bugünkü hâline ulaşamazdı.

Scrum Kılavuzu Tarihçesi
Ken Schwaber ve Jeff Sutherland, Scrum'ı ilk olarak 1995'te OOPSLA Konferansı'nda birlikte tanıttılar. Bu
sunum, esasen Ken ve Jeff’in önceki yıllarda Scrum'ı uygulayarak edindikleri birikimin bir belgesidir.
Scrum'ın ilk herkese açık resmi tanımı da bu sunum ile gerçekleşti.
Scrum Kılavuzu, Jeff Sutherland ve Ken Schwaber’ın 30 yılı aşkın süredir geliştirdiği, evrimleştirdiği ve
koruduğu Scrum’ı belgeler. Diğer kaynaklar size Scrum çerçevesini dolduracak davranış kalıpları, süreçler
ve iç görüler sunar. Bunlar üretkenliği, değeri, yaratıcılığı ve sonuç memnuniyetini artırabilir.
Scrum’ın eksiksiz tarihçesi başka kaynaklarda anlatılmaktadır. Denendiği ve geliştiği ilk yerler olarak
Individual Inc., Newspage, Fidelity Investments ve IDX’i (şu an GE Medical) saymak gerekir.

Çeviri Teşekkür
Scrum Kılavuzu 2020 versiyonu çevirisi Agile Turkey takımını temsilen Barış Bal, Erdem Kılınç, Fatma
Tartar Doğanay, Melike Ak Şahin tarafından yapılmış, Scrum.org Professional Scrum Eğitmeni (PST)
Tolga Kombak tarafından gözden geçirilmiştir.
Çeviri esnasında, Scrum Kılavuzu Çeviri Rehberi’ne sadık kalınarak bazı terimler Türkçe’ye çevrilmedenolduğu gibi kullanılmış, metin içinde bu terimlerde kullanılan ekler, Türkçe dilbilgisi ve yazım kurallarınaen uygun halde yazılmıştır. Bu terimler şunlardır: Scrum, Sprint, Sprint Planning, Daily Scrum, Sprint
Review, Sprint Retrospective, Scrum Team, Scrum Master, Product Owner, Developers, Product Backlog,
Sprint Backlog, Increment.
Bu terimlerin Türkçe karşılığı Kavram Sözlüğü bölümünde bulunabilir. Çeviri ile ilgili soru, yorum ve geri
bildirimleriniz için info@agileturkey.org adresi üzerinden Agile Turkey takımı ile iletişime geçebilirsiniz.

13

2017 Scrum Kılavuzu ile 2020 Scrum Kılavuzu ArasındakiDeğişiklikler
Daha Az Tarifleyici
Yıllar geçtikçe, Scrum Kılavuzu biraz daha tarifleyici olmaya başladı. 2020 versiyonu, tarifleyici dili kaldırarak veya
yumuşatarak Scrum’ı minimum düzeyde yeterli bir çerçeve haline getirmeyi amaçladı. Örneğin Daily Scrum soruları
kaldırıldı, Product Backlog maddeleri detayları ve özellikleri ile ilgili dil yumuşatıldı, Sprint Backlog’daki iyileştirmemaddeleri ile ilgili dil yumuşatıldı, Sprint iptal etme bölümü kısaltıldı ve bunun gibi başka değişiklikler yapıldı.

Tek Ürüne Odaklı, Tek Takım
Amacımız, PO ve Dev Team arasında “vekil” veya “biz ve onlar” davranışına yol açan, bir takım içinde ayrı bir takım
kavramını ortadan kaldırmaktı. Artık PO, SM ve Developers olarak üç farklı sorumluluk grubu ile aynı hedefe
odaklanan sadece bir Scrum Team var.

Ürün Hedefi’nin Takdimi
2020 Scrum Kılavuzu, Scrum Team’e daha büyük ve değerli bir hedefe odaklanmak için Ürün Hedefi kavramını sunar.
Her Sprint, ürünü genel Ürün Hedefi’ne yaklaştırmalıdır.

Sprint Hedefi, Bitti Tanımı ve Ürün Hedefi için AdresÖnceki Scrum Kılavuzları, Sprint Hedef’i ve Bitti Tanımı’nı onlara gerçekten bir kimlik vermeden tanımladı. Tam olarakeser değillerdi, ancak bir şekilde eserlere bağlıydılar. Ürün Hedefi’nin eklenmesiyle, 2020 versiyonu bu konuda dahafazla netlik sağlıyor. Üç eserin her biri artık onlara yönelik “taahhütler” içeriyor. Product Backlog için Ürün Hedefi,
Sprint Backlog için Sprint Hedefi, Increment için Bitti Tanımı (artık tırnak içine almadan). Bu taahhütler, her bir esereşeffaflık getirmek ve her bir eserin ilerlemesine odaklanmak için var.

Kendi Kendine Organize Olmak Yerine Kendi Kendini YönetmekÖnceki Scrum Kılavuzları, Geliştirme Takımlarından kendi kendine organize olan, yani kimin çalışacağını ve nasılçalışacağını belirleyen takımlar olarak bahsediyordu. Scrum Team’e daha çok odaklanan 2020 versiyonu, kiminçalışacağını, nasıl çalışılacağını ve ne üzerinde çalışılacağını seçen kendi kendini yöneten bir Scrum Team’i vurguluyor.

Sprint Planning’in Üç Konusu
2020 Scrum Kılavuzu, “Ne” ve “Nasıl” gibi Sprint Planning konularına ek olarak, Sprint Hedefi’ne atıfta bulunanüçüncü bir konu olan “Neden”e vurgu yapmaktadır.

Daha Geniş Kitleler için Genel Dil Basitleştirmesi
2020 Scrum Kılavuzu, BT işlerine yönelik olan çıkarımları (örneğin test etme, sistem, tasarım, gereksinim vb.) ortadan
kaldırmanın yanı sıra, gereksiz ve karmaşık ifadeleri elemeye de odaklanmıştır. Artık, Scrum Kılavuzu 13 sayfadan az.

14

Kavram Sözlüğü
Türkçeİngilizce

Adaptasyon

Adaptation

Artımlı

IncrementalAşağı‐tüketim

Burn‐down

Bitti Tanımı

Definition of DoneBüyüklük

SizeÇapraz fonksiyonlu

Cross‐functionalÇerçeve

Framework

Değer

Value

Deneysellik

Empiricism

Deneysel süreç kontrol

Empirical process control

Engel

Impediment

Eser

Artifact

EtkinlikEventGeliştiriciler

Developers

GözlemInspection

Günlük Scrum

Daily Scrum

Hazır

Ready

İşlevsellik

Functionality

Yinelemeli

Iterative

Kendini yönetme

Self‐managing

Kümülatif akışCumulative flow

Paydaş

Stakeholder

Scrum Kılavuzu

Scrum Guide

15

Sprint

SprintSprint Değerlendirme

Sprint Review

Sprint Hedefi

Sprint Goal

Sprint İş Listesi

Sprint Backlog

Sprint Planlama

Sprint Planning

Sprint Retrospektifi

Sprint RetrospectiveŞeffaflık

TransparencyÜrün İş Listesi

Product Backlog

Ürün İş Listesi Maddesi

Product Backlog ItemÜrün İş Listesini İyileştirme

Product Backlog RefinementÜrün Parçası

IncrementÜrün Sahibi

Product OwnerÜrün Hedefi

Product Goal

Scrum MasterScrum Master

Taahhüt

Commitment

Bitti

Done

Kullanıma alma

ReleaseYukarı‐tüketim

Burn‐up

Zaman sınırı

Time‐box

16