Expert Judgment

Concerning My PMI-ACP Exam Experiences

Posted in Agile, Project Management by dnzrn on September 15, 2011

Today I attended the PMI-Agile Exam. Since it is the first day of the examination in the whole world, it is my privilege to write about this experience that I may call the first encounter of mankind with PMI-ACP.

As most of you may be aware of there has been discussions about the examination contents, in many Agile, Scrum, Lean and PMP mail lists and LinkedIn Groups. Some people think the examination would be an abomination and PMI’s structural approach to Project Management may bruise the spirit of Agile. Others see PMI-ACP as a noble attempt to gather many Agile Methodologies and define a broad Agile Practitioner Body Of Knowledge  (APBOK (?) ), and finally put a formal definition to what Agile is. There is one think in common for all. Nobody knew what the exam would be like. Until today…

Ladies and Gentlemen, my fellow PMP’s and Agile comrades, I present you my experiences and suggestions regarding the exam:

Smart Questions

Most of the questions were prepared smartly. You should read carefully. Make sure you understand what the question really asks.

Unclear Concepts Handled Well

Some Agile concepts have conflicting definitions in the reference books. Questions related to these kinds of concepts had guiding choices as answers. Read all the choices before you select the answer. Some might be “more correct” !

Very Important Points

  • Characteristics of Stories
  • Roles in Scrum & XP
  • Scrum Processes (Sprint Planning, Daily Scrum, Sprint Review, Retrospectives)
  • Estimation (Roles, Game, Different Levels of Estimation)
  • Agile Risk Management
  • Adopting New Agile Principles
  • Velocity, Burndown, EVM
Completion Takes 1,5 Ideal Hours

The duration of the exam is 3 hours + 15 minutes of surveys. However question texts are not long, not boring, easily understandable, so it takes approximately 1,5 ideal hours to complete, and control marked questions.

Reference Books

Most of the books were used in preparing questions. Read Cohn’s book, “User Stories Applied” cover to cover. Warden & Shore’s book, “Art of Agile Development” is important. Adkyns’ “Coaching Agile Teams” is where most of the soft skills related questions come from.  At least read the chapter summaries and comparison of Agile and PMBOK processes from “Project Manager’s Bridge to Agility“.

It was really hard to read and understand Highsmith’s “Creating Innovative Products“. I was affraid of the eccentric process definitions and Complex Adaptive System references in the book. Fortunately for me, there were not many questions from Highsmith.

Shocking Surprise at the End !!!

As experienced exam takers, we expect the Pass/Fail result at the end of the exam session. Instead I got a note stating that the exam result will be available in December (!) because it is a pilot exam. This raises the concerns that PMI not having confidence in its ability to  ask accurate questions.

Last notes… Don’t sweat it. Exam is well prepared. (Well done PMI Agile COP). Please don’t ask me further about the questions, because of my obvious information disclosure obligations. Trust in your own knowledge and experience!
I wish you all the best of  luck !

Epic Breakdown Structure & Types of User Stories

Posted in Professional, Project Management by dnzrn on May 25, 2011

“There have been great societies that did not use the wheel, but there have been no societies that did not tell stories.”

—Ursula K. LeGuin

As we are well aware, work to be done is represented by/based on Stories, in Agile Projects. Recently my team was asked to develop a WBS for an Agile project, by using a specific open source project management/issue tracking tool, for demonstrative purposes. While working on this assignment the team quickly figured out that “work” is already represented by stories, so defining a WBS may be wasted effort.

It is obvious that WBS is a key element of Project Scope Planning and a valuable practice for the team to be aware of all the things that are in the project. However, Agile approach to Project Management accepts that initial scope definitions are generally inaccurate, so recommends defining the scope at a low level of detail.

After a swift brainstorming session the team reached consensus about how to form a WBS, by utilizing the stories. Behold, the EBS (Epic Breakdown Structure)

EBS is simply the hierarchical representation of a group of Stories, which will be covered by the Project. It may not be a new concept but was enough to ignite the creativity within the team. Thus the team configured the project management/issue tracking tool to support the EBS.

