PMI-ACP Study Guide

1. This post was published to Wafi Mohtaseb at 5:43:47 AM 2/27/2012
PMI-ACP Study Guide
Category Agile Project Management ; Project Management ; Scrum
In this Article:
WHY TO APPLY FOR PMI-ACP?
FACTS ABOUT THE PMI-ACP EXAM
WHAT TO READ & WHAT TOPICS TO FOCUS ON?
PMI Agile Certified Practitioner (PMI-ACP)sm is the newest credential offered by PMI. It was
opened for the public at the 31st Jan 2012, the same day I passed the exam. As all of PMI's
certificates, you should fulfill all the requirements in order to apply for the exam; details can be
found here PMI-ACP Handbook
WHY TO APPLY FOR PMI-ACP?
Back to top↑ I can think of lots of reasons why you should apply for PMI-ACP, specially if you
are involved in the software industry, but I will list few of them here:
Offered by PMI, which means it's recognized and respected worldwide.
It's not a methodology specific; it covers more than one Agile methodology (Scrum, XP,
Lean, DSDM, FDD,...).
Agile Project Management practices are booming, and in my opinion they will take over
in the coming few years.
Big Enterprises are adapting Agile Practices, Microsoft for example, check below links
o MSF for Agile Software Development v5.0
o MSF for Scrum
o Visual Studio Scrum 1.0
FACTS ABOUT THE PMI-ACP EXAM:
Back to top↑
Multiple choice questions
120 questions
3 hours duration
Questions Distribution
Content % of Exam
Agile tools & techniques 50%
Agile knowledge and skills 50%
For more details about the exam structure please check the Examination Content Outline on
PMI website. PMI listed 11 books as reference material for the exam; check the Reference

2. Materials on PMI website, it will take a while to read all of them, so I will be summarizing what
you need to read and what you need to focus on.
WHAT TO READ & WHAT TOPICS TO FOCUS ON?
Back to top↑
Agile Methodologies
o Agile in General : Agile Estimating & Planning by Mike Cohn is highly
recommended (I read the entire book), It will give an excellent understanding
to:
 Adaptive planning: Release, Iteration and Daily planning (Progressive
elaboration planning).
 What is velocity, how measure it, and how to use it.
 Agile estimating techniques (relative sizing, planning poker, who does
the estimation).
o SCRUM: Agile Project Management with Scrum by Ken Schwaber is
recommended; INTERNATIONAL SCRUM INSTITUTE website provides a very
good material to start with.
 Understand what is Sprint.
 Understand the Scrum artifacts such as product backlog and burn down
charts; know what they are, why we use them and how to analyze the
charts.
 Understand the Scrum meetings such as Sprint Planning, Daily Scrum,
Sprint Review and Retrospective very well. You should know what
happens in each of these meetings.
 Scrum Roles: Understand the roles and responsibilities of the Scrum
Master & the Product Owner.
o Extreme Programming (XP): Art of Agile Development by James Shore's is
recommended.
 Focus on XP Roles.
 Understanding the below terms:
 Test driven development.
 Continuous Integration.
 Technical debt.
 Refactoring.
 Timeboxing.
 Root-Cause Analysis (the five Whys).
o Lean Methodology:
 Understand the History of Lean and the Lean Software Development
Principles.
 What is Lean Portfolio Management and what is the value of it to the
organization?
 Value Stream Mapping.
 Understand the basics of Kanban.
 What is Work In Progress (WIP)? What's the benefit of limiting the WIP?
 below articles are recommended:

3.  KanbanFor Software Engineering by David Joyce.
 Lean Software Development by Dasari. Ravi Kumar.
 Lean Software Development by Andre van der Schyff.
Agile Risk Management: The Software Project Manager's Bridge to Agility by Michele
Sliger (Chapter 11).
o Risk Burndown Charts: Understand what they are, their overall purpose and
how to analyze them.
o Risk Audit Meeting: What is this about and when does it happen during
iteration?
o Agile Qualitative vs. Quantitative Risk Analysis: How would we compare
o Agile risk analysis to traditional? What is the difference between these two
methods?
Communications Management: The Software Project Manager's Bridge to Agility by
Michele Sliger (Chapter 10).
o Stakeholder Management: Setting clear expectations from the very start with
your stakeholders on what information they need, how and when they should
engage with the team and how frequently (time commitment needed for
success), how do we communicate changes in scope/time/schedule to them,
how do we communicate project risk.
o Planning: Identifying who you need to communicate to (Team members,
Sponsor, Stakeholders) and what you need to communicate to them (Project
and Team Charters, Release Plan, Iteration planning, daily standup, demo and
retrospective meeting dates/location, team velocity, team task board or team
room location, project portal site ..etc)
o Performance Reporting and Visible Information Radiators: Understanding what
information radiators are all about and why we use them, how to leverage their
power even for distributed teams, how we track and report performance
through burn up/burn down charts at the iteration level and at the release level.
How we can analyze the various charts and understand if things are going well
or not and respond quickly to what we're seeing.
o Osmotic Communication: Alistair Cockburn (author of Agile Software
Development - The Cooperative Game) describes this as the information that
flows in the background hearing of teams that are co-located so they pick up
relevant information, as though by osmosis. When someone asks questions then
others can tune in or out and contribute to the conversation. This is an example
of rapid and rich feedback that has high value with little structure. It can help
the team identify and address errors, issues and risks early on the project.
Servant Leadership: Coaching Agile Teams by Lyssa Adkins
o Leaders understand that their role is to empower the team, help them make
their own decisions, help them become self-organizing and not use command
and control to direct them. This is the hardest transition initially for traditional
project managers (and leaders) if they were used to a command and control
style of managing.
o The focus of servant leaders is the growth and empowerment of the people
instead of the management of the tasks. Learn how you can transition to being
the team's coach, mentor and facilitator instead of their problem solver.
Project and Quality Standards:

4. o Quality is collectively owned by the team and no longer the sole responsibility of
the testing team. The testers, analysts and developers all collaborate early on to
define the quality measures for their project.
o Quality planning in Agile happens as part of the team's Release Planning,
Iteration Planning and daily planning activities.
o The team along with the product owner develops their 'Definition of Done' that
provides clear guidance for when a 'story' is done. This could also be defined at
various other levels, for example we could have a 'Release definition of Done'
and a 'Project definition of Done'. The story definition of Done would contain
the product owner's expectations for quality and the team's standards.
Earn Value Management, below articles are recommended:
o Earned Value For Agile Projects by John Rusk.
o Agile EVM by Tamara Sulaiman.
o Earned Value and Agile Reporting by Mike Griffiths.
Business Case Development:
o I think what is needed to understand here is how an Agile business case may
differ from traditional business case development. An Agile Business Case could
still be born during the traditional 'Initiation' phase which may also be referred
to as 'Visioning' or 'Feasibility' in Agile and needs to have 'Just Enough' or 'Barely
Sufficient' analysis as Alistair Cockburn would say.
o An Agile business case may use techniques such as 'Design the Box' for defining
the vision and objectives and should also include very clear conditions of
satisfaction and measures for success (also called Project Level Definition of
Done).
o High level requirements, a high level roadmap along with high level estimates
could be submitted with the knowledge that after execution of a few iterations
these estimates will be continuously updated to reflect the team's new
knowledge and actual velocity.
Innovation Games:
o You should know what innovation games are about (created by Luke Hohmann),
why we use them and know the top ones such as Product Box (used during
visioning) and Buy a Feature (used for prioritizing).
I hope that this article helps you for your exam preparation. Special thanks to Mr. Mohamed
Khalifa Hassan, who helped me in my exam preparation. References: PMI Website