Scrum Ürün Yönetimi: Kapsamlı Rehber + Örnekler

Scrum, ürün yönetimi alanında yeni bir şey değil. Çoğumuz şirketlerimizde Scrum kullanıyor ve hedeflerimize ulaşmak için bu çerçevenin rollerini ve ilkelerini anlamaya çalışıyoruz.

Ne yazık ki şirketlerin Scrum'ın ilkelerini yanlış yorumlaması ve bunları hatalı kullanması yaygın bir durumdur; bu da kullanıcıların Scrum'ın sunduğu birçok faydayı elde etmesini engeller.

Bu nedenle bu sevimli küçük rehber, Scrum'ın ne olduğunu, neden farklı Scrum rolleri bulunduğunu, ürün yönetimi sorumluluklarının neler olduğunu ve işlevler arası iş birliğinde nasıl başarılı olunacağını açıklayarak bu çerçeveyi daha iyi kullanmanıza yardımcı olmayı amaçlıyor.

Ürün Yönetiminde Scrum Nedir?

Birçoğumuz, Scrum süreçleri ve Çevik metodoloji bağlamında ürün yöneticisinin rolünü tartışmayı seviyoruz (başka bir deyişle, PM'nin bir Scrum ekibinde ne yaptığı konusunu). Bunu yalnızca açıklamak yerine, PM'nin ekip organizasyon şemasında nerede bulunduğunu göstermeninin daha kolay olduğunu düşünüyorum.

Ancak bu rehberde konuya ters yönden yaklaşmak ve Scrum'ın bir ürün yönetimi profesyoneli olarak gerçekliğinize nasıl uyduğunu ve ürün hedeflerinize ulaşmanıza nasıl yardımcı olabileceğini göstermek istiyorum.

İşe, Scrum çerçevesinin temel ilkelerinin çalışmalarımızın etkililiği üzerindeki etkisini tartışarak başlamak istiyorum.

Yazarın Notu

Bu ilkelerle ilgili bilgilerinizi tazelemeniz gerekiyorsa, Agile Alliance’ın harika bir rehberi size yardımcı olabilir.

Muhtemelen bizim için en değerli Scrum ilkesi, kullanıcılara sürekli değer sunmaktır. İnsanlar sorunları ne kadar hızlı çözebilirse ürününüz de o kadar iyi performans gösterir. Ayrıca özelliği gerçek hayattaki bir senaryoda kullanmış kişilerden erken geri bildirim alma fırsatınız olur.

Scrum'ın sunduğu ikinci avantaj esnekliktir. Pazar koşulları değişirse ürün iş listenizi tamamen yenileyerek ve yeni özellikleri bir sonraki sprintte ekibinize devrederek bu değişime hızla uyum sağlayabilirsiniz (bu konuda sprint planlamasında yapay zekâ yardımcı olabilir).

Bu iki şeyi, kapsamın tamamen sabit olduğu ve kullanıcıların ürüne ancak SDLC'nin en sonunda erişebildiği Waterfall gibi geleneksel çerçevelerle yapmak çok zordur (hatta neredeyse imkânsızdır).

Scrum Entegrasyonu Sayesinde Başarılı Olan Ürünlere Örnekler

Yıllarca Scrum ekipleriyle çalıştığım için bu Çevik çerçeveye karşı tamamen taraflıyım. Bu yüzden söylediklerimi mutlak doğru kabul etmeyin. Bunun yerine Scrum'a geçişin ürün ekiplerinin daha hızlı başarılı olmasına yardımcı olduğu gerçek hayat örneklerine bakalım.

Microsoft Visual Studio: Teknoloji devinin ana kod düzenleme aracı, hatalı sürümler ve inanılmaz derecede seyrek yayınlarla sonuçlanan, üretim cehenneminin tekrar eden döngüleriyle kötü bir üne sahipti. Ürün ekibi Scrum'dan yararlanmaya başladığı andan itibaren şirket, çok daha sık yayın döngülerinin yanı sıra ürün kararlılığında da belirgin bir artış gördü ve pazardaki rekabet gücünü yeniden kazandı.

Spotify: Sevdiğimiz müzik yayın hizmetinin Scrum'ı benimsemesi, sektördeki en ünlü örneklerden biridir. Spotify, Scrum'ı benimseyene kadar süreçle ilgili zorluklarını çözmek için yeterince hızlı uyum sağlamakta ve ölçeklenmekte zorlandı. Ancak Spotify'ı farklı kılan şey, hızlı bir şekilde denemeler yapabilen ve kullanıcı geri bildirimlerini dâhil edebilen, ihtiyaç duydukları tüm uzmanlığa erişimi olan bir grup özerk Çevik ekipten oluşan kendi Scrum proje yönetimi modelini geliştirmiş olmasıdır.

ING: Hollandalı bankacılık devi, bankacılığın geleceğinin dijital olduğunu fark eden ilk finans kuruluşları arasındaydı. Ayrıca son derece geleneksel proje yönetimi süreçlerinin yazılım geliştirme için uygun olmadığını da fark ettiler. Bu nedenle yalın ve Scrum metodolojilerini hızla benimsediler ve şaşırtıcı olmayan bir şekilde elektronik bankacılıkta lider konuma geldiler.

Scrum Ürün Yönetimindeki Temel Roller

Bir PM olarak Scrum'ın izlenecek yol olduğuna karar verirseniz, burada bu çerçevedeki temel rollere ve ürün yöneticisi rolünüz ile Scrum ürün sahibi arasındaki farkları anlamanıza yardımcı olacak hızlı bir genel bakış bulabilirsiniz.

Rollerle başlayalım. Tipik bir Scrum ekibi aşağıdaki kişilerden oluşur:

• Scrum yöneticisi: Bu kişi, ekibin Scrum kurallarına uymasına ve süreçlerini optimize etmesine yardımcı olur.
• Ürün Sahibi: Bu kişi, Scrum ekibinde işletmeyi ve kullanıcıları temsil eder. Ürün sahipleri iş listesinin sorumluluğunu üstlenir, sprint hedeflerini ve kullanıcı hikâyesi önceliklerini belirler.
• Scrum ekibi: Ürünü geliştiren geliştiricileriniz, tasarımcılarınız, kalite güvence uzmanlarınız ve diğer uzmanlarınız.

Scrum ekibi söz konusu olduğunda, burada başka birçok uzman türü de bulunabilir. Çapraz işlevli ekipler kavramı, ekibin profesyonel uzmanlığa erişim açısından bağımsız olduğunu varsayar. Örneğin, ürününüz yoğun biçimde analitiğe dayanıyorsa ekibinizde bir veri analisti de bulunabilir.

Ürün Yöneticisi ve Ürün Sahibi: Aralarındaki Fark Nedir?

Verdiğim ürün sahibi tanımı, bir ürün yöneticisinin genellikle yaptığı işlere çok benzediği için kafanızı biraz karıştırmış olabilir.

Öyleyse bu durumda, ürün yöneticisi ile ürün sahibi arasındaki fark nedir?

Farkı anlamak için öncelikle her birinin temel sorumluluklarına bakalım.

Ürün Yöneticileri

• Ürün keşfi yapar, müşteri ihtiyaçlarını ve sorunlarını anlar.
• Ürün vizyonunu ve ekibin izleyeceği yönü belirler.
• Müşteri ihtiyaçlarını karşılayabilecek ürün çözümleri geliştirir.
• Ürün teslim sürecine liderlik eder.
• Müşteri geri bildirimlerine ve veriye dayalı karar almaya göre ürünü küçük artışlarla geliştirir.
• Ürün vizyonunu ve uygulamasını şirket genelinde ve şirketin farklı kademelerinde yönetir.

Ürün Sahipleri

• Ürün iş listesini oluşturur ve güncel tutar.
• Scrum ekibi için strateji, tasarım ve iş mantığı açısından tek doğruluk kaynağı olarak görev yapar.
• Ürün iş listesindeki öğelere öncelik verir ve neyin önemli olduğu konusunda ekibe netlik kazandırır.
• Özellikler için kabul kriterlerini belirler ve sprint sonuçlarını bunlara göre kabul eder.
• Gereksinimleri netleştirerek ve bunlarla ilgili sorunları çözerek ekip üyelerinin önündeki engelleri kaldırır.
• Scrum etkinliklerine katılır ve ekipte işletmenin ve müşterilerin sesi olarak görev yapar.

Gördüğümüz gibi, çoğumuz her iki listede de yer alan işleri yapıyoruz. Bu oldukça normal ve yaygın bir durum, çünkü çoğumuz aynı anda hem ürün yöneticisi hem de ürün sahibi olarak görev yapıyoruz.

Bu ikisi arasındaki temel fark, ürün yönetiminin bir meslek ve beceri seti, ürün sahipliğinin ise Scrum ekibindeki bir rol olmasıdır.

Peki bu ne anlama geliyor?

Bu, ürün sahibinin ürün yöneticisi olmak zorunda olmadığı anlamına gelir. Üç geliştiriciyle birlikte bir CEO'nuzun bulunduğu küçük bir girişimde CEO, geliştiricilere önceliklendirilmiş bir iş listesi sağlayarak ürün sahibi rolünü üstlenir.

Tersi durum da mümkündür. Ürün sahibi olmadan ürün yöneticisi olabilirsiniz. Bunun iyi bir örneği benim; eski ekiplerimden biri Scrum kullanmıyordu. Scrum yoksa ekipte ürün sahibi de yoktur. Yine de yalın ve Çevik ilkeleri uyguluyorduk.

Bu ikisi arasındaki farkı daha iyi anlamanız için, yaptıklarının yan yana bir karşılaştırmasını burada bulabilirsiniz.

Fakat Scrum ekibinde özel bir role sahip olmanın asıl amacı neydi? Ekipte yer almayan ürün yöneticileriyle yalnızca iş birliği yapamazlar mıydı? Teresa Torres'in bu soruya verdiği yanıtı gerçekten beğeniyorum.

Dolayısıyla Scrum ekibinde belirli bir ürün rolünün bulunmasının temel nedeni, kurum içindeki ürün bilgisini ve uzmanlığını ekibe sunmak ve ekibin çapraz işlevliliğini daha da güçlendirmektir. 

Ürün Yöneticisi Scrum Ekipleriyle Nasıl Etkileşim Kurar?

Scrum yolunu seçmeye karar verdiğinizi varsayarsak, ekibin bir üyesi olmayı ve ekip arkadaşlarınızla nasıl iş birliği yapacağınızı bilmeniz gerekir. Her bir Scrum etkinliği ve eseri için size kısa bir genel bakış sunayım.

• Günlük Scrum (diğer adıyla günlük toplantılar): Zaman kutulu bu toplantılar sırasında yaptığınız en önemli iş, geliştirme ekibinizin ürünle ilgili sorularını yanıtlamak ve engelleri ortadan kaldırmaktır.
• Sprint Planlama Toplantısı: Burada, sunmayı beklediğiniz özellikler konusundaki beklentilerinizi açıkça tanımlayarak Sprint'in hedefini belirleyen kişi sizsiniz.
• Sprint Retrospektifi: Öncelikleri ve gereksinimleri ekibe sunmak için kullandığınız süreçler, ekibin verimliliğini artırabilir veya azaltabilir. Bu nedenle, ekipten geri bildirim toplamak ve süreçlerinizi iyileştirmek için bu toplantıyı kullanabilirsiniz.
• Sprint İncelemesi: Buradaki göreviniz, Sprint'in tamamlanan özelliklerini kabul etmek ve ekibe çalışmaları hakkında geri bildirim sağlamaktır.
• Ürün İyileştirme (diğer adıyla düzenleme): Bu toplantının sahibi sizsiniz ve size ayrılan zamanı, ekip için hazırladığınız kullanıcı hikâyelerinin önceliklerini ve ayrıntılarını görüşmek üzere kullanmanız gerekir. Ekibi her zaman gereksinimlerinize meydan okumaya ve orada bıraktığınız “ürün hatalarını” bulmaya teşvik edin.
• Ürün İş Listesi: Ürün iş listesini yönetmek ve temiz ve önceliklendirilmiş tutmak sizin sorumluluğunuzdadır; çünkü ekip Sprint'ini buna göre oluşturacaktır.
• Sprint İş Listesi: Bu listenin sahibi siz değilsiniz. İş birliğinizin temel noktası, ekibe doğru hikâyeleri Sprint iş listesine alması konusunda rehberlik ederek Sprint hedefinize ulaşabilmelerini sağlamaktır.

Bunun dışında, paydaş yönetimi veya ürün keşfi gibi başka türlerde ürün çalışmaları da yapacaksınız. Scrum ekibinin bir üyesi olarak göreviniz, paydaş ve kullanıcı ihtiyaçlarını netleştirdikten sonra ekibin her ikisinden de haberdar olmasını sağlamaktır.

Örneğin, bir kullanıcıyla görüşme yaptığınızda ve giriş akışınızdaki kullanıcı deneyiminin genel olarak kafa karıştırıcı olduğunu keşfettiğinizde, sonraki Sprint'lerde bu bölüme dikkat etmelerini sağlamak için bu bilgiyi ekiple paylaşmanız önemlidir.

Scrum Ürün Yönetimi İçin En İyi Uygulamalar

Ürün yönetimi Scrum (ve genel olarak Çevik geliştirme) merceğinden bakıldığında kolay görünse de, kendi kendini organize eden ekiplerimizle çalışırken sıkça yaptığımız birçok hata vardır.

Bu nedenle, bunlardan kaçınmanıza yardımcı olabilecek birkaç Scrum en iyi uygulamasını aşağıda bulabilirsiniz:

• Net Beklentiler Belirleyin: Yapabileceğiniz en büyük hata, ekibinize belirsiz öncelikler ve gereksinimler sunmaktır. Netlik eksikliği, geliştirme gecikmelerinin ve sizinle ekip arasındaki gerilimin başlıca nedenlerinden biridir. Bunu nasıl başaracağımızı kısa süre içinde ayrıntılı olarak ele alacağız.
• Uyarlanabilirliği Kötüye Kullanmayın: Yön değiştirebilme becerisine sahip olmak harikadır, ancak bunu yalnızca ürün iş listenizde yapabilirsiniz; Sprint iş listenizde değil. Sprint başladıktan sonra lütfen iş listesine hikâye eklemeyin veya çıkarmayın. Bu, ekibinizin planlarını ve ilerlemesini bozar ve tamamlanmamış Sprint'lere yol açar.
• Duygusal Açıdan Güvenli Bir Ortam Oluşturun: Siz ekibin bir üyesisiniz, patronu değil. Bu nedenle ekibinizi daha büyük taahhütler almaya veya işleri erken bitirmeye zorlamayın. Scrum.org tarafından yayımlanan da dâhil olmak üzere tüm Scrum kılavuzları, ekip arkadaşlarınızla sağlıklı ilişkiler sürdürmeye büyük önem verir; çünkü bu, etkili ekip çalışmasının temel taşlarından biridir.

Deneyimlerime göre bu üç en iyi uygulama en önemli olanlardır. Ancak ürün yöneticileri için Çevik iş akışları ve Scrum en iyi uygulamaları hakkında daha fazla ipucu istiyorsanız Çevik ürün yönetimi hakkındaki ayrı kılavuzumuza göz atmayı unutmayın.

Ürün İş Listesini EtkinBir Şekilde Yönetme

Daha önce belirttiğim gibi, ekibinize netlik sağlamak bir ürün yöneticisinin en önemli görevlerinden biridir. İyi haber şu ki ürün iş listeniz, bunu başarmak için muhtemelen en iyi araçtır. Bu nedenle, size yardımcı olacak birkaç ürün iş listesi yönetimi ipucunu burada bulabilirsiniz:

Düzenleme Toplantıları: Kullanıcı hikâyelerinizi ne kadar iyi yazarsanız yazın, orada “hatalar” bırakacaksınız ve geliştirme ekibinizin bunları kontrol edip size bildirmesini isteyeceksiniz. Ayrıca geliştirici olmadığınız için uygulaması zor gereksinimler yazabileceğiniz gerçeği de var. Yine ekibiniz, düzenleme süreci sırasında size bundan bahsedecektir.

Önceliklendirme Teknikleri: Hangi özelliklerin diğerlerinden daha önemli olduğunu anlamak için çok sayıdaki önceliklendirme çerçevesinden yararlanın. Kişisel favorim, basitliği nedeniyle MoScoW'dur.

Yol Haritası ve Vizyonla Uyum: İş listenizdeki epikler ve hikâyeler, ulaşmak istediğiniz genel ürün hedeflerini ve ölçümlerini temsil etmelidir. Bu nedenle iş listesine bir şey eklerken yol haritanızı sürekli olarak gözden geçirdiğinizden emin olun.

Scrum'da Paydaşları Hizalamak

Scrum'da ürün yöneticisinin rolünün özü, kendi kendini organize eden ekip ile kullanıcılar, paydaşlar veya diğer ekipler gibi dış dünya arasındaki bağlantıyı sağlayan kişi olmanızdır.

Dolayısıyla, bir ürün yöneticisi olarak düzenli paydaş yönetimi görevlerinizi yerine getirmenin yanı sıra bu bilgileri ekibinize aktarmanız ve bunun tersini de yapmanız gerekir. Ekipten gelen bilgileri paydaşlara aktarmanız gereken durumlar da olacaktır.

Buna iyi bir örnek, belirli bir özelliğin zaman çizelgesini veya kapsamını etkileyebilecek sürekli entegrasyon sorunları gibi teknik zorlukların ortaya çıkmasıdır. Bu, paydaşlarla görüşmeniz ve ya yeni zaman çizelgesini/kapsamı kabul etmeniz ya da farklı bir çözüm bulmanız gereken bir konudur (ör. ekibi bu konuyla ilgili daha fazla uzmanlıkla güçlendirmek).

Ekibinizin yol haritasına eklenmeye değer ilginç bir özellik fikri veya çözüm geliştirdiği durumlar da olabilir. Yine bu bilgiyi paydaşlara aktarıp planınıza ekleyip eklemeyeceğinize karar verirsiniz.

Scrum'da Çevik Yol Haritalamanın Önemi

Doğrudan Scrum'ın bir parçası olmasa da çevik yol haritaları, Scrum'ı mümkün kılan araçlardan biridir. Sonuçta, ürününüz için çevik bir yol haritası yerine Şelale çerçevesini kullanıyorsanız yinelemeli planlamanın ne anlamı kalır?

Bu durumda, Scrum ürün stratejisi olarak adlandırdığınız şey, klasik SDLC ile önceden tanımlanmış ve sabit bir planı 2 haftalık (veya sprintleriniz ne kadar sürüyorsa o uzunlukta) parçalara bölmekten ibaret olurdu. Bu nedenle Scrum'ı ekibiniz için anlamlı hâle getirmek üzere çevik, yinelemeli planlama yapmanız ve zaman içinde değişebilecek bir yol haritası oluşturmanız gerekir.

Şimdi, çevik yol haritanızı ekibinizin Scrum süreçleriyle doğru şekilde birleştirmek için şunları yapmanızı öneriyorum:

• Yol haritası öğelerini (genellikle Epik'leri) ürün iş listesindeki kullanıcı hikâyelerine bağlayın. Böylece taktik çalışmalarınız (hikâyeler) ile stratejiniz (yol haritası) arasında doğrudan bir bağlantı kurulur.
• Yol haritanızı Scrum ekibinize sunun. Böylece ürünün nereye gittiğini bilir ve ön yüz ya da arka uç mimarisini tasarlarken yaklaşan özellikleri göz önünde bulundururlar.
• Jira, Monday.com ve Clickup gibi uzmanlaşmış araçlardan yararlanarak yol haritalama ve iş listesi yönetimi sürecinizi kolaylaştırın.

Son noktaya ilişkin olarak, bu üç araç pratikte kullandığım araçlardır. Ancak bunun yerine kullanmayı değerlendirebileceğiniz başka birçok ürün yönetimi aracı da vardır.

Scrum Ürün Yönetimindeki Zorluklar

Scrum, ürün hedeflerinize ulaşmak için harika bir çerçeve olsa da bu çerçeveyi kullanmak aşağıdakiler gibi kendine özgü bir dizi zorluğu beraberinde getirir:

• Ekibiniz veya paydaşlarınız Scrum'un neyle ilgili olduğunu anlamayabilir. Bu durum, belirli araçları kullanmayı reddetmek gibi önemli Scrum benimseme sorunlarına yol açabilir. Çerçeve tamamen uygulandığında ekibin ve iş akışının nasıl görüneceğine dair arzu edilen "son durumu" göstererek bu durumun önüne geçmenizi öneririm.
• İnsanların (ve sizin) ekip içindeki ve dışındaki rolünüz konusunda kafası karışabilir. Kariyerim boyunca çalıştığım her şirketin Scrum Ürün Sahibinin ne yaptığına dair kendine özgü bir anlayışı vardı. Ekibiniz için bunun ne olduğunu ve ne olmadığını netleştirmek en iyisidir.
• Üzerinde çalıştığınız özelliklerin kapsamı sonsuza dek genişleme eğilimindedir. Şaşırtıcı olmayan bir şekilde, bu durum kapsam kayması bölgesine girmeyi oldukça kolaylaştırır. Scrum ekipleri, neyi üstlenecekleri ve neye "hayır" diyecekleri konusunda acımasız olmalıdır.
• Yol haritası kolayca rayından çıkabilir. Ne üzerinde çalışacağını seçebilen görece bağımsız bir ekibe sahip olduğunuzda, kendinizi yol haritanızın dışında kalan şeyleri geliştirirken bulabilirsiniz. Bu tuzaktan kaçınmak için nihai hedefi net bir şekilde odağınızda tutmanız büyük önem taşır.

Bu zorluklar oldukça yaygın olsa da iyi haber şu ki, Scrum sürecini anlaması ve bunların büyük çoğunluğunun üstesinden gelmesi Ürün Yöneticisinin yalnızca birkaç sprintini alır. Uzmanlıklarını resmileştirmek isteyenler için Scrum Master olmayı öğrenmek, liderlere ekiplerini bu çerçeve boyunca yönlendirme konusunda güvenilir bir avantaj sağlayabilir.

Sonuç

Scrum, ürün yöneticilerine sunulan en iyi armağanlardan biridir. Uzun vadede Çevik olma ile kısa yinelemeler içinde disiplinli olma arasındaki denge sayesinde, çerçevesiz bir Çevik geliştirme sürecinin kaosundan kaçınırken ürününüzün yönünü pazar tepkisine göre değiştirme becerinizi koruyabilirsiniz.

Rehberimizi beğendiğinizi umuyoruz. Öyleyse daha fazla ürün yönetimi kaynağı ve rehberi ile sektör liderlerinden ve uzmanlarından en yeni podcast'leri, röportajları ve diğer içgörüleri almak için bültenimize abone olmayı unutmayın.