In this model, Stories are described in greater detail (when needed) by Business Rules and Requirements.

Only one problem left to be solved. How do we address and display the work that is not related with a Story, such as Project Planning, Documentation, Building Infrastructure (e.g. development environment)? The answer is, we don’t.  If a work item is present yet there is no Story defined for that purpose, just define the Story. And a really important point: Stories are not always business focused.

There are many types of Stories, described in the Agile literature. Here are a few:

Business Story

Business focused. Almost always written by the business. Sometimes written by the analysts.

Ex: “Student selects courses she wishes to take, from the list of all courses offered in that semester”

Non Functional (Performance) Stories

Not related to the functionality of the system, but describes the performance attributes of the system, such as, Scalability, Availability, Reliability, Maintainability, Usability…

Ex: “Registration pages use the same font and background color scheme as the other pages of the Student Affairs Information System.”

Ex: “The Student Affairs Information System is up and running 99.9% during the registration time period defined in the Academic Calendar.”

Documentation Stories
Even Agile projects need documentation and keeping documentation requires effort.

Ex: “The user manual of registration program is written in both English and Turkish, describing the registration procedure and providing screenshots.”

Defect/Bug Stories

Stories defining how/what to fix some buggy functionality which were delivered in an earlier iteration.

Ex: “Warning message displayed is translated to Turkish from Mandarin Chinese when Advisor approves Student’s Course List.”

Spike Stories / Technology Debt 

There are times when the team is not familiar with a new technology or approach which may be used in upcoming iterations. Or we simply think that spending effort on a utilization of a tool/technique will save time and effort in the future. So we carry out our own personal R&D for a bit of time. This should be defined by a Spike Story, aka Technology Debt.

Ex: “Voice operated semantic search utility of Mikrokom Corp. is examined.”

Plannning / Estimating Stories

The team spends time when planning the project. Define this time by a Planning Story.

Ex: “The planning game takes place.”

Meeting Stories

Many governmental organizations never miss the opportunity to socialize, so they organize meetings… lots and lots of meetings…

Just write a story for upcoming meetings.

Ex: “Progress and risk review meeting is organized.”

Architecture / Infrastructure Stories

All projects need infrastructure support to some extent. Show the effort spent in establishing the infrastructure as an Infrastructure Story.

Ex: “Redmine the Issue Tracking Tool is deployed and user authentication mechanisms for the software support team members are developed.”

PMI Agile Certification (PMI-ACP) Pilot Programme is Up !

Posted in Professional, Project Management by dnzrn on May 23, 2011


I am pleased to announce that I just have applied to the PMI-ACP Pilot Programme.

For application use the following address:

In order to apply you should claim that you have the minimum eligibility requirements:

  • graduate of (at least) a high school
  • 2000+  hours of Project Management Experience in last 5 years or to have PMP
  • 1500+ hours of work experience in an Agile Project Team in last 2 years
  • 21 contact hours of Agile Project Management Training
  • Pass the exam
The application form consists of 3 major parts
Your Contact Information
Agile Training Background
For each training:
  • Start Date / End Date
  • Title
  • Institution
  • Contact Hours
Agile Project Experiences
For each project:
  • Title
  • Start Date / End Date
  • Project Role
  • Primary Industry
  • Organization Information
  • # Hours of Agile Project Experience
  • Description of the Role (Which Agile practices you’ve performed, which Agile tools you have used, …)
This is the link to the certification home page:
This is the link to the certification handbook:
I wish all pioneers applying this pilot program, best of luck.
Don’t forget to get prepared for the exam, which will be available in September 2011
Exam topics:

[TR] Çevik Test Süreci

Posted in Uncategorized by dnzrn on March 24, 2011

Çalıştığım kurumda bir süredir üzerinde uğraştığım çevik yazılım geliştirme metodolojileri ve çevik test süreci hakkında araştırmalarımın ilk çıktısı olarak sizlere derleme bir makale sunuyorum.

