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.”