Orijinal makaleler İngilizce, aldığım notlar Türkçe. İlerleyen haftalarda konu hakkında daha detaylı ve yapısal bir rapor sunuyor olacağım. Çevik süreçlerin uygulanması konusunda deneyimli olan ve/veya bu konuda katkıda bulunmak isteyenler benimle iletişime geçebilirler.

NOT: Makalenin derlenmesinde Storify adlı web tabanlı bir araç kullandım. Yaptığım araştırma niteliğindeki işlerinin sonuçlarını etkin ve bilgi kaynağına saygılı bir biçimde sunmamı sağlıyor. İlginizi çekerse inceleyin.

[TR] Proje Yönetim Ofisi

Posted in Professional, Project Management by dnzrn on March 17, 2011

Yapısal bir Proje Yönetimi yaklaşımının kurumlara kazandırılması kolay bir iş değil. Özellikle de kemikleşmiş bir iş kültürüne sahip olanlara…

İşleri Projeler biçiminde yönetme yaklaşımının (Management by Projects) pek çok kazanımı var. Bu kültürün organizasyonda verimli şekilde işlemesini sağlamak için, kabul görmüş bir örgüt birimi olan Proje Yönetim Ofisi’nin kullanımı önerilir. Bir örgütte Proje Yönetim Ofisi (PYO) kurulurken dikkat edilmesi gereken bazı noktalar var:

  • Çalışanlara bu yapının fazladan bürokratik bir engel değil,  işlerini kolaylaştırmak üzere kurulmuş olduğunun açıklanması,
  • Yönetimsel destek. Bu basit bir görevlendirme yazısı olabileceği gibi, örgütün yöneticisinin PYO’nun da yöneticisi olarak belirtilmesine kadar gidebilir.
  • PYO nun kapsamının çok net belirlenmesi,
  • PYO nun görev alanının Projeler ile sınırlanması, Operasyonların sorumluluğunun PYO üzerine bırakılmaması.

ODTÜ Bilgi İşlem Dairesinde yaptığım PYO yapısını konu alan bir sunum:

Research Resources

Posted in Academics, Professional by dnzrn on March 14, 2011


The greater our knowledge increases the more our ignorance unfolds.

-John F. Kennedy


I don’t think of myself as either an Academician or Practitioner, I’m a true hybrid. It has it’s drawbacks just as it has it’s boons. One should really try hard to understand the academic habitat thoroughly and the mysterious ways it works. During my discussions with peers and professors, I was often queried about my research resources and the journals and academic events that I regularly trace. To be honest I do not regularly check any journal. Most of the articles I read come from my keyword searches. This behavior may have suited me well before my PhD Thesis studies, but now I find it insufficient. So I decide to subscribe a number of journals and events. Now, how should one find the best few among many?

This January, I was searching for research scholarship opportunities when I encountered the website of Blekinge Institute of Technology (BTH). They have a really successful Software Engineering Research Lab, mainly focusing on Software Requirements Engineering.  They published a list of Software Engineering Journals. So I decided to copy some of the links for future use:

Software Engineering Journals

ACM Communications of the ACM

[METU Accessible] ACM Communications of the ACM

ACM Transactions on Software Engineering and Methodology

Annals of Software Engineering

Automated Software Engineering

Empirical Software Engineering

IET Research Journals (formerly IEE Proceedings)

IEEE Computer

IEEE Software

[METU Accessible] IEEE Software

IEEE Transactions on Software Engineering

IEEE Transactions on Computers

Information and Software Technology

Journal of Software Maintenance and Evolution: Research and Practice

Journal of Systems Architecture

Journal of Systems and Software

Requirements Engineering Journal

Software Concepts and Tools

Software – Practice & Experience

Software Process – Improvement and Practice

Software Quality Journal

Software Testing Verification & Reliability

In the Gloom of the Dragon’s Den

Posted in Uncategorized by dnzrn on June 14, 2010

Never laugh at live dragons.

-“The Hobbit” by J.R.R. Tolkien

Recently I became aware of a TV series called the “Dragon’s Den”. The show is originally hosted by BBC. The series is about entrepreneurs, presenting their innovative (?) ideas to five intimidating investors, -so called dragons-, in order to convince them to invest in their business initiatives.

Though it seems to be a very tense, stressful show, it inherits certain wisdom. I like to observe the presentation and negotiation techniques of the entrepreneurs. And I certainly enjoy watching the decision process of the dragons. They have a very different (unique) perspective, when looking at business opportunities.

Long story short, I think, BBC’s Dragon’s Den is the most educative show of last couple of years.

[TR] Makale Gözden Geçirme Yazısı: “P.Y. – 21. Yüzyılda Çılgınlığa Karşı Metodolojiler”

Posted in Project Management by dnzrn on May 3, 2010

Proje Yönetimi: 21. Yüzyılda Çılgınlığa Karşı Metodolojiler

– Makale Gözden Geçirme Yazısı –


Orta Doğu Teknik Üniversitesi,

Bilgi İşlem Daire Başkanlığı |

Birkaç gün önce, bir arkadaşımın yönlendirmesi üzerine, 2000 senesinde yazılmış bir makaleyi inceledim. Makale, 2000 senesinde yapılan bir söyleşinin (Software Methods and Tools 2000), konuk konuşmacısının yaptığı açıklamaları konu almakta. İlginç olan konuşmanın konusu. Önlerindeki 10 sene boyunca Yazılım Proje Yönetimi alanında yaşanacak değişiklikleri öngörmüşler. Ben de tam 10 sene sonra (2010) bu makaleyi okuma ve öngörülerin ne kadar gerçek olduğunu değerlendirebilme fırsatı yakaladım.

Makalenin yazarları, Amerika’daki Capital One Bankası’ının Finans Departmanı’nda çalışan iki arkadaş; George Kelly Flanagin ve Susan R. Jacobs. Makale, yazarların yaptığı bir dizi öngörünün sıralanması ve açıklanması biçiminde organize edilmiş.  Bu öngörüler şu şekilde;

“Yazılım profesyonellerinin sertifikalandırılması büyüyen bir trend ve büyümeye devam edecek.”

Makalenin yazıldığı senelerde, Microsoft’un sadece üç sertifikası vardı ve bunlar da epeyce yeniydi. MCSE, MCSD ve MCDA sertifikaları yeni yeni çıkıyordu. 2000’lerin başlarında bu sertifikalar çok zor ediniliyordu ve çok değerliydi. Yazarların tahminleri, bu tür sertifikaların sayısının ve çeşitliliğinin artacağı ve sertifikasyon işinin büyük bir pazar olacağı yönünde idi. Haklı olduklarını bugünkü duruma bakarak görebiliyoruz. Microsoft’un şu anda 17 adet sertifikasyonu var. Ne var ki artık bu sertifikaları edinmek zor sayılmaz ve bunlara sektördeki kuruluşlar tarafından eskisi kadar değer de verilmiyor.

Yazarlar, sertifikasyonların detaylanmasında bir risk görmüşler. Öngörülerine göre, sertifika sahibi profesyoneller daha detaylı işler ile ilgilenecekler ancak kendi alanlarının uzmanları oldukları için bir çok projede kendi uzmanlık alanlarında “misafir” olarak görev yapacaklar. Yani bir “Sertifikalı İş Analisti” sıfatına sahip bir kişi, bir projede iş analizini yaptıktan sonra o projenin analiz fazının geçilmesi üzerine, başka projeye transfer edilecek ve yapmış olduğu işin ilk proje üzerindeki etkilerini izleyememiş olacak. Bu da son kullanıcılara karşı direk sorumluluğu olmayan (olmamış) kişilerin, yazılım geliştirme projelerinde, mimari sürecinin bir aşamasında kullanılmasına sebep olacak. Bugün itibariyle, sertifika sahiplerinin organizasyonlarda, yazılım geliştirme süreçlerinin ilgili aşamalarında görevlendirilmesine dair bir eğilim söz konusu. Ancak bu durumun yapılan işin kalitesi üzerindeki etkisinin ne olduğunun araştırıldığına henüz rastlamadım. İleriki bir araştırmanın konusu olarak not alıyorum.

“Yazılım her geçen gün daha büyük bir gereklilik oldukça, yazılım profesyonelleri, yazılım şirketlerine kayacaklar.”

Yazarların öngörülerine göre, diğer şirketlerin BT birimlerinde çalışan yazılım geliştiriciler, yazılım şirketlerine kayma eğilimi gösterecekler. Bu da nitelikle BT personelinin yazılım geliştirme şirketleri haricinde şirketlerde bulunulmasını zorlaştıracak. Özellikle yazılım geliştirme kökenli Yazılım Proje Yöneticileri, en zor bulunur personel olacak.

Baktığımızda, bu öngörünün büyük oranda doğru olduğunu görüyoruz. Sektörde, yazılım geliştirme projeleri genellikle, büyük yazılım şirketleri tarafından sahiplenilip, alt yükleniciler vasıtasıyla yürütülüp, tamamlanıyor. Yazılım Proje Yöneticileri bu süreçte hem yazılımı geliştiren alt yüklenicilerde, hem de alt yüklenicilerin işini denetleyen asıl proje sahibi organizasyonlarda bulunabiliyorlar. Ne var ki, bir numaralı iş alanı BT olmayan organizasyonlarda, yazılım projelerinin kurum içi veya alt yükleniciler vasıtasıyla yönetilmesi yazılım geliştirme kökenli olmayan personel tarafından da gerçekleştirilebiliyor.

“Yazılım ihtiyacı olan şirketlerin çoğu dış kaynaklı yazılım geliştirme yapacaklar.”

Öngörüye göre, kalifiye BT personelinin yazılım şirketlerine geçmesi sonucu, diğer şirketler çareyi yazılım projelerini geliştirirken dış kaynak kullanılmasında bulacaklar.

Günümüzde yazılım geliştirme projelerinin dış kaynak kullanımı ile yürütülmesi çok rastlanan bir durum. Tabii ki bunun sebepleri arasında yazılım şirketlerinin yetkinliklerinin, kurum içi BT birimlerinden daha yüksek olması da var. Ancak tek sebep bu değil. Dış kaynak kullanımı pek çok operasyon ve kalite maliyetlerinden de kurtulmayı ve yazılım geliştirmeyi optimize etmeyi sağlamakta.

Öngörülene göre ana faaliyet alanı BT olmayan organizasyonlarda kalmayı seçen proje yöneticileri, yazılım geliştirme projelerinin büyük kısmının 3. parti organizasyonlar tarafından yürütüleceğini tecrübe edecekler. Dana önce bahsettiğim sebeplerden bunu da gerçekleşmiş bir öngörü olarak değerlendiriyorum.

“3. dünya ülkelerinde yazılım eğitiminin artması, dış kaynak kullanımını uluslararası boyuta taşıyacak.”

Makale, Amerika, Kanada, Avustralya ve Batı Avrupa ülkelrindeki nitelikli BT iş gücünün azlığına dikkat çekmiş ve bu açığın kapatılması için Hindistan gibi gelişmekte olan ülkelerden işgücü transfer edileceğini öngörmüş. Yazarlar üç farklı uluslararası dış kaynak kullanım modelinden bahsetmişler. Bunlardan ilki, gereksinimlerin ve iş analizinin yerinde yapılmasını takiben, işin yapılacağı ülkeye transfer edilmesi ve işin burada yürütülmesi. Ne var ki yapılacak işin doğası gereği her tür proje bu şekilde transfer edilebilir olmuyor. Diğer bir yurtdışı dış kaynak kullanımı modeli ise, ucuz iş gücünün bulunduğu ülkede bir şirket birimi oluşturmak. Bunun da en büyük dezavantajı, yabancı ülkelerin kuralları, kanunları ve kültürlerine hakim olmamanın getireceği riskler. Makalede belirtilen üçüncü ve son dış kaynak kullanım modeli ise iş gücünün 3. Dünya ülkelerinden taşınarak, gelişmiş ülkelere taşınması.

Baktığımızda, bu öngörünün de büyük oranda gerçeğe döndüğünü görebiliriz. Amerika ve Avrupa’da konumlanmış olan pek çok büyük yazılım şirketinin, Hindistan, Çin ve Brezilya’da ofisleri var veya en azından çeşitli projeleri yürütürken bu ülkelerdeki yazılım çiftliklerinden faydalanıyorlar.

“Var olan servislerin kullanımı ile yazılım geliştirme yoğunluğu artarken, yazılımı sıfırdan geliştirme yoğunluğu düşecek.”

On sene önce yapılmış olan bu tahmin aslında, Hizmet Odaklı Mimari (SOA) nın bir habercisi adeta. Günümüzde pek çok yazılım çözümünün geliştirilmesinde bu yaklaşım uygulanıyor.

“İnternet, yazılım geliştirme ve proje yönetimini kökten değiştirecek.”

Yazarlar, 2000’lerin ilk on senesinde, özellikle internet tabanlı ürünlerin geliştirilmesinde, yazılım projeleri büyüdükçe, projedeki satıcı ve geliştirici paydaşların sayısının artacağını öngörmüşler. Projenin yaşam süresi boyunca bu paydaşların etkinliklerini hatta varlıklarını dahi kaybetmelerinin söz konusu olabileceğinden bahsedilmiş. Yazarlar, yoğun alt yüklenici yönetimi gerektiren projelerde, bir proje yöneticisinin sahip olması gereken en önemli özelliğin seri ve doğru düşünme ve karar verebilme olduğunu belirtmişler. Gerçekten de günümüzde yazılım yoğun sistemlerin geliştirildiği büyük projelerde çok sayıda alt yüklenici kullanılıyor. Gün geçtikçe organizasyonlar BT’nin kaldıraç etkisinden faydalanmak için yeni fırsatları araştırıyorlar. İş gereksinimleri karmaşıklaştıkça, sistemler de karmaşıklaşıyor. Doğal olarak bu yazılım geliştirme sürecinin de karmaşıklaşmasına, çok sayıda uzmanlık alanının ve işgücünün bir arada kullanılmasına ihtiyaç duyulmasına sebep oluyor. Bu da makale yazarlarının doğru çıkan öngörülerinden.

Makalede, çok sayıda alt yüklenici kullanılmasının bir riskinden daha bahsedilmiş. Bu risk, her alt yüklenici kendi iteratif veya çevik süreci ile iş geliştirirken, farklı alt yükleniciler tarafından geliştirilen ve farklı zamanlarda hazır olan iş ürünü parçalarının bir araya getirilerek, işlevsel bir bütünlük içinde test edilmesinin zorlaşması. Basitçe açıklamak gerekirse, alt yüklenici sayısı arttıkça, bu alt yüklenicilerin üretim döngülerinin birbirleri ile senkronizasyonunun sağlanması daha karmaşık bir süreç halini almakta. Bu da yazılım parçalarının bir araya getirilerek, alfa işlev bütünlüğünün ancak üretim fazının sonlarında oluşmasına sebep olmakta. Bu projenin sahibi olan organizasyon için test aşamasını –dolayısıyla kaliteyi- ilgilendiren büyük bir risk oluşturuyor.

Usability Professionals Association – Ankara Chapter

Posted in HCI, Professional, Uncategorized by dnzrn on April 25, 2010

I am glad to inform you that I was lucky enough to be a part of the establishment process of the UPA-Ankara Chapter. Usability is a real hot topic nowadays. Promising so much value to be delivered…

I think The UPA-Ankara Chapter will be very useful for creating an awareness and establishing a body of knowledge in Ankara, capitol of Turkiye, where most of the government organizations and government subcontractors are located. I can’t wait to post about new developments we are going to make.


UPA – International Conference Munich, Germany | May 24-28, 2010

Posted in HCI, Professional by dnzrn on April 25, 2010

I am going to attend the Usability Professionals Association’s International Conference, in Munich, this May. The program content is really exciting. There is still time to